Ben oui, ce sujet m’intéresse car je suis motivé par la préservation de ce que je considère comme précieux dans les données que je crée ou récupère sur mon PC. En tant que bidouilleur j’ai moi aussi créé un outil pour cela. Il correspond à mon besoin et j'en suis satisfait. Voici mon cheminement.

J’ai fait une recherche sur LinuxFR.org avec le mot sauvegarde et j’ai trouvé des articles et des réactions toutes très intéressantes. Les besoins, les solutions, les mises en œuvre sont très variées. Chacun choisit ou crée selon son ressenti et finit par être satisfait de ce qu’il fait. Chacun partage son expérience, en espérant qu’elle profitera à d’autres. À mon tour.

Le meilleur outil de sauvegarde est celui qu’on utilise et en lequel on a confiance.

Je te propose un jeu : demande à un utilisateur de PC, smartphone… si la destruction inopinée de son appareil entraînerait des pertes de fichiers irrémédiables qui pourraient l’affecter (photos familiales, documents…). Demande ensuite s’il fait des copies et/ou des sauvegardes. Pour beaucoup, tu seras catalogué comme vilain geek alarmiste. Il y a du travail de prise de conscience !

Sommaire

• Notion de sauvegarde
• Que demande-t-on à un outil de sauvegarde ?
• Un script shell écrit sur un coin de table (au début)
• Scripts bash tzsauv
• Subtilités et pièges
• Conclusion

Notion de sauvegarde

Une analyse très courte de la fonction sauvegarde serait « ranger quelque part des données qui permettront de restituer ce que je considère comme précieux ».
Les mots clés sont « ranger » « quelque part » « données » « restituer » « précieux ».
On a deux verbes « ranger » « restituer », deux localisations de données « quelque part » « ce qui est précieux », et une notion de filtrage dans le mot « précieux ».

Un autre point de vue serait de dire qu’une information précieuse doit résider en deux endroits, pour que la défaillance de l’un puisse être compensée par l’autre. Une des conséquences consiste à doubler les archivages : la libération des espaces précieux par la suppression de données inactives doit être précédée de l’archivage des données à supprimer vers deux supports distincts. Une autre conséquence est d’utiliser un média spécifique pour recevoir les sauvegardes (autre que celui où sont les données à sauver).

La défaillance peut être de plusieurs origines : matérielle, corruption du média, utilisateur qui efface/écrase…

Que demande-t-on à un outil de sauvegarde ?

Si je rédigeais un cahier des charges pour un outil de sauvegarde, je ferais les listes suivantes. Je suis dans mon contexte de PC isolé, ayant accès éventuellement à un petit serveur sur le réseau local.

Fonctionnalités de base :

• sauver juste ce qui a été modifié depuis la sauvegarde précédente => opération rapide,
• compression des fichiers archives => prend peu de place sur l’espace de sauvegarde,
• facile à lancer et rapide en exécution => sera lancé souvent => sécurisation accrue,
• filtrage => possibilité de conserver dans les espaces sauvés des fichiers qui n’encombreront pas les sauvegardes,
• robuste => confiance.

Fonctionnalités nécessaires :

• vérification de l’intégrité des fichiers archives engendrés,
• restitution facile malgré le grand nombre de fichiers archives à exploiter,
• restitution qui permette de régénérer (ailleurs) l’espace sauvegardé dans le même état que ce qu’il était au moment d’une des opérations de sauvegarde (accès aux états antérieurs),
• recherche/extraction de fichiers dans le grand nombre de fichiers archives obtenus,
• traçage pour vérifier le bon déroulement des opérations.

On peut ajouter aussi :

• algorithme ouvert et source fourni,
• qui s’accommode de tous types de support de stockage,
• qui utilise des formats standard,
• qui a toutes ses fonctionnalités accessibles en ligne de commande.

Le dernier point permettra d’utiliser l’outil comme une commande classique. On pourra le lancer dans un script bash qui adaptera l’usage au besoin spécifique du moment (ajout de montage/démontage du média de sauvegarde, rsync réseau des fichiers générés…). C’est une commodité qui me manque quand je suis coincé dans l’usage d’un outil cliquodrome.

Un script shell écrit sur un coin de table (au début)

J’ai rencontré le shell lors de mon premier contact avec Unix, en 1987. Au début j’ai eu le sentiment de régresser par rapport à la syntaxe COM des Vax/VMS. Depuis, j’ai appris à apprécier le bash, bien plus commode que ses ancêtres sh csh. Une des philosophies du shell est de combiner des commandes simples et robustes pour en faire une réponse à un besoin. Par exemple ls | wc -l renvoie le nombre de fichiers/répertoires du répertoire courant. Toutefois, il y a des cas sournois où le résultat est faux, on verra plus loin ce que je qualifie de pièges.

Avec les pipelines, les redirections, les variables, les traitements de chaînes de caractères, et tout le reste, on peut construire à l’infini des séquences d’opérations qui s’appuient sur des commandes simples à lancer mais puissantes (genre outil de compression, outil de parcours d’une arborescence de fichiers…). Beaucoup des fonctionnalités du système GNU sont construites comme cela. Un bidouilleur système ne peut pas ignorer le bash. En plus, emacs permet un accès très commode aux man. Je n’ai jamais eu de projet ou de besoin qui me pousse à maîtriser Perl ou Python. Je pense qu’ils sont encore plus puissants que bash.

Comme j’aime bien bidouiller, à la fin du 20^e siècle j’avais dans l’idée de faire un outil de sauvegarde basique qui s’appuie sur un pipeline : une commande find qui sélectionne les fichiers modifiés, tar pour les copier et gzip pour compresser. J’ai fait divers essais. En 2021, je m’y suis mis sérieusement et j’ai découvert beaucoup de subtilités du bash.

Un des problèmes des sauvegardes incrémentales est de deviner si un fichier doit être sauvé, sans avoir à comparer son contenu avec la version sauvée dernièrement (ça coûte trop cher). Il faut se baser sur les paramètres du système de fichiers. Il faut bien choisir ces paramètres (on surveille leur changement), au risque de rater certains fichiers ou alors d’en sélectionner trop. Je me suis arrêté sur la date de modification du statut et le numéro d'inode.

Scripts bash tzsauv

Je pense être arrivé au bout des spécifications avec l’outil tzsauv que j’ai écrit en bash. Il est disponible sur mon site.
Je m’en sers quotidiennement. Selon les jours, j’envoie les fichiers archives sur le 2ᵉ disque ou sur clé USB. Je fais aussi un miroir du répertoire disque des fichiers archives vers GoogleDrive (ceinture et bretelles). Je fais aussi une sauvegarde à longue périodicité (six mois) sur une clé USB dédiée (double ceinture).

Les opérations principales utilisent les commandes standard find sed tar zstd md5sum, le bash sert à enchaîner tout ça et sert aux dialogues. Pour installer, il suffit de copier deux scripts sur le média de sauvegarde (SauverTZ_ProjXY_01.bash tzsauv.bash, total 96k, ajouter éventuellement l’aide Alire.txt), et modifier quelques paramètres dans l’un des scripts (le script lanceur SauverTZ_*.bash). Le lancement peut se faire en ligne de commande ou via l’explorateur de fichiers par Clic-Droit/Actions/LancerDansKonsole.

L’interprétation du bash prend des ressources, mais je pense qu’elles sont négligeables par rapport à celles prises par les E/S et les commandes standard citées ci-dessus. Le compresseur zstd semble être très performant, en temps et en taux de compression. De plus, il est multithread, ce qui lui permet de tirer avantage des processeurs actuels qui gagnent en puissance en augmentant le nombre de cœurs. Le paramétrage de tzsauv permet de choisir parmi plusieurs formats d’archives.

Pour la sauvegarde vers le 2^e disque, j’ai copié sur le Bureau le lanceur de Konsole, puis j’ai renommé la copie et dans ses Propriétés/Application j’ai modifié l’argument (-e ./SauverTZ_ProjXY_01.bash) et le dossier de travail. Du coup, avec juste un double-clic je lance la sauvegarde en mode interactif (-> question « … TOTALE o/n/q ? »). Elle est pas belle la vie ?

Subtilités et pièges

Je fais régulièrement des petits programmes bash pour explorer des détails de fonctionnement soit du bash, soit des commandes. Les man ont beau être détaillés, ils ne peuvent pas tout dire. Pour un bug de tar je suis allé jusqu’à consulter le source C, le corriger par plaisir et vérifier que c’était OK. La remontée du bug n’a pas abouti (personne n’utilise l’option -u de tar ! C’est de la tétrapilectomie, je suis xyloglotte mais pas encore alopécique).

Si tu lances sous bash ls | wc -l puis touch -- 'a'$'\n''b' puis de nouveau ls | wc -l, le nombre renvoyé aura augmenté de deux alors que tu n’as ajouté qu’un seul fichier. C’est normal car le nom du fichier ajouté tient sur deux lignes ! Solution : ls -q | wc -l ou ls --zero | tr '\n\0' '\0\n' | wc -l. Pour voir le résultat de ls -q envoyé à wc -l via le pipeline, entrer ls -q | cat.

Les deux seuls caractères interdits dans les noms de fichiers/répertoires *unix* sont « / » et « \0 » (à méditer).

Je t’invite à créer sous bash un fichier piège par echo "abcd" > $' xyza\x01b\x02c\x03d\x04e\x05f\x06g\x07h\x08i\x09j\x0ak\x0bl\x0cm\x0dn\x0eo\x0fESC\x1bDEL\x7f\x80\xff\x26\x22\x27\x60\x5c SPC ', à le sauver avec ton outil, puis à le restituer. Tu verras si ça passe et si le nombre de fichiers est correct. Pour le détruire rm -i *xyza* devrait convenir.
Essaye aussi avec un sous-répertoire mkdir $' xyzp\x01b\x02c\x03d\x04e\x05f\x06g\x07h\x08i\x09j\x0ak\x0bl\x0cm\x0dn\x0eo\x0fESC\x1bDEL\x7f\x80\xff\x26\x22\x27\x60\x5c SPC '. Mets-y un fichier, puis fais une sauvegarde totale, modifie le fichier et fais une incrémentale. Ensuite fais un essai de restitution. Joue aussi à modifier le nom du répertoire parent du sous-répertoire piège.
Pour jouer avec ces choses dangereuses, je te conseille de faire une zone à part, ne fais pas courir de risque à ta production. Sur ma Mageia9.2-official, le navigateur Dolphin n’arrive pas à détruire le répertoire piège. Je passe par la ligne de commande.

J’ai rencontré tout plein de pièges et j’en ai imaginé d’autres : un fichier de nom -f, un répertoire de nom -, comment détruire le fichier ? Comment faire un cd vers le répertoire ?
Solutions : rm -f -- -f et cd -- -/ et si le nom du répertoire est dans la variable var cd -- "${var%/}/" (prévoir le cas où var="/").
J’ai découvert que zstd en mode filtre lancé par tar, se met en erreur s’il existe un sous-répertoire de nom - dans le répertoire courant (c’est très particulier, en effet). L’examen des sources de tar et de zstd m’a confirmé le problème, la solution m’a parue simple (inverser l’ordre de deux tests dans le source de zstd) mais la remontée de bug n’a pas abouti. Ce n’est pas grave, je sais maintenant qu’il ne faut pas utiliser tar ... --zstd ..., et je mets plutôt zstd -c[d] dans un pipeline.

J’en raconte un maximum dans le fichier notes01.bash. Toute cette expérience me permet de créer des scripts bash robustes.

Conclusion

Ton outil de sauvegarde est le meilleur, car il te convient.
Fais-toi une idée claire

• de tous tes espaces contenant des fichiers précieux à tes yeux,
• de tous tes espaces de sauvegarde,
• des mécanismes de sauvegarde et de restitution.

Cela participe à la confiance.

N’oublie pas de faire de temps en temps un contrôle d’intégrité des archives et un exercice de restitution. C’est un peu de travail, juste pour vérifier qu’une mise à jour, ou une donnée inhabituelle, ou autre chose, n’a pas mis en défaut la capacité à restituer comme tu l’entends.

Si la restitution est rendue impossible, c’est comme si tu n’avais jamais sauvegardé !

La confiance, en informatique ça se surveille du coin de l’œil
L’informatique est une science exacte pour la machine, pas pour l’homme ; il compense par l’humilité et l’empirisme