È l'ora peggiore del mestiere, e se ne esce più spesso di quanto sembri. Lavora dalla copia più recente andando all'indietro, e mentre provi non sovrascrivere nulla.

Prima cosa: non toccare l'originale

cp backup.tar.gz /srv/work/backup-copy.tar.gz

Ogni tentativo di recupero qui sotto è distruttivo da qualche parte. Lavora sempre su una copia, così un tentativo fallito non costa niente.

Se gzip si rifiuta

gzip -t backup.tar.gz                 # what is wrong
zcat backup.tar.gz > partial.tar 2>/dev/null || true
tar -xf partial.tar --ignore-zeros --warning=no-timestamp

Un gzip troncato decomprime comunque tutto fino al punto del danno. Su un archivio ordinato alfabeticamente quello è spesso gran parte del sito.

Se un dump SQL non si importa

zcat db.sql.gz | head -50            # is the header there
zcat db.sql.gz | tail -5            # does it end with "Dump completed"

# import ignoring the failures, then see what arrived
zcat db.sql.gz | mysql --force restore_test
mysql restore_test -e "SHOW TABLES"

--force tira avanti oltre un'istruzione rotta. Un dump troncato a metà di una tabella ripristina tutte le tabelle che la precedono, e spesso è proprio quella che ti serviva.

Poi cerca altre copie

  • Le istantanee del fornitore, che sono separate dalle tue.
  • Un server di prova, cioè una copia leggermente più vecchia della produzione.
  • Il portatile di uno sviluppatore con sopra un dump recente.
  • Le esportazioni dell'applicazione stessa: un CSV degli ordini vale più di niente.

Dopo, perché non accada una seconda volta

Un backup o è verificato, o è una speranza. Prova l'archivio a ogni esecuzione e ripristinane uno con regolarità — vedi Provare un ripristino e Leggere il registro di un backup fallito. E tienine più di uno, in più di un posto: Perché un solo backup non è un backup.