Backup del server: la regola 3-2-1 e come ripristinare

La regola 3-2-1 dice: tieni tre copie dei dati importanti (l'originale e due backup), su due tipi diversi di supporto, con almeno una copia conservata altrove. Su un VPS significa avere almeno una copia fuori dal server, oltre ai dati sul server stesso.

La stessa regola è consigliata nel documento Data Backup Options, preparato per US-CERT e pubblicato sul sito della CISA. Lo scopo è evitare che un singolo guasto, errore o attacco possa distruggere tutte le copie insieme.

Backup, snapshot e ridondanza dei dischi non sono la stessa cosa

• Backup: una copia separata dei tuoi dati, di solito con le versioni precedenti. Riporta indietro un file cancellato o danneggiato per errore.
• Snapshot: registra lo stato del server in quel momento. Va bene per tornare indietro in fretta prima di un aggiornamento importante. Ma dipende dal disco originale, quindi non sostituisce un backup.
• Ridondanza dei dischi: gli stessi dati scritti su due dischi contemporaneamente. Ti protegge quando un disco si guasta. Un file che cancelli viene cancellato da entrambi i dischi, e i dati cifrati da un ransomware sono cifrati su entrambi. Quindi non è un backup.

Come applicare il 3-2-1 su un VPS

Puoi contare il backup giornaliero del pannello come una delle tue copie. Ma la copia che soddisfa la condizione "altrove" è quella che configuri e controlli tu. Anche i termini di servizio di Seturack ti chiedono di conservare a parte una copia dei dati importanti.

Cosa salvare

Copiare i file di un database in esecuzione può dare un backup incoerente. Fai prima un dump. Questi comandi vengono eseguiti come root, come in uno script cron:

mysqldump --single-transaction --all-databases | gzip > /var/backups/mysql-$(date +%F).sql.gz

sudo -u postgres pg_dumpall | gzip > /var/backups/pg-$(date +%F).sql.gz

Per i file basta questo: /etc, i file del tuo sito, la cartella dati della tua applicazione, i volumi Docker se usi Docker e i file .env. Non salvare ciò che puoi scaricare di nuovo, come pacchetti e immagini Docker. Se la tua applicazione ha una chiave di cifratura, conservala a parte. Per alcune applicazioni un backup senza la chiave è inutile.

La frequenza dei backup dipende da quanti dati puoi permetterti di perdere. Un backup al giorno significa perdere al massimo un giorno di dati. Per un'applicazione che registra ordini o pagamenti è più sicuro fare il dump del database ogni ora e mandarlo fuori dal server.

Un backup fuori dal server con restic

restic è uno strumento di backup open source che cifra i backup e memorizza una sola volta i dati ripetuti. L'esempio qui sotto scrive il backup su un altro server raggiunto via SFTP. La destinazione deve avere l'accesso SSH senza password (con chiave), perché un backup automatico non può rispondere a una richiesta di password. Crea il file della password (/root/.restic-password) con un editor di testo ed esegui chmod 600 su di esso.

sudo apt install -y restic

export RESTIC_REPOSITORY=sftp:[email protected]:/backups/vps

export RESTIC_PASSWORD_FILE=/root/.restic-password

restic init

restic backup /etc /var/www /var/backups

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

La documentazione di restic avverte che se perdi la password i tuoi dati sono persi per sempre. Conserva la password anche in un gestore di password. Metti le due righe export, i dump dei database, restic backup e restic forget in uno script come /usr/local/bin/backup.sh, in quest'ordine, e rendilo eseguibile con chmod +x. Non dimenticare di aggiungere in fondo una riga che elimina i vecchi dump, find /var/backups -name '*.sql.gz' -mtime +2 -delete, altrimenti i file di dump riempiranno il disco. Poi esegui lo script ogni notte, per esempio da /etc/cron.d/backup con questa riga:

30 3 * * * root /usr/local/bin/backup.sh

borg è uno strumento simile. Per le semplici copie di file puoi usare rsync, e per inviare dati a un object storage puoi usare rclone.

La vera prova: il ripristino

Un backup che non riesci a ripristinare non vale nulla. Provalo subito dopo la configurazione e poi a intervalli regolari:

• Con restic, estrai l'ultimo backup in una cartella vuota e controlla i file: restic restore latest --target /tmp/restore-test
• Carica un dump del database in un database temporaneo e guarda le tabelle.
• Nel pannello, fai clic sull'icona Recupera file da qui accanto a un backup, sfoglia al suo interno e scarica un file. Un ripristino completo sostituisce tutto il disco attuale, quindi recuperare un singolo file è il modo più sicuro per provare.

Scegli per quanto tempo conservare i backup in base a quanto tardi potresti accorgerti di un problema. Il backup del pannello conserva gli ultimi 7 giorni e non si può tornare più indietro. Se potresti aver bisogno di versioni più vecchie, conserva versioni settimanali e mensili nella tua copia. Per i dettagli sul backup del pannello, leggi l'articolo sui backup giornalieri.

Errori comuni

• Scrivere il backup sul disco dello stesso server. Se il disco si riempie o il server va perso, il backup se ne va con lui.
• Tenere la password o la chiave del backup nello stesso posto del backup.
• Non accorgersi che lo script fallisce. Aggiungi una notifica allo script oppure controlla ogni tanto la data dell'ultimo backup con restic snapshots.
• Non controllare quanto si riempie la destinazione del backup. Una destinazione piena significa backup che falliscono in silenzio.