Un piano di backup per il Suo server

Modulo 8: Backup e monitoraggio · Tempo di lettura: 11 minuti

Obiettivo della lezione: Al termine di questa lezione sarà in grado di creare un piano di backup per il Suo server: che cosa conservare, dove, con quale frequenza e per quanto tempo, e come avere la certezza che il ripristino funzioni.

Concetti chiave: regola 3-2-1, snapshot, backup del provider, backup proprio fuori dal provider, RPO, RTO, dump del database (mariadb-dump, pg_dump), configurazione in /etc, volumi Docker, crittografia, ransomware, append-only, test di ripristino

Perché un piano, e non "tanto un backup c'è"?

Quasi tutti coloro che hanno perso un server pensavano di avere un backup. Poi si scopre che conteneva solo il sistema operativo e non il database, oppure che si trovava sullo stesso server ormai perso, oppure che è stato cifrato dallo stesso ransomware, oppure che nessuno conosce la password. Un backup vale qualcosa solo se è possibile ripristinarlo. Per questo si inizia con un piano e si finisce con un test.

Un piano risponde a cinque domande:

1. Che cosa deve poter essere ripristinato?
2. Quanti dati può permettersi di perdere? (RPO)
3. Quanto velocemente deve tornare a funzionare? (RTO)
4. Dove si trovano le copie, e quante sono?
5. Come sa che funziona?

Che cosa deve poter essere ripristinato?

Un server è composto da livelli. Non tutti i livelli devono finire nel backup:

Presti particolare attenzione ai database. Un database in esecuzione scrive continuamente. Se copia i file di un MariaDB o PostgreSQL in esecuzione, può ottenere una copia danneggiata. Per questo crei prima un dump: un'istantanea coerente sotto forma di file, che poi include nel backup.

root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz

(mariadb-dump in passato si chiamava mysqldump; di solito anche quel comando funziona ancora.) Se il database gira in un container, fa la stessa cosa con docker compose exec (lezione 9.4).

RPO e RTO: quanto può permettersi di perdere?

Due concetti della pratica professionale aiutano a fare delle scelte:

• RPO (recovery point objective): quanto tempo di dati può perdere al massimo? Un backup giornaliero alle 03:00 significa che, se il server va in crash alle 22:00, perde quasi un giorno. Per un negozio online con ordini è troppo; per un blog che cambia una volta a settimana va benissimo.
• RTO (recovery time objective): quanto tempo può passare prima che tutto torni a funzionare? Ripristinare un backup completo del provider può richiedere pochi minuti; ricostruire un nuovo server e ripristinare tutto a mano può richiedere ore.

Li annoti per il Suo server. Determinano con quale frequenza esegue un backup e come lo conserva.

Snapshot, backup del provider, backup proprio

Su un VPS ha in genere tre tipi di rete di sicurezza. Si somigliano, ma proteggono da cose diverse.

1. Lo snapshot. Un'istantanea dell'intero disco virtuale, creata nel pannello del Suo provider. Si crea in fretta e si ripristina in fretta. Ideale subito prima di un upgrade (lezione 4.3). Però: presso la maggior parte dei provider uno snapshot si trova sullo stesso storage del Suo server. Se quello storage si guasta, o se perde il Suo account, anche lo snapshot è perso. E uno snapshot non si conserva a lungo: cresce con tutte le modifiche successive. Uno snapshot non è un backup.

2. Il backup del provider. Molti provider creano (eventualmente come opzione) ogni giorno automaticamente una copia dell'intero server, su un altro storage. Presso WebOké, per esempio, si tratta di un backup giornaliero dell'intero VPS conservato per sette giorni; presso altri provider funziona in modo simile, con tempi propri. È un buon secondo livello contro hardware guasto e contro i Suoi errori di ieri. Ma resta un'unica parte: il Suo account, il Suo pagamento, un loro guasto. E il ripristino avviene di solito per l'intero server in una volta.

3. Il Suo backup, fuori dal provider. Una copia dei Suoi dati presso un'altra parte o in un altro luogo, che Lei crea e gestisce (lezione 8.2). È il livello che rimane quando tutto il resto va storto.

La regola 3-2-1

Una regola pratica diffusa:

• 3 copie dei Suoi dati (l'originale più due backup);
• su 2 tipi diversi di storage o di sistemi;
• di cui 1 in un altro luogo.

Per un VPS può essere: i dati sul server, il backup giornaliero del provider e un Suo backup cifrato con restic verso uno storage presso un'altra parte. Un'integrazione moderna è che almeno una copia non possa essere cancellata da chi prende il controllo del server (offline, oppure append-only, lezione 8.2). Il ransomware su un server cerca attivamente i backup per cifrarli o cancellarli a loro volta. Un backup che il server stesso può cancellare non offre alcuna protezione contro questo.

La crittografia e la password del Suo backup

Un backup presso un'altra parte deve essere cifrato: contiene dati dei clienti, password e chiavi. restic (lezione 8.2) cifra per impostazione predefinita. Ma così nasce un nuovo rischio: la password del Suo backup. Se la perde, il backup diventa inutilizzabile. E lo stesso vale se si trova solo sul server che ha perso.

Conservi quindi la password anche fuori dal server: nel Suo gestore di password ed eventualmente su carta in una cassaforte. Lo stesso vale per le credenziali di accesso allo storage in cui si trova il Suo backup.

Testare il ripristino

La parte più importante del piano. Un test di ripristino significa: ripristina davvero un backup, in un luogo dove non può danneggiare nulla, e verifica che il risultato funzioni.

• In piccolo e spesso: ripristinare un singolo file o una singola cartella in /tmp/terug e confrontare (diff). Per esempio una volta al mese.
• In grande e di tanto in tanto: costruire un server di prova completamente nuovo a partire dal backup, importare il database, avviare il sito web. Per esempio una volta all'anno, o a ogni modifica importante. È anche l'esercitazione per quando le cose vanno davvero male (lezione 10.3).

Annoti quanto tempo ha richiesto: quello è il Suo RTO reale.

Tempi di conservazione

Non conservi solo l'ultimo backup. Se si accorge solo dopo due settimane che un file è danneggiato o è stato cancellato, Le serve un backup di tre settimane prima. Uno schema diffuso: sette versioni giornaliere, quattro settimanali e sei mensili. restic lo gestisce con forget (lezione 8.2). Pensi anche al GDPR: i dati personali non si conservano più a lungo del necessario, nemmeno nei backup. Metta per iscritto i Suoi tempi di conservazione.

In pratica

Usi lo snapshot del Suo provider subito prima di modifiche rischiose e lo elimini dopo; lasci attivo il backup giornaliero del provider, se disponibile; e crei inoltre un Suo backup cifrato dei dati e della configurazione verso un'altra parte. Presso WebOké, nella schermata del VPS, questo si chiama Snapshots e Backups; presso altri provider i nomi e i tempi sono diversi, ma il principio è lo stesso. Un pacchetto di hosting o un servizio gestito prevede spesso accordi diversi: verifichi che cosa è previsto nel Suo caso.

Riepilogo

• Un backup vale qualcosa solo se il ripristino funziona; si inizia con un piano e si finisce con un test.
• Esegua il backup soprattutto di dati e configurazione: database come dump, /etc, siti web, volumi Docker, file compose.
• Stabilisca l'RPO (quanto può perdere) e l'RTO (quanto velocemente deve funzionare).
• Snapshot (stesso storage, breve durata), backup del provider (altro storage, stessa parte) e un backup proprio fuori dal provider sono tre livelli diversi; segua la regola 3-2-1 con almeno una copia che il server stesso non può cancellare.
• Cifri, conservi la password del backup fuori dal server e testi il ripristino in piccolo e spesso, in grande di tanto in tanto.

Quiz

Esercizio

Esercizio O8.1: Il Suo piano di backup. Crei per il Suo server un piano di backup su una sola pagina: che cosa deve poter essere ripristinato (per livello), il Suo RPO e RTO, quali copie possiede (snapshot, provider, proprie) e dove, i Suoi tempi di conservazione, dove si trova la password del backup e quando esegue un test di ripristino. Compili il modulo; dopo l'invio vedrà un piano di esempio da confrontare con il Suo.

Per approfondire

• Snapshot e backup del suo VPS
• Strategia di backup: la regola del 3-2-1 per la Sua azienda
• Come faccio il backup del mio database MySQL?
• Nel corso Sicuri online: le lezioni sulla regola 3-2-1 e sui backup che sopravvivono al ransomware.
• MariaDB, mariadb-dump: https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
• PostgreSQL, Backup and Restore (SQL Dump): https://www.postgresql.org/docs/current/backup-dump.html