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

Faire vivre une communauté

Florent Jardin — Tue, 30 Jul 2024 09:30:00 +0000

Le PG Day France s’est tenu les 11 et 12 juin derniers à Lille, ma ville natale. Il s’agit de l’événement de la communauté française de PostgreSQL qui pose ses valises dans une ville différente chaque année. L’occasion était trop belle pour moi et j’y ai rencontré de nombreuses personnes venant de toute la France et de ses alentours, pour discuter de PostgreSQL au cours de deux jours d’ateliers et de conférences.

Pour cette édition, j’ai eu le plaisir de prendre la parole et de faire un retour d’expérience sur l’animation du groupe Meetup local dont j’ai repris les rennes il y a maintenant quatre ans. Dans cet article, je souhaite retranscrire les principaux points abordés lors de cette présentation, en attendant que la vidéo de la conférence soit mise en ligne.

Le support de ma présentation est disponible à cette adresse.

Qu’est-ce qu’un PUG ?

Un « PUG » est un groupe d’utilisateur·rices de PostgreSQL, ou « PostgreSQL User Group » en anglais. Réunis régulièrement pour échanger autour de PostgreSQL, les PUGs sont des lieux de rencontres et d’apprentissage pour les personnes intéressées par ce système de gestion de base de données. Ces communautés locales sont fréquentes, particulièrement pour les logiciels libres, et permettent de fédérer les utilisateurs et utilisatrices autour d’un même outil.

À Lille, nous avons la chance d’avoir un tissu économique très dynamique, avec de nombreuses communautés, telles que le Ch’ti JUG (Java User Group), le GDG Lille (Google Developer Group), Nord Agile ou encore Software Craft Lille. Quoi de plus naturel que de vouloir proposer à une poignée de ce public des rencontres autour de PostgreSQL ?

Une page du projet PostgreSQL recense les différents PUGs à travers le monde, et il est possible d’y trouver des groupes dans de nombreux pays, dont la France. À l’heure de la rédaction de ma conférence, je dénombrais 62 groupes mondiaux, dont 5 en France : Paris, Lyon, Nantes (non référencée), Toulouse et Lille.

La plateforme Meetup est souvent utilisée pour organiser les rencontres, et pour preuve, 46 PUGs y sont affiliés. Il s’agit d’une commodité depuis plus de 10 ans, et la plupart des groupes français y sont inscrits.

La création d’un PUG reconnu par la communauté internationale est un processus simple, qui nécessite de constituer un groupe d’organisation et de postuler à l’adresse e-mail usergroups@postgresql.org. Le groupe doit respecter un certain nombre de règles, prévues par la charte des PUGs, et doit s’engager à respecter les valeurs de la communauté PostgreSQL. En substance, voici les points qu’il faut retenir :

Le groupe doit être ouvert à tous et toutes, sans discrimination.
Les rencontres doivent être proposées a minima une fois tous les deux ans.
Les rencontres ne doivent pas faire l’objet d’un accord de confidentialité (NDA).
Les rencontres sont rattachées à la zone géographique du groupe.
Une entreprise ne peut pas être représentée à 50% ou plus dans le comité d’organisation.
La sélection des conférences est à la discrétion du comité d’organisation.
Les entreprises peuvent promouvoir leurs produits et leurs services, si leurs activités facilitent l’adoption de PostgreSQL et si les contenus présentés sont de nature technique.
Le groupe doit divulguer le nom des sponsors, et peut les mentionner en introduction des rencontres.
Le PUG doit adopter un code de conduite et peut utiliser celui de la communauté PostgreSQL.

Genèse du groupe

Le groupe Meetup PostgreSQL Lille a été fondé le 25 février 2016 sur la plateforme éponyme. À l’époque, l’idée de reproduire le format des Meetup à Paris était partagée entre Guillaume Lelarge et Pierre Hilbert, deux lillois qui se croisaient régulièrement aux événements. L’une des principales motivations était de participer à la promotion du logiciel libre avec un partage de retours d’expérience pour inspirer les autres acteurs locaux.

À cette période, je fréquentais moi-même les événements organisés par le groupe Meetup Oracle Paris et Province, et je suivais avec attention les conférences autour de PostgreSQL dans ma région. La première rencontre du groupe PG Lille a eu lieu le 24 juin 2016, dans les locaux de Decathlon Campus (Villeneuve D’Ascq, 59). J’ai été séduit par le format et l’ambiance décontractée, et j’en ai gardé un excellent souvenir.

Cependant, la régularité des rencontres n’a pas été au rendez-vous du projet. L’événement suivant fut planifié plus d’une année plus tard, le 17 octobre 2017 et ce fut le seul auquel je n’ai pas pu participer. Les impératifs professionnels de Guillaume et de Pierre ne leur ont pas permis de maintenir le rythme, et le groupe a été laissé en sommeil pendant plus de trois années.

C’est en 2019 que j’ai pris la décision de reprendre le flambeau, en proposant à Pierre de me transmettre les droits d’administration du groupe. Mon arrivée chez Dalibo en tant que consultant PostgreSQL m’a donné l’opportunité de faire la rencontre d’experts passionnés, notamment Guillaume Lelarge et Stefan Fercot, qui m’ont encouragé à reprendre le projet.

Fort d’un réseau professionnel de qualité sur Twitter à l’époque, j’ai pu rapidement mobiliser une équipe de bénévoles pour organiser le Meetup du 28 janvier 2020. J’ai pu compter sur le soutien de Stefan Fercot (Dalibo), de Stéphane Definin (Think) et de Sébastien Freiss (SFEIR) pour faire de cette reprise un petit succès.

… Malheureusement, en mars de cette même année, la pandémie de COVID-19 a contraint le groupe à suspendre ses projets et je n’ai pas eu le courage de proposer des contenus en ligne, au grand dam des membres du groupe. Pour l’anecdote, aucun autre groupe Meetup de France n’a été épargné par la crise sanitaire et les restrictions en vigueur.

Une pause de deux années supplémentaires s’est imposée au groupe, avant que ne se stabilise la situation sanitaire. En 2022, j’ai ainsi contacté Lætitia Avrot, une membre très active de la communauté française, pour relancer les activités et retrouver une dynamique et un rythme pour ses membres. L’événement du 14 avril 2022 fut un soulagement pour moi, voyant que je pouvais toujours compter sur la participation de la communauté.

À partir de cet instant, aucune nouvelle ombre n’est venue assombrir le tableau, et le groupe a pu reprendre l’organisation régulière de rencontres, de deux à trois par ans. La communauté s’est élargie, et le comité d’organisation s’est renforcé avec l’arrivée de Yoann La Cancellera en 2023, qui a permis notamment de déposer une demande de reconnaissance au sein de la communauté internationale, le 24 février 2023.

How-to Meetup

En guise de conclusion à ce retour d’expérience, j’ai voulu partager toutes les étapes nécessaires pour organiser un Meetup, en appuyant sur les points cruciaux de réussites et les pièges à éviter.

Accueil : trouver le lieu d’accueil de pour l’événement

À l’image du PG Day France qui change de lieu chaque année, le groupe Meetup PG Lille a fait le choix de varier les lieux d’accueil à chaque rencontre. Cela permet de découvrir de nouveaux espaces et de stimuler la curiosité inter-communauté. Les entreprises locales sont souvent ravies de pouvoir accueillir des événements techniques, et cela permet de renforcer les liens entre les acteurs locaux.

La recherche d’un lieu est souvent la première étape de l’organisation d’un Meetup. Il est important de trouver un espace qui puisse accueillir entre dix et quarante personnes, avec un accès en transports en commun ou un parking à proximité. Pour cela, j’ai eu l’occasion d’user de plusieurs stratégies :

Le bouche-à-oreille : demander à ses contacts professionnels s’ils connaissent des lieux d’accueil potentiels
Les réseaux sociaux : publier une annonce sur Twitter ou LinkedIn pour solliciter des propositions spontanées ou des pistes à étudier
La privatisation d’un espace : contacter les espaces de coworking ou les salles de réunion pour obtenir un devis de location
S’allier avec d’autres groupes : proposer un partenariat avec un autre groupe Meetup pour partager les frais de location ou pour bénéficier d’un lieu d’accueil déjà identifié

Intervenant·es : trouver deux présentations variées

Dès le premier Meetup, Pierre et Guillaume ont fait le choix de proposer deux présentations techniques pour varier les sujets et les formats. Cela permet de toucher un public plus large et de satisfaire les attentes des membres du groupe. Cette formule a été reprise pour les rencontres suivantes, et a été un succès à chaque fois.

La recherche d’intervenant·es est un travail qui demande du temps et de la patience. Souvent, une rencontre opportune ou une discussion informelle peut déboucher sur une proposition de présentation. Le mieux est de se constituer un vivier de personnes ressources, qui pourront être sollicitées en cas de besoin. Ce n’est pas toujours facile, c’est un travail de longue haleine, mais cela en vaut la peine.

Discutez autours de vous, demandez à vos collègues, à vos amis, à vos contacts professionnels s’ils ne sont pas intéressés pour partager leur expérience ou leur expertise, ou s’ils ne connaissent pas quelqu’un qui pourrait être intéressé.

Apéro : prolonger la soirée avec un temps fort communautaire (networking)

Selon moi, c’est l’étape la plus importante de l’organisation d’un Meetup. (rires !)

C’est le moment où les membres du groupe peuvent échanger, discuter, partager, et se rencontrer. C’est un temps fort de la soirée qui me tient particulièrement à cœur, et qui est intimement lié à la réussite de l’événement. Le networking est ce qui favorise le mieux la sérendipité, la rencontre fortuite, le partage d’expérience, et la création de liens durables. Je discute des prochains projets du groupe avec les membres et le comité d’organisation, et je prends des notes sur les attentes de chacun·es et j’écoute leurs suggestions.

Bien entendu, il est important de prévoir des boissons et des encas pour prolonger la soirée. Il faut prévoir un espace pour faciliter la circulation et la création naturelle de petits groupes de discussion. Le choix d’un sponsor est principalement motivé par la prise en charge de ces frais, avec une facture ou une note de frais à l’appui.

Jusqu’à présent, aucun incident n’est à déplorer, les participants et participantes respectent les quelques règles de sécurité et de conduite que l’on énonce en début de soirée.

Communication : atteindre la jauge d’inscription

Cette étape est à prendre au sérieux un mois avant la tenue de l’événement. Il s’agit de maximiser la visibilité de l’événement pour atteindre la jauge maximale établie par le lieu qui accueille l’événement. Pour cela, j’ai eu l’occasion de me doter de plusieurs méthodes :

Être le plus exhaustif possible dans la description de l’événement (date, lieu, horaires, programme, sponsors, visuels, etc.)
Créer du contenu régulier sur les réseaux sociaux pour rappeler la date de l’événement et les modalités d’inscription (LinkedIn majoritaire, Twitter par le passé)
Solliciter les participants de l’événement pour qu’ils partagent l’événement sur leurs réseaux sociaux ou leurs réseaux d’entreprise
Informer la communauté française avec la liste de diffusion pgsql-fr-generale pour toucher un public plus large, voire donner envie à d’autres groupes de se lancer dans l’organisation de Meetup (qui sait ?)

Identité visuelle (optionnelle)

Au cours des derniers mois, nous avons travaillé avec Yoann, la refonte de l’identité visuelle du groupe Meetup avec un nouveau logo et une nouvelle charte graphique. C’est cosmétique, mais cela permet de donner une image plus professionnelle et une identité forte au sein des communautés lilloises existantes. Nous espérons nous faire une petite place et une petite notoriété dans le paysage local.

Pour avoir délégué par deux fois la création de la vignette de l’événement, je recommande de travailler avec un graphiste ou un designer pour obtenir un résultat professionnel et soigné. En attendant qu’un des membres qui m’entoure soit suffisamment qualifié, on fait avec les moyens du bord.

Enfin, et c’était notre petite fierté de l’année, nous nous sommes dotées d’un logo Slonik, la mascotte de PostgreSQL. La démarche de création s’est appuyée énormément sur les nouveaux outils de génération par intelligences artificielles, et nous avons été bluffés par la qualité du résultat. Un grand merci à Isaac pour son aide précieuse dans les retouches et les ajustements du logo.

Remerciements

Au cours de cette conférence, j’ai eu l’occasion de remercier un tas de monde. En particulier, les membres de l’association PostgreSQL France, pour leur confiance qu’ils nous ont accordée, Matthieu Cornillon et moi-même, d’avoir accepté notre dossier de candidature pour le choix de la ville de Lille cette année 2024.

Un des slides de ma présentation était dédié à toutes les entreprises qui ont accueilli nos rencontres, et qui, sans le savoir, m’ont permis d’ajuster le format et le contenu de nos Meetups. Un grand merci à elles pour leur sympathie et leur accueil chaleureux. C’était également l’opportunité de mettre en avant les intervenants et les intervenantes qui ont accepté de partager leur expérience et leur expertise lors des Meetup PostgreSQL Lille. Un grand merci à elles et à eux d’avoir vécu l’aventure avec moi !

Enfin, j’ai été heureux que ce retour d’expérience puisse faire écho à quelques personnes dans la salle, qui m’ont félicité pour le travail accompli et m’ont informé de leur intention de se lancer dans l’organisation de Meetup dans leur propre ville. C’est une belle récompense pour moi, et cela me donne envie de poursuivre mon engagement et de donner l’exemple pour la promotion de PostgreSQL en France.

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.

Migrer vers PostgreSQL

Florent Jardin — Mon, 06 Dec 2021 00:00:00 +0000

Le marché de la migration en France est intense. Le Groupe de Travail Inter-Entreprises PostgreSQL (PGGTIE) a même publié un guide de transition à PostgreSQL à destination des entreprises françaises. Ce dernier est le fruit de près de cinq années de travaux au sein de plusieurs organismes publics et a pour ambition de démontrer l’intérêt de PostgreSQL aux décideurs techniques en présentant les forces et les faiblesses du moteur.

Le mois dernier, une traduction en anglais est sortie des cartons pour promouvoir davantage ce mouvement vers le logiciel libre dans les autres pays. Je trouvais intéressant de profiter de cette actualité pour partager mes réflexions du moment, entre ma vision du marché français et l’approche technique pour engager les migrations de données vers PostgreSQL.

Une transition à marche forcée

La démarche n’est pas anodine, car depuis 2012, l’État français au travers de ses différents ministères, tente de contrer l’imposant marché des logiciels propriétaires en favorisant leurs remplacements systématiques par une alternative Open Source. Depuis quelques années, le Socle Interministériel de Logiciels Libres (SILL) est mis à jour par un groupe de travail pour faire un bilan des choix structurants engagés sur le territoire français.

La publication d’un guide de transition pour PostgreSQL aspire à rassurer les équipes opérationnelles et décisionnelles en apportant un grand nombre de conseils et de comparaisons sur ce qu’il est aujourd’hui possible de faire avec PostgreSQL. Il mentionne les trois grandes étapes pour réaliser la migration des données d’une application vers le moteur open-source :

migration des données ;
correction et réécriture des requêtes SQL et des procédures embarquées ;
recette du système pour écarter les régressions fonctionnelles.

Chacune de ces étapes a un coût, qu’il sera nécessaire de pondérer durant le chantier de migration. Les logiciels Open Source sont libres, mais ne sont pas gratuits et c’est un rappel essentiel que proposent les conclusions de ce guide. Les coûts de formation et de prestations externes ne sont également pas négligeables…

En 2018, la société française Dalibo avait publié un livre blanc dans ce même esprit de pédagogie sur l’importance des coûts d’investissement et de possession. Dans un scénario de migration, acté sur cinq années de transition, l’étude montre que l’analyse de portabilité vers PostgreSQL est la principale dépense au cours de la première année, suivie par un investissement important pour la recherche et le développement d’un socle d’outils dédiés aux déploiements, la maintenance et l’administration du parc PostgreSQL.

La seconde courbe peut paraître surprenante pour du logiciel libre, mais la nécessité de contracter une offre de support reste d’actualité, car trop peu de services informatiques disposent des compétences internes pour assurer la disponibilité et la maintenance des instances. Un effort initial de formation est requis pour aider les administrateurs en poste à faire également leur transition vers cette autre technologie.

Pour cette raison, de nombreux acteurs se positionnent depuis des décennies pour proposer de l’accompagnement opérationnel et technique auprès des entreprises de toutes tailles qui souhaitent (principalement) réduire les coûts de licence de logiciels propriétaires. Et bien que la transition pouvait être pénible il y a dix ans, les dernières versions de PostgreSQL et la prolifération d’outils communautaires apportent leur lot de fonctionnalités qui ne rougissent plus devant les atouts phares de certains mastodontes historiques du marché.

S’armer d’outils et de courage

Réaliser une migration impose de s’équiper d’un panel d’outils pour simplifier les grandes lignes de la migration et bien sûr, économiser du temps et de l’argent. Parmi les contributions libres, nous retrouverons l’incontournable Ora2pg, spécialisé dans la conversion d’un schéma Oracle et la migration de son contenu vers une instance PostgreSQL. Pour une base de type SQL Server de Microsoft, pgloader sera privilégié. Les deux outils supportent également les données en provenance de MySQL.

En juillet dernier, je partageais mes réflexions sur l’implémentation de la norme SQL/MED et des foreign data wrappers, ou connecteurs. L’actualité fut particulièrement riche cet été, avec la sortie de la version 22.0 du projet Ora2Pg, dont le nouveau support de l’extension oracle_fdw annonçait des gains vertigineux sur le temps de copie des données.

Ni une ni deux, j’ai souhaité comprendre et découvrir les dessous d’un tel procédé en manipulant moi-même les tables externes pour réaliser une migration de schémas et de données d’une base Oracle vers PostgreSQL, sans utiliser l’outil Ora2Pg. Cette procédure s’inspire d’un autre article de MigOps, publié plus tôt cette année.

1. Compiler le wrapper communautaire

Le connecteur oracle_fdw nécessite d’être compilé à partir des sources du projet pour prendre en compte les bibliothèques propriétaires d’Oracle, garantes du protocole de connexion et des échanges de données. Dans l’exemple ci-dessous, je dispose d’un serveur CentOS 7 avec une instance PostgreSQL 14 et j’ai installé l’Instant Client 19, disponible sur la plateforme de téléchargement d’Oracle.

yum install -y postgresql14-devel
export ORACLE_HOME=/usr/lib/oracle/19.13/client64
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export PATH=$PATH:$ORACLE_HOME/bin

cd ORACLE_FDW_2_4_0/
make PG_CONFIG=/usr/pgsql-14/bin/pg_config
make PG_CONFIG=/usr/pgsql-14/bin/pg_config install

Pour résoudre d’éventuels problèmes de détection de la librairie Oracle Instant Client et permettre la création de l’extension, il est nécessaire de renseigner la variable $LD_LIBRARY_PATH pour l’instance PostgreSQL au niveau de son service :

systemctl edit postgresql-14

[Service]
Environment="ORACLE_HOME=/usr/lib/oracle/19.13/client64"
Environment="LD_LIBRARY_PATH=/usr/lib/oracle/19.13/client64/lib"

L’extension peut ainsi être créée avec les privilèges d’un super-utilisateur dans la base qui accueillera les données finales. Le privilège USAGE peut ensuite être octroyé au propriétaire de la base pour préparer le schéma.

CREATE EXTENSION oracle_fdw;
GRANT USAGE ON FOREIGN DATA WRAPPER oracle_fdw TO hr;

2. Importer les tables externes

L’unique configuration repose sur la création d’un objet SERVER et l’attribution d’un mot de passe pour l’utilisateur courant, afin d’ouvrir un pont entre les deux systèmes.

CREATE SERVER orcl_hr FOREIGN DATA WRAPPER oracle_fdw
 OPTIONS (dbserver '//localhost:1521/hr');

CREATE USER MAPPING FOR hr SERVER orcl_hr
 OPTIONS (user 'hr', password 'demo');

La magie du wrapper opère lors de l’inspection de la base de données externe et de la création des relations dans un schéma PostgreSQL. Dans mon exemple, je dispose d’une base Oracle XE avec le schéma prédéfini HR contenant une variété de tables, de vues, d’index et de contraintes d’intégrité.

CREATE SCHEMA source;
SET search_path = source;
IMPORT FOREIGN SCHEMA "HR" FROM SERVER orcl_hr INTO source;

Avec psql et la méta-commande \dE, il est dès lors possible de consulter les tables externes importées dans le schéma source. L’une des huit tables est en réalité une vue, car l’extension consulte le catalogue ALL_TAB_COLUMNS dans lequel figurent les tables et vues accessibles par l’utilisateur connecté. Dans la phase d’étude de la migration, ce point doit être correctement identifié pour récupérer l’ordre de création de la vue, en adaptant la requête SQL si besoin.

 List of relations
 Schema | Name | Type | Owner
--------+------------------+---------------+-------
 source | countries | foreign table | hr
 source | departments | foreign table | hr
 source | emp_details_view | foreign table | hr
 source | employees | foreign table | hr
 source | job_history | foreign table | hr
 source | jobs | foreign table | hr
 source | locations | foreign table | hr
 source | regions | foreign table | hr

3. Créer les tables et les vues

Pour chacune de ces tables externes, il faut créer leur équivalent dans la base PostgreSQL. Pour mon exemple, je choisis le schéma public comme destination. L’une des méthodes les plus rapides repose sur l’option LIKE de l’instruction CREATE TABLE.

CREATE TABLE public.countries (LIKE source.countries);
CREATE TABLE public.departments (LIKE source.departments);
CREATE TABLE public.employees (LIKE source.employees);
CREATE TABLE public.job_history (LIKE source.job_history);
CREATE TABLE public.jobs (LIKE source.jobs);
CREATE TABLE public.locations (LIKE source.locations);
CREATE TABLE public.regions (LIKE source.regions);

À partir de cette étape, il est judicieux d’apporter quelques modifications aux types de colonnes. En effet, les types DATE et NUMBER en provenance d’Oracle ont des équivalences bien plus riches et efficientes avec PostgreSQL. Pour aller plus loin, l’un des chapitres de la formation Dalibo « Migrer d’Oracle à PostgreSQL » revient sur les différences notables entre les deux systèmes.

ALTER TABLE public.regions ALTER region_id TYPE smallint;
ALTER TABLE public.countries ALTER region_id TYPE smallint;
ALTER TABLE public.employees ALTER hire_date TYPE date;
ALTER TABLE public.job_history
 ALTER start_date TYPE date,
 ALTER end_date TYPE date;

La vue, quant à elle, doit être recréée pour les besoins de l’application.

CREATE OR REPLACE VIEW public.emp_details_view (
 employee_id, job_id, manager_id, department_id, location_id, country_id,
 first_name, last_name, salary, commission_pct, department_name, job_title,
 city, state_province, country_name, region_name
) AS
SELECT e.employee_id, e.job_id, e.manager_id, e.department_id, d.location_id,
 l.country_id, e.first_name, e.last_name, e.salary, e.commission_pct,
 d.department_name, j.job_title, l.city, l.state_province,
 c.country_name, r.region_name
 FROM public.employees e
 JOIN public.departments d ON e.department_id = d.department_id
 JOIN public.jobs j ON j.job_id = e.job_id
 JOIN public.locations l ON d.location_id = l.location_id
 JOIN public.countries c ON l.country_id = c.country_id
 JOIN public.regions r ON c.region_id = r.region_id;

4. Importer les données

La méthode la plus simple pour importer les données reste la copie table à table avec l’instruction INSERT INTO. Avec PostgreSQL, la commande TABLE est équivalente à un SELECT * FROM, que j’utilise pour alléger les requêtes dans l’exemple ci-dessous.

INSERT INTO public.countries TABLE source.countries;
INSERT INTO public.departments TABLE source.departments;
INSERT INTO public.employees TABLE source.employees;
INSERT INTO public.job_history TABLE source.job_history;
INSERT INTO public.jobs TABLE source.jobs;
INSERT INTO public.locations TABLE source.locations;
INSERT INTO public.regions TABLE source.regions;

Dans le cas de tables hautement volumineuses, cette méthode montrera très vite des faiblesses de performance, car les instructions sont exécutées les unes après les autres et que le parcours d’une table distante n’est réalisé que par un seul processus.

À moins de développer son propre système de distribution de requêtes et de lectures parallélisées, sachez que l’outil Ora2Pg propose parfaitement des pistes d’optimisation pour accélérer grandement les insertions lors de cette phase de chargement.

5. Créer les séquences, les index et les contraintes

Cette dernière étape est indispensable pour maintenir la cohérence du modèle et pour garantir des performances similaires, il ne faut donc pas mésestimer la phase d’étude qui permettra d’inventorier les séquences, les index et les contraintes à recréer dans la base PostgreSQL. Pour aller jusqu’au bout de ma démonstration, voici les instructions à exécuter pour finaliser la migration.

-- regions
ALTER TABLE regions
 ADD CONSTRAINT reg_id_pk PRIMARY KEY (region_id);

-- countries
ALTER TABLE countries
 ADD CONSTRAINT country_c_id_pk PRIMARY KEY (country_id),
 ADD CONSTRAINT countr_reg_fk FOREIGN KEY (region_id)
 REFERENCES regions(region_id);

-- locations
CREATE SEQUENCE locations_seq
 START WITH 3300 INCREMENT BY 100 MAXVALUE 9900;

ALTER TABLE locations
 ALTER location_id SET DEFAULT nextval('locations_seq'::regclass),
 ADD CONSTRAINT loc_id_pk PRIMARY KEY (location_id),
 ADD CONSTRAINT loc_c_id_fk FOREIGN KEY (country_id)
 REFERENCES countries(country_id);

-- departments
CREATE SEQUENCE departments_seq
 START WITH 280 INCREMENT BY 10 MAXVALUE 9990;

ALTER TABLE departments
 ALTER department_id SET DEFAULT nextval('departments_seq'::regclass),
 ADD CONSTRAINT dept_id_pk PRIMARY KEY (department_id),
 ADD CONSTRAINT dept_loc_fk FOREIGN KEY (location_id)
 REFERENCES locations (location_id);

-- jobs
ALTER TABLE jobs
 ADD CONSTRAINT job_id_pk PRIMARY KEY(job_id);

-- employees
CREATE SEQUENCE employees_seq
 START WITH 207 INCREMENT BY 1;

ALTER TABLE employees
 ALTER employee_id SET DEFAULT nextval('employees_seq'::regclass),
 ADD CONSTRAINT emp_emp_id_pk PRIMARY KEY (employee_id),
 ADD CONSTRAINT emp_dept_fk FOREIGN KEY (department_id)
 REFERENCES departments,
 ADD CONSTRAINT emp_job_fk FOREIGN KEY (job_id)
 REFERENCES jobs (job_id),
 ADD CONSTRAINT emp_manager_fk FOREIGN KEY (manager_id)
 REFERENCES employees;

ALTER TABLE departments
 ADD CONSTRAINT dept_mgr_fk FOREIGN KEY (manager_id)
 REFERENCES employees (employee_id);

-- job_history
ALTER TABLE job_history
 ADD CONSTRAINT jhist_emp_id_st_date_pk PRIMARY KEY (employee_id, start_date),
 ADD CONSTRAINT jhist_job_fk FOREIGN KEY (job_id)
 REFERENCES jobs,
 ADD CONSTRAINT jhist_emp_fk FOREIGN KEY (employee_id)
 REFERENCES employees,
 ADD CONSTRAINT jhist_dept_fk FOREIGN KEY (department_id)
 REFERENCES departments;

Dans des situations particulièrement simples, la migration vers PostgreSQL peut être intégralement réalisée à l’aide du langage SQL et d’une extension de la famille des foreign data wrappers. Cependant, le temps de copie restera très dépendant de l’ordonnancement que l’on peut en faire, et du débit de transfert entre les deux systèmes.

Conclusion

La migration deviendra complexe lorsque la base de données à migrer embarque du code PL/SQL stratégique. À moins d’extraire la logique métier et de l’implémenter dans une application dédiée, la conversion du code en routines PL/pgSQL méritera toute votre attention. Bien qu’Ora2Pg puisse simplifier le travail de portage avec une conversion automatique tout à fait honorable, il sera indispensable de tester la non-régression fonctionnelle.

Un outil comme pgTAP peut aider à rédiger des tests unitaires ou de bout en bout pour couvrir le code et vous accompagner dans le portage des procédures. L’année dernière, j’avais pris plaisir à rédiger un atelier complet sur la traduction des procédures PL/SQL fournies avec le schéma HR présenté aujourd’hui. N’hésitez pas à le consulter !

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.