Cosa fare se il backup è danneggiato

Sheet happens. Nella lezione precedente abbiamo anche visto il processo passo-passo per il ripristino completo del database dopo un crash. Però la realtà ama sorprendere. Cosa fare se il tuo backup risulta danneggiato? È arrivato il momento di capirlo insieme.

Dove è meglio mettere il curriculum?

Scherzo. Ora vediamo le questioni tecniche. Ma ricorda che in ogni scherzo c'è solo una parte di scherzo :)

Analisi del danno al backup

Backup danneggiato — è come il file della tua tesi che non si apre proprio prima della consegna. I sintomi sono simili:

• Errori durante il tentativo di ripristino: quando lanci pg_restore puoi vedere errori tipo:

  pg_restore: [archiver] input file does not appear to be a valid archive

• Parte dei dati manca oppure il file ha una dimensione strana (tipo improvvisamente piccolo o pari a zero).
• Il file SQL estratto contiene dati troncati, caratteri strani o sezioni vuote.

I danni ai backup possono succedere per tanti motivi:

• Interruzione del processo di backup (tipo blackout o spegnimento del sistema).
• Trasferimento errato del file (errori durante la copia su una chiavetta o via rete).
• Problemi hardware (dischi, RAM, crash di un array RAID).
• Errori nella configurazione del sistema o dell'utility di backup.
• Virus, malware e ovviamente il classico "click sbagliato".

Recupero dati da un backup danneggiato

Se il file è danneggiato, non è la fine del mondo. A volte si riesce comunque a recuperare qualcosa. Vediamo qualche approccio.

Provare il ripristino con pg_restore

Se il file è stato creato con pg_dump in formato custom o directory, prova a ripristinare con il comando pg_restore usando il flag --ignore-errors. Esempio:

pg_restore --dbname=your_database --ignore-errors backup_file.dump

Questo flag dice all'utility di ignorare gli errori durante il ripristino e andare avanti. Ovviamente i dati nelle parti danneggiate andranno persi, ma almeno una parte delle info potrebbe essere recuperata.

Se funziona, controlla bene i dati ripristinati alla fine e annota cosa manca.

Uso di dati parziali

Supponiamo che tu abbia un backup in formato testo SQL. Prova ad aprirlo con un editor di testo (meglio se avanzato, tipo Visual Studio Code o Notepad++) per vedere dove si interrompe. Se il file è leggibile e la maggior parte delle query SQL è ok:

1. Taglia via la parte danneggiata del file.
2. Esegui le query SQL rimaste a mano o con il comando psql:

psql -U username -d database_name -f partial_backup.sql

Lettura di un file in formato custom

Se il tuo backup è in formato custom, puoi provare a estrarre il contenuto a pezzi:

pg_restore --list backup_file.dump > file_list.txt

Questo comando crea la lista di tutti gli oggetti nel backup. Poi puoi provare a ripristinare solo alcuni elementi (tipo tabelle o schemi) con:

pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump

Editando file_list.txt, puoi escludere gli elementi danneggiati dal ripristino.

Ripristino tramite log di archivio (WAL)

Se usi backup incrementali o differenziali (tipo con pg_basebackup), probabilmente hai i log di archivio (file WAL). Questi tengono traccia di tutte le modifiche dal backup precedente. Per recuperare i dati puoi:

1. Trovare l'ultimo backup integro (tipo un backup completo).
2. Dire a PostgreSQL dove sono i file WAL:

   restore_command = 'cp /path/to/wal_directory/%f %p'

3. Eseguire il ripristino.

Uso di strumenti di terze parti

A volte i danni ai backup si possono ridurre con utility di recupero file. Uno strumento popolare è ddrescue. Esempio:

ddrescue --force backup_file.dump recovered_dump.file

Questo tool proverà a recuperare più dati possibile e creare una nuova copia del file.

Prevenire danni ai backup

Sì, lavorare con file danneggiati è stressante. Vediamo come evitare queste situazioni.

Conservare copie in posti diversi

Come in ogni progetto, il backup segue sempre la regola "non mettere tutte le uova nello stesso paniere". Vale la pena duplicare i tuoi backup:

• Su un server locale.
• Nel cloud (Amazon S3, Google Cloud Storage o anche un servizio semplice tipo Dropbox).
• Su dispositivi esterni (se vuoi essere super-sicuro).

Verifica regolare dell'integrità dei backup

C'è un detto nel mondo IT: "Un backup che non è stato testato, non è un backup". Controlla regolarmente i tuoi backup facendo un ripristino di prova. Per farlo:

1. Carica il backup su un server di test.
2. Ripristina i dati da lì.
3. Controlla che siano corretti.

Uso di checksum

Quando crei i backup, genera anche i checksum dei file (tipo con MD5 o SHA256):

md5sum backup_file.dump > backup_file.md5

Quando ripristini i dati, confronta il checksum attuale con quello originale:

md5sum -c backup_file.md5

Così saprai subito se il file è danneggiato.

Esempi di recupero da backup danneggiati

Vediamo un paio di casi reali.

Case 1. Errore nel trasferimento del file

Stai trasferendo un backup via FTP, ma noti che il file è più piccolo del previsto. Hai usato pg_dump in formato testo, quindi:

1. Hai aperto il file nell'editor.
2. Hai tagliato la parte danneggiata dei dati.
3. Hai ripristinato la parte funzionante con psql.

Case 2. Perdita parziale di dati nei WAL

Il tuo server usava backup incrementali e file WAL di archivio. Improvvisamente alcuni file sono spariti. Però sei riuscito a recuperare i dati con pg_basebackup e i file WAL rimasti, indicando il loro percorso nelle impostazioni di ripristino.

Ricorda che il backup non è solo fare copie, ma anche testarle. Non aspettare l'apocalisse per scoprire che i tuoi backup sono inutili. E se il backup si danneggia, niente panico: PostgreSQL offre tanti modi per recuperare i tuoi dati. L'importante è agire in fretta e con attenzione!

E se proprio niente funziona — rileggi il primo punto di questa lezione.