URL: https://linuxfr.org/news/sauvegardes-encore-et-restitution
Title: Sauvegardes (encore !) et restitution
Authors: Yves DEMUR
 ElectronLibre63, Xavier Teyssier et Ysabeau 🧶
Date: 2024年07月08日T17:14:56+02:00
License: CC By-SA
Tags: sauvegarde et bash
Score: 34
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.
![tape-drive](http://yves.demur.free.fr/tape-drive120.png)
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 !
----
----
# 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](http://yves.demur.free.fr).
Je m’en sers quotidiennement. Selon les jours, j’envoie les fichiers archives sur le 2e 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 '\n0円' '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***
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/news/sauvegardes-encore-et-restitution.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/news/sauvegardes-encore-et-restitution.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>