Quand la sauvegarde est cassée elle aussi

C'est la pire heure du métier, et on en réchappe plus souvent qu'il n'y paraît. Travaillez de la copie la plus récente en remontant, et n'écrasez rien pendant vos essais.

D'abord : ne touchez pas à l'original

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

Chaque tentative de récupération ci-dessous est destructrice quelque part. Travaillez toujours sur une copie, ainsi un essai raté ne coûte rien.

Si gzip refuse

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 tronqué décompresse quand même tout jusqu'au point d'endommagement. Sur une archive rangée par ordre alphabétique, c'est souvent la plus grande partie du site.

Si un fichier SQL refuse de s'importer

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 poursuit au-delà d'une instruction cassée. Un fichier coupé au milieu d'une table restaure toutes les tables qui la précèdent, et c'est souvent celle qu'il vous fallait.

Cherchez ensuite d'autres copies

• Les instantanés de l'hébergeur, distincts des vôtres.
• Un serveur de préproduction, qui est une copie un peu plus ancienne de la production.
• L'ordinateur d'un développeur, avec un export récent dessus.
• Les exports de l'application elle-même — un CSV de commandes vaut mieux que rien.

Ensuite, pour que cela n'arrive pas deux fois