Sauvegarde 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.

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.

La brêve histoire du fichier backup_label

Florent Jardin — Tue, 19 Jan 2021 00:00:00 +0000

Je suis resté longtemps ignorant des mécanismes de journalisation et de PITR avec PostgreSQL alors même qu’il s’agit d’un des fonctionnements critiques pour la durabilité des données d’une instance. Mieux comprendre ces concepts m’aurait permis à une époque, d’être plus serein lors de la mise en place de sauvegardes et surtout au moment de leur restauration !

Dans cet article, je vous propose de revenir sur un fichier anecdotique qui a fait parlé de lui pendant plusieurs années : le fichier backup_label. Qui est-il et à quoi sert-il ? Comment a-t-il évolué depuis sa création en version 8.0 de PostgreSQL et qu’adviendra-t-il de lui dans les prochaines années ?

Il était une fois la journalisation

En guise d’introduction pour mieux comprendre cet article, il est bon d’expliquer que chaque opération d’écriture dans PostgreSQL comme un UPDATE ou un INSERT, est écrite une première fois au moment du COMMIT de la transaction dans un groupe de fichiers, que l’on appelle WAL ou journaux de transactions. Ajoutées les unes à la suite des autres, ces modifications représentent un faible coût pour l’activité des disques par rapport aux écritures aléatoires d’autres processus de synchronisation à l’œuvre dans PostgreSQL.

Parmi l’un d’eux, le processus checkpointer s’assure que les nouvelles données en mémoire soient définitivement synchronisées dans les fichiers de données à des moments réguliers que l’on appelle CHECKPOINT. Cette écriture en deux temps sur les disques apporte d’excellentes performances et garantit qu’aucun bloc modifié ne soit perdu lorsqu’une transaction se termine correctement.

Par ce mécanisme de journalisation, les fichiers de données de notre instance sont constamment en retard sur la véritable activité transactionnelle, et ce, jusqu’au prochain CHECKPOINT. En cas d’arrêt brutal du système, les blocs en attente de synchronisation (dirty pages) présents dans la mémoire Shared Buffer sont perdus et les fichiers de données sont dit incohérents car ils mixent des données de transactions anciennes, nouvelles, valides ou invalides.

Dans pareilles situations, il est possible de redémarrer l’instance afin qu’elle rejoue les modifications dans l’ordre des transactions telles qu’elles avaient été écrites dans les WAL. Cette reconstruction des fichiers de données pour retrouver leur état consistant est sobrement appelée la récupération des données ou crash recovery.

En version 8.0 et supérieures, ce mécanisme a permis l’émergence des solutions de restauration dans le temps (Point In Time Recovery) et de réplication par récupération des journaux (Log Shipping) sur une instance secondaire.

Que ce soit à la suite d’un crash ou dans le cadre d’une restauration de sauvegarde, les fichiers de données doivent être cohérents pour assurer le retour du service et l’accès en écriture aux données. Quelle mauvaise surprise n’a-t-on pas lorsqu’une instance PostgreSQL interrompt son démarrage avec le message suivant :

PANIC: could not locate a valid checkpoint record

Il indique que l’instance a détecté une inconsistance dans les fichiers au moment de son démarrage et qu’elle échoue à trouver le point de reprise le plus proche de son état. Sans les journaux, la récupération échoue et s’arrête. À cet instant précis, vos nerfs et votre politique de sauvegarde sont mis à rude épreuve.

Pour le dire encore autrement : en l’absence des journaux de transactions ou de leurs archives, vos plus récentes données sont perdues.

… Et l’outil pg_resetwal ne les récuperera pas pour vous.

Entre en scène le backup_label

Après ce charmant avertissement, on considèrera que l’archivage des journaux de transactions n’est plus une option dans vos plans de sauvegarde. Assurez-vous que ces archives soient stockées sur un espace sécurisé, voire une zone décentralisée pour qu’elles soient accessibles par toutes les instances secondaires lorsque vous devez déclencher votre plan de bascule.

Pour ceux ayant atteint cette partie de l’article, vous ne devriez pas être trop perdus si je vous annonce que le fichier backup_label est un composant d’un plus large concept, à savoir : la sauvegarde.

Le fichier historique de sauvegarde est un simple fichier texte. Il contient le label que vous avez attribué à l’opération pg_basebackup, ainsi que les dates de début, de fin et la liste des segments WAL de la sauvegarde. Si vous avez utilisé le label pour identifier le fichier de sauvegarde associé, alors le fichier historique vous permet de savoir quel fichier de sauvegarde vous devez utiliser pour la restauration.

Source : Réaliser une sauvegarde de base

Prenons une instance classique en cours d’exécution et réalisons une sauvegarde avec l’outil pg_basebackup que nous vante la documentation. Observons son comportement le plus simple avec la génération d’une archive au format tar.

$ pg_basebackup --label=demo --pgdata=backups --format=tar \
 --checkpoint=fast --verbose
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/16000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created temporary replication slot "pg_basebackup_15594"
pg_basebackup: write-ahead log end point: 0/16000100
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: syncing data to disk ...
pg_basebackup: renaming backup_manifest.tmp to backup_manifest
pg_basebackup: base backup completed

Depuis la version 10, l’option --wal-method est définie sur stream par défaut, ce qui indique que tous les journaux de transactions présents et à venir dans le sous-répertoire pg_wal de l’instance seront également sauvegardés dans une archive dédiée, notamment grâce à la création d’un slot de réplication temporaire.

Depuis la version 13, l’outil embarque le fichier manifeste dans la sauvegarde afin de pouvoir contrôler l’intégrité de la copie par la commande pg_verifybackup. Contrôlons le contenu du répertoire de sauvegarde et recherchons le tant attendu backup_label.

$ tree backups/
backups/
├── backup_manifest
├── base.tar
└── pg_wal.tar

$ tar -xf backups/base.tar --to-stdout backup_label
START WAL LOCATION: 0/16000028 (file 000000010000000000000016)
CHECKPOINT LOCATION: 0/16000060
BACKUP METHOD: streamed
BACKUP FROM: master
START TIME: 2021-01-18 15:22:52 CET
LABEL: demo
START TIMELINE: 1

Ce dernier se trouve à la racine de notre archive et joue un rôle très particulier dans le processus de démarrage startup puisqu’il renseigne le point de reprise à partir duquel rejouer les journaux. Dans notre exemple, il s’agit de la position 0/16000060 présente dans le journal 000000010000000000000016. En cas d’absence du backup_label, le processus de démarrage consultera à la place le fichier de contrôle afin de déterminer le plus récent point de reprise sans garantie qu’il soit le bon.

L’heure de gloire

Vous conviendrez que la forme et l’intérêt du fichier backup_label sont anecdotiques (bien qu’essentiels) dans l’architecture de sauvegarde avec PostgreSQL. Il ne s’agit que d’un fichier texte de quelques lignes, requis exclusivement pour assurer certains contrôles lors d’une restauration.

Et pourtant, la petite révolution que provoqua la version 8.0 en janvier 2005 avec l’archivage continu et la restauration PITR suscita naturellement la créativité de l’équipe de développement au cours des années qui suivirent. Le fichier backup_label évolua pour gagner en modularité et en stabilité.

À l’origine, l’outil pg_basebackup n’était pas encore disponible et seul l’appel à la méthode pg_start_backup() permettait de générer le fichier dans lequel se trouvaient les quatres informations suivantes pour accompagner la sauvegarde à chaud :

# backend/access/transam/xlog.c
fprintf(fp, "START WAL LOCATION: %X/%X (file %s)\n",
 startpoint.xlogid, startpoint.xrecoff, xlogfilename);
fprintf(fp, "CHECKPOINT LOCATION: %X/%X\n",
 checkpointloc.xlogid, checkpointloc.xrecoff);
fprintf(fp, "START TIME: %s\n", strfbuf);
fprintf(fp, "LABEL: %s\n", backupidstr);

Les versions majeures se sont enchaînées avec son lot de corrections ou d’améliorations. Parmi les contributions notables, j’ai relevé pour vous :

Contribution de Laurenz Albe (commit c979a1fe)

Publié avec la version 8.4, le code xlog.c se voit enrichir d’une méthode interne pour annuler la sauvegarde en cours. L’exécution de la commande pg_ctl stop en mode fast renomme le fichier en backup_label.old ;
Contribution de Dave Kerr (commit 0f04fc67)

Apparue avec la version mineure 9.0.9, la méthode pg_start_backup() inclut un appel fsync() pour forcer l’écriture sur disque du fichier backup_label. Cette sécurité garantit la consistance d’un instantané matériel ;
Contribution de Heikki Linnakangas (commit 41f9ffd9)

Proposé en version 9.2, ce patch corrige des comportements anormaux de restauration à partir de la nouvelle méthode de sauvegarde par flux. Le fichier backup_label précise la méthode employée entre pg_start_backup ou streamed ;
Contribution de Jun Ishizuka et Fujii Masao (commit 8366c780)

Depuis la version 9.2, la méthode pg_start_backup() peut être exécutée sur une instance secondaire. Le rôle de l’instance d’où provient la sauvegarde est renseignée dans le fichier backup_label ;
Contribution de Michael Paquier (commit 6271fceb)

Ajoutée en version 11, l’information timeline dans le fichier backup_label rejoint les précédentes pour comparer sa valeur avec celles des journaux à rejouer lors d’une récupération de données ;

Vous l’aurez compris, pendant de nombreuses années, la capacité de faire une sauvegarde dite consistante, reposait sur les deux méthodes vues précédemment. La fonction historique pg_start_backup() fut particulièrement touchée par d’incessantes critiques au sujet d’un comportement non souhaité, notamment son mode « exclusif ».

Voyons cela ensemble sur une instance récente en version 13 :

SELECT pg_start_backup('demo');
-- pg_start_backup
-- -----------------
-- 0/1D000028

$ kill -ABRT $(head -1 data/postmaster.pid)
$ cat data/backup_label
START WAL LOCATION: 0/1D000028 (file 00000001000000000000001D)
CHECKPOINT LOCATION: 0/1D000060
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2021-01-18 16:49:57 CET
LABEL: demo
START TIMELINE: 1

Le signal ABRT interrompt sans préavis le processus postmaster de l’instance et la routine d’arrêt CancelBackup n’est pas appelée pour renommer le fichier en backup_label.old. Avec une activité classique de production, les journaux sont recyclés et archivés à mesure que les transactions s’enchaînent. Au démarrage de l’instance, le fichier backup_label présent dans le répertoire de données est lu par erreur et n’indique plus le bon point de reprise pour la récupération des données.

LOG: database system was shut down at 2021-01-18 17:08:43 CET
LOG: invalid checkpoint record
FATAL: could not locate required checkpoint record
HINT: If you are restoring from a backup, touch "data/recovery.signal"
 and add required recovery options.
 If you are not restoring from a backup, try removing the file
 "data/backup_label".
 Be careful: removing "data/backup_label" will result in a corrupt
 cluster if restoring from a backup.
LOG: startup process (PID 19320) exited with exit code 1
LOG: aborting startup due to startup process failure
LOG: database system is shut down

Ce message complet n’est apparu qu’à partir de la version 12 avec un avertissement plus prononcé dans la documentation au sujet du fichier, faisant suite à de longs échanges sur la possibilité de se séparer ou non de cette méthode. Dans l’un d’eux, on peut lire la remarquable intervention de Robert Haas qui revient sur le succès de cette fonctionnalité depuis ses débuts et la confusion fréquente que rencontrent les utilisateurs qui ne comprennent ni la complexité ni les instructions claires de la documentation.

À présent, une note y clarifie les choses.

Ce type de sauvegarde peut seulement être réalisé sur un serveur primaire et ne permet pas des sauvegardes concurrentes. De plus, le fichier backup_label créé sur un serveur primaire peut empêcher le redémarrage de celui-ci en cas de crash. D’un autre côté, la suppression à tord de ce fichier d’une sauvegarde ou d’un serveur secondaire est une erreur fréquente qui peut mener à de sérieuses corruptions de données.

Source : Créer une sauvegarde exclusive de bas niveau

Place à la relève

Cette limitation était connue de longue date et l’équipe de développement proposa une alternative en septembre 2016 avec la sortie de la version 9.6 et l’introduction de la sauvegarde dite « concurrente ». Depuis ce jour, la sauvegarde exclusive est annoncée obsolète par les développeurs et pourrait être supprimée dans les versions à venir.

Le fichier backup_label ne disparaît pas en soi. Ses informations sont toujours requises pour la restauration PITR mais le fichier n’a plus d’état transitoire sur le disque et n’est plus écrit dans le répertoire de l’instance par la méthode pg_start_backup(). En remplacement, l’administrateur ou le script de sauvegarde doit être en capacité d’exécuter la commande pg_stop_backup() dans la même connexion à l’instance pour y récupérer les éléments et reconstruire le fichier au moment de la restauration.

SELECT pg_start_backup(label => 'demo', exclusive => false, fast => true);
-- pg_start_backup
-- -----------------
-- 0/42000028

SELECT labelfile FROM pg_stop_backup(exclusive => false);
-- labelfile
-- ----------------------------------------------------------------
-- START WAL LOCATION: 0/42000028 (file 000000010000000000000042)+
-- CHECKPOINT LOCATION: 0/42000060 +
-- BACKUP METHOD: streamed +
-- BACKUP FROM: master +
-- START TIME: 2021-01-18 18:17:16 CET +
-- LABEL: demo +
-- START TIMELINE: 1 +

Une autre méthode nous permet de retrouver facilement le contenu du fichier, d’autant plus si l’archivage est en place sur l’instance. En effet, à l’annonce de la fin d’une sauvegarde, les éléments précédents sont écrits dans un fichier d’historique .backup au sein des journaux de transactions et un fichier .ready est ajouté dans le répertoire archive_status à destination du processus d’archivage. Une recherche rapide sur le dépôt des archives plus tard, et nous sommes en possession du fichier prêt à l’emploi pour une restauration.

$ find archives -type f -not -size 16M
archives/000000010000000000000016.00000028.backup

$ grep -iv ^stop archives/000000010000000000000016.00000028.backup
START WAL LOCATION: 0/42000028 (file 000000010000000000000042)
CHECKPOINT LOCATION: 0/42000060
BACKUP METHOD: streamed
BACKUP FROM: master
START TIME: 2021-01-18 18:17:16 CET
LABEL: demo
START TIMELINE: 1

La venue d’une brique complète pour la sauvegarde concurrente a permis l’émergence de nouvelles solutions de sauvegardes, plus performantes et plus modulaires que pg_basebackup. Dans le paysage des outils tiers, vous entendriez peut-être parler de pgBackRest écrit en C, Barman écrit en Python ou pitrery écrit en Bash. En outre, ces outils soulagent l’administrateur de la rédaction de scripts devenus trop complexes et loin d’être immuable dans les années à venir.

Morale de l’histoire

Au fil des versions, le fichier backup_label a enduré de nombreuses tempêtes et rebondissements pour aboutir à une forme plus aboutie de la sauvegarde et de la restauration physique dans PostgreSQL.

Si vous êtes responsable de la maintenance d’instances, particulièrement dans un environnement virtualisé, je ne peux que vous recommander de contrôler vos politiques de sauvegarde et l’outillage associé. Il n’est pas rare de voir des hyperviseurs réaliser des instantanées des machines virtuelles avec des appels de la méthode pg_start_backup() en mode exclusif.

Les outils spécialisés cités plus haut peuvent/doivent être étudiés. S’ils ne correspondent pas très bien à vos besoins, il est toujours possible de bénéficier des mécanismes de la sauvegarde concurrente à l’aide d’un fichier temporaire sous Linux et sa commande mkfifo.

La décision de supprimer définitivement la sauvegarde exclusive n’est actuellement plus débattue et a été retirée du backlog de développement lors du Commitfest de juillet 2020. Lors des derniers échanges, le contributeur David Steele (auteur de pgBackRest notamment) annonçait qu’une sauvegarde exclusive pourrait stocker son fichier backup_label directement en mémoire partagée plutôt que sur le disque et ainsi corriger sa principale faiblesse :

It might be easier/better to just keep the one exclusive slot in shared memory and store the backup label in it. We only allow one exclusive backup now so it wouldn’t be a loss in functionality.

La suite au prochain épisode !

Construire une instance standby avec pgBackRest

Florent Jardin — Thu, 07 Nov 2019 16:00:00 +0200

Pour cette démonstration, j’utilise le système Debian et dispose de deux instances en version 12, d’un serveur de sauvegarde et du paquet pgbackrest pour mettre en place une réplication et observer les nouveautés concernant la disparition du fichier recovery.conf.

Pour faciliter le transfert des WAL et des sauvegardes PITR, j’ajoute un compte utilisateur pgbr sur le serveur de sauvegarde, accessible à partir des deux instances avec un partage de clé SSH. (Conseil : toujours externaliser les sauvegardes de bases de données sur un système et un stockage indépendant de l’infrastructure de production PostgreSQL…)

sudo useradd -s /bin/bash -md /etc/pgbackrest pgbr
sudo mv /etc/pgbackrest.conf /etc/pgbackrest/
sudo chown pgbr: /etc/pgbackrest/pgbackrest.conf \
 /var/log/pgbackrest /var/lib/pgbackrest

La réplication par flux (streaming) est assurée par un compte dédié nommé streamer, autorisé à se connecter sur les instances PostgreSQL du sous-réseau grâce à l’ajout d’une entrée dans le fichier pg_hba.conf.

sudo -u postgres createuser --replication --pwprompt streamer

# pg_hba.conf
# Allow replication connections from trusted subnet, by a user with the
# replication privilege.
host replication streamer 10.1.0.0/28 md5

Le fichier .pgpass est déposé sur chaque serveur pour le compte postgres, afin d’assurer la connexion du compte streamer sans saisie de mot de passe.

Dans ce scénario, les archives générées par l’instance primaire seront déplacées sur le serveur de sauvegarde et l’instance standby les consultera au besoin. La planification des sauvegardes sera sous la responsabilité de l’utilisateur pgbr avec une administration distante. La configuration fine se découpe dans les fichiers suivants.

# /etc/pgbackrest/bkp1.conf
[lab]
pg1-host=lab1
pg2-host=lab2
pg1-host-user=postgres
pg2-host-user=postgres
pg1-path=/var/lib/postgresql/12/lab1
pg2-path=/var/lib/postgresql/12/lab2
pg1-host-config=/etc/pgbackrest/lab1.conf
pg2-host-config=/etc/pgbackrest/lab2.conf

[global]
start-fast=y
log-level-console=info
repo1-retention-full=2
repo1-path=/var/lib/pgbackrest

# /etc/pgbackrest/lab1.conf
[lab]
pg1-path=/var/lib/postgresql/12/lab1

[global]
repo1-host=bkp1
repo1-host-user=pgbr

# /etc/pgbackrest/lab2.conf
[lab]
pg1-path=/var/lib/postgresql/12/lab2
recovery-option=recovery_target_timeline=latest
recovery-option=primary_conninfo=host=lab1 port=5432 user=streamer

[global]
repo1-host=bkp1
repo1-host-user=pgbr

Avant de pouvoir créer la stanza, il est nécessaire de démarrer l’instance secondaire en mode standby ; il suffit de positionner un fichier standby.signal dans le répertoire de données et de redémarrer l’instance :

sudo pg_ctlcluster stop 12 lab2
sudo -u postgres touch /var/lib/postgresql/12/lab1/standby.signal
sudo pg_ctlcluster start 12 lab2

À partir de ce moment, et même si les deux instances ne partagent pas les mêmes données, je peux créer la stanza avec l’outil pgbackrest sur mon serveur de sauvegarde avec l’utilisateur dédié.

sudo -u pgbr pgbackrest stanza-create \
 --stanza=lab --config=/etc/pgbackrest/bkp1.conf

Dès ce moment, mon instance, consciente de l’espace de stockage distant, peut envoyer ses archives de WAL via la commande archive-push de pgbackrest. Un redémarrage est requis pour activer le mode archive.

ALTER SYSTEM SET archive_mode = on;
ALTER SYSTEM SET archive_command =
 'pgbackrest archive-push %p --stanza=lab --config=/etc/pgbackrest/lab1.conf';

Et pour finir, une première sauvegarde complète peut être lancée sur le serveur de sauvegarde pour assurer la construction de l’instance standby.

sudo -u pgbr pgbackrest backup --stanza=lab --config=/etc/pgbackrest/bkp1.conf
sudo -u pgbr pgbackrest info

# stanza: lab
# status: ok
# cipher: none
#
# db (current)
# wal archive min/max (12-1): 000000010000000000000008/000000010000000000000008
#
# full backup: 20191107-103443F
# timestamp start/stop: 2019-11-07 10:34:43 / 2019-11-07 10:35:09
# wal start/stop: 000000010000000000000008 / 000000010000000000000008
# database size: 23.5MB, backup size: 23.5MB
# repository size: 2.8MB, repository backup size: 2.8MB

La sauvegarde de l’instance primaire peut être restaurée sur la seconde instance avec les options --delta et --type=standby pour écraser les fichiers erronés et ajouter le descripteur standby.signal dans le répertoire de données. pgBackRest se charge de configurer les options de réplication dans le fichier postgresql.auto.conf

sudo pg_ctlcluster stop 12 lab2
sudo -u postgres pgbackrest restore --stanza=lab \
 --delta --type=standby --config=/etc/pgbackrest/lab2.conf
sudo pg_ctlcluster start 12 lab2

Tadaa ! Une connexion est alors établie entre les deux nœuds et l’on constate que l’utilisateur streamer rejoue en asynchrone les transactions de l’instance primaire vers l’instance standby.

select * from pg_stat_replication;

-- -[ RECORD 1 ]----+------------------------------
-- pid | 8893
-- usesysid | 16384
-- usename | streamer
-- application_name | 12/lab2
-- client_addr | 10.1.0.1
-- client_hostname |
-- client_port | 38820
-- backend_start | 2019-11-07 10:50:22.424464+00
-- backend_xmin |
-- state | streaming
-- sent_lsn | 0/A000060
-- write_lsn | 0/A000060
-- flush_lsn | 0/A000060
-- replay_lsn | 0/A000060
-- write_lag | 00:00:00.001095
-- flush_lag | 00:00:00.004415
-- replay_lag | 00:00:00.004696
-- sync_priority | 0
-- sync_state | async
-- reply_time | 2019-11-07 12:39:59.595595+00

Pour la rédaction de cet article, je n’ai pas véritablement utilisé trois serveurs, mais bien un seul en réalité. L’astuce pour faire tourner deux instances sur le même port 5432 consiste à ajouter des IP virtuelles sur l’interface du serveur et de faire résoudre les noms de machines par le fichier /etc/hosts local.

sudo ip add add 10.1.0.1/28 dev ens6
sudo ip add add 10.1.0.2/28 dev ens6
sudo ip add add 10.1.0.3/28 dev ens6

Les instances doivent ensuite être installées/configurées avec les bons paramètres listen_addresses et unix_socket_directories comme suivent :

sudo apt-get install -y postgresql-common
sudo vim /etc/postgresql-common/createcluster.conf
sudo apt-get install -y postgresql-12

sudo -u postgres mkdir -p /var/run/postgresql/lab{1,2}
sudo pg_createcluster 12 lab1 \
 --pgoption listen_addresses='10.1.0.1' --pgoption port=5432 \
 --pgoption unix_socket_directories=/var/run/postgresql/lab1
sudo pg_createcluster 12 lab2 \
 --pgoption listen_addresses='10.1.0.2' --pgoption port=5432 \
 --pgoption unix_socket_directories=/var/run/postgresql/lab2

sudo pg_ctlcluster 12 lab1 start
sudo pg_ctlcluster 12 lab2 start

Quelques ajustements de droits sur le répertoire /tmp/pgbackrest pour les fichiers de verrous (paramètre --lock-path) et le tour est joué !