Procédure de restauration de sauvegarde… Surprise !

Depuis plusieurs mois donc, mes services auto-hébergés sont sauvegardés quotidiennement de façon automatique et incrémentale. Je suis en théorie protégé contre la perte de mes données en cas de panne matérielle du support de stockage de mon serveur. Ça, c’est la théorie, il me restait en l’occurrence à valider le processus de sauvegarde en m’assurant de la façon de restaurer les données.

J’ai donc commencé ces derniers jours l’écriture d’un script ansible permettant de redéployer automatiquement l’ensemble de mes services sur un nouveau serveur si besoin. L’occasion rêvée de vérifier que la restauration de sauvegarde fonctionne correctement.

Après configuration de duplicity sur la nouvelle machine, je tente donc de restaurer un fichier pris au hasard:

duplicity restore --file-to-restore path/to/wallabag/vendor/jdorn/sql-formatter/LICENSE.txt -t now cf+hubic:// test/LICENSE-restored.txt

J’obtiens une erreur dès les premières tentatives : No backup chains found, et lis au détour d’une page web qu’il faut à priori effectuer un list-current-files au préalable. Il faudra que je vérifie cette information lors du test réel de mon script sur un système vierge. Je découvre donc que duplicity récupère dans un premier temps tous les fichiers manifest. La récupération des fichiers se poursuit, et c’est le drame :

Giving up after 1 attempts. NoSuchObject: Object 'duplicity-inc.20180212T113006Z.to.20180213T113007Z.manifest.gpg' doesn't exist (HTTP 404)

L’un des fichiers n’est pas renvoyé par hubiC. Il est néanmoins visible dans l’interface, mais impossible de le récupérer, la requête effectuée par l’interface web retourne elle aussi une mauvaise erreur 404. Ce problème de manifeste manquant concerne une chaîne secondaire, mais impacte malheureusement l’ensemble de la collection. Impossible de restaurer les données via duplicity…

Last full backup date: Tue Mar 6 22:30:07 2018
Collection Status
-----------------
[...]

Found 3 secondary backup chains.
Secondary chain 1 of 3:
-------------------------
[...]
-------------------------

Secondary chain 2 of 3:
-------------------------
[...]
-------------------------

Secondary chain 3 of 3:
-------------------------
Chain start time: Mon Feb 12 22:30:06 2018
Chain end time: Mon Mar 5 22:30:07 2018
Number of contained backup sets: 22
Total number of contained volumes: 24
 Type of backup set: Time: Num volumes:
 Full Mon Feb 12 22:30:06 2018 3
 Incremental Tue Feb 13 22:30:07 2018 1
 Incremental Wed Feb 14 22:30:07 2018 1
 Incremental Thu Feb 15 22:30:08 2018 1
 Incremental Fri Feb 16 22:30:07 2018 1
 Incremental Sat Feb 17 22:30:08 2018 1
 Incremental Sun Feb 18 22:30:07 2018 1
 Incremental Mon Feb 19 22:30:07 2018 1
 Incremental Tue Feb 20 22:30:08 2018 1
 Incremental Wed Feb 21 22:30:07 2018 1
 Incremental Thu Feb 22 22:30:07 2018 1
 Incremental Fri Feb 23 22:30:08 2018 1
 Incremental Sat Feb 24 22:30:06 2018 1
 Incremental Sun Feb 25 22:30:05 2018 1
 Incremental Mon Feb 26 22:30:07 2018 1
 Incremental Tue Feb 27 22:30:07 2018 1
 Incremental Wed Feb 28 22:30:08 2018 1
 Incremental Thu Mar 1 22:30:07 2018 1
 Incremental Fri Mar 2 22:30:09 2018 1
 Incremental Sat Mar 3 22:30:07 2018 1
 Incremental Sun Mar 4 22:30:06 2018 1
 Incremental Mon Mar 5 22:30:07 2018 1
-------------------------


Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Tue Mar 6 22:30:07 2018
Chain end time: Tue Mar 20 22:30:09 2018
Number of contained backup sets: 13
Total number of contained volumes: 17
 Type of backup set: Time: Num volumes:
 Full Tue Mar 6 22:30:07 2018 3
 Incremental Wed Mar 7 22:30:07 2018 1
 Incremental Thu Mar 8 22:30:07 2018 1
 Incremental Fri Mar 9 22:30:08 2018 1
 Incremental Mon Mar 12 22:30:06 2018 1
 Incremental Tue Mar 13 22:30:07 2018 1
 Incremental Wed Mar 14 22:30:07 2018 1
 Incremental Thu Mar 15 22:30:07 2018 1
 Incremental Fri Mar 16 22:30:07 2018 1
 Incremental Sat Mar 17 22:30:07 2018 1
 Incremental Sun Mar 18 22:30:07 2018 1
 Incremental Mon Mar 19 22:30:07 2018 1
 Incremental Tue Mar 20 22:30:09 2018 3
-------------------------
No orphaned or incomplete backup sets found.

En cas de corruption ou de perte de l’un des éléments de la chaîne de sauvegarde, il faut donc garder à l’esprit que l’ensemble de la chaîne devient inutilisable par duplicity, même si l’élément incriminé concerne une chaîne secondaire et que l’on dispose d’une chaîne primaire plus récente partant d’une sauvegarde complète. Du côté des bonnes nouvelles, si les sauvegardes complètes effectuées périodiquement ne sont pas corrompues, il est possible de récupérer les données à la main très simplement, en quelques commandes.

En récupérant les fichiers chiffrés composants la sauvegarde complète, en se munissant du mot de passe utilisé et en suivant les instructions du wiki Gnome, on commence donc par déchiffrer chaque fichier avec gpg :

gpg --output duplicity-full.20180306T223007Z.vol1.difftar --decrypt duplicity-full.20180306T223007Z.vol1.difftar.gpg

Pour déchiffrer l’ensemble des fichiers en une commande :

gpg --multifile --decrypt duplicity-full.20180306T223007Z.*.difftar.gpg

Une fois les fichiers déchiffrés, on peut décompresser l’ensemble avec tar :

tar xf duplicity-full.20180306T223007Z.vol1.difftar

Ou l’ensemble des fichiers en une fois :

for t in duplicity-full.20180306T223007Z.*.difftar; do tar xf $t; done

Il ne reste plus qu’à explorer le contenu des dossiers décompressés pour y chercher les données que l’on souhaite récupérer. Une procédure similaire est ensuite applicable à chaque dossier incrémental pris séparément, si la dernière sauvegarde complète n’est pas suffisante.

Une autre solution consiste à prendre son mal en patience, croiser les doigts et réessayer périodiquement. Il se trouve que le lendemain, le fichier manquant était à nouveau disponible : plus d’erreur 404.

Cette mésaventure m’aura au moins permis de valider la récupération des données en cas de problème unitaire sur la chaîne de sauvegarde. Pour le reste, l’automatisation suit son cours et l’utilisation d’ansible, au vu des premiers essais, devrait me permettre de redéployer facilement mes services sur une nouvelle machine à partir des données sauvegardées.
La boucle est bouclée.

Anonyme

Auteur/autrice : Victor

Ingénieur en informatique de formation et de métier, j’administre ce serveur et son domaine et privilégie l'utilisation de logiciels libres au quotidien. Je construis progressivement mon "cloud" personnel service après service pour conserver un certain contrôle sur mes données numériques.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *