Corso Linux / Creare backup con tar e verificare un ripristino

La compressione riduce la dimensione dei dati; un backup conserva una copia recuperabile di uno stato precedente. Creare un archivio non basta per dimostrare che il backup sia utilizzabile: ripristinalo in una posizione separata e verifica contenuti, metadati e possibilità di usarli con l’applicazione.

In questa lezione ripristini prima una copia manuale in un’altra directory e confronti contenuti e permessi. Automatizza poi la procedura verificata seguendo la lezione sui backup pianificati e controlli indipendenti dello stato (in inglese).

Distinguere compressione, archiviazione, sincronizzazione e backup

Una seconda directory sullo stesso disco può aiutare dopo una sovrascrittura accidentale, ma andare persa insieme al disco. Progetta uno spazio di archiviazione indipendente, copie di più momenti e copie che le credenziali di produzione compromesse non possano modificare immediatamente. Se cifri i backup, custodisci le chiavi separatamente e assicurati che le persone autorizzate al recupero possano ottenerle. La cassaforte della rappresentazione illustrata non significa che tar cifri automaticamente i dati.

Preparare una piccola origine isolata

Esegui la prova con Bash e gli strumenti GNU tar, gzip, coreutils, find e diff in una macchina Linux di laboratorio. Per l’ultima anteprima serve anche rsync. Verifica prima la disponibilità con command -v tar gzip sha256sum diff stat rsync e registra le versioni, per esempio con tar --version. Installa gli strumenti mancanti tramite il gestore della distribuzione, se autorizzato. Conserva lo stesso terminale per usare la variabile lab nei blocchi successivi.

lab=$(mktemp -d "$HOME/linux-backup-lab.XXXXXX") &&
mkdir -p "$lab/source/docs" "$lab/archives" "$lab/restore" &&
printf "version 1\n" > "$lab/source/docs/note.txt" &&
printf "enabled=yes\n" > "$lab/source/settings.conf" &&
chmod 600 "$lab/source/settings.conf" &&
find "$lab/source" -type f -print

La catena di && arresta il blocco se un passaggio fallisce. Controlla l’esito e i percorsi stampati prima di continuare: devono essere dentro la nuova directory temporanea. Origine, archivio e ripristino sono separati; tenere l’archivio fuori dall’origine evita di includere il backup nel backup stesso. Non sostituire questi percorsi con dati di produzione.

La prova tratta file ordinari dell’utente, non verifica proprietà root, elenchi di controllo degli accessi (ACL), attributi estesi o coerenza di database. Su Linux il modo 600 consente lettura e scrittura al proprietario e nessun accesso al gruppo o agli altri utenti. I modi mostrati da Git Bash su Windows non dimostrano gli stessi permessi del file system Linux.

Creare un archivio con percorsi relativi

tar -czf "$lab/archives/source.tar.gz" -C "$lab" source
tar -tzf "$lab/archives/source.tar.gz"
(cd "$lab/archives" && sha256sum source.tar.gz > source.tar.gz.sha256)
(cd "$lab/archives" && sha256sum -c source.tar.gz.sha256)

-c crea l’archivio, -z applica gzip e -f indica il nome dell’archivio. -C cambia la directory di riferimento: i membri sono source/..., non percorsi assoluti. -t elenca il contenuto. Controlla che compaiano source/docs/note.txt e source/settings.conf, oltre alle directory previste, e che la creazione non abbia segnalato errori.

SHA-256 è una funzione di hash che produce un’impronta dei dati; sha256sum -c confronta l’archivio con l’impronta salvata e, se coincide, stampa source.tar.gz: OK. Non continuare al ripristino se il controllo fallisce. L’impronta rileva modifiche rispetto al valore registrato, ma non autentica il backup contro chi può sostituire sia archivio sia file di checksum. Un checksum corretto non dimostra neppure che all’origine fossero presenti tutti i dati necessari.

Ripristinare altrove e confrontare il risultato

tar -xzf "$lab/archives/source.tar.gz" -C "$lab/restore"
diff -r "$lab/source" "$lab/restore/source"
stat -c "%a %n" "$lab/source/settings.conf" "$lab/restore/source/settings.conf"
cat "$lab/restore/source/docs/note.txt"

-x estrae nella directory separata indicata da -C. Verifica il successo di ogni comando prima del successivo: questi quattro comandi non formano una catena di arresto automatico. Se diff non stampa nulla e termina con stato 0, i contenuti esplorati coincidono. Controlla lo stato subito dopo diff con printf 'exit=%s\n' "$?": 1 indica differenze e 2 un problema di confronto. Un confronto fallito non va scambiato per una differenza valida.

Su Linux confronta con stat il modo 600 di settings.conf e verifica che il file recuperato contenga version 1. Diff non controlla proprietà, ACL e attributi estesi: un ripristino di produzione richiede verifiche aggiuntive per i metadati effettivamente necessari e una prova di utilizzo dell’applicazione.

Per osservare il recupero di uno stato precedente, modifica soltanto l’origine con printf 'version 2\n' > "$lab/source/docs/note.txt" e ripeti diff. Questa volta deve mostrare una differenza, mentre cat "$lab/restore/source/docs/note.txt" deve ancora leggere version 1. Ripristina poi la condizione iniziale dell’origine con printf 'version 1\n' > "$lab/source/docs/note.txt" e ripeti il confronto, che deve tornare a stato 0. Mantieni la copia ripristinata separata invece di usarla per sovrascrivere i dati originali.

Trattare con attenzione archivi sconosciuti e servizi attivi

Prima di estrarre un archivio non familiare, esamina l’elenco dei membri e usa una nuova directory isolata con un account senza privilegi amministrativi. Controlla percorsi inattesi, collegamenti simbolici, numero e dimensione dei file. Non estrarlo come root nell’albero del sistema. L’elenco non è una garanzia completa di sicurezza: separa la prova dai sistemi e dai dati importanti.

Archiviare con tar la directory di un database in esecuzione può mescolare stati di file non coerenti. Usa le procedure di backup logico o fisico previste dal database e i relativi requisiti, che possono includere un arresto coordinato o snapshot coerenti. Definisci quanta perdita di dati e quanto tempo di recupero siano accettabili e valutali attraverso un ripristino reale. La riuscita di questo piccolo esempio non verifica il recupero di un database.

Visualizzare le modifiche di rsync prima di applicarle

rsync -av --dry-run "$lab/source/" "$lab/restore/source/"

Con rsync installato, --dry-run simula l’operazione senza applicare modifiche. La barra finale dell’origine indica il contenuto della directory anziché aggiungere un ulteriore livello con il suo nome. -a richiede la modalità archivio, ma non include automaticamente tutti i tipi di metadati, per esempio ACL e attributi estesi. I privilegi e il file system di destinazione possono imporre ulteriori limiti.

L’esempio omette --delete, che può cancellare file presenti soltanto nella destinazione. Verifica entrambi i percorsi e conserva punti di recupero indipendenti prima di applicare una sincronizzazione. Se hai ripristinato version 1 nell’origine, non aspettarti necessariamente una copia del contenuto nell’anteprima; possono comunque essere segnalate differenze di metadati. Rsync normalmente decide se aggiornare un file usando dimensione e data di modifica: non usare la sola anteprima come prova che i contenuti siano identici.

Quando hai finito, controlla il percorso temporaneo e i risultati nel gestore dei file e rimuovi soltanto i dati di questa prova. Le copie nello stesso albero di laboratorio servono a imparare la procedura; non costituiscono uno spazio di backup indipendente dal disco sorgente.

Documentazione ufficiale

• Manuale GNU tar distribuito da Debian.
• Manuale ufficiale di rsync.
• Controlli SHA-256, stati d’uscita di GNU diff e modi dei file con GNU stat.