Linux on Carnet de découvertes

Sauvegardes personnelles avec Restic

Florent Jardin — Wed, 08 Oct 2025 16:00:00 +0200

Ces derniers temps, j’ai mis fin à une histoire d’amour avec Debian qui aura duré près de trois ans. Pas que je n’aime plus le système, oh non, je le préfère toujours à sa cousine Ubuntu. Mais voilà, j’ai un attachement particulier à Archlinux depuis, wouh, au moins les bancs de l’école d’ingénieur où nous l’installions sur des machines virtuelles et où nous nous adonnions à la pratique du linux ricing pour passer le temps.

Après une expérimentation de Manjaro i3 entre 2019 et 2022 sur mon poste professionnel, je me suis convaincu qu’il me fallait retourner à l’essentiel. Au début du mois de septembre, j’ai réussi le portage de ma config Sway de Debian Trixie vers Archlinux. L’occasion parfaite pour requestionner mes pratiques en matière de sauvegarde de poste et de remplacer BorgBackup par Restic.

Prise en main éclair

J’ai lu plusieurs articles et avis au sujet de Restic. Je l’avais vite identifié comme un outil équivalent à BorgBackup, mais je ne m’étais pas pressé de le tester. Quelle erreur ! J’ai été déconcerté par la facilité d’utilisation, par son interface en ligne de commande claire et complète, et par sa documentation de qualité.

Pour avoir régulièrement vécu des dégâts sur des clés de mauvaise qualité avec ma pratique exotique sur BorgBackup, je m’étais penché sur la possibilité de sauvegarder vers un dossier distant avec SSH. J’ai du insisté deux bonnes heures à l’époque sans parvenir à quoique ce soit avec Borg.

Avec Restic, ce n’est pas moins de 13 types différents de dépôts supportés, dont le SFTP. Il ne m’en fallait pas plus pour tourner le dos à son homologue. La mise en place d’un dépôt est simplifiée à l’extrême :

set -x RESTIC_REPOSITORY "sftp:<server>:<directory>"
restic init
restic backup ~ \
 --dry-run \
 --exclude-file ~/.config/restic/excludes.txt

Je ne suis pas en reste avec une gestion poussée des stratégies de rétention des instantanés. Pour l’exemple, je maintiens une sauvegarde par semaine, pendant trois mois.

restic forget --prune --keep-within-weekly 3m

La technique d’exploration d’un instantané est identique à Borg, avec un montage FUSE sous Linux. Une fois encore, la documentation est limpide à ce sujet.

sudo install -o $USER -g $USER -d /mnt/restic
restic mount /mnt/restic

Planification avec systemd

Je me suis prêté au même jeu qu’avec BorgBackup sur ma précédente installation Debian. En lieu et place de cron, je planifie mes sauvegardes avec un timer utilisateur pour déclencher une tâche deux fois par jour sur mes journées de travail.

# ~/.config/systemd/user/restic.timer
[Unit]
Description=Daily Restic backup
Documentation=man:restic

[Timer]
OnCalendar=Mon..Fri 09:30
OnCalendar=Mon..Fri 16:30
Persistent=true

[Install]
WantedBy=timers.target

La tâche consiste à appeler restic avec mon fichier d’exclusion, suivi d’une purge des vieux instantanés présents sur le dépôt.

# ~/.config/systemd/user/restic.service
[Unit]
Description=Restic backup

[Service]
Type=oneshot
ExecStart=restic backup %h --exclude-file $RESTIC_EXCLUDE_FILE
ExecStartPost=restic forget --prune --keep-within-weekly 3m

Pour la configuration, je déclare les variables dans un fichier d’environnement pour que restic sache identifier et déchiffrer correctement les instantanés.

# ~/.config/environment.d/restic.conf
RESTIC_REPOSITORY=sftp:<server>:<directory>
RESTIC_PASSWORD_FILE=$HOME/.config/restic/pass
RESTIC_EXCLUDE_FILE=$HOME/.config/restic/excludes.txt

Pour armer la planification, il suffit de recharger systemd.

systemctl --user daemon-reload

En exportant les bonnes variables dans votre shell, la consultation des instantanés se fait sobrement avec la commande suivante.

restic snapshots

repository 3db74709 opened (version 2, compression level auto)
ID Time Host Tags Paths Size
-----------------------------------------------------------------------------------
f7bb4fea 2025-09-16 11:50:18 florent-dalibo /home/florent 4.309 GiB
5a4dbf59 2025-09-19 09:30:01 florent-dalibo /home/florent 5.639 GiB
1012f0ab 2025-09-27 19:28:38 florent-dalibo /home/florent 5.871 GiB
629c2687 2025-10-03 09:30:00 florent-dalibo /home/florent 6.006 GiB
98b32adb 2025-10-08 10:00:08 florent-dalibo /home/florent 4.677 GiB
-----------------------------------------------------------------------------------
5 snapshots

Conclusion

Restic est un bon outil. Tellement bon, que la communauté Gnome l’utilise à présent comme backend pour l’interface Déjà Dup dans leur dernière version 49.0 sortie le mois dernier.

Pour ma part, tout se déroule bien depuis presque un mois. Il ne manque plus qu’à sécuriser le serveur distant qui fait office de dépôt avec ses propres sauvegardes ! Pour ce faire, j’envisage de mettre en place Restic sur la plupart des répertoires d’importances de mon serveur multimédia, en gardant bien en mémoire le principe 3-2-1 de la sauvegarde réussie.

Prenez soin de vos sauvegardes.

Poissons et coquillages

Florent Jardin — Mon, 14 Oct 2024 10:30:00 +0200

En tant que pur produit académique des années 2010, mon langage de script de prédilection a toujours été le Bash (Bourne Again Shell). Non sans ignorer qu’il ait pu en exister d’autres, je ne me suis jamais vraiment tourné vers d’autres shells pour automatiser les tâches du quotidien dans mon métier de DBA.

Et pour cause, j’ai administré des centaines de serveurs de distributions très variées et il n’était pas bien vu d’installer des dépendances systèmes lourdes pour enrichir des scripts Python ou Perl. Nous apprenions donc à écrire des scripts portables et universels, compatibles partout où nous déposions nos valises.

Me suis-je enfermé dans un dogme conservateur, en m’interdisant de facto à me tourner vers des shells modernes et bien plus aisés à appréhender ?

Beurk, le Bash

Ne faisons pas de détour, le Bash c’est moche. Puissant, pratique, universel, mais moche.

Vous pourriez penser que c’est un avis parfaitement subjectif, et qu’il ne faut pas juger un livre à sa couverture… mais avouez-le, une partie de vous pense sensiblement la même chose que moi. Combien d’heures ai-je pu perdre durant ma courbe d’apprentissage du langage, à cause d’un grand nombre de subtilités et de pièges de syntaxes ?

Entre les assignations sans espace autour du signe =, les accolades {} pour les variables contenant un signe _, les backticks ` ` pour les commandes subshells, ou encore les doubles crochets [[ ... ]] pour les comparaisons non-POSIX, il y a de quoi s’arracher les cheveux.

Certain·e·s y verront une forme d’esthétisme ou de tradition d’une culture informatique, mais personnellement je trouve que c’est un langage qui vieillit mal, très mal. Vous ne vous offusqueriez pas non plus si je devais vous témoigner mon désamour le Perl, n’est-ce pas ?

# une comparaison de deux variables
[[ "$a" == "$b" ]]

# une addition et une affectation
z=$(( $x + $y ))

# une boucle for
for i in $(seq 1 10); do
 echo $i
done

# un switch case
case $1 in
 1) echo "un";;
 2) echo "deux";;
 *) echo "autre";;
esac

# une chaîne en minuscule
a=${a,,}

# une gestion des erreurs de commandes chaînées
some_command | another_command
if [[ ${PIPESTATUS[0]} -ne 0 || ${PIPESTATUS[1]} -ne 0 ]]; then
 echo "Une des commandes a échoué"
fi

Le Bash est apparu l’année de ma naissance, en 1989. Il a été conçu en opposition au Bourne Shell (sh) pour apporter des fonctionnalités de programmation plus avancées. Il est devenu le shell par défaut de la plupart des distributions Linux, et est devenu un standard pour tous les scripts à travers le monde entier.

Fort de ses années de succès, et de son emprise sur le monde Unix, le Bash s’impose parfois comme la première porte vers la programmation pour des administrateurices système ou les étudiant·e·s en informatique. Et il faut accepter que la qualité de ses premiers scripts n’est pas toujours au rendez-vous. Souvenez-vous des longues heures passées sur StackOverflow à trouver la syntaxe la plus lisible ou la plus efficace, car les réponses se révélaient aussi variées que touffues !

Et c’est l’un des plus gros problèmes que je trouve au Bash : ce langage de programmation est exigeant, excentrique, voire idiosyncratique, et qui ne pardonne pas les erreurs. Un des paradoxes que j’associe au Bash est qu’il peut ne pas être considéré comme un véritable langage de programmation, réduisant ainsi la volonté et l’effort de l’apprendre en profondeur par une large communauté de professionnel·le·s.

Et si vos scripts Bash sont nuls, utilisez un autre langage.

L’ami Fish, Friendly Interactive Shell

Je suis tombé sur Fish par hasard, alors que je questionnais mon usage quotidien sur ZSH. Sur mon poste personnel, j’ai étendu mon expérience passée sur le Bash avec une configuration ZSH enrichie de Oh My Zsh. C’était un peu le jour et la nuit dans l’interaction avec mes terminaux : la navigation, les suggestions, les thèmes, les plugins, tout est plus fluide et plus agréable. Sa compatibilité avec Bash m’avait alors évité de tout réapprendre.

Fish répond au besoin de modernité et de simplicité que je cherche sans vraiment le savoir. Contrairement à ZSH, un grand nombre de fonctionnalités sont disponibles sans aucune configuration préalable ou plugin à activer.

Assistance à la commande

Recopie la commande incomplète et en erreur sans besoin de naviguer dans l’historique
Accès à l’historique partiel avec les touches directionnelles dès la première frappe au clavier
Proposition de chemins avec la complétion de la touche Tab, suivie des touches directionnelles

Auto-suggestions des chemins et des options d’une grande majorité des outils

Mémoire des précédents répertoires parcourus
Support très complet des commandes Git, notamment le git rebase -i ❤️

Coloration plus poussée des commandes

une couleur différente par mot selon la syntaxe employée (variables, chemin, options)
un rouge prononcé pour les commandes inconnues

Un langage qui vous veut du bien

Pour revenir au sujet principal de cet article, Fish révolutionne notre rapport avec la rédaction de scripts. Fini les pièges et la syntaxe qui nous ont tenu en otage durant des années. Les choses deviennent bien plus simples et lisibles.

# une comparaison de deux variables
test "$a" = "$b"

# une addition et une affectation
set z (math $x + $y)

# une boucle for
for i in (seq 1 10)
 echo $i
end

# un switch case
case $argv[1]
 1; echo "un"
 2; echo "deux"
 *; echo "autre"
end

# une chaîne en minuscule
set a (string lower $a)

# une gestion des erreurs de commandes chaînées
some_command | another_command
if contains 1 $pipestatus
 echo "Une des commandes a échoué"
end

L’investissement initial pour perdre ses habitudes acquises avec Bash est modéré, notamment le remplacement de export ou de l’assignation = par la méthode set -x ou set -u respectivement. Mais l’enrichissement du langage par quelques nouveaux mots-clés permet d’alléger le script avec des syntaxes claires et lisibles (contains, math ou string présents dans l’exemple ci-dessus).

L’ajout de plugins communautaire n’est pas en reste, si comme moi, vous en consommiez avec Oh-My-ZSH. L’outil Fisher s’installe dans votre ~/.config/fish et donne accès à un gestionnaire complet et sobre. Pour ma part, j’ai pu rapidement combler mon besoin de charger les variables d’environnement fournies par l’agent SSH (ssh-agent) lors du démarrage de ma session.

$ fisher install danhper/fish-ssh-agent
fisher install version 4.4.5
Fetching https://api.github.com/repos/danhper/fish-ssh-agent/tarball/HEAD
Installing danhper/fish-ssh-agent
 /home/florent/.config/fish/functions/__ssh_agent_is_started.fish
 /home/florent/.config/fish/functions/__ssh_agent_start.fish
 /home/florent/.config/fish/conf.d/fish-ssh-agent.fish
Updated 1 plugin/s

Pas de mystère, ni d’arcanes magiques, votre environnement est enrichi de nouvelles fonctions et de scripts de démarrage, développés en Fish.

Osons la modernité

La documentation du projet est très bien fournie. En plus de la page Tutorial, vous trouverez une page dédiée aux utilisateurs de Bash pour vous aider à réussir votre transition. Pour ma part, j’y retrouve des syntaxes bien plus proches du Python, et c’est un vrai plaisir.

Le projet est vivant, avec un rythme de versions régulier. Je me suis surpris moi-même à ne pas en avoir entendu parler par d’autres collègues ou auprès des auteurices de blogs que je suis. Au cours des dernières années, la communauté francophone a essaimé quelques bons articles qui complètent le mien.

Changer de shell, de Bash à Fish (2016)
Fish, une ligne de commande intelligente et simple d’utilisation (2017)
Comment passer de Bash à Fish Shell sous Linux (2021)
Migration de shell de zsh à fish (2024)

Ces temps-ci, je fais évoluer mon expérience d’utilisateur de Linux avec une transition vers Wayland et SwayWM (j’y reviendrais dans un autre article). Je ne le cache pas, la tentation de remplacer mes scripts Bash qui gèrent mes thèmes ou les composants swaybar, est forte, très forte.

De quoi occuper mes prochaines longues soirées d’hiver.

Construire PostgreSQL avec Meson

Florent Jardin — Thu, 29 Sep 2022 00:00:00 +0000

Alors que la version 15 de PostgreSQL se prépare à sortir dans les prochains jours, le groupe de développement du projet communautaire ont intégré leurs récents travaux pour accélérer les tâches d’automatisation et de compilation à l’aide du système de construction Meson.

Ce chantier n’est pas anodin et redessine les contours de l’écosystème du moteur de bases de données open-source le plus avancé au monde. Depuis sa forme libre publiée en 1998, PostgreSQL repose sur des solutions robustes et éprouvées, mais de plus en plus complexes à maintenir pour les nouvelles générations de contributeur·rices. En proposant de se tourner vers un logiciel comme Meson, ces amoureux et amoureuses du libre se tournent résolument vers l’avenir.

En finir avec autoconf

Un système de construction ou build system (ne vous y trompez pas, j’ai une préférence pour la dénomination anglaise) est un ensemble d’instructions dans une syntaxe qui lui est propre, qui facilite la compilation d’un logiciel. Les ramifications d’un projet, les dépendances et les librairies ou tout simplement l’outillage interne, deviennent inexorablement la rançon d’une complexité après plusieurs décennies d’existence.

Le système le plus répandu est sans conteste Make et son fichier déclaratif Makefile qui contiendra les instructions de compilation. Son principe absolu consiste à transformer un fichier source (le code) en un autre fichier cible (le binaire). Dans un projet minimaliste, le Makefile suivant permet de générer le binaire foo si le code source foo.c ou son en-tête foo.h contiennent des nouveautés.

# ./Makefile
CC=gcc
CFLAGS=-I.

foo: foo.c foo.h
 $(CC) -o foo foo.c

À l’appel de la commande make à la racine du projet, le fichier Makefile sera parcouru pour détecter les cibles du projet et suivre les instructions selon les règles qui y sont renseignées pour construire les fichiers binaires.

Une pratique plus sophistiquée propose de générer ces instructions dans un format compatible avec le système de construction, lorsque celles-ci sont nombreuses, évolutives voire dépendantes d’un contexte ou d’un environnement tel que le système d’exploitation ou l’utilisation d’une option spécifique.

Dans le cas du projet PostgreSQL, c’est la suite GNU Autotools qui a été partiellement retenue pour faciliter la création des binaires sur un ensemble de systèmes compatibles Unix. La génération repose sur les composants Autoconf (fichier configure.ac) et Automake (fichier Makefile.am) pour aboutir au même résultat que la commande make de notre précédent exemple. Dans les faits, seul le premier composant est véritablement employé pour préparer le script configure lors de la compilation de PostgreSQL.

Comme le montre le diagramme ci-dessus, les étapes avant d’obtenir le fichier binaire sont un peu plus nombreuses, et dépendent d’un ensemble de fichiers d’instructions qui deviennent complexes à rédiger sans introduire d’incohérences ou de bogues.

C’est d’ailleurs l’un des constats de la communauté qui, depuis fin 2021, a questionné la possibilité de passer sur un autre système de construction.

Autoconf is showing its age, fewer and fewer contributors know how to wrangle it. Recursive make has a lot of hard to resolve dependency issues and slow incremental rebuilds.

Le principal moteur de la réflexion, Andres Freund, annonçait dans un message sur pgsql-hackers qu’il observait de bien meilleures performances avec une alternative bien plus moderne. Il y énonçait par ailleurs ses arguments pour en finir avec Autoconf :

« Autoconf et make ne sont plus activement maintenus. Notamment autoconf qui reçoit à peine quelques correctifs mineurs. C’est également des technologies que peu de monde veut utiliser – m4 d’autoconf est effrayant et effraie les personnes qui démarrent bien plus récemment que nous autres, les committers » ;
« make en mode récursif comme nous l’utilisons n’est pas aussi bien employé que ce qu’il devrait être. L’une des raisons pour laquelle le nettoyage du build est si lent est que nous devons retrouver les dépendances dans un paquet d’endroits. En malgré cela, il m’arrive régulièrement de voir des builds incrémentaux échouer et nécessitant un nouveau rebuild » ;
« Et nous n’avons pas uniquement un système de build basé sur autoconf et make, il y a surtout le projet de génération MSVC (Microsoft Visual C++) – ce machin que la plupart d’entre nous ne veut pas toucher. Je pense qu’en plus du fait qu’il n’y est pas facile de dérouler tous les tests, ce système est juste tout simplement différent de l’autre, ce qui ne favorise pas l’intérêt des développeurs sous Windows (et indirectement, la qualité de PostgreSQL sur Windows) » ;
« Le dernier gros problème que je vois avec la situation actuelle est qu’il n’y a aucun bon test d’intégration. Le résultat de make check-world est très majoritairement illisible et impossible à analyser automatiquement. Ce qui impose à la buildfarm de traiter les tests séparément afin que les erreurs puissent être repérées et tracées correctement. Cette approche n’est malheureusement pas adaptée aux processeurs multicœurs et ralentit considérablement l’ensemble des serveurs ».

Meson, une alternative moderne

À l’image des Autotools, Meson est un système qui génère les instructions de compilation. Ce fut le choix qu’a proposé Andres Freund à la communauté après l’avoir analysé aux côtés de CMake et Bazel, deux autres compétiteurs bien connus du monde libre. Meson est écrit en Python et son but premier est de réduire la part d’efforts des développeurs dans la rédaction d’instructions au profit d’une plus grande productivité sur le logiciel en tant que tel.

Le projet Meson s’appuie sur un système de construction bas niveau appelé ninja qui se veut, d’après son auteur Evan Martin, être minimaliste et bien plus performant que make. Les instructions de compilation sont renseignées automatiquement par Meson dans le fichier build.ninja qui sera ensuite parcouru par la commande ninja pour compiler les sources en un fichier binaire.

Pour reprendre mon projet minimaliste foo, le fichier Makefile est remplacé par le fichier meson.build, en y renseignant les méta-données du projet, le point d’entrée du programme et le fichier binaire souhaité.

# ./meson.build
project('foo', 'c')
executable('foo', 'foo.c')

Meson est un jeune projet, dont la première sortie date de 2013. Bien qu’il rougît de son âge face à CMake, il n’en reste pas moins un concurrent qui ne cesse de gagner du terrain depuis la dernière décennie. Parmi les projets qui s’appuient désormais sur Meson, je peux citer de très connus comme : systemd, Gnome et GTK+, QEMU, Xorg et Wayland… De quoi se parer d’une forte communauté d’utilisateurs dans les prochaines années !

Sur la page « Use of Python » du projet, les créateurs de Meson se défendent d’un reproche souvent adressé aux technologies modernes et affirment ne reposer que sur python3 tout en interdisant l’usage de modules externes, en gages de qualité et de compatibilité. Ainsi, le projet se veut accessible pour tous les systèmes d’exploitation, faisait un pied de nez au mastodonte Autotools qui était très couplé au shell Unix dans son implémentation.

La décision pour le projet PostgreSQL de progressivement glisser vers Meson est le fruit de plusieurs mois de réflexion, avec pour ambition notamment de se passer du système MSVC, un ensemble de scripts Perl maison maintenus par une poignée de personnes pour compiler le logiciel sous Windows. En prime, les travaux d’Andres démontrent un gain significatif dans les temps de build, ce qui ne paraît pas surprenant au regard du benchmark entre les deux systèmes sur une architecture ARM.

In any case, using Autotools for a modern C/C++ project in 2021 is like using CVS for source code version control in 2021: there are better tools available and thus it isn’t very interesting to still consider the legacy solutions.

Citation de Georg Sauthoff, The Rise of Meson.

Conclusion

La route empruntée semble la bonne, bien que le chemin soit encore long pour se débarrasser définitivement des résidus historiques d’Autoconf dans le projet PostgreSQL. Lors de la dernière Developer Unconference qui s’est tenue en ligne le 25 mai 2022 lors de l’événement annuel du PgCon, les membres de la communauté ont statué sur les efforts à fournir pour porter ce chantier titanesque.

Avec ce récent patch rattaché à présent à la branche master, la construction des binaires sur la plupart des systèmes d’exploitation est implémentée, avec notamment la compilation de PostgreSQL sur Windows à travers ninja. C’est une première pierre qui est posée pour la prochaine version 16 en cours de développement et l’émergence d’une architecture qui grandira avec d’autres améliorations dans un avenir proche.

BorgBackup ou la sauvegarde facile

Florent Jardin — Tue, 24 Aug 2021 00:00:00 +0000

Jusqu’à très récemment, je ne me préoccupais pas de la pertinence de mes sauvegardes de fichiers personnels réalisées naïvement avec un script rsync. C’est honteux dans nos métiers, mais l’adage du cordonnier s’est vérifié avec moi lors de l’exécution d’un vulgaire find $NOVAR/ -delete durant des tests.

Après cet épisode et l’amertume d’avoir perdu quelques travaux, ou la surprise de découvrir les ravages de leur disparition plusieurs semaines après ma fatale erreur, je me suis tourné vers l’outil incontournable dont tous mes collègues me parlaient : BorgBackup

Des atouts séduisants

Cela fait à présent deux années que je travaille au quotidien sur Linux pour mon activité professionnelle. Étant responsable de mon matériel et des données que je manipule, il n’existe pas de politique particulière pour les sauvegardes régulières ni le stockage de celles-ci.

Mon précédent script était passablement trivial, à savoir :

Sauvegarder une copie unique des documents courants ;
Sauvegarder une liste des fichiers de configuration, appelés dotfiles ;
Exclure les projets contenant un répertoire .git ;
Exclure les fichiers de plus de 200 Mo.

Le tout sur une clé USB de 8 Go, chiffrée avec le système LUKS pour se prévenir de la perte ou du vol dans un espace public dudit support.

Borg (son petit nom), permet de répondre correctement à l’ensemble de ces points, et le fait à merveille. En bénéficiant de la déduplication et de la compression, j’ai pu conserver ma clé USB et m’engager dans la rédaction d’un nouveau script plus complet.

Exclusion de fichiers et de répertoires

Certains fichiers ou répertoires cachés vivent leur vie sur nos postes, et un fichier d’exclusion peut être transmis à Borg pour ne pas les inclure dans la routine de sauvegarde. Le mien est relativement léger pour le moment, et pourrait s’enrichir avec l’expérience.

# ~/.config/borg/exclude.list
/home/**/.git
/home/**/.vagrant
/home/*/.local
/home/*/.cache
/home/*/.mozilla
/home/*/.thunderbird
/home/*/.config/chromium
/home/*/.config/discord
/home/*/.npm
/home/*/.cpan

Déduplication et rétention d’une semaine

Le gain remarquable entre mon script et la nouvelle solution que m’offre Borg réside dans son algorithme de déduplication, où la version d’un fichier n’est stockée qu’une seule fois jusqu’à une éventuelle modification, permettant de ne conserver qu’une copie de mes documents sur une bien plus longue période avec un coût de stockage ridiculement faible.

À chaque exécution, je demande le rapport de sauvegarde avec l’option --stats dont voici un exemplaire sur l’exécution de ce matin.

------------------------------------------------------------------------------
Archive name: florent-2021-08-24T08:42:05
Archive fingerprint: be38707dd52f5a86f8e75fe3ad4997aae58b3016366a988b7cb37ce3b
Time (start): Tue, 2021-08-24 08:42:06
Time (end): Tue, 2021-08-24 08:42:06
Duration: 0.96 seconds
Number of files: 3720
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
 Original size Compressed size Deduplicated size
This archive: 2.11 GB 1.78 GB 480.51 kB
All archives: 12.63 GB 10.67 GB 1.75 GB
 Unique chunks Total chunks
Chunk index: 3974 25888
------------------------------------------------------------------------------

Pour une semaine de rétention, l’espace total consommé sur le montage USB n’excède pas (encore) les 1,75 Go alors que les images décompressées pèsent au total 12,63 Go que ne parvennait pas à stocker mon ancien script sur plusieurs jours.

Au passage, la durée d’exécution est significativement réduite chaque jour grâce à ce mécanisme, qui ne sélectionne que les nouveautés d’une exécution à l’autre.

Un montage virtuel pour naviguer dans le temps

L’outil propose deux options pour la restauration :

extract pour restaurer le contenu d’une archive dans le répertoire courant (doc) ;
mount pour visualiser les fichiers ou dossiers à restaurer, voire les déplacer manuellement dans le répertoire cible avec un outil graphique (doc).

Cette seconde proposition est particulièrement utile pour naviguer d’une archive à une autre, à la recherche d’un fichier perdu dans le temps. Le montage s’effectue à l’aide du système de fichiers FUSE qui ne nécessite aucun droit administrateur.

Pour être utilisé à partir de Borg, le paquet python-llfuse sera requis selon votre distribution.

Planification avec systemd

Ce fut une découverte lors de mes lectures émerveillées de la documentation et des ressources de la communauté française d’Archlinux. N’étant pas particulièrement fan de cron pour un usage personnel, j’ai suivi à la lettre la configuration d’un service utilisateur et du timer associé pour garantir le lancement de la sauvegarde chaque jour, 30 minutes après le démarrage de mon système.

# .config/systemd/user/borg.service
[Unit]
Description=Borg backup

[Service]
Type=oneshot
ExecStart=%h/.bin/borg-create.sh

# .config/systemd/user/borg.timer
[Unit]
Description=Daily Borg backup
Documentation=man:borg

[Timer]
OnBootSec=30min
OnUnitActiveSec=1d

[Install]
WantedBy=timers.target

Une fois le service activé, je n’ai qu’à attendre chaque matin la notification de fin de sauvegarde pour consulter les rapports avec la commande journalctl.

journalctl --user -xeu borg.service

août 24 08:42:02 florent systemd[877]: Starting Borg backup...
août 24 08:42:27 florent systemd[877]: Finished Borg backup.
août 24 08:42:27 florent systemd[877]: borg.service: Consumed 1.535s CPU time.

Conclusion

De trop nombreux utilisateurs (Windows notamment) comptent sur leur miraculeuse corbeille, jusqu’à ce qu’une véritable suppression ne survienne ou qu’un disque défaillant fasse des siennes. Pour s’assurer qu’une donnée ne disparaisse pas définitivement, la sauvegarde doit être correctement mise en place, idéalement sur plusieurs périodes et sur plusieurs supports.

Le conseil vaut aussi bien pour les bases de données que pour les fichiers personnels : une sauvegarde n’est fiable que si la restauration de son contenu est possible. Une corruption de l’archive, une erreur dans l’exécution du script ou une mise à jour majeure de l’outil de sauvegarde sont autant de situations qui peuvent rendre vos sauvegardes irrécupérables.

Prenez soin de vos sauvegardes.

Les liens physiques avec pg_upgrade

Florent Jardin — Thu, 23 Apr 2020 15:30:00 +0200

La création d’un lien sous Unix se réalise avec les commandes ln ou cp. Cette action permet de lier deux fichiers vers la même donnée et de rendre disponible une ressource par l’intermédiaire de l’un ou de l’autre de ces fichiers.

Cependant, les opérations diffèrent selon le type de ce lien. Le plus connu reste le symlink, le lien symbolique. Mais qu’en est-il des autres ? Comment se caractérisent-ils et dans quels contextes ? En vrai, qu’est-ce qu’un inode ? Et PostgreSQL dans tout ça ? Autant de petites questions de curiosité que j’aborde avec vous dans cet article !

Parlons d’abord du lien symbolique

Pour faire simple, on peut comparer le lien symbolique à un raccourci Windows. Il s’agit d’un pointeur vers un fichier ou un répertoire qui permet toutes les opérations simples comme la lecture ou l’écriture.

Par exemple, pour une instance PostgreSQL, il est possible de déporter le répertoire des fichiers WAL sur un autre montage à l’aide d’un lien symbolique. Cette opération nécessite un arrêt du service et la copie des fichiers vers le nouveau montage, comme suit :

# à réaliser avec le compte root
systemctl stop postgresql-12.service

# créer le nouveau répertoire en préservant les permissions
install --owner=postgres --group=postgres --mode=700 -d /u01/pg_wal/12
mv /var/lib/pgsql/12/data/pg_wal/* /u01/pg_wal/12/

# créer le lien vers le nouveau répertoire
rmdir /var/lib/pgsql/12/data/pg_wal
ln --symbolic /u01/pg_wal/12 /var/lib/pgsql/12/data/pg_wal

# et redémarrer l'instance
systemctl start postgresql-12.service

Le lien ainsi obtenu par la commande ln --symbolic se présente comme une fausse copie du répertoire d’origine, permettant aux données d’être consultées à plusieurs endroits sans risque d’être dupliquées. La commande stat nous donne de précieuses informations à son sujet :

# FORMAT="File = %N\nType = %F\nOwner = %U:%G\nAccess = %A\nInode = %i\n"
# stat --printf="$FORMAT" /var/lib/pgsql/12/data/pg_wal
File = ‘/var/lib/pgsql/12/data/pg_wal’ -> ‘/u01/pg_wal/12’
Type = symbolic link
Owner = root:root
Access = lrwxrwxrwx
Inode = 33725146

Il apparait que son propriétaire est root, que son accès est ouvert à tous, et que l’inode qui lui est associé vaut 33919915. Qu’en est-il de répertoire contenant les journaux de transactions ?

# stat --printf="$FORMAT" /u01/pg_wal/12
File = ‘/u01/pg_wal/12’
Type = directory
Owner = postgres:postgres
Access = drwx------
Inode = 33867963

Les deux fichiers sont bien distincts et présentent des différences notables, comme les propriétaires et les droits d’accès. En réalité, Unix propose sept types de fichiers et chacun présente des caractéristiques et comportements que lui sont propres. On retrouve ainsi les fichiers, répertoires, liens symboliques, mais aussi les named pipes, les sockets, les devices ou les doors.

Le dernier attribut que remonte ma commande stat correspond au inumber ou numéro inode. Il s’agit d’un identifiant unique sur le système de fichiers permettant de retrouver toutes les métadonnées du fichier dans une table d’inodes. Nous avions vu à l’instant les droits et le propriétaire, l’inode permet également de stocker les horodatages de création ou de modification ainsi que l’adresse physique des données du fichier sur le disque.

Ainsi, pour chaque fichier sur notre système lui est associé un inode. La représentation suivante permet donc de comprendre la relation entre un lien symbolique et un répertoire.

Le mode --link de `pg_upgrade`

Les choses sont devenues passionnantes lorsque j’ai découvert la notion de lien physique, ou hardlink, qu’il était possible de créer entre deux fichiers. Ce n’est en rien une nouveauté, car inclu dans les systèmes Unix depuis longtemps mais ça m’a permis de comprendre davantage l’intérêt des fameux inodes.

Puisqu’un exemple concret parle toujours de lui-même, je propose d’étudier la méthode de migration de données d’une version 9.6 vers une version 12 de PostgreSQL avec l’outil pg_upgrade. Ce dernier propose l’option --link pour réduire le temps de migration des données sans copier les fichiers d’une instance à l’autre. Bien sûr, ce n’est pas le comportement par défaut.

La distribution CentOS 7 est utilisée pour la démonstration.
Le paquet postgresql12-server doit être installé au préalable.

# la routine setup permet la création du fichier de service ainsi
# que l'initilisation d'un répertoire de données minimaliste
/usr/pgsql-12/bin/postgresql-12-setup initdb postgresql-12

# durant la migration, l'instance 9.6 doit être arrêtée
systemctl stop postgresql-9.6.service

export PGDATAOLD=/var/lib/pgsql/9.6/data
export PGDATANEW=/var/lib/pgsql/12/data
export PGBINOLD=/usr/pgsql-9.6/bin
export PGBINNEW=/usr/pgsql-12/bin
$PGBINNEW/pg_upgrade --link --verbose

# extrait du déroulement
mappings for database "prod":
public.pgbench_accounts: 16397 to 16391

linking "/var/lib/pgsql/9.6/data/base/16384/16397" to
 "/var/lib/pgsql/12/data/base/16402/16391"
linking "/var/lib/pgsql/9.6/data/base/16384/16397_fsm" to
 "/var/lib/pgsql/12/data/base/16402/16391_fsm"
linking "/var/lib/pgsql/9.6/data/base/16384/16397_vm" to
 "/var/lib/pgsql/12/data/base/16402/16391_vm"

L’outil pg_upgrade est composé d’une série d’opération de contrôle, de copies de fichiers, d’arrêt/démarrage des instances et d’une remise à zéro des journaux de transactions avec pg_resetwal. Les lignes ci-dessus illustrent le mode --link lors de notre migration, avec la création d’un lien entre les deux versions du fichier de la table pgbench_accounts.

La méthode employée peut être consultée dans les sources de pg_upgrade et repose sur la méthode link. Regardons en détail les métadonnées des fichiers de données de la table pgbench_accounts dans les deux répertoires.

# FORMAT="${FORMAT}Links = %h\n"
# stat --printf="$FORMAT" /var/lib/pgsql/9.6/data/base/16384/16397
File = ‘/var/lib/pgsql/9.6/data/base/16384/16397’
Type = regular file
Owner = postgres:postgres
Access = -rw-------
Inode = 101132106
Links = 2

# stat --printf="$FORMAT" /var/lib/pgsql/12/data/base/16402/16391
File = ‘/var/lib/pgsql/12/data/base/16402/16391’
Type = regular file
Owner = postgres:postgres
Access = -rw-------
Inode = 101132106
Links = 2

Au niveau du système, les fichiers sont strictement similaires. Pour dire vrai, il s’agit des mêmes inodes. Les métadonnées sont communes aux deux fichiers et les blocs de données de la table pgbench_accounts résident à la même adresse physique.

À la différence du lien symbolique, ce type de lien rattache un fichier non pas à un autre fichier, mais au numéro d’inode d’un autre fichier. L’attribut Links de ma commande stat correspond au nombre de liens sur l’inode en question. Une représentation de cette relation pourait être la suivante :

Les avantages sont doubles dans le cas d’une migration majeure :

Temps de copie des données quasi-nul : le modèle de données est importé dans la nouvelle instance et les fichiers de données sont liés à ceux de la version précédente ;
Économie d’espace disque : la migration n’a pas besoin du double d’espace disque.

En contrepartie :

Pas de retour arrière : chacune des deux instances disposent de fichiers internes comme les journaux de transactions ou le fichier de contrôle, rendant incompatibles les fichiers de données à l’une des deux instances dès lors que l’autre a démarré après la migration.

Fin de vie d’une donnée liée

L’une de mes questions à l’issue d’une migration par pg_upgrade a été : « Mais que se passe-t-il si nous ne supprimons pas l’ancien répertoire de données ? ». Puisque la donnée est référencée par la nouvelle instance, toutes les nouveautés y seront stockées et il n’y a pas de risque pour l’espace disque. Vraiment ?

Comme nous le voyions précédemment, les données de la table pgbench_accounts sont accessibles à travers le numéro d’inode 101132106. Les deux liens pointent vers la même adresse physique et la même allocation d’espace disque, ici 13 Mo.

# du -lh 9.6/data/base/16384/16397 12/data/base/16402/16391
13M 9.6/data/base/16384/16397
13M 12/data/base/16402/16391

Il est possible au cours de la vie d’une table de voir son identifiant relfilenode varier au moment de la réécriture du fichier sous un nom différent. Le cas se présente lorsque l’on souhaite déplacer la table dans un autre tablespace, quand il faut la défragmenter avec VACUUM FULL, ou lors de la restauration d’un dump. Ces opérations réalisent toute une reconstruction de la table, avec le déplacement des lignes dans un nouveau fichier.

SELECT pg_relation_filepath('pgbench_accounts');
-- pg_relation_filepath
-- ----------------------
-- base/16402/16391

VACUUM FULL pgbench_accounts;
CHECKPOINT;

SELECT pg_relation_filepath('pgbench_accounts');
-- pg_relation_filepath
-- ----------------------
-- base/16402/16435

Ici, la défragmentation reconstruit la table dans un nouveau fichier 16435. L’instruction CHECKPOINT permet d’écrire sur disque la totalité des nouveaux blocs et d’actualiser l’usage des fichiers, supprimant en principe les anciens fichiers de données.

# du -lh 9.6/data/base/16384/16397 12/data/base/16402/16435
0 9.6/data/base/16384/16397
13M 12/data/base/16402/16435

# FORMAT="File = %n\nInode = %i\n"
# stat --printf="$FORMAT" 9.6/data/base/16384/16397 
File = 9.6/data/base/16384/16397
Inode = 101132106

# stat --printf="$FORMAT" 12/data/base/16402/16435
File = 12/data/base/16402/16435
Inode = 34082173

Le nouveau fichier de notre table pour l’instance 12 pèse toujours 13 Mo, le fichier maintenu par le lien physique de la version précédente a été vidé lors de l’opération VACUUM FULL et pèse à présent zéro octet. Mais il n’a pas été supprimé ! Nous nous retrouvons avec un fichier et son inode en trop sur le serveur.

Sur un système de fichiers, le nombre maximal de fichiers que l’on peut créer est défini par la quantité d’inodes disponibles, alors autant faire le ménage dès que possible pour ne pas atteindre cette limite. D’autant plus que la suppression du répertoire 9.6/data est proposée à la fin de la migration par l’outil pg_upgrade et ne présente aucun risque !

Conclusion

Apparu en version 9.0, l’outil pg_upgrade est une petite usine qui simule un import/export des structures d’une instance complète, avec la capacité de copier ou lier les anciens fichiers, de façon bien plus rapide qu’une insertion massive avec l’instruction COPY de pg_restore. C’est une solution de choix lorsque l’on migre d’une version majeure à l’autre sur un même serveur, notamment pour le gain de temps non négligeable que propose l’option --link.

Avec la version 12, l’outil propose une nouvelle option --clone et s’appuie sur la notion de liens « par référence » (ou reflinks), conçus initialement sur les systèmes de fichiers supportant la copie sur écriture. La documentation précise que la copie des fichiers est pratiquement instantanée et n’affecte pas l’ancienne instance.

Peut-être l’occasion de creuser le sujet dans un prochain article ?

Linux on Carnet de découvertes

Sauvegardes personnelles avec Restic

Prise en main éclair

Planification avec systemd

Conclusion

Poissons et coquillages

Beurk, le Bash

L’ami Fish, Friendly Interactive Shell

Un langage qui vous veut du bien

Osons la modernité

Construire PostgreSQL avec Meson

En finir avec autoconf

Meson, une alternative moderne

Conclusion

BorgBackup ou la sauvegarde facile

Des atouts séduisants

Planification avec systemd

Conclusion

Les liens physiques avec pg_upgrade

Parlons d’abord du lien symbolique

Le mode --link de pg_upgrade

Fin de vie d’une donnée liée

Conclusion

Le mode --link de `pg_upgrade`