Come usare tar per fare backup e ripristinare dati su Linux

Backup con tar: quando basta, quando no

tar non è un sistema di backup completo: è un contenitore per file e directory. Proprio per questo è utile in moltissimi casi operativi, perché è rapido, universale e leggibile su quasi ogni distribuzione Linux. Se devi salvare configurazioni, documenti, directory applicative, export di siti statici o dati non transazionali, tar fa il suo lavoro senza introdurre dipendenze strane.

Il punto non è “fare un archivio”, ma costruire una procedura ripetibile: scegliere cosa includere, cosa escludere, come comprimere, dove salvare, come verificare e come ripristinare. Un backup che non sai ripristinare vale poco; un archivio senza controllo di integrità è solo una speranza con estensione .tar.gz.

In pratica, tar è perfetto quando ti serve un backup file-level, veloce da creare e semplice da restaurare. Non sostituisce snapshot, dump applicativi o backup consistenti di database, ma si integra bene con essi. Per i dati transazionali, prima si fa il dump coerente del motore, poi si archivia quel file insieme al resto.

Scelta del formato: tar puro, gzip, bzip2, xz o zstd

Il formato base è .tar: nessuna compressione, massima compatibilità, velocità alta in scrittura e lettura. Se lo spazio conta, si aggiunge un compressore. Oggi le scelte sensate sono tre: gzip per compatibilità e velocità, xz per massima compressione ma tempi più lunghi, zstd quando vuoi un buon equilibrio tra rapporto di compressione e prestazioni.

In ambienti operativi moderni, zstd è spesso la scelta più pratica. Su grossi tree di file riduce i tempi rispetto a xz e, a parità di hardware, può essere più sensato di gzip se vuoi contenere il consumo disco senza rallentare troppo il job. Se però devi aprire l’archivio anche su sistemi vecchi o ridotti all’osso, gzip resta la scelta meno problematica.

Il compressore non cambia il principio del backup: tar legge i file, crea l’archivio e, se richiesto, passa lo stream al compressore. Questo è importante perché puoi anche usare lo standard output e reindirizzare il risultato verso un file, una pipe o una destinazione remota.

Backup base di una directory

Il caso più comune è salvare una directory intera, per esempio un sito web, una home utente o una cartella di configurazione. Il comando più lineare è questo:

tar -czf backup-home-$(date +%F).tar.gz /home/utente

Qui -c crea l’archivio, -z abilita gzip, -f indica il file di output. L’uso di $(date +%F) serve a rendere il nome del backup leggibile e ordinabile. Se stai salvando directory di sistema o dati applicativi, è buona norma lanciare il comando da un percorso neutro, per non includere accidentalmente il contesto corrente.

Se vuoi archiviare una directory mantenendo il path relativo e non quello assoluto, entra nella directory padre e salva il nome della cartella. È la differenza tra avere un archivio ripristinabile in modo pulito e ritrovarti con percorsi annidati in modo scomodo.

cd /home
 tar -czf /backup/home-utente.tar.gz utente

Questo approccio evita problemi quando ripristini in una destinazione diversa. È una piccola abitudine che fa risparmiare tempo al momento del restore.

Escludere file temporanei, cache e dati inutili

Un archivio serio non copia tutto a occhi chiusi. Cache, socket, file temporanei, log ruotati o directory ricostruibili spesso non hanno senso in un backup giornaliero. Tar permette di escludere pattern specifici con --exclude.

tar -czf backup-app.tar.gz \
  --exclude='*.log' \
  --exclude='cache' \
  --exclude='tmp' \
  /var/www/app

Le esclusioni vanno pensate in base all’applicazione, non per abitudine. Per esempio, su un sito PHP potresti voler escludere cache framework, sessioni e file generati, ma non la configurazione né i template. Su un ambiente WordPress, la directory uploads va quasi sempre inclusa, mentre alcune cache plugin possono essere ricostruite e quindi escluse.

Se usi più esclusioni conviene salvarle in un file dedicato, così il comando resta leggibile e la policy di backup è versionabile. Questo è utile soprattutto quando la procedura deve essere eseguita da cron o da un sistema di automazione.

# /etc/backup/excludes.txt
*.log
cache
tmp
*.swp

tar -czf backup-app.tar.gz --exclude-from=/etc/backup/excludes.txt /var/www/app

Mantenere permessi, owner e ACL

Tar preserva di default molti metadati utili, ma il comportamento dipende da come lo usi e da cosa stai archiviando. Se devi ripristinare una directory di sistema o una struttura con permessi delicati, vale la pena controllare che owner, group, mode e ACL vengano trattati correttamente.

Per i backup di dati sensibili o ambienti con permessi estesi, considera l’uso di opzioni che preservano attributi e ACL, se supportate dal tuo scenario. In particolare, se l’applicazione fa uso di ACL POSIX o attributi estesi, un restore “semplice” può non bastare. Il rischio tipico è ripristinare i file ma perdere il contesto di accesso, con errori difficili da capire a posteriori.

Un controllo rapido dopo il backup è confrontare i metadati principali sul file archivio e su una directory campione prima di dichiarare il job valido. Se il backup è pensato per disaster recovery, non fermarti alla dimensione del file.

tar -tvf backup-app.tar.gz | head

Il listing non sostituisce un test di restore, ma ti fa già vedere se l’archivio contiene ciò che ti aspetti e se i percorsi sono coerenti.

Backup incrementali con tar: utili, ma da capire bene

Tar supporta anche backup incrementali tramite snapshot file. È una funzione spesso sottovalutata, perché consente di salvare solo ciò che è cambiato rispetto a uno stato precedente. Questo riduce spazio e tempo, ma introduce complessità operativa: devi conservare il file snapshot e sapere esattamente come vengono generati i livelli.

Un esempio minimale è questo:

tar --listed-incremental=/var/backups/app.snar -czf /var/backups/app-full-or-incr.tar.gz /var/www/app

Il file .snar contiene lo stato della scansione precedente. Se lo perdi, perdi anche la catena logica dell’incrementale. Per questo gli incrementali hanno senso solo se il processo di backup è disciplinato: naming chiaro, retention definita, test di restore periodici e conservazione sicura del file snapshot.

In molti contesti piccoli o medi, un backup completo giornaliero è più semplice e meno rischioso di una catena incrementale costruita male. Lo spazio costa meno del tempo perso durante un ripristino confuso.

Ripristino: prima verifica, poi estrazione

Il restore non inizia con tar -x, ma con una verifica dell’archivio. Prima controlla che il file non sia corrotto e che il contenuto sia quello previsto. Se l’archivio è compresso con gzip, puoi testarlo con il tool di compressione e poi ispezionarlo con tar.

gzip -t backup-app.tar.gz
 tar -tzf backup-app.tar.gz | head

Se il test passa, estrai in una directory di staging, non direttamente in produzione. Questo riduce il rischio di sovrascrivere file sbagliati o di mischiare versioni vecchie e nuove.

mkdir -p /restore/test
 tar -xzf backup-app.tar.gz -C /restore/test

Dopo l’estrazione, confronta struttura e permessi. Se l’archivio contiene path assoluti o percorsi inattesi, fermati prima di fare danni. Un restore ben fatto è un’operazione con checklist, non una scommessa.

Ripristinare solo un file o una sottodirectory

Uno dei vantaggi di tar è che non devi per forza estrarre tutto. Se ti serve solo un file o una sottodirectory, puoi farlo in modo mirato. Questo è utile quando devi recuperare una configurazione cancellata o una singola risorsa sovrascritta per errore.

tar -xzf backup-app.tar.gz etc/nginx/nginx.conf -C /tmp/restore

In questo caso è importante conoscere il path interno all’archivio. Per trovarlo, usa tar -tzf e cerca il nome esatto del file. Se il backup è stato creato con percorsi relativi, il restore selettivo è semplice; se è stato creato con path assoluti, la situazione diventa più fragile e meno portabile.

Un flusso pratico è questo: ispezione del contenuto, estrazione in staging, verifica del file, copia manuale nella posizione finale con backup del file esistente. È più lento di un restore diretto, ma molto più sicuro in ambienti condivisi.

Archiviare database e applicazioni: tar va usato dopo il dump

Per MySQL, MariaDB, PostgreSQL e altri motori transazionali, tar non deve essere usato per copiare direttamente i file live del database, salvo scenari molto specifici e con motore fermo o snapshot coerenti. La strada corretta è generare prima un dump consistente, poi includere quel dump nel backup tar insieme al resto dei file.

mysqldump --single-transaction --routines --events nome_db > /var/backups/nome_db.sql

tar -czf backup-completo.tar.gz /var/backups/nome_db.sql /var/www/app /etc/nginx

Il principio è semplice: prima rendi coerente il dato applicativo, poi archivialo. Lo stesso vale per molte piattaforme CMS o applicazioni custom: file statici con tar, dati dinamici con dump o esportazione dedicata. Mescolare tutto senza criterio porta a backup formalmente completi ma praticamente inutilizzabili.

Permessi, sudo e rischio operativo

Fare backup di configurazioni e dati di sistema richiede spesso privilegi elevati. Qui conviene restare minimali: esegui solo il comando necessario, su percorsi noti, e salva l’archivio in una destinazione controllata. Se lavori con sudo, evita di fare pipe complicate o di scrivere in directory non verificate.

Un errore comune è avviare tar con privilegi root e poi estrarre in una directory sbagliata o troppo ampia. Il blast radius aumenta in fretta se il path è errato. Prima di ogni restore, verifica il contenuto dell’archivio e prepara una directory di staging con permessi chiari.

Se il backup include segreti, chiavi private o file di configurazione con password, tratta l’archivio come un oggetto sensibile. Non lasciare copie sparse su workstation, non inserirlo in repository e non esporlo via web. Se possibile, cifra il backup a livello di storage o di transport, e ruota i segreti se sospetti una esposizione.

Compressione, checksum e verifica di integrità

La verifica non dovrebbe fermarsi alla possibilità di aprire l’archivio. In un contesto serio, conviene generare anche un checksum e conservarlo separatamente. Così puoi accorgerti di una corruzione a riposo o durante il trasferimento.

sha256sum backup-app.tar.gz > backup-app.tar.gz.sha256

Al restore, controlla il checksum prima di estrarre:

sha256sum -c backup-app.tar.gz.sha256

Se il file non torna, non forzare l’estrazione. La causa può essere un trasferimento incompleto, un disco difettoso o un archivio troncato. È meglio scoprire il problema prima del restore che dopo aver sovrascritto dati validi.

Automazione con cron: semplice, ma con log e retention

Tar si presta bene all’automazione. Un job cron può creare backup giornalieri, ma deve scrivere log, gestire retention e fallire in modo visibile. Un backup silenziosamente rotto è peggio di un backup assente, perché ti dà un falso senso di sicurezza.

Uno schema minimo è: esecuzione, verifica del codice di uscita, checksum, pulizia dei backup vecchi, notifica in caso di errore. Se vuoi evitare sorprese, salva l’output standard e l’errore in un log dedicato.

0 2 * * * /usr/local/bin/backup-app.sh >> /var/log/backup-app.log 2>&1

Dentro lo script, usa nomi file coerenti e aggiungi una retention esplicita. Per esempio, tieni sette backup giornalieri e quattro settimanali, oppure adotta una policy che sia compatibile con il tuo RPO. Il punto non è accumulare file, ma avere una storia utile da cui ripartire.

Restore test: il passo che separa un backup reale da uno teorico

Il test più importante non è la creazione dell’archivio, ma il ripristino su un ambiente di prova. Prendi un backup reale, estrailo in una directory vuota e confronta il risultato con la struttura attesa. Se l’applicazione ha dipendenze esterne, prova almeno l’avvio dei servizi o l’apertura dei file principali.

Un controllo utile è verificare che il restore non alteri proprietario, permessi e path. Se l’archivio contiene file critici come configurazioni web o script di deploy, un restore parziale può bastare a dimostrare che la procedura funziona. Per i sistemi più delicati, invece, serve un test più completo e ripetibile.

In pratica, un backup sano produce tre evidenze: archivio leggibile, checksum valido, restore in staging coerente. Se una di queste manca, la procedura va corretta prima di considerarla affidabile.

Errori tipici da evitare

Il primo errore è includere percorsi assoluti senza pensarci. Il secondo è salvare tutto, compresi log giganti e cache ricostruibili, e poi lamentarsi della dimensione dell’archivio. Il terzo è non testare mai il restore. Il quarto è trattare tar come se fosse un backup transazionale per database o applicazioni stateful complesse.

Un altro errore frequente è l’uso di comandi scritti in fretta e mai revisionati. Un backup deve essere leggibile anche da chi lo eredita. Se il tuo script non dice chiaramente cosa salva, cosa esclude, dove scrive e come verifica, prima o poi ti crea un problema operativo.

Infine, non dimenticare la sicurezza del file archivio. Dentro un tar possono finire chiavi SSH, certificati, file .env, credenziali e configurazioni di servizi. Se il backup viene copiato altrove, devi sapere chi può leggerlo e per quanto tempo resta conservato.

Flusso operativo consigliato

Se vuoi una procedura pulita e ripetibile, usa questo schema:

1. Identifica i dati da salvare: file, configurazioni, dump applicativi, esclusioni.
2. Crea il backup con tar usando percorsi relativi quando possibile.
3. Genera checksum separato.
4. Verifica archivio e checksum.
5. Copi il backup su storage affidabile o off-site.
6. Prova il restore in staging.
7. Documenta cosa è stato incluso e cosa no.

Questa sequenza vale più di un singolo comando ben riuscito. Ti impedisce di confondere “archivio creato” con “backup utilizzabile”.

Esempio pratico: backup di un sito web Linux

Supponiamo di dover salvare un sito con file web in /var/www/sito, configurazione Nginx in /etc/nginx e dump MySQL in /var/backups/db.sql. Una procedura ragionevole potrebbe essere questa:

mkdir -p /var/backups/site
mysqldump --single-transaction nome_db > /var/backups/db.sql
cd /
tar -czf /var/backups/site/site-$(date +%F).tar.gz \
  var/www/sito \
  etc/nginx \
  var/backups/db.sql

Subito dopo, calcola il checksum e conserva entrambi i file. Se vuoi essere più ordinato, separa i backup dei dati applicativi da quelli della configurazione di sistema. In caso di ripristino parziale, avere archivi distinti semplifica la vita.

Per il restore, estrai in staging, controlla i percorsi interni e ripristina prima i file, poi la configurazione, infine il database. Questo ordine evita di avviare servizi con una base incompleta.

Conclusione operativa: tar funziona se il processo è disciplinato

Tar è uno strumento essenziale proprio perché non fa magia. Ti obbliga a decidere cosa salvare, come conservarlo e come ripristinarlo. Se lo usi con criterio, diventa una base solida per backup di file system, configurazioni e dati esportati. Se lo usi come scorciatoia indiscriminata, produce archivi grandi ma poco affidabili.

La regola pratica è semplice: backup coerente, esclusioni ragionate, checksum separato, restore testato. Il resto è solo sintassi.