Migrare da un server di posta Jessie ad uno Stretch

Upgrade o re-installazione?

Io consiglio di configurare un nuovo server e di assicurarsi che funzioni correttamente prima di cominciare a migrare gli utenti esistenti. Si potrebbe obiettare che Debian può essere aggiornata facilmente usando “apt-get dist-upgrade” ma questo è molto pericoloso da fare su un server online. Le modifiche automatiche delle configurazioni possono avere effetti dannosi e voi potete perdere mail. Come minimo causerete un lungo downtime per i vostri utenti.

Se volete seguire il mio consiglio allora procuratevi un nuovo server ed installateci Debian. Appena gli utenti vengono migrati correttamente e tutto funziona bene potete spegnere il vecchio server.

Comunque se siete molto coraggiosi potete provare un upgrade al volo. I cambiamenti da Jessie a Stretch fortunatamente non sono così fondamentali. Solo rspamd.

Leggi prima di scrivere

Seguite questa guida fino alla fine. Solo allora cominciate la migrazione. Informate i vostri utenti della migrazione e stabilite un orario quando intendete spostare gli account email sul nuovo server. Il cambiamento richiede una modifica ai DNS che necessita di tempo per essere visibile a livello mondiale, quindi ci sarà un periodo in cui le mail in entrata dei vostri utenti saranno ritardate. Tuttavia se procedete correttamente non una singola mail verrà persa.

Quindi avete il vostro nuovo server Stretch operativo? Ok, allora cominciamo a…

Preparare il record DNS

Il record DNS “MX” del vostro dominio contiene il nome del vostro server di posta. Quando passate al nuovo server dovete o cambiare il record MX (se il nuovo server ha un hostname diverso) oppure il record A che punti all’attuale server di posta. Ogni record DNS ha un TTL (time to live) che definisce il tempo per il quale il record rimane valido anche dopo che lo modificate. Normalmente questo TTL è abbastanza alto, tipo 86400 secondi (= 1 giorno). Diminuitelo temporaneamente a 60 secondi in modo che il resto di internet recepisca la vostra modifica più in fretta.

Migrare il database

Dovete copiare il database che contiene i dati dei vostri domini e account di posta. Accedete al vecchio server (Jessie) come root e fate il backup del database mailserver. Semplicemente date

mysqldump mailserver > mailserver.sql

Copiate questo file sul nuovo server (usando scp) ed importatelo:

mysql mailserver < mailserver.sql

Ovviamente qualsiasi modifica nel vecchio server dovrà essere eseguita anche nel nuovo server.

Migrare le mail “a caldo”

Fortunatamente Dovecot usa il formato maildir che salva le mail come semplici file su disco. Loggatevi sul nuovo server (Stretch) ed usate rsync per copiare le mail dal vecchio server di posta (Jessie):

rsync -va jessieserver:/var/vmail/ /var/vmail/

(Notare le barre finali. Digitatele esattamente come mostrato sopra altrimenti i vostri file finiranno in posti sbagliati.)

Non c’è bisogno di chiudere Dovecot nel vecchio server di produzione Jessie. Copiare i file mentre Dovecot è in esecuzione non creerà problemi. Questo è chiamato copia “a caldo”. Può creare dei disallineamenti ma farà risparmiare tempo nella fase finale di sincronizzazione.

Downtime

Avete avvisato i vostri utenti del downtime, giusto? Il momento è arrivato? Ok. Chiudete Dovecot in entrambi i server.

Migrare le mail “a freddo”

Sincronizziamo di nuovo. rsync copierà solo i file modificati risultando molto più veloce della prima sincronizzazione. Nel nuovo server lanciate:

rsync -va --delete jessieserver:/var/vmail/ /var/vmail/

(l’opzione “–delete” fa in modo che i file rimossi dal vecchio server vengano cancellati anche nel nuovo server.)

Modificare i record DNS

Per ogni vostro dominio dovete far puntare i record DNS “MX” e “A” al nuovo server.

Abilitare il soft_bounce

Incidenti possono capitare. E voi non volete perdere mail. Lanciate questo comando per abilitare la vostra “rete di sicurezza” sul nuovo server:

postconf soft_bounce=yes

Ora Postfix terrà nella sua coda anche mail che normalmente rifiuterebbe. Avviate Postfix e Dovecot nel nuovo server. Controllate /var/log/mail.log e lanciate “mailq” di tanto in tanto per vedere quali mail rimangono bloccate in coda. Se siete sicuri che queste mail possono essere rimosse, lanciate “postsuper -d QUEUE-ID” (come mostrato dall’output di “mailq”).
Quando siete sicuri che le mail vengono ricevute e inviate correttamente, potete togliere la modalità soft_bounce:

postconf soft_bounce=no

Spegnete il vecchio server

Se possibile fate un backup finale del vecchio server. Se gli utenti non si lamentano allora rimuovete il vecchio sistema dopo una settimana.