Ce post a été publié sur LinuxFr.org. Vous pouvez le lire là bas, ainsi que les commentaires associés

Bonjour ‘Nal,

J’ai les boules, un peu les glandes, et les… ouais tu vois le genre.

Il y a chez moi un petit Eee PC qui nous sert de NAS et rend quelques autres menus services : il fait tourner Apt Cacher, Transmission, stocke quelques dépôts Git pour divers petits trucs perso, et surtout un partage NFS où nous mettons les trucs à partager (le KeyPass, les photos, quelques documents, etc.)

Histoire d’avoir un peu de crédit dans les dîners mondains, j’ai bien sûr chiffré le disque de l’Eee PC. J’ai aussi mis en place une sauvegarde quotidienne sur un disque externe, chiffré aussi, et sur S3, chiffré aussi grâce à rclone, sur les bons conseils de l’excellence bivalve.

Quelle ne fut pas ma surprise de voir l’ordi éteint sans raison apparente récemment. Ce n’est rien, me dis-je, on rallume et ça repart. Ok ça boot, il me demande le mot de passe du disque. Quel est-il déjà ?

Heureusement, pas con, j’avais enregistré le mot de passe dans le KeePass. Stocké sur l’ordi que je suis en train d’essayer de démarrer. Une goutte de sueur perle sur mon front.

Regardons sur la copie du fichier KeePass qui est sur mon téléphone. Mmmh ok j’ai bien le mot de passe, avec une petite note :

Attention, le clavier est probablement en qwerty.

Comment ça « probablement » ? Ça ne m’a pas l’air très rigoureux tout ça. Quoi qu’il en soit je rentre le mot de passe. Refusé. Bon en qwerty alors. Re. Fu. Sé. Je tente cinquante fois, toujours rien. Je reboote et ouvre une console Grub pour vérifier ce que j’écris et là je pige : une touche est faiblarde et n’imprime pas toujours. Bon je relance et je saisis le mot de passe à coup d’Elbow Drop. Toujours rien. En qwerty peut-être ?

Nope, ça ne passe pas.

Une goutte de sueur perle sur ma goutte de sueur.

Là il faut se rendre à l’évidence, ça sent la restauration de sauvegarde. Les hauts-parleurs hurlent : « Ceci n’est pas un exercice. Je répète : ceci n’est pas un exercice ».

Allez c’est parti, coup de pot j’ai encore l’ISO d’Ubuntu Server que j’avais installée, pas besoin de retélécharger. Une vraie chance. Quel. Gros. Veinard.

Après l’installation et vérification que j’arrive à saisir le nouveau mot de passe du disque, je branche le disque externe. Aucun problème pour entrer son mot de passe, ouf. Je le monte. Dans ces moments on s’accroche aux plus petites victoires.

Première réflexion : ça manque d’un script de restauration en fait. Bon je commence à en écrire un, c’est pas trop compliqué. Je recopie l’arborescence à coup d’rsync --recursive --progress et… Et j’attends. Bon sang que c’est long. 250 Go de données à faire transiter d’un disque USB mécanique vers le disque interne SSD, ça se fait au mieux à 12 Mo/s. et ça prend au moins six heures. Je ne suis pas pressé de faire une restauration depuis S3.

Je mets aussi dans le script de quoi remettre les paquets qui vont bien : apt-cacher-ng en premier, puis je lui restaure sa config, et seulement ensuite j’installe les autres paquets.

Penser à virer snapd et désactiver le message du jour au login aussi.

Finalement la restauration se fait bien, modulo quelques typos dans le script et des erreurs de propriétaires de fichiers dans la restauration. Forcément tout ce qui est restauré de la sauvegarde appartient à root, mais Apt Cacher et Transmission s’attendent à avoir des fichiers possédés par leurs utilisateurs associés. Je me demande comment je pourrais garder les propriétaires lors de la sauvegarde. A priori il y aurait moyen de garder l’UID dans la copie mais que se passera-t-il si ce n’est pas l’UID des utilisateurs initiaux lors de la restauration ?

Cela étant vu, c’est l’heure du bilan :

• dossier partagé accessible sur le réseau avec ses fichiers originaux : check ;
• les machines du réseau passent par Apt Cacher : double check ;
• les pages HTML documentant les service sur le réseau sont accessibles : tchèckeu ;
• Transmission est accessible sur le réseau, avec la config restaurée : super tchèckeu turbo prime, high-five, combo ×4 ;
• la config rclone est bien restaurée : ultimate tchèckeu ;
• le script de backup est… ah bah tiens il est où ce con ? fail ;
• les dépôts Git sont absents : double fail, moins mille points.

Bon ben c’est pas si mal pour une première deuxième. Oui j’avais déjà dû faire une restauration pour cause de disque mort, ce qui m’avait amené à mettre en place des sauvegardes un peu sérieuses, notamment en copiant sur S3.

Je suis bien dégoûté de ne pas avoir sauvegardé mon script de sauvegarde. Il était hyper classe, j’en était fier, et il est parti. Avec lui a disparu la démonstration que P != NP que j’avais rédigé dans les marges, mais bon c’est la vie. En plus c’est bien galère à tester comme script, ça m’avait pris pas mal de temps de le mettre en place.

Pour les dépôts Git ça devrait aller puisque, par désaïgne, c’est sauvegardé sur d’autres machines.

Notes pour l’avenir :

• pense à fréquemment copier ton fichier KeePass sur d’autres supports ;
• « Bon y’a des trucs qui sont copiés ça a l’air ok » n’est pas une validation acceptable pour un script de sauvegarde ;
• pense à avoir un script de restauration ;
• la restauration est étonnamment lente. Le disque est un 5400 rpm qui devrait sortir du 60 Mo/s., sur un port USB 2 qui a un débit théorique à 90 Mo/s. Il y a quelque chose à faire là dessus ;
• pense à tester les scripts de sauvegarde et de restauration ;
• pense à tester le script de test des scripts de sauvegarde et de restauration ;
• pense à tester le script de test du script de test… argh.