DEV Community: ZINSOU Trinité

Maîtriser la gestion des branches avec Git

ZINSOU Trinité — Fri, 17 Oct 2025 21:43:33 +0000

🚀 Introduction

Imagine ton équipe de devs comme une bande de super-héros. Chacun a ses pouvoirs, chacun travaille sur une mission différente. Mais si tout le monde se met à lancer des lasers sur sa cible sans coordination, la ville finira en ruines au lieu d’être sauvée.

C’est là que Git entre en jeu. Puissant, il offre aux développeurs la liberté de créer des espaces de travail isolés, d’expérimenter et de collaborer sans se marcher dessus. Mais cette liberté peut vite tourner au chaos : sans stratégie claire pour gérer les branches, les équipes se retrouvent souvent avec des historiques brouillons, des conflits de fusion interminables et des flux de déploiement incertains.

Une bonne stratégie de gestion des branches ne se contente pas d’organiser le code : elle influence la manière dont ton équipe collabore, livre des fonctionnalités, corrige des bugs et déploie ses produits.

Dans cet article, nous allons explorer quelques stratégies de gestion des branches Git les plus populaires, leurs avantages et leurs inconvénients, afin de t’aider à trouver celle qui correspond le mieux à ton équipe.

🌱 Qu’est-ce qu’une branche Git ?

Imagine les branches Git comme des lignes temporelles alternatives dans un film Marvel.

Dans une ligne temporelle, tu construis une page de connexion.
Dans une autre, tu corriges un vilain bug en production.
Et dans une troisième, tu expérimentes un mode sombre (parce que… pourquoi pas 😎).

Les branches te permettent d’explorer tous ces univers parallèles sans abîmer l’histoire principale(ici ton projet 😉).

Techniquement, une branche Git est simplement un pointeur vers un commit : une référence légère qui te permet de travailler sur des changements sans impacter directement la base de code principale.

Pourquoi utiliser des branches ?

Pour isoler les fonctionnalités tant qu’elles ne sont pas prêtes.
Pour corriger des bugs sans perturber le développement en cours.
Pour préparer des releases de manière contrôlée.

Pense aux branches comme à des lignes temporelles parallèles dans ton projet.

Un bon modèle de branches les garde propres et maîtrisées, et t’évite surtout un cataclysme interdimensionnel, un effet papillon à l’échelle du multivers (merci Marvel 😉).

🪵 Les 6 principaux types de branches

Type de branche	Rôle principal
main / master	Pour préparer les versions en production, de manière contrôlée.
dev / develop	Branche d’intégration des nouvelles fonctionnalités et correctifs. Contient l’état le plus récent du développement (pas forcément stable).
feature	Pour les nouvelles fonctionnalités ou améliorations. Créée à partir de `dev`, fusionnée ensuite dans `dev`.
release	Pour finaliser une version. Créée à partir de `dev`, fusionnée après dans `main` et `dev`.
hotfix	Pour les correctifs urgents en production. Créée à partir de `main`, fusionnée après dans `main` et `dev`.
fix (optionnelle)	Pour les bugs mineurs non critiques. Créée à partir de `dev` (ou d’une `release`).

🏷️ Nommer ses branches Git

Chaque équipe est libre de définir ses propres règles de nommage des branches, ce qui compte vraiment, c’est la cohérence. Une convention très répandue consiste à préfixer les branches selon leur type (feature/, release/, hotfix/, etc.) et à utiliser des noms courts, descriptifs, en minuscules et séparés par des tirets. Par exemple : feature/login-page , release/1.0.0 ,hotfix/1.0.1 . Cette approche garde ton dépôt propre et lisible, et permet de comprendre instantanément l’objectif de chaque branche.

🛠️ Les stratégies majeures

Chaque dépôt Git démarre avec une seule branche : main (ou master, selon les cas). C’est l’épine dorsale du projet; tout repose dessus. Imaginons donc une équipe de développement travaillant sur plusieurs fonctionnalités principales, de feat1 à featN, à partir d’un même dépôt avec sa branche principale. Nous verrons ensuite une liste de quelques-unes des stratégies les plus utilisées dans l'industrie.

1. Feature Branching

Avec elle, chaque fonctionnalité, changement ou correctif possède sa propre branche, créée à partir de la branche principale (main). Une fois le développement terminé, la branche est fusionnée dans main, puis supprimée pour garder le dépôt propre.

Cette approche favorise l’isolation du développement; chaque développeur peut travailler sur ses fonctionnalités sans interférer avec le code principal. Mais attention, cela peut entraîner des conflits Git lors des fusions sur main,

surtout si les branches ont subies de longues modifications. La clé de cette méthode, c’est la discipline : mettre régulièrement à jour ses branches avec main pour éviter les mauvaises surprises. Le schéma ci-dessous illustre bien son fonctionnement :

Les développeurs commencent par créer leurs branches de fonctionnalités à partir de main (1). Le dev travaillant sur feat1 effectue plusieurs commits avant de fusionner sa branche dans main à l’étape 2. À ce moment-là, la branche feat1 est supprimée (représentée par une ligne en pointillés). Puis, au point 3, le dev travaillant sur feat2 termine ses modifications en récupérant les derniers changements de main pour se synchroniser. Cette étape permet d’éviter les conflits lors de la fusion au point 4, après quoi cette branche est également supprimée.

En résumé, cette stratégie constitue la base de la plupart des autres stratégies.

2. Git Flow

Avec Git Flow, on maintient deux branches permanentes : une pour la production et une pour la pré-production, généralement nommées main et dev. À cela peuvent s’ajouter d’autres branches selon le contexte, comme les branches feature/, fix/ ou hotfix/. Ici, avoir de bonnes conventions de nommage joue un rôle essentiel pour garder le projet clair, cohérent et bien organisé. Le schéma ci-dessous illustre parfaitement le fonctionnement du Git Flow :

Les développeurs créent leurs branches de fonctionnalités à partir de dev pour construire de nouvelles choses géniales, puis les fusionnent une fois qu’elles sont prêtes. Quand le projet approche de la mise en production, une branche de release est créée pour les dernières retouches et tests avant le déploiement final. Une fois validée, cette branche est fusionnée à la fois dans main et dans dev. Mais que se passe t’il si un bug se glisse en production ?

C’est là que les branches hotfix entrent en scène, comme des pompiers du code 🧯: elles sont créées directement à partir de la version de main affectée en production, corrigent le problème, puis la correction est ensuite sychronisée dans main et dev. Ce flux de travail est conçu pour un développement structuré et orienté release, pas pour du déploiement immédiat. La conséquence de tout ceci c’est une production stable, des versions propres, et une équipe qui sait exactement où travailler sans se marcher dessus.

3. GitHub Flow

Si Git Flow te semble un peu lourd, avec toutes ses demandes de fusion à gérer, rencontre son cousin plus léger : GitHub Flow. Cette stratégie, lancée par GitHub, est conçue pour les équipes qui veulent livrer vite et souvent, c’est un workflow orienté déploiement continu. Contrairement à Git Flow :

il n’y a pas de branche develop,
pas de branches release longue durée,
seulement main (ou master) et des branches de fonctionnalités courtes.

Avec GitHub Flow : tout ce qui est dans main est déployable, pour développer une fonctionnalité, crée une branche de feature, fais tes changements, créé une pull/merge request, fusionne la branche, et tes changements sont prêts à être déployés. Quelques problèmes mineurs peuvent apparaître, mais ils peuvent être corrigés et redéployés immédiatement : dans ce workflow, un hotfix n’est pas différent d’une petite fonctionnalité. Tu codes, tu merges, et tu livres directement depuis main.

4. GitLab Flow

Ce workflow priorise les environnements de staging. Si Git Flow te paraît trop lourd et GitHub Flow trop léger, alors GitLab Flow est un juste milieu. Il combine la simplicité du Feature Branching avec la flexibilité du déploiement basé sur les environnements.

Les développeurs créent toujours des branches de fonctionnalités à partir de main (parfois à partir de develop si cette branche est utilisée). Au lieu de plusieurs branches longue durée comme dans Git Flow, GitLab Flow met l’accent sur les environnements :

main (production)
pré-production / staging
development / dev

Chaque branche d’environnement reflète une étape réelle de déploiement. Les fonctionnalités sont fusionnées dans la branche appropriée selon l’endroit où elles doivent être déployées.

Le code circule ainsi : main → pré-production → production .

5. Release Branching

Le Release Branching est une approche structurée utilisée dans les processus de développement logiciel. Lorsque le projet approche d’une nouvelle version, une branche de release dédiée est créée à partir de main(parfois à partir de develop). Cette branche sert de zone de sécurité : les équipes peuvent y appliquer les dernières retouches, corriger les bugs restants, stabiliser la base de code, tout cela sans bloquer ni perturber le développement des fonctionnalités en cours.

Contrairement aux branches de fonctionnalités, qui se concentrent sur le développement de fonctionnalités spécifiques, ou aux branches hotfix, qui servent à corriger des problèmes urgents en production, les branches de release ont une mission unique. Elles regroupent tout le travail prévu pour la prochaine version et offrent un environnement contrôlé pour peaufiner et préparer le produit au déploiement. En d’autres termes, elles servent de pont entre le développement actif et la production, garantissant que la version soit cohérente, stable et prête à être mise en ligne.

6. Trunk-Based Development

Si Git Flow est structuré et que GitHub Flow est léger, alors Trunk-Based Development (TBD) est l’extrême minimaliste 🪶. Le principe est simple : tout le monde travaille sur une seule branche, le tronc

(généralement main ou master).

Dans le Trunk-Based Development, les développeurs travaillent généralement sur des branches de courte durée, contenant seulement quelques commits.

Contrairement aux stratégies qui utilisent des branches de fonctionnalités longue durée, cette approche permet de livrer du code rapidement et régulièrement. Elle devient particulièrement précieuse lorsque la base de code et l’équipe s’agrandissent, aidant à maintenir un flux constant de releases en production.

🧭 Choisir la bonne stratégie de branches Git

Avec Git comme standard de facto, les équipes sont confrontées à une question cruciale : quelle stratégie de branches soutient le mieux leur workflow, leur architecture et leur cadence de releases ? Que vous développiez un monolithe ou orchestriez des microservices, travailliez seul ou à plusieurs dizaines de développeurs, le modèle de branches que vous choisissez peut accélérer ou freiner vos progrès. Ce guide compare les stratégies présentées ci-dessus pour vous aider à trouver celle qui correspond le mieux à votre workflow.

Stratégie	Adaptation à l’architecture	Taille de l’équipe	Style de déploiement	Idéal pour
Feature Branching	✅ Monolithe
✅ Microservices	👥 Petite à grande (3–50+)	🌀 Modéré à rapide	- Travail isolé sur les fonctionnalités
- Développement parallèle
- Culture de revue de code
Git Flow	✅ Monolithe	👥 Moyenne à grande (10–100)	🧊 Releases lentes et planifiées	- Applications d’entreprise traditionnelles
- Environnements QA/staging
- Gestion des hotfix
GitHub Flow	✅ Microservices	👥 Petite à moyenne (3–30)	⚡ Livraison continue	- Produits SaaS
- Iteration rapide
- Workflows PR GitHub
GitLab Flow	✅ Microservices
✅ Hybride	👥 Moyenne à grande (10–100)	🌀 Flexible (CI/CD + staging)	- Déploiements basés sur l’environnement
- Pipelines GitLab CI/CD
- Modèles de release complexes
Release Branching	✅ Monolithe
✅ Hybride	👥 Moyenne à grande (10–100)	🧊 Releases versionnées	- Support long terme
- Développement parallèle de fonctionnalités + maintenance
- Secteurs réglementés
Trunk-Based Development	✅ Microservices	👥 Petite à moyenne (3–30)	⚡ Intégration continue	- Équipes à haute vélocité
- Culture DevOps
- Utilisation de feature flags

🏁 Conclusion

Au final, aucune stratégie de branches ne règne sur toutes les autres, et c’est toute la beauté de Git.

Feature Branching vous offre l’isolation, Git Flow apporte l’ordre, GitHub Flow garde les choses légères, GitLab Flow ajoute un contrôle des environnements, Release Branching assure la stabilité, et Trunk-Based Development favorise la vélocité.

La meilleure stratégie est celle qui correspond à la culture de votre équipe, à votre rythme de release et à la maturité de vos outils.

Si vos développeurs aiment expérimenter et livrer rapidement, optez pour une approche légère.
Si vous gérez des systèmes critiques en production, la structure est votre alliée.

💡 Rappelez-vous : les stratégies de branches sont des outils, pas des règles.

Vous pouvez même les mélanger et les adapter : ce qui compte vraiment, c’est la cohérence, la collaboration et la livraison de code génial.

Si vous souhaitez aller plus loin, consultez ces excellentes ressources :

Mastering Git Branching Strategies: Finding the Right Fit for Your Team

ZINSOU Trinité — Fri, 17 Oct 2025 21:36:48 +0000

🚀 Introduction

Imagine your dev team as a group of superheroes. Everyone’s got powers, everyone’s working on different missions, but if you all start blasting lasers at the same target with no coordination, you’ll end up destroying the city instead of saving it. That’s where git comes in, it is powerful and gives developers the freedom to create isolated workspaces, experiment, and collaborate without stepping on each other’s toes. But with this freedom comes chaos and without a branching strategy teams often end up with messy histories, endless merge conflicts, and uncertain deployment flows.

A good branching strategy doesn’t just organize code. It shapes how your team collaborates, delivers features, fixes bugs, and ships products. In this article, we’ll explore the most popular Git branching strategies, their pros and cons, and help you decide which one fits your team.

🌱 What is a Git Branch, Anyway?

Think of Git branches as alternate timelines in a Marvel movie.

One timeline: you’re building a login page.
Another timeline: you’re fixing a nasty production bug.
Another: you’re experimenting with dark mode (because why not).

Branching lets you explore all these universes without messing up the main storyline. A branch in Git is also simply a pointer to a commit, a lightweight reference that lets you work on changes without affecting the main codebase.

Why branch at all?

To isolate features until they’re ready.
To fix bugs without disturbing ongoing development.
To prepare releases in a controlled way.

Think of branches as parallel timelines in your project. A good branching model keeps those timelines clean and manageable and it help you to avoir an interdimensional cataclysm( thanks marvel 😉 ).

We have mainly 6 branch types:

main/master: To prepare releases in a controlled way.
dev/develop: Integration branch for features and fixes, contains the latest development state, not necessarily production-ready.
feature: for new features or improvements, branched from dev, merged back into dev.
release: for finalizing a release, branched from dev, merged into main and dev.
hotfix: for urgent production fixes, branched from main, merged into main and dev.
fix (optional): for non-critical bug fixes, branched from dev (or a release branch).

🏷️ Naming git branches

Every team is free to define its own branch naming rules, but consistency is what really matters. A common convention is to prefix branches with their type (feature/, release/, hotfix/) and use short, descriptive names in lowercase with dashes. For example: feature/login-page, release/1.0.0, or hotfix/1.0.1. This keeps the repository clean, makes the purpose of each branch instantly clear.

🛠️ The Big 6 Strategies

Every git repository comes with a single branch, the main/master(its depends) which is the backbone of the project, everything rely on him. Assume that we have one git repository with his main/master. We will consider from now, a dev team working on n mains features from feat1 to feat n.

1. Feature Branching

With feature branching each feature/change/fix has its own branch created from the main branch and once the feature is completed the branch can be merged into main and be deleted.

This strategy allows isolation of development; each developer can work on their features simultaneously without affecting the main codebase. However, it can often lead to git conflicts during merges on the main branch, depending on the branch timeline, so the team should have discipline and regularly update their git branches. The diagram below explains how it works.

The devs start by creating their feature branches from main (1), and the dev working on feat1 makes several commits before merging into the main branch in step 2. At this point, the feat1 branch is deleted (marked by a dotted line), and at point 3, the dev working on feat2 completes the changes by pulling from main to get its latest state. This is done to prevent conflicts during the merge at point 4, after which this branch is also deleted.

The feature branching strategy is the building block for most others branching strategies.

2. Git Flow

With it, we maintain two permanent branches, a production and pre-production branch generally named main and dev. We can have additional branches like feature/fix/hotfix branches depending on the context, and here having good naming conventions plays a crucial role in maintaining clarity and consistency. The diagram below is a good illustration of how gitflow works.

Developers break off into feature branches from dev to build cool stuff, then bring it back when it’s ready. When the project is about to ship, a release branch appears for final polish and testing before it goes live (and gets merged into both main and dev). But what if a bug sneaks into production? That’s where hotfix branches come in like firefighters, they branch straight off main, put out the fire, and then sync the fix back into both main and dev. This flow is designed for structured, release-oriented development, not immediate deployment.

The result? A workflow where production stays safe, releases stay clean, and your team knows exactly where to work without stepping on each other’s toes.

3. GitHub Flow

If GitFlow feels a bit heavy, due to merge request everywhere, meet its lighter cousin: GitHub Flow. This strategy was popularized by GitHub and is designed for teams that want to ship fast and often, it’s a continuous-deployment-focused workflow . Unlike GitFlow, there’s no develop branch or long-lived release branches , just main/master and short-lived feature branches. With Github Flow, anything in the master branch is deployable, if you have some feature to develop just create feature branche, make your changes, opend a pull/merge request, merge it and your changes are ready to be deployed. Little issues can be introduced, but then they can be fixed and redeployed without delay, you just have to do a hotfix and there is no difference in the this flow between a hotfix and a very small feature, juste make your code and ship after merge on the main branch. You can lear more about here.

4. GitLab Flow

This flow priorise staging areas, if GiktFlow feels too heavy and GitHub Flow too light, GitLab Flow is the middle ground.It combines the simplicity of feature branching with the flexibility of environment-based deployment.

Here:

Developers still create feature branches from main (or sometimes from develop if used).
Instead of multiple long-lived branches like in GitFlow, GitLab Flow emphasizes environments:
- main (production)
- pre-production / staging
- development/dev
Each environment branch reflects a real-world deployment stage.
Features are merged into the right branch depending on where they should go..
Code moves from main → pre-production → production, like superheroes testing their powers in a training arena before saving the world.

5.Realease branching

Release branching is a structured approach used in the software development process. When a project is nearing a new version, a dedicated release branch is created from main (or sometimes develop). This branch works like a safety zone where teams can apply final adjustments, fix remaining bugs, and stabilize the codebase all without blocking or disrupting ongoing feature development.

Unlike feature branches, which focus on building specific functionalities, or hotfix branches, which exist to patch urgent production issues, release branches have a unique mission. They bring together all the work intended for the next version and provide a controlled environment to polish and prepare the product for deployment. In other words, they act as the bridge between active development and production delivery, ensuring the release is cohesive, stable, and ready to go live.

6. Trunk-Based Development

If GitFlow is structured and GitHub Flow is lightweight, Trunk-Based Development (TBD) is the extreme minimalist 🪶. The principle is simple: everyone works on a single branch, the trunk (usually main or master).

In trunk-based development, developers typically work on short-lived branches containing only a few small commits, unlike strategies that involve long-lived feature branches. This approach becomes particularly valuable as the codebase and team expand, helping maintain a steady flow of production releases.

🧭 Choosing the Right Git Branching Strategy

With Git as the de facto standard, teams face a critical decision: which branching strategy best supports their workflow, architecture, and release cadence? Whether you're building a monolith or orchestrating microservices, working solo or scaling across dozens of developers, the branching model you choose can accelerate or hinder your progress. This guide compares the strategies we explore above to help you pick the one that fits your workflow best.

Strategy	Architecture Fit	Team Size Fit	Deployment Style	Best For
Feature Branching	✅ Monolith<br>-✅ Microservices	👥 Small to Large (3–50+)	🌀 Moderate to fast	- Isolated feature work<br>- Parallel development<br>- Code review culture
Git Flow	✅ Monolith	👥 Medium to Large (10–100)	🧊 Slow, staged releases	- Traditional enterprise apps<br>- QA/staging environments<br>- Hotfix management
GitHub Flow	✅ Microservices	👥 Small to Medium (3–30)	⚡ Continuous delivery	- SaaS products<br>- Fast iteration<br>- GitHub PR workflows
GitLab Flow	✅ Microservices<br>-✅ Hybrid	👥 Medium to Large (10–100)	🌀 Flexible (CI/CD + staging)	- Environment-based deployments<br>- GitLab CI/CD pipelines<br>- Complex release models
Release Branching	✅ Monolith<br>-✅ Hybrid	👥 Medium to Large (10–100)	🧊 Versioned releases	- Long-term support<br>- Parallel feature + maintenance<br>- Regulated industries
Trunk-Based Development	✅ Microservices	👥 Small to Medium (3–30)	⚡ Continuous integration	- High-velocity teams<br>- DevOps culture<br>- Feature flag usage

🏁 Conclusion

At the end of the day, no single branching strategy rules them all and that’s the beauty of Git.

Feature Branching gives you isolation, GitFlow offers order, GitHub Flow keeps things light, GitLab Flow adds environment control, Release Branching ensures stability, and Trunk-Based Development powers speed.

The best strategy is the one that fits your team’s culture, release rhythm, and tooling maturity.

If your developers love experimenting and pushing fast, go lightweight.

If you’re handling production-critical systems, structure is your friend.

Remember: branching strategies are tools, not rules. You can even mix and adapt them what matters most is consistency, collaboration, and delivering awesome code.

If you want to go more deeper, check these resources:

Getting Started with Vagrant

ZINSOU Trinité — Sun, 14 Sep 2025 21:35:22 +0000

🧠 Introduction

"What if you could magically spin up as many machines as you want for your test environments? No wand, just Vagrant."

Test environments can quickly become a nightmare: bad installs, version conflicts, etc. What if we could change that with a tool that makes you feel like a DevOps wizard? 🎩✨

In this article, we will:

Discover what Vagrant is (without falling asleep) 😴❌
Use it to create two Ubuntu VMs 🖥️🖥️ and prepare a test environment for our series on incremental backups with Postgres + Barman
And test our setup like pros 🧪

🪄 What is Vagrant?

"Vagrant is kind of like Docker, but for VMs. It's your conductor for VirtualBox, VMware, Hyper-V, and other hypervisors. It's a super reliable tool to manage complete environments with real virtual machines in a simple and automated way."

It's a tool developed by Hashicorp that makes it easy to manage VMs with fully isolated dependencies and configurations, all in a unique and disposable environment.

You write a Vagrantfile, type vagrant up, and boom 💥: your machine(s) is(are) ready to use. No need to click through 27 buttons in VirtualBox or fight with Hyper-V.

Vagrant saves you from:

❌ Downloading an ISO

❌ Clicking through the installer manually

❌ Struggling with networking and scripts

✅ You can do everything automatically, and reset your environment anytime, like a quick save in your dev life.

🔍 Why is it useful?

🔄 Easy testing: want to test a Postgres config? SSH? A cluster? A network lab? Boom, spin up a VM.
💥 Safe: easily prepare demos or tutorials without polluting your main machine. If you break everything, just run vagrant destroy && vagrant up.
🤝 Shareable: working in a team? Commit your Vagrantfile and everyone gets the same environment.
🧪 Closer to production: you can create environments that really mimic a real server (unlike Docker). Perfect for learning sysadmin or DevOps.

🛠️ How does it work?

Vagrant relies on:

A provider (usually VirtualBox or Hyper-V) to run the machines
Boxes: pre-built system images deployable in any Vagrant environment. They're essentially packaged distributions for uniform deployment. You can explore official boxes here
A Vagrantfile (your recipe): the file where the magic is defined
Scripts or tools to provision the machine (install software, configure base services)

Vagrant will provision the machine based on what's described in the Vagrantfile (usually in the project root). A Vagrantfile is a Ruby file, but it doesn’t require deep Ruby knowledge. It defines the machine specs (storage, RAM, network, etc.) and sets up the required tools for it to run properly.

🎓 Getting Started with Vagrant

Next, we’ll get hands-on with Vagrant and set up a lab for our incremental backup series with Postgres.

In the end, we’ll boot two VMs: one with Postgres, and another with Barman.

🚀 Installing Vagrant

You can install Vagrant via the CLI or by using an executable from the official documentation.

You’ll also need a working VirtualBox setup, which is the provider we’ll use.

🛠️ Using Vagrant

Let's create our first Vagrantfile with the minimal config to run a VM. Create a folder and inside it, a Vagrantfile like this:

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/focal64"
  config.vm.hostname = "vagrantbox"
end

Vagrant provides a wide variety of commands to manage the different components of the Vagrant ecosystem. For example, vagrant box list and vagrant box add box_name respectively list the boxes available locally and add a box to the local collection.

$ vagrant box add ubuntu/focal64
==> box: Loading metadata for box 'ubuntu/focal64'
    box: URL: https://vagrantcloud.com/api/v2/vagrant/ubuntu/focal64
This box can work with multiple providers! The providers that it
can work with are listed below. Please review the list and choose
the provider you will be working with.

1) hyperv
2) libvirt
3) virtualbox
4) vmware_desktop

Enter your choice: 3
==> box: Adding box 'ubuntu/focal64' (v2004.01) for provider: virtualbox
    box: Downloading: https://vagrantcloud.com/ubuntu/boxes/focal64/versions/20240821.0.1/providers/virtualbox/unknown/vagrant.box

$ vagrant box list             
ubuntu/bionic64 (virtualbox, 20230607.0.0)
ubuntu/focal64  (virtualbox, 20240220.0.0)

More info on box management here.

Next, let's verify that the syntax of the file is correct using vagrant validate.

If there are no errors, you will see the following message: Vagrantfile validated successfully.

Then launch your VM:

$ vagrant up             
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/focal64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/focal64' version '20240220.0.0' is up to date...
==> default: A newer version of the box 'ubuntu/focal64' for provider 'virtualbox' is
==> default: available! You currently have version '20240220.0.0'. The latest is version
==> default: '20240821.0.1'. Run `vagrant box update` to update.
==> default: Setting the name of the VM: ocr_default_1749933808776_2967
==> default: Clearing any previously set network interfaces...
[...]

$ vagrant status
Current machine states:

default                   running (virtualbox)
[...]Check the status:

Once the VM is up and running, we can connect to it via SSH to perform various operations using the command vagrant ssh machine_name.

Vagrant can also be effectively used in a context that requires a multi-tier architecture — i.e., multiple machines (sometimes with different operating systems) at once, as is often the case in production. You simply need to define as many VM configurations as needed.

Let’s now connect to the machine we’ve prepared so far.

$ vagrant ssh default             
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-172-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro
[...]
vagrant@vagrantbox:~$

The diagram below illustrates the typical lifecycle of a Vagrant virtual machine, from initialization to complete removal.

Main Steps

vagrant init creates a Vagrantfile
Configure the Vagrantfile

This is an important step in setting up the Vagrantfile.

Here, we define everything needed to prepare the machine (provisioning and more). Then, using the vagrant up command, we start the virtual machine. If it doesn’t exist yet, it will be created and provisioned.
Running

The machine is now running. From this point on, you have several options available to you:

* `vagrant reload` : restart the VM with the updated config

* `vagrant suspend` / `vagrant resume` : to suspend and resume the VM

* `vagrant halt` : to shut down the VM properly

* `vagrant provision` : rerun the provisioning scripts

Destroy With vagrant destroy, the VM is completely removed. You then return to a clean state.

🚀 Provisioning Vagrant VMs

Now that our base environment is defined in the Vagrantfile, it's time to prepare each machine so they are ready to use that is, install everything necessary to operate them. This is the provisioning step.

Vagrant provides several interfaces to provision our VMs: shell, file, Chef, Docker, Ansible, etc.

Next, we will explore some of these provisioners and prepare what’s needed to provision our VMs for the Postgres and Vagrant lab.

1. Shell Provisioner

It allows you to specify a series of instructions to execute in order to provision the machine. This interface supports two options by default: inline and path.

These let you specify either a command directly within the Vagrantfile or the path to a ready-to-use bash script to set up the machine, as shown in the example below.

Vagrant.configure("2") do |config|
  # ... others configuration
  config.vm.provision "shell",
    inline: "echo Hello, World"
end

Vagrant.configure("2") do |config|
  # ... others configuration
  config.vm.provision "shell", path: /path/to/my/bash/script
end

2. File Provisioner

It allows you to mount a file or folder from the host machine to the virtual machine.

This mechanism is especially useful for sharing provisioning scripts, configuration files, or datasets between the host and the VM without having to manually copy them each time.

For example, to copy a file to the host machine, the syntax is as follows:

Vagrant.configure("2") do |config|
  # ... others configuration

  config.vm.provision "file", source: "~/path/to/host/folder", destination: "$HOME/remote/newfolder"
end

This copy is one-time and does not synchronize the file state.

To synchronize the file state between the host and the VM, the configuration should be as follows:

Vagrant.configure("2") do |config|
  # ... others configuration

  config.vm.synced_folder "src/", "/srv/website"
end

For more information about synchronization, please consult the official documentation here.

3. Ansible Provisioner

Unlike traditional shell scripts, the Ansible provisioner allows you to describe the desired state of a system in a declarative way.

This means you write "playbooks" (YAML files) that define what you want to achieve (e.g., PostgreSQL installed, a user created, a service started), and Ansible takes care of making the necessary changes to reach that state, without unnecessarily repeating tasks that have already been done.

Why use Ansible with vagrant?

✅ More readable, structured, and reusable code.
🔁 Idempotence: running a playbook again doesn’t change anything if everything is already in place.
⚙️ Easy to maintain, especially for complex or multi-machine environments.

Vagrant can run Ansible as either a local or remote provisioner, depending on whether Ansible is installed on the host or on the VM itself.

Here is a minimal example in a Vagrantfile:

config.vm.provision "ansible" do |ansible|
  ansible.playbook = "playbook.yml"
  ansible.inventory_path = "inventory.ini"
end

🧪 Practical: Building the PostgreSQL + Barman Lab

It’s time to get hands-on and build our test environment.

The goal of this phase is to create two virtual machines using Vagrant:

🐘 A first VM with PostgreSQL installed; it will simulate our source database,
📦 A second VM with Barman installed; it will represent an administrator workstation or a control machine from which we can manage our backups.

We will automate the installation of each component using Bash provisioning scripts.The Vagrantfile will define the architecture of our lab and execute the scripts automatically when the machines start.

Let's start by creating the Vagrantfile and the scripts needed to install Postgres and Barman.

Vagrantfile

# Vagrantfile
Vagrant.configure("2") do |config|
  config.vm.define "vm1_postgres" do |vm1|
    vm1.vm.box = "ubuntu/jammy64"
    vm1.vm.hostname = "postgres"
    vm1.vm.network "private_network", ip: "192.168.56.10"
    vm1.vm.provision "shell", path: "scripts/setup_postgres.sh"
  end

  config.vm.define "vm2_vagrant" do |vm2|
    vm2.vm.box = "ubuntu/jammy64"
    vm2.vm.hostname = "vagrant"
    vm2.vm.network "private_network", ip: "192.168.56.11"
    vm2.vm.provision "shell", path: "scripts/setup_vagrant.sh"
  end
end

`scripts/setup_postgres.sh`

#!/bin/bash
set -e

echo "[INFO] Installing PostgreSQL..."

sudo apt-get update
sudo apt-get install -y postgresql postgresql-contrib

psql --version && echo "[OK] PostgreSQL installed"

`scripts/setup_barman.sh`

#!/bin/bash
set -e

echo "[INFO] Installing Barman..."

sudo apt-get update
sudo apt-get install -y barman

barman --version && echo "[OK] Barman installed"

🧩 Conclusion

We have just discovered Vagrant and, in practice, laid the foundation for a test environment by setting up two virtual machines: one with PostgreSQL installed, and the other with Barman, our backup tool in the incremental backups series.

Thanks to Vagrant and provisioning scripts, we have automated the deployment of this environment, allowing us to easily reproduce our tests, save time, and avoid manual errors.

What we set up here is not limited to the context of Postgres and Barman: this type of lab can serve as a generic base for all kinds of DevOps practices, system experiments, or technical tests in isolated environments.

🧰 A simple, reproducible, and extensible foundation — ideal for learning, testing, breaking… and starting over!

See you soon in the next post on this blog.

A la découverte de vagrant

ZINSOU Trinité — Sun, 14 Sep 2025 21:33:55 +0000

🧠 Introduction

"Et si tu pouvais faire apparaître autant de machines comme par magie, autant que tu en voudrais pour tes environnementes tests? Pas de baguette, juste Vagrant."

Les environnements de test peuvent vite virer au cauchemar : installation foireuse, conflits de versions, etc. Et si on changeait ça avec un outil qui te fait sentir comme un DevOps sorcier ? 🎩✨

Dans cet article, on va :

Découvrir ce qu’est Vagrant (sans s’endormir) 😴❌
L’utiliser pour créer deux VMs Ubuntu 🖥️🖥️ et préparer un environnement de test pour notre série sur les sauvegardes incrémentales avec Postgre+Barman
Et tester notre setup comme des pros 🧪

🪄 Vagrant, c’est quoi ce truc ?

"Vagrant, c’est un peu comme Docker, mais pour les VM. C’est ton chef d’orchestre pour VirtualBox, VMware, Hyper-V, et autres joyeusetés. C’est un outil ultra fiable pour gérer des environnements complets avec de vraies machines virtuelles de manière simple et automatisée."

Il s’agit d’un outil développé par Hashicorp permettant de gérer facilement des VMs avec une isolation totale des dépendances et des configurations, tout ceci dans un environement unique et jetable.

Tu lui écris un Vagrantfile, tu tapes vagrant up, et boum 💥 : ta(tes) machine(s) est(sont) là, toute prête à etre utilisée(s). Pas besoin de cliquer sur 27 boutons dans VirtualBox ou te battre avec Hyper-V.

Vagrant t’évite de :

❌ Aller télécharger une ISO

❌ Suivre l’installateur à la main

❌ Galérer avec le réseau et les scripts

✅ Il te permet de tout faire automatiquement, et de réinitialiser ton environnement quand tu veux, comme une sauvegarde rapide de ta vie de dev.

🔍 Pourquoi c’est pratique ?

🔄 Test facile : tu veux tester une config Postgres ? SSH ? Un cluster ? Un lab réseau? Boom, tu spin une VM.
💥 Sans risque : tu peux facilement préparer des démos ou tutoriels sans polluer ta machine principale. Si tu casses tout, tu fais vagrant destroy && vagrant up et ça repart.
🤝 Partageable : tu bosses en équipe ? Tu commits ton Vagrantfile et tout le monde a le même environnement.
🧪 Proche de la prod : tu peux créer des environnements qui imitent vraiment un serveur réel (contrairement à Docker qui fait du container). Tu as désormais donc tout pour apprendre l’admin système ou le DevOps.

🛠️ Comment ça fonctionne ?

Vagrant repose sur :

Un provider (généralement VirtualBox ou Hyper-V) pour faire tourner les machines
Les boxes : ce sont des images de systèmes déployables au sein de tout environnement Vagrant. Il s'agit en pratique d'une façon de packager une distribution afin de permettre un déploiement uniforme quel que soit le système d'exploitation ou l'hyperviseur utilisé. Tu peux consulter le depot officiel des boxes de vagrant ici
Un Vagrantfile (ta recette): le fichier dans lequel toute la magie se définie.
Des scripts ou outils pour provisionner la machine (installer des logiciels, configurer les services de base)

Vagrant va provisioner la machine en fonction de ce qui est décrit dans le fichier Vagrantfile (souvent à la racine du projet). Un fichier Vagrantfile est un fichier Ruby, dont le contenu ne nécessite pas une grande connaisance de Ruby. Il sert à décrire toutes les caractéristiques de la machine cible (stockages, Ram, réseaux, etc) et aussi à préparer tous les utilitaires de base nécessaire au bon fonctionnement de la machine.

🎓 Premiers pas avec vagrant

Dans la suite nous allons prendre en main vagrant et mettre en place un lab pour la série à propos des sauvegardes incrémentales avec postgres. On mettra dans la suite notre lab en place sur une machine Ubuntu.

Il s’agira à la fin de pouvoir démarrer deux VM sur lequelles nous allons installer respectivement barman et postgres.

🚀 Installation de Vagrant

Tu peux installer vagrant soit en ligne de commande soit avec un executable disponible sur la documentation officielle ici.

Il faudra aussi VirtualBox fonctionnel pour la suite, c’est le provider vagrant que nous allons utiliser dans la suite

🛠️ Manipulation de Vagrant

Pour démarrer nous allons simplement écrire notre premier Vagrantfile, on y mettra le minimum d’information pour faire tourner une VM. Il faudra créer un dossier qui contiendra un fichier Vagrantfile dont le contenu pourra être le suivant

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/focal64"
  config.vm.hostname = "vagrantbox"
end

Vagrant mets à disposition une large variété de commande pour manipuler les différentes composantes de l’ecosystème vagrant comme vagrant box list ou vagrand box add box_name pour respectivement lister les box disponibles localement, et ajouter une box à la collection locale.

$ vagrant box add ubuntu/focal64
==> box: Loading metadata for box 'ubuntu/focal64'
    box: URL: https://vagrantcloud.com/api/v2/vagrant/ubuntu/focal64
This box can work with multiple providers! The providers that it
can work with are listed below. Please review the list and choose
the provider you will be working with.

1) hyperv
2) libvirt
3) virtualbox
4) vmware_desktop

Enter your choice: 3
==> box: Adding box 'ubuntu/focal64' (v2004.01) for provider: virtualbox
    box: Downloading: https://vagrantcloud.com/ubuntu/boxes/focal64/versions/20240821.0.1/providers/virtualbox/unknown/vagrant.box

$ vagrant box list             
ubuntu/bionic64 (virtualbox, 20230607.0.0)
ubuntu/focal64  (virtualbox, 20240220.0.0)

Plus d’information sur la gestion des box vagrant ici.

Vérifions ensuite que la syntaxe du fichier est correcte avec vagrant validate. S’il n’y a aucune erreur tu verras le message suivant Vagrantfile validated successfully.

A ce stade s’il n’y a aucune erreur, on peut lancer notre vm avec la commande vagrant up

$ vagrant up             
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/focal64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/focal64' version '20240220.0.0' is up to date...
==> default: A newer version of the box 'ubuntu/focal64' for provider 'virtualbox' is
==> default: available! You currently have version '20240220.0.0'. The latest is version
==> default: '20240821.0.1'. Run `vagrant box update` to update.
==> default: Setting the name of the VM: ocr_default_1749933808776_2967
==> default: Clearing any previously set network interfaces...
[...]

$ vagrant status
Current machine states:

default                   running (virtualbox)
[...]

Une fois la VM lancée, on pourra s’y connecter par ssh pour effectuer nos différentes manipulations avec la commande vagrant ssh nom_machine.

Vagrant peut etre bien aussi utilisé dans un context pour répondre à un schéma d’architecture multi-tiers ie plusieurs machines(parfois avec différents OS) à la fois comme c’est souvent le cas en production; il suffi juste d’alligner autant de description de VM qu’il nous faut.

Connectons nous à présent à notre machine jusqu’ici préparée

$ vagrant ssh default             
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-172-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro
[...]
vagrant@vagrantbox:~$

Le diagramme ci-dessous illustre le parcours typique d'une machine virtuelle Vagrant, depuis son initialisation jusqu'à sa suppression complète.

Étapes principales

vagrant init

Initialise un projet Vagrant en créant un Vagrantfile.
Configured vagrantfile

Etape importante pour la mise en place du Vagrantfile. On y mettre le necessaire pour la préparation de la machine(provisonnement et autre). Ensuite grace à la commande vagrant up on démarre la machine virtuelle. Si elle n’existe pas, elle est créée et provisionnée.
Running

La machine est en cours d'exécution. À partir de là, plusieurs options s’offrent à toi :

* `vagrant reload` : redémarre la VM avec la config à jour

* `vagrant suspend` / `vagrant resume` : suspend et reprend l’exécution

* `vagrant halt` : éteint la VM proprement

* `vagrant provision` : réexécute les scripts de provisioning

Destroy Avec vagrant destroy, la VM est complètement supprimée. Tu reviens alors à un état propre.

🚀 Provisionner les VM vagrant

Maintenant que notre environnement de base est défini dans le Vagrantfile, il est temps de préparer chaque machine pour qu’elles soient prêtes à l’emploi ie installer le nécessaire qu’il faut pour les utiliser; c’est l’etape du provisionnement.

Vagrant met à disposition plusieurs interfaces pour provisionner nos VM: les provisionneur de type shell, fichier, chef, docker, ansible, etc. Dans la suite, nous allons découvrir quelques un de ces provisonneurs et préparer le nécessaire pour provisonner nos VM pour le lab sur postgres et vagrant.

Provisionner Shell

Il permet de spécifier une suite d’instruction à exécuter pour provisionner la machine. Cette interface supporte par defaut deux options inline et path pour respectivement spécifier une commande à directement saisir dans le vagranfile ou le chemin vers un script bash deja pret à l’emploi pour préparer notre machine comme le montre l’exemple ci dessous

Vagrant.configure("2") do |config|
  # ... autre configuration
  config.vm.provision "shell",
    inline: "echo Hello, World"
end

Vagrant.configure("2") do |config|
  # ... autre configuration
  config.vm.provision "shell", path: /path/to/my/bash/script
end

Provisionner fichier

Il permet de monter un fichier ou un dossier depuis la machine hôte vers la machine virtuelle.

Ce mécanisme est particulièrement utile lorsqu’il s’agit de partager des scripts de provisionnement, des fichiers de configuration ou des jeux de données entre l’hôte et la VM, sans avoir à les copier manuellement à chaque fois. Pour copier par exemple un fichier vers la machine hote, la syntaxe est la suivante:

Vagrant.configure("2") do |config|
  # ... autre configuration

  config.vm.provision "file", source: "~/path/to/host/folder", destination: "$HOME/remote/newfolder"
end

Cette copie est ponctuelle et ne synchronise pas l’etat des fichiers. Pour synchroniser l’etat des fichiers entre l’hote et la VM, la configuration doit se présenter comme suit:

Vagrant.configure("2") do |config|
  # ... autre configuration

  config.vm.synced_folder "src/", "/srv/website"
end

Pour plus d’informations sur la sychronisation consulter la documentation officielle ici.

Provisionner ansible

Contrairement aux scripts shell classiques, le provisionneur Ansible permet de décrire l’état attendu d’un système de manière déclarative. Cela signifie que tu écris des "playbooks" (fichiers YAML) qui définissent ce que tu veux obtenir (ex. : PostgreSQL installé, un utilisateur créé, un service démarré), et Ansible s’occupe de faire le nécessaire pour atteindre cet état, sans répéter inutilement les tâches déjà effectuées.

🔍 Avantages d’utiliser Ansible avec Vagrant :

✅ Code plus lisible, structuré et réutilisable.
🔁 Idempotence : rejouer un playbook ne modifie rien si tout est déjà en place.
⚙️ Facile à maintenir, surtout pour des environnements complexes ou multi-machines.

Vagrant peut exécuter Ansible en tant que provisionneur local ou distant, selon que Ansible est installé sur l’hôte ou sur la VM elle-même.

Voici un exemple minimal dans un Vagrantfile :

config.vm.provision "ansible" do |ansible|
  ansible.playbook = "playbook.yml"
  ansible.inventory_path = "inventory.ini"
end

🧪 Phase pratique : mise en place du lab PostgreSQL + Barman

Il est temps de passer à la pratique et de construire notre environnement de test.

L’objectif de cette phase est de créer deux machines virtuelles à l’aide de Vagrant :

🐘 Une première VM avec PostgreSQL installé; elle simulera notre base de données source,
📦 Une seconde VM avec barman installé; elle représentera un poste administrateur ou une machine de contrôle depuis laquelle on pourra gérer nos sauvegardes.

Nous allons automatiser l’installation de chaque composant à l’aide de scripts de provisionnement Bash. Le Vagrantfile définira l’architecture de notre lab et exécutera les scripts automatiquement au démarrage des machines.

Commençons par créer le fichier Vagrantfile et les scripts nécessaires à l’installation de postgres et barman.

Vagranfile:

# Vagrantfile
Vagrant.configure("2") do |config|
  config.vm.define "vm1_postgres" do |vm1|
    vm1.vm.box = "ubuntu/jammy64"
    vm1.vm.hostname = "postgres"
    vm1.vm.network "private_network", ip: "192.168.56.10"
    vm1.vm.provision "shell", path: "scripts/setup_postgres.sh"
  end

  config.vm.define "vm2_vagrant" do |vm2|
    vm2.vm.box = "ubuntu/jammy64"
    vm2.vm.hostname = "vagrant"
    vm2.vm.network "private_network", ip: "192.168.56.11"
    vm2.vm.provision "shell", path: "scripts/setup_vagrant.sh"
  end
end

scripts/setup_postgres.sh

#!/bin/bash
set -e

echo "[INFO] Installation de PostgreSQL..."

# Mise à jour des paquets
sudo apt-get update

# Installation de PostgreSQL
sudo apt-get install -y postgresql postgresql-contrib

# Vérification
psql --version && echo "[OK] PostgreSQL installé"

scripts/setup_barman.sh

#!/bin/bash
set -e

echo "[INFO] Installation de Barman..."

# Mise à jour des paquets
sudo apt-get update

# Installation de Barman (et dépendances)
sudo apt-get install -y barman

# Vérification
barman --version && echo "[OK] Barman installé"

🧩 Conclusion

Nous venons de découvrir Vagrant et en application poser les bases d’un environnement de test en mettant en place deux machines virtuelles : l'une avec PostgreSQL installé, et l'autre avec Barman, notre outil de sauvegarde dans la série sur les sauvegardes incrémentales.

Grâce à Vagrant et aux scripts de provisionnement, nous avons automatisé le déploiement de cet environnement, ce qui nous permettra de reproduire facilement nos tests, de gagner du temps, et d’éviter les erreurs manuelles.

Ce que nous avons mis en place ici ne se limite pas au contexte de postgres et de barman : ce type de lab peut servir de base générique pour toutes sortes de pratiques DevOps, d’expérimentations systèmes ou de tests techniques en environnement isolé.

🧰 Un socle simple, reproductible et extensible idéal pour apprendre, tester, casser… et recommencer !

À très bientôt pour le prochain article de ce blog

Setting up incremental backups with PostgreSql - Recovery - Part 3

ZINSOU Trinité — Sat, 13 Sep 2025 11:21:08 +0000

🧭 Introduction

Setting up backups is essential. But knowing how to restore them effectively when needed is even more crucial. This is where PITR (Point-In-Time Recovery) comes into play, a powerful feature offered by PostgreSQL and fully managed by Barman.

Whether it’s to correct a human error, revert after a failed deployment, or analyze the state of the database at a specific moment, Barman allows you to bring PostgreSQL back in time, replaying only the changes up to a defined point.

In this chapter, we’ll explore:

What PITR actually is,
The prerequisites for it to work,
And most importantly, how to use it step by step with Barman, reliably.

Ready to travel back in time with PostgreSQL? Let’s go 👇

🕰️ What is PITR (Point-In-Time Recovery)?

Point-In-Time Recovery, or PITR, is a powerful PostgreSQL feature that allows you to restore a database to a precise moment in the past.

It’s a bit like a time machine 🕳️🕒.

Imagine a bug or human error corrupted data this morning at 10:30 AM. With PITR, you can restore the database exactly as it was at 09:29 AM, just before the issue.

For this to work, PostgreSQL logs all database writes in files called WALs (Write Ahead Logs). These files contain the history of all changes made to the database.

Barman uses these files to replay the database history up to the chosen moment, starting from a full backup. It essentially rewinds the database to a specific point captured by the existing backups.

🎯 RPO and RTO: The Two Pillars of a Solid Backup/Restore Strategy

When talking about business continuity and disaster recovery, two concepts are essential to understand before even considering backups or tools like Barman:

📌 Recovery Point Objective (RPO)

RPO, or Recovery Point Objective, represents the maximum amount of data you can afford to lose in case of an incident.

👉 Example:

If you can accept losing up to 5 minutes of data, your RPO is 5 minutes. This means your backups (or WAL captures) should occur at least every 5 minutes.

⏱ Recovery Time Objective (RTO)

RTO, or Recovery Time Objective, represents the maximum acceptable downtime after an incident.

👉 Example:

If you consider a 30 minutes service outage acceptable, your RTO is 30 minutes. This means your tools and restoration mechanisms (like Barman and your automations) must be able to restore and bring the service online within this timeframe.

⚖️ Finding the Right Balance Between Ideal and Reality

We’d all love RPO = 0 (no data loss) and RTO = 0 (no downtime).

But in real life, there’s usually a trade-off between cost and service criticality.

For example:

For a brochure website, an RPO/RTO of several hours may be acceptable.
For a banking application, every second counts: RPO/RTO must be near zero.

💡 RPO and RTO with PostgreSQL and Barman

Good news: with a well-configured open-source stack, you can get very good performance:

RPO = 0 🎯

Thanks to PostgreSQL’s synchronous streaming replication, your data can be protected without loss.
Minimal RTO ⏱

By combining Barman for backups and repmgr for high availability, near-instant recovery is possible in case of issues.

🧰 Prerequisites for PITR Restoration

Before attempting a point-in-time restore, some elements must be in place for a smooth process:

1. Valid backup available

You must have at least one full backup in Barman. This will serve as the starting point for restoration.

2. WAL archiving enabled

PITR relies on replaying WALs (Write Ahead Logs) up to a precise moment. Ensure archiving works correctly and files are present in Barman’s wals directory.

3. Sufficient disk space

Restoration will create a new copy of the database. Ensure there is enough free space on the target server.

4. Timestamp or XID for restoration

To trigger PITR, specify the restore point, either:

a date/time ('2025-04-11 16:00:00'),
a transaction ID (XID),
or simply the end of the backup (if you don’t replay WALs).

5. Test environment (optional but recommended)

Before restoring in production, it’s strongly recommended to test the restore in an isolated environment.

🔄 Data Recovery with Barman (Practical Example)

Let’s create a table in our test databas

e and make several manipulations to test our backup system. Here’s a script you can use:

--- create articles table
CREATE TABLE articles (
  id SERIAL PRIMARY KEY,
  title TEXT,
  content TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

--- insert 20 rows into articles table
INSERT INTO articles (title, content)
SELECT
  'Article title ' || i,
  'Lorem ipsum dolor sit amet, consectetur adipiscing elit. 
   Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. 
   Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.'
FROM generate_series(1, 20) AS s(i);

Next, take an incremental backup before simulating a data loss (e.g., accidental deletion) using barman backup pg (assuming pg is your PostgreSQL server in Barman’s config):

# on the barman server
$ barman backup pg
Starting backup using rsync-concurrent method for server pg in /var/lib/barman/pg/base/20250415T201516
Backup start at LSN: 0/14000028 (000000010000000000000014, 00000028)
Starting backup copy via rsync/SSH for 20250415T201516
Copy done (time: 2 seconds)
Asking PostgreSQL server to finalize the backup.
Backup size: 38.9 MiB. Actual size on disk: 4.8 MiB (-87.55% deduplication ratio).
Backup end at LSN: 0/14000100 (000000010000000000000014, 00000100)
Backup completed (start time: 2025-04-15 20:15:16.336556, elapsed time: 4 seconds)
Processing xlog segments from file archival for pg
    000000010000000000000013
    000000010000000000000014
    000000010000000000000014.00000028.backup

Note the backup end time, which will be used to set your --target-time during restoration.

Now, simulate data loss:

--- delete articles with even IDs
DELETE FROM articles WHERE id % 2 = 0;

--- verify deletion
SELECT COUNT(id) FROM articles;

/*
--------------------------------------------
                OUTPUT
--------------------------------------------
*/
 count 
-------
    10
(1 row)

💥 All articles with even IDs are now deleted. This is the perfect moment to use incremental recovery and revert to the original state. First, take a new backup and stop the PostgreSQL server:

# on the barman server
$ barman backup pg
Starting backup using rsync-concurrent method for server pg in /var/lib/barman/pg/base/20250415T201754
Backup start at LSN: 0/17000028 (000000010000000000000017, 00000028)
Starting backup copy via rsync/SSH for 20250415T201754
Copy done (time: 2 seconds)
Asking PostgreSQL server to finalize the backup.
Backup size: 38.9 MiB. Actual size on disk: 129.7 KiB (-99.67% deduplication ratio).
Backup end at LSN: 0/17000100 (000000010000000000000017, 00000100)
Backup completed (start time: 2025-04-15 20:17:55.167843, elapsed time: 4 seconds)
Processing xlog segments from file archival for pg
    000000010000000000000016
    000000010000000000000017
    000000010000000000000017.00000028.backup

$ barman list-backup pg
pg 20250415T201754 - Tue Apr 15 20:17:58 2025 - Size: 54.9 MiB - WAL Size: 0 B
pg 20250415T201516 - Tue Apr 15 20:15:19 2025 - Size: 54.9 MiB - WAL Size: 48.0 MiB
pg 20250413T113210 - Sun Apr 13 11:32:14 2025 - Size: 54.8 MiB - WAL Size: 32.0 MiB

# on the PostgreSQL server
$ sudo service postgresql stop

Two backups surround the incident: 20250415T201516 and 20250415T201754. The first one (pre-incident) will be used for PITR.

To restore, run this command on the Barman server:

$ barman recover --remote-ssh-command "ssh postgres@192.168.58.11" --target-time="2025-04-15 20:17:58.270833+00:00" pg 20250415T201754 /var/lib/postgresql/12/main
Starting remote restore for server pg using backup 20250415T201754
Destination directory: /var/lib/postgresql/12/main
Remote command: ssh postgres@192.168.58.11
Doing PITR. Recovery target time: '2025-04-15 20:17:58.270833+00:00'
Using safe horizon time for smart rsync copy: 2025-04-15 20:17:54.690087+00:00
Copying the base backup.
Copying required WAL segments.
Generating recovery configuration
Identify dangerous settings in destination directory.

IMPORTANT
These settings have been modified to prevent data losses

postgresql.conf line 755: archive_command = false

WARNING
You are required to review the following options as potentially dangerous

postgresql.conf line 41: data_directory = '/var/lib/postgresql/12/main'     # use data in another directory
postgresql.conf line 43: hba_file = '/etc/postgresql/12/main/pg_hba.conf'   # host-based authentication file
postgresql.conf line 45: ident_file = '/etc/postgresql/12/main/pg_ident.conf'   # ident configuration file
postgresql.conf line 49: external_pid_file = '/var/run/postgresql/12-main.pid'          # write an extra PID file
postgresql.conf line 66: unix_socket_directories = '/var/run/postgresql'    # comma-separated list of directories
postgresql.conf line 102: ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem'
postgresql.conf line 104: ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'
postgresql.conf line 740: include_dir = 'conf.d'            # include files ending in '.conf' from

Recovery completed (start time: 2025-04-16 15:14:41.903013, elapsed time: 8 seconds)

Your PostgreSQL server has been successfully prepared for recovery!

Command options:

--remote-ssh-command: SSH command to connect to the PostgreSQL server
--target-time: date/time to restore the data
server_name: name of the server
backup_id: backup to use
destination_directory: folder for restoration

Restoration can be done in any folder other than PostgreSQL’s main directory if you reconfigure PostgreSQL to point to it. After recovery:

--- verify data count
SELECT COUNT(id) FROM articles;

/*
--------------------------------------------
                OUTPUT
--------------------------------------------
*/
 count 
-------
    20
(1 row)

🏁 Conclusion

Human errors, software corruption, or hardware failures are not a matter of if, but when. In this context, the ability to revert PostgreSQL to a precise previous state is essential.

With Barman and Point-In-Time Recovery (PITR), you have a reliable, robust, and powerful tool to ensure business continuity. By combining full backups with archived WAL files, you can restore your database to the exact second before an incident.

Moreover, as you’ve seen, this process can be automated, tested, and industrialized, offering a lot of advantages for enhancing your PostgreSQL architecture’s resilience.

Setting up incremental backups with PostgreSql - Implementation - Part 2

ZINSOU Trinité — Sat, 13 Sep 2025 11:19:15 +0000

🧭 Introduction

In the first part, we laid the foundation: understanding the different types of backups, the crucial role of WAL files, and what Barman has to offer. Now, it’s time to take action.

In this hands-on guide, we’ll configure PostgreSQL and Barman step by step to set up a robust and automated incremental backup system. The goal is simple: you should be able to replicate it in your own environment.

ℹ️ This article uses Ubuntu as the reference environment.

We’ll use two Ubuntu 22 servers named pg and barman, with respective IPs: 192.168.58.11 (PostgreSQL) and 192.168.58.12 (Barman).

Ready? Let’s dive in. 👇

🤔 Which Backup Strategy Should You Choose with Barman?

Choosing the right backup strategy is key to building a reliable system. Barman supports two main methods:

Via rsync: a classic method using SSH to transfer files from the PostgreSQL server to the Barman server.
Via pg_basebackup: a more modern approach using PostgreSQL’s native streaming replication protocol.

Since incremental backups with pg_basebackup are only supported starting with PostgreSQL 17, we’ll configure our setup using rsync.

The diagram below illustrates how to set up incremental backups with rsync:

To succeed with this configuration, we need:

A standard connection to PostgreSQL (1)

Used by Barman for management, coordination, and monitoring tasks. This is a classic TCP/IP connection on PostgreSQL’s port.
SSH connection for base backups (2)

Since we’re using rsync, Barman must use SSH to connect to the PostgreSQL server. The barman user (on the Barman server) connects as postgres (on the PostgreSQL server) to access backup files.
SSH connection for WAL archiving (3)

The archive_command in PostgreSQL (we’ll get to that 😉) triggers the PostgreSQL server to initiate an SSH connection. The postgres user (on the PostgreSQL server) connects as barman (on the Barman server) to send the WAL files.

🔑 SSH Configuration Between Barman and PostgreSQL

To ensure secure, passwordless communication between PostgreSQL and Barman, we must set up SSH key authentication between the two servers.

We'll generate SSH key pairs for both postgres and barman users and exchange them accordingly.

On the PostgreSQL server:

su postgres
ssh-keygen -t rsa -b 2048
ssh-copy-id -i /var/lib/postgresql/.ssh/id_rsa barman@192.168.58.12

💡 Make sure both postgres and barman have strong passwords set beforehand.

🔧 PostgreSQL Configuration for Incremental Backups (via rsync)

Before Barman can operate, we need to prepare PostgreSQL to provide the necessary WAL (Write-Ahead Log) files stored in /var/lib/postgresql/<version>/main/pg_wal/.

🗂️ Enable WAL Archiving in `postgresql.conf`

Open the postgresql.conf file (usually located in /etc/postgresql/<version>/main) and locate:

include_dir = 'conf.d'

This allows us to create a custom config file like archivage.conf inside conf.d. Add the following:

bashCopierModifierlisten_addresses = '*'
wal_level = replica
archive_mode = on
archive_command = 'rsync -a %p barman@192.168.58.12:/var/lib/barman/pg/incoming/%f'
max_wal_senders = 3

Explanation:

wal_level = replica: Enables WAL logging needed for replication and backups.
archive_mode = on: Activates archiving of WAL files.
archive_command: Command executed for every new WAL segment here using rsync to send it to the Barman server.
max_wal_senders: Sets how many connections can send WALs concurrently.

✅ Tip: Test your rsync command manually between servers to confirm connectivity.

🔐 Allow Barman Connections in `pg_hba.conf`

In /etc/postgresql/<version>/main/pg_hba.conf, add:

# Backup access
host    replication     barman     192.168.58.12/32      md5

Then create the barman user in PostgreSQL:

$ createuser --superuser --replication -P barman

✅ Restart PostgreSQL to apply changes:

$ sudo systemctl restart postgresql

🛠️ Barman Configuration for Incremental Backups

Now that PostgreSQL is sending WAL files, let’s configure Barman to receive and manage them.

📁 Set Up the Backup Directory

By default, Barman uses /var/lib/barman. Let’s prepare a directory for our server:

$ sudo mkdir -p /var/lib/barman/pg
$ sudo chown -R barman:barman /var/lib/barman/pg

🧾 `barman.conf` Configuration

Global config: /etc/barman.conf

Per-server config: /etc/barman.d/pg.conf

Here’s a minimal config example:

[pg]
description = "Primary PostgreSQL server"
conninfo = host=192.168.58.11 user=barman dbname=test_db
ssh_command = ssh postgres@192.168.58.11
backup_method = rsync
streaming_archiver = on
slot_name = barman

Key Options:

conninfo: Connection string to PostgreSQL
ssh_command: SSH access via postgres
backup_method: rsync
streaming_archiver: Enables real-time WAL capture
slot_name: Replication slot name for WAL streaming

⚙️ Optional Advanced Settings

You can customize your setup:

iniCopierModifierreuse_backup = link
retention_policy = RECOVERY WINDOW OF 7 DAYS
compression = gzip

reuse_backup = link: Avoids file duplication
retention_policy: Keep backups for 7 days
compression: Saves disk space with gzip

📌 Full config options available in Barman's documentation

🔐 Store Passwords in `.pgpass`

To enable passwordless conninfo logins, add a .pgpass file for barman:

bashCopierModifiersu barman
cat <<'EOF' >>~/.pgpass
mon_serveur:5432:test_db:barman:password
EOF
chmod 0600 ~/.pgpass

Format:

[host]:[port]:[database]:[user]:[password]

✅ Check That Everything Works

Now test the Barman-PostgreSQL connection:

$ barman check pg
  Server pg:
  PostgreSQL: OK
  ...
  continuous archiving: OK
  archiver errors: OK

🚀 Run Your First Backup

$ barman backup pg
Starting backup using rsync...
Backup completed
WAL segments processed:
  000000010000000000000011
  000000010000000000000012

🔁 Automate Incremental Backups with Barman

Use cron to automate regular backups.

🕒 Schedule a Daily Backup at 2 AM

Edit Barman's crontab:

$ sudo -u barman crontab -e

Add this:

0 2 * * * barman backup pg

💡 Always test your command manually before automating.

📉 Optimize Disk Space

Enable compression: compression = gzip
Use retention policy: retention_policy = RECOVERY WINDOW OF 7 DAYS

🔍 Monitor and Manage Backups with Barman

✅ List Available Backups

$ barman list-backup pg
pg 20250415T201754 - Size: 54.9 MiB - WAL Size: 16.0 MiB

📊 Check Server Status

$ barman check pg

🔎 Inspect a Specific Backup

$ barman show-backup pg 20250415T201754

🧯 What If Something Fails?

If a backup fails:

Run barman check
Check logs in /var/log/postgresql and /var/log/barman/

🏁 Conclusion: Stay in Control of Your PostgreSQL Backups

In this second part, we focused on the technical setup required to build a solid incremental backup strategy using Barman. From PostgreSQL tuning and secure SSH keys to cron automation and proactive monitoring—each step boosts the resilience of your data.

Barman is a powerful, flexible, and open source solution that meets the needs of even the most demanding environments. But backup mastery doesn’t stop here.

In the next part, we’ll learn how to restore a PostgreSQL database, including Point-In-Time Recovery (PITR) and practical recovery scenarios.

👉 Stay tuned to complete your PostgreSQL backup strategy!

Setting up incremental backups with PostgreSql - Introduction - Part 1

ZINSOU Trinité — Sat, 13 Sep 2025 11:18:40 +0000

🧭 Introduction

PostgreSQL is a robust, reliable, and widely used database management system in the development world. It adheres to SQL standards, is open source, and most importantly, it keeps our data safe.

But even the best tool can't protect you from a bad command, a bug, or a server crash. That’s where our best ally comes in: the backup.

In this guide, we’ll explore how to configure incremental backups on PostgreSQL.

The goal? Whether you're a developer, administrator, student, or just curious, you'll be able to set up an automatic, efficient, and reassuring backup system.

Here’s what we’ll cover:

Understanding what a backup is (and what an incremental backup means 🧠)
Discovering PostgreSQL’s built-in tools 🔧
Step-by-step configuration of an incremental backup system 🛠️
Automating the process with scripts and cron ⏰
And even testing restoration (because an untested backup is just an illusion of safety 😉)

Ready? Let’s start with the basics. 👇

🧠 Reminder: What’s a backup (and what’s an incremental one)?

Before jumping into the configuration, let’s take a moment to lay the groundwork because good understanding is already half the job.

🔐 What is a backup?

It’s simply a copy of data (files, databases, configurations, etc.) stored separately, in a safe place, so we can recover it if something goes wrong: human error, failure, hacking or just a “Oops, I deleted everything.”

🧱 The 3 main types of backups

There are several ways to back up data. Here are the three most common:

Full backup: you copy all files every time. It’s simple but can quickly become heavy on disk space.
Differential backup: you copy only files that have changed since the last full backup. It's lighter, but over time it accumulates.
Incremental backup: you copy files that have changed since the last backup whatever type it was (full or incremental). It’s the most optimized in terms of size and time but a bit more technical to manage.

📌 Why are incremental backups great?

Because they help you save time and space while keeping a history of changes. And the good news is: PostgreSQL supports this kind of backup thanks to a built-in mechanism called Write-Ahead Logging (WAL).

👉 That’s exactly what we’ll use in this guide.

🔍 How does PostgreSQL handle incremental backups?

Let’s start by reviewing the types of backups PostgreSQL offers so we can understand the available mechanisms before diving into incremental backups.

🧬 The different types of backups in PostgreSQL

PostgreSQL offers three backup options 👇:

1. Full backup

This consists of copying the entire database at a specific point in time. It’s a snapshot of the database and allows restoration to its exact state when the backup was taken. Tools like pg_basebackup or manual file copying can be used for this.

2. Logical backup (pg_dump)

This uses the pg_dump tool to export the database as an SQL script. It’s a form of full backup that lets you recover the database independently of PostgreSQL’s physical structure. It’s often used for migrations or targeted backups (e.g., a table or schema). However, it has limitations for incremental backups, as it doesn’t include WAL transaction logs.

3. Incremental backup (WAL-based)

The incremental backup only saves changes made since the last backup (whether full or incremental). It relies on archiving WAL (Write-Ahead Log) files generated by PostgreSQL. These files record every transaction applied to the database. Using them, you can restore the database to a precise moment in time achieving a very low RPO (Recovery Point Objective), often just a few minutes. This is about minimizing the amount of data you are willing to lose after an incident.

🧪 About incremental backups

PostgreSQL’s key feature for incremental backups is Write-Ahead Logging (WAL).

Each write operation on the database is logged in special log files. These files record changes to the database before they are actually applied, thus ensuring data integrity.

This mechanism, known as WAL, makes it possible to restore the state of the database at a specific point in time, a technique called Point In Time Recovery (PITR). This means that after an initial full backup, you can restore a database to any given moment by replaying the WAL files generated since that backup.

That’s exactly what we’re going to leverage in our configuration with Barman.

⚙️ How WAL works

When WAL archiving is enabled, PostgreSQL generates log files in a specific directory (/var/lib/postgresql/{version}/main/pg_wal/) with each write operation. These files are rotated once they reach 16 MB (by default).

Each time a WAL file is created or modified, PostgreSQL can run a custom command, allowing centralized WAL archiving and simplified recovery.

Barman leverages these WAL files to manage incremental backups and point-in-time restores.

🚀 What is Barman?

🍹 Introducing Barman

Barman (Backup and Recovery Manager) is a Python-based tool that simplifies backup and recovery operations for PostgreSQL.

It helps with:

Scheduling and automating backups
Managing full and incremental backups
Performing Point-In-Time Recovery (PITR) using WAL files

It’s especially useful for managing multiple PostgreSQL servers and centralizing backup/restoration operations.

We’ll be configuring and using this tool in this article.

🤔 Barman vs `pg_dump`

Before going further, let’s compare Barman with traditional PostgreSQL backup tools: pg_dump / pg_basebackup.

pg_dump / pg_basebackup: These tools perform full backups, exporting the database’s state (as an SQL script, for example). However, they are limited when it comes to fast disaster recovery, since they only restore the exact point in time when the backup was made.

Let’s say you run a nightly pg_dump at 3 AM, and an incident happens at 6 PM. You’d lose all changes made since 3 AM 15 hours of data loss, which is unacceptable in most business scenarios.
Barman: Unlike pg_dump, Barman works at the physical level. It handles full and incremental backups, using WAL files to recover any change since the last backup. This allows low RPOs, minimizing data loss to a few minutes.

Of course, it requires more disk space, but the tradeoff is well worth it for data security and recovery capabilities.

📦 Installing Barman

Before using Barman, make sure PostgreSQL is properly installed.

Ubuntu users can follow this tutorial, and CentOS/RHEL users can refer to this one.

Once PostgreSQL is ready, we’ll look into advanced configuration. But first, let’s install Barman:

a. On Ubuntu/Debian

On Debian-based systems like Ubuntu, install Barman from official repositories:

Install from the repository:

$ sudo apt update
$ sudo apt install barman

Check the installation:

Once installation is complete, check that Barman has been installed correctly by running the following command:
```
$ sudo apt update
$ sudo apt install barman
```

a. On Ubuntu/Debian

On CentOS or RHEL, you must first add the official Barman repository before installing it.

Add the barman official repository:

$ sudo yum install -y https://dl.enterprisedb.com/barman/barman-2.16.0-1.rhel7.x86_64.rpm

Update system packages and install Barman:

 $ sudo yum update
 $ sudo yum install barman

Check the barman installation:
```
 $ barman --version
```

🧾 Conclusion

In this article, we explored the fundamental concepts needed to implement incremental backups in PostgreSQL, with a focus on the critical role of transaction logs (WAL) and the PITR mechanism. We also saw how Barman, the backup and recovery management tool, fits seamlessly into this process.

The goal was to provide a clear understanding of what incremental backups involve in PostgreSQL before diving into the technical configuration itself. With this foundation, you now have a broader perspective on the challenges and tools required for effective backup management.

In Part 2, we’ll get into the heart of the matter with the complete configuration of Barman from installation to enabling incremental backups. We’ll also cover best practices to ensure the continuity and reliability of your backups.

Stay tuned for the next article to learn how to configure and automate your backups efficiently.

Configurer des sauvegardes incrémentales avec PostgreSql - Introduction-Partie 3

ZINSOU Trinité — Sun, 29 Jun 2025 13:18:02 +0000

🧭 Introduction

Mettre en place des sauvegardes, c’est essentiel. Mais savoir les restaurer efficacement en cas de besoin, c’est encore plus crucial. C’est ici que le PITR (Point In Time Recovery) entre en jeu, une fonctionnalité puissante offerte par PostgreSQL et parfaitement gérée par Barman.

Que ce soit pour corriger une erreur humaine, revenir avant un déploiement raté ou analyser l’état de la base à un instant précis, Barman permet de ramener PostgreSQL dans le passé, en rejouant uniquement les modifications jusqu’à un point bien défini.

Dans ce chapitre, nous allons explorer :

Ce qu’est concrètement le PITR,
Les prérequis pour qu’il fonctionne,
Et surtout, comment l’utiliser pas à pas avec Barman, de manière fiable.

Prêt à voyager dans le temps avec PostgreSQL ? C’est par ici 👇

🕰️ C’est quoi le PITR (Point-In-Time Recovery) ?

Le Point-In-Time Recovery, ou PITR, est une fonctionnalité puissante de PostgreSQL qui permet de restaurer une base de données à un instant précis dans le passé.

C’est un peu comme une machine à remonter le temps 🕳️🕒.

Imaginons qu’un bug ou une erreur humaine ait corrompu des données ce matin à 10h30. Grâce au PITR, vous pouvez restaurer la base exactement comme elle était à 09h29, juste avant le problème.

Pour que cela fonctionne, PostgreSQL enregistre toutes les écriture sur la base de données dans des fichiers appelés WALs (Write Ahead Logs). Ces fichiers contiennent l’historique des modifications apportées à la base.

Barman exploite ces fichiers pour rejouer l’histoire de la base jusqu’à l’instant choisi, à partir d’une sauvegarde complète. Il effectue ainsi un rétropédalage jusqu’à un instant désiré bien pris en compte par les sauvegardes existantes

🎯 RPO et RTO : Les deux piliers d’une bonne stratégie de sauvegarde/restauration

Quand on parle de continuité d’activité et de plan de reprise après sinistre (disaster recovery), deux notions sont essentielles à comprendre avant même de parler de sauvegarde ou d’outil comme Barman :

📌 Recovery Point Objective (RPO)

Le RPO, ou objectif de point de reprise, représente la quantité maximale de données que l'on peut se permettre de perdre en cas d’incident.

👉 Exemple :

Si vous acceptez de perdre au maximum 5 minutes de données, votre RPO est de 5 minutes. Cela implique que vos sauvegardes (ou la capture de vos WAL) doivent se faire au moins toutes les 5 minutes.

⏱ Recovery Time Objective (RTO)

Le RTO, ou objectif de temps de reprise, désigne la durée maximale acceptable d’indisponibilité du service après un incident.

👉 Exemple :

Si vous estimez qu’une interruption de service de 30 minutes est tolérable, alors votre RTO est de 30 minutes. Cela implique que vos outils et mécanisme de restauration (comme Barman et les automatisations que vous mettrez en place) doivent être capables de restorer et remettre le service en ligne dans ce délai.

⚖️ Trouver le bon équilibre entre idéal et réalité

On aimerait tous avoir un RPO = 0 (aucune perte de données) et un RTO = 0 (aucun temps d’arrêt).

Mais dans la vraie vie, il faut souvent faire un compromis entre le coût et la criticité du service.

Par exemple :

Pour un site vitrine, un RPO/RTO de plusieurs heures peut être toléré.
Pour une application bancaire, chaque seconde compte : le RPO/RTO doit être quasi nul.

💡 RPO et RTO avec PostgreSQL et Barman

Bonne nouvelle : avec un stack open source bien configuré, il est possible de s’approcher de très bonnes performances :

RPO = 0 🎯

Grâce à la réplication en streaming synchrone de PostgreSQL, vos données peuvent être protégées sans perte.
RTO minimal ⏱

En combinant Barman pour les sauvegardes et repmgr pour la haute disponibilité, on peut atteindre un redémarrage quasi instantané en cas de problème.

🧰 Prérequis pour une restauration avec PITR

Avant de tenter une restauration point-in-time, quelques éléments doivent être en place pour que tout se passe bien :

1. Sauvegarde valide disponible

Vous devez avoir au moins une sauvegarde complète dans Barman. Elle servira de point de départ pour la restauration.

2. Archivage WAL activé

Le PITR repose sur la capacité à rejouer les WAL (Write Ahead Logs) jusqu’à un instant précis. Assurez-vous que l’archivage fonctionne correctement et que les fichiers sont bien présents dans le répertoire wals de Barman.

3. Espace disque suffisant

La restauration va créer une nouvelle copie de la base. Il est essentiel d’avoir suffisamment d’espace libre sur le serveur cible.

4. Horodatage ou XID de restauration

Pour déclencher un PITR, vous devez spécifier le point de restauration, soit :

* une date/heure ('2025-04-11 16:00:00'),

* un identifiant de transaction (XID),

* ou simplement la fin de la sauvegarde (si vous ne rejouez pas les WAL).

5. Environnement de test (optionnel mais recommandé)

Avant de lancer une restauration en production, il est fortement conseillé de tester la restauration dans un environnement isolé.

🔄 Récupération des données avec Barman (cas pratique)

Nous allons créer une table au niveau de notre base de données test et faire plusieurs manipulations afin d’éprouver notre système de sauvegarde.On va donc ajouter une table à notre base de données et y ajouter quelques lignes(tu peux te servir de ce script😉):

--- creation d'une table articles
CREATE TABLE articles (
  id SERIAL PRIMARY KEY,
  title TEXT,
  content TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

--- insertion de 20 lignes dans la table articles

INSERT INTO articles (title, content)
SELECT
  'Titre de l’article ' || i,
  'Lorem ipsum dolor sit amet, consectetur adipiscing elit. 
   Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. 
   Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.'
FROM generate_series(1, 20) AS s(i);

A cette étape on va refaire une sauvegarde incrémentale de notre base donnée avant de simuler un incident, une suppression involontaire de données par exemple toujours à l’aide de la commande barman backup pg(ici pg est le nom de notre serveur de base de données dans notre configuration barman), voici le retour à mon niveau:

# sur le serveur barman
$ barman backup pg
Starting backup using rsync-concurrent method for server pg in /var/lib/barman/pg/base/20250415T201516
Backup start at LSN: 0/14000028 (000000010000000000000014, 00000028)
Starting backup copy via rsync/SSH for 20250415T201516
Copy done (time: 2 seconds)
Asking PostgreSQL server to finalize the backup.
Backup size: 38.9 MiB. Actual size on disk: 4.8 MiB (-87.55% deduplication ratio).
Backup end at LSN: 0/14000100 (000000010000000000000014, 00000100)
Backup completed (start time: 2025-04-15 20:15:16.336556, elapsed time: 4 seconds)
Processing xlog segments from file archival for pg
    000000010000000000000013
    000000010000000000000014
    000000010000000000000014.00000028.backup

Note bien la date de fin de sauvegarde (start time+ temps ecoulé ou accesible avec barman show-backup pg id_backup ). Elle te servira de référence pour définir ton --target-time lors de la restauration.A présent simulons la perte de données:

--- suppression des articles d'id pairs
DELETE FROM articles WHERE id % 2 = 0;

--- vérifier que les éléments ont bien été supprimés
SELECT COUNT(id) FROM article; 

/*
--------------------------------------------
                OUTPUT
--------------------------------------------
*/
 count 
-------
    10
(1 row)

💥 Tous les articles avec un identifiant pair etant désormais supprimés (cet incident intervient peu de temps après ma dernière sauvegarde). C’est le moment idéal pour utiliser la récupération incrémentale et revenir à l’état initial. Avant de restorer nos données nous allons refaire une nouvelle sauvegarde et arreter notre serveur postgresql:

# sur le serveur barman
$ barman backup pg
Starting backup using rsync-concurrent method for server pg in /var/lib/barman/pg/base/20250415T201754
Backup start at LSN: 0/17000028 (000000010000000000000017, 00000028)
Starting backup copy via rsync/SSH for 20250415T201754
Copy done (time: 2 seconds)
Asking PostgreSQL server to finalize the backup.
Backup size: 38.9 MiB. Actual size on disk: 129.7 KiB (-99.67% deduplication ratio).
Backup end at LSN: 0/17000100 (000000010000000000000017, 00000100)
Backup completed (start time: 2025-04-15 20:17:55.167843, elapsed time: 4 seconds)
Processing xlog segments from file archival for pg
    000000010000000000000016
    000000010000000000000017
    000000010000000000000017.00000028.backup

$ barman list-backup pg
pg 20250415T201754 - Tue Apr 15 20:17:58 2025 - Size: 54.9 MiB - WAL Size: 0 B
pg 20250415T201516 - Tue Apr 15 20:15:19 2025 - Size: 54.9 MiB - WAL Size: 48.0 MiB
pg 20250413T113210 - Sun Apr 13 11:32:14 2025 - Size: 54.8 MiB - WAL Size: 32.0 MiB

# sur le serveur postgres
$ sudo service postgresql stop

A cette étape deux sauvegardes encadren notre incident, celles d’ids 20250415T201516 et 20250415T201754. La première est celle avec d’avant incident qui nous servira donc pour notre PITR.

La commande de restoration à taper sur le serveur barman est la suivante:

$ barman recover --remote-ssh-command "ssh postgres@192.168.58.11" --target-time="2025-04-15 20:17:58.270833+00:00" pg 20250415T201754 /var/lib/postgresql/12/main
Starting remote restore for server pg using backup 20250415T201754
Destination directory: /var/lib/postgresql/12/main
Remote command: ssh postgres@192.168.58.11
Doing PITR. Recovery target time: '2025-04-15 20:17:58.270833+00:00'
Using safe horizon time for smart rsync copy: 2025-04-15 20:17:54.690087+00:00
Copying the base backup.
Copying required WAL segments.
Generating recovery configuration
Identify dangerous settings in destination directory.

IMPORTANT
These settings have been modified to prevent data losses

postgresql.conf line 755: archive_command = false

WARNING
You are required to review the following options as potentially dangerous

postgresql.conf line 41: data_directory = '/var/lib/postgresql/12/main'     # use data in another directory
postgresql.conf line 43: hba_file = '/etc/postgresql/12/main/pg_hba.conf'   # host-based authentication file
postgresql.conf line 45: ident_file = '/etc/postgresql/12/main/pg_ident.conf'   # ident configuration file
postgresql.conf line 49: external_pid_file = '/var/run/postgresql/12-main.pid'          # write an extra PID file
postgresql.conf line 66: unix_socket_directories = '/var/run/postgresql'    # comma-separated list of directories
postgresql.conf line 102: ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem'
postgresql.conf line 104: ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'
postgresql.conf line 740: include_dir = 'conf.d'            # include files ending in '.conf' from

Recovery completed (start time: 2025-04-16 15:14:41.903013, elapsed time: 8 seconds)

Your PostgreSQL server has been successfully prepared for recovery!

Les options de cette commande sont: --remote-ssh-command une commande ssh vers le serveur postgres, --target-time la date à laquelle restorée les données qui doit etre xxxxxxxxxxxxxx, server_name pour le nom du serveur, backup_id le nom du backup et destination_directory pour le dossier qui doit accepter les sauvegardes. Tu pourrais avoir plus d’options avec barman recover -h.

La recupération peut se faire dans n’importe quel dossier à part celui de base de postgres à condition de reconfiguer postgres pour pointer sur le dossier considéré. On peut après avoir à nouveau accès à nos données récupérées:

--- vérifier que les éléments ont bien été supprimés
SELECT COUNT(id) FROM article; 

/*
--------------------------------------------
                OUTPUT
--------------------------------------------
*/
 count 
-------
    20
(1 row)

🏁 Conclusion

Les erreurs humaines, les corruptions logicielles ou les incidents matériels ne sont pas une question de "si", mais de "quand". Dans ce contexte, la capacité à revenir à un état antérieur précis de ta base PostgreSQL est essentielle.

Avec Barman et la fonctionnalité de Point-In-Time Recovery (PITR), tu disposes d’un outil fiable, robuste et puissant pour répondre aux impératifs de continuité d’activité. En combinant les sauvegardes complètes aux fichiers WAL archivés, tu peux restaurer ta base à la seconde près, juste avant un incident.

Plus encore, tu l’as vu : ce processus peut s’automatiser, se tester, s’industrialiser; autant d’atouts pour renforcer la résilience de ton architecture PostgreSQL.

Configurer des sauvegardes incrémentales avec PostgreSql - Introduction-Partie 2

ZINSOU Trinité — Thu, 12 Jun 2025 22:40:57 +0000

🧭 Introduction

Dans la première partie, on a posé les bases : comprendre les différents types de sauvegardes, le rôle crucial des fichiers WAL et ce que propose Barman. Maintenant, il est temps de passer à l’action.

Dans ce guide pratique, on va configurer PostgreSQL et Barman pas à pas pour mettre en place un système de sauvegarde incrémentale robuste et automatisé. L’objectif est simple : que tu puisses le reproduire dans ton propre environnement.

ℹ️ L'environnement de référence utilisé dans cet article est Ubuntu

Dans la suite nous utiliserons deux serveurs Ubuntu 22, qu’on appellera pg et barman pour postgres et barman respectivements et d’ip respectifs 192.168.58.11 et 192.168.58.12

Prêt ? On entre dans le vif du sujet. 👇

🤔 Quelle stratégie de sauvegarde choisir avec Barman ?

Le choix de la stratégie de sauvegarde est un élément crucial dans la mise en place d’un système fiable. Barman prend en charge deux grandes méthodes :

Via rsync : une méthode classique utilisant SSH pour transférer les fichiers du serveur PostgreSQL vers le serveur Barman.
Via pg_basebackup : une méthode moderne qui s’appuie sur le protocole de réplication en streaming natif de PostgreSQL.

Le streaming via pg_basebackup ne permet les sauvegardes incrémentales qu’à partir de la version 17 de Postgres, nous allons donc dans la suite voir comment faire nos configurations pour effectuer nos sauvegardes via rsync.

La figure ci dessous illustre comment mettre en place les sauvegardes incrémentales avec rsync.

Il nous faut donc pour réussir notre configuration:

Une connexion standard à PostgreSQL (1)

Utilisée par Barman pour les opérations de gestion, de coordination et de supervision. Cette connexion se fait généralement via un accès réseau classique au port PostgreSQL, souvent en TCP/IP.
Connexion SSH pour les sauvegardes de base (2)

Puisque nous avons décidé d’utiliser rsync, Barman doit pouvoir utiliser SSH pour se connecter au serveur PostgreSQL. L’utilisateur barman (sur le serveur Barman) doit se connecter en tant que postgres (sur le serveur PostgreSQL) et accéder aux fichiers nécessaires à la sauvegarde.
Connexion SSH pour l’archivage des fichiers WAL (3)

Pour l’archivage des WALs, une configuration appelée archive_command de postgresql est activé(on en parle dans la suite 😉), et là le serveur PostgreSQL doit initier une connexion SSH. L’utilisateur postgres (du serveur PostgreSQL) va se connecter en SSH au serveur Barman, en tant qu’utilisateur barman, afin d’envoyer les fichiers WAL au bon endroit.

🔑 Configurations SSH entre Barman et PostgreSQL

Pour permettre à Barman et PostgreSQL de communiquer de manière sécurisée et automatisée, il est essentiel de configurer une authentification par clé SSH entre les deux serveurs. Cette étape garantit des transferts fiables, sans mot de passe, pour les sauvegardes et l’archivage des fichiers WAL.

On va donc générer des paires de clés ssh en tant qu’utilisateurs postgres et barman à échanger entre nos différents serveurs.

Sur le serveur postgres:

su postgres
ssh-keygen -t rsa -b 2048
# fichier généré par default => /var/lib/postgresql/.ssh/id_rsa
ssh-copy-id -i /var/lib/postgresql/.ssh/id_rsa barman@192.168.58.12

Sur le serveur barman:

su barman
ssh-keygen -t rsa -b 2048
# fichier généré par default => /var/lib/barman/.ssh/id_rsa
ssh-copy-id -i /var/lib/barman/.ssh/id_rsa postgres@192.168.58.11

Cette étape nécessite de définir en amont pour les utilsateurs postgres et barman des mots de passe robustes.

🔧 Configuration détaillée de PostgreSQL pour les sauvegardes incrémentales (avec rsync)

Avant que Barman ne puisse faire son travail, il faut préparer PostgreSQL pour lui fournir ce dont il a besoin : les fichiers WAL (Write-Ahead Logs). Ces fichiers contenus dans le dossier /var/lib/postgresql/<version>/main/pg_wal/ contiennent un historique clair de toutes les écritures sur la base de données et sont essentiels pour effectuer des sauvegardes incrémentales.

Nous allons donc commencer par activer l’archivage WAL au niveau de notre serveur PostgreSQL.

🗂️ Activer l’archivage WAL dans `postgresql.conf`

Ouvre ton fichier postgresql.conf, généralement situé dans le répertoire principal de PostgreSQL (/etc/postgresql/<version>/main), et recherche la ligne

include_dir = 'conf.d' # include files ending in '.conf' from.

Grace à cette ligne, on peut créer dans le dossier conf.d du répertoire principal, un fichier archivage.conf pour porter nos configurations. Une fois le fichier crée ajoute ce contenu :

listen_addresses = '*'
wal_level = replica
archive_mode = on
archive_command = 'rsync -a %p barman@192.168.58.12:/var/lib/barman/pg/incoming/%f'
max_wal_senders = 3

Explications :

wal_level = replica : definit le niveau de journalisation minimal pour permettre les sauvegardes incrémentales.
archive_mode = on : active l’archivage des WAL.
archive_command : commande à exécuter à chaque rotation de logs expliqué dans la première partie de la série; ici on indique à PostgreSQL comment transférer chaque fichier WAL vers le serveur Barman en utilisant rsync.
max_wal_senders : nombre maximum de connexions pour envoyer des WAL à des clients (comme Barman).

✅ Astuce : Vérifie que la commande rsync fonctionne en testant manuellement la copie d’un fichier entre les serveurs.

🔐 Autoriser les connexions Barman dans pg_hba.conf

Dans le fichier /etc/postgresql/<version>/main/pg_hba.conf, ajoute cette ligne pour autoriser l’utilisateur Barman à se connecter :

# Connexion pour les sauvegardes
host    replication     barman     192.168.58.12/32      md5

Ensuite assure-toi que l’utilisateur barman existe dans PostgreSQL, avec un mot de passe sécurisé :

createuser --superuser --replication -P barman

🚀 Redémarrer PostgreSQL

Une fois ces modifications faites, redémarre PostgreSQL pour qu’elles prennent effet :

sudo systemctl restart postgresql

🛠️ Configuration de Barman pour les sauvegardes incrémentales

Une fois PostgreSQL prêt à envoyer ses WAL, il est temps de préparer Barman pour recevoir, stocker et gérer les sauvegardes; notamment les incrémentales.

📁 Configuration du répertoire de sauvegarde

Par défaut, Barman stocke ses données dans le répertoire /var/lib/barman. Il faut créer un sous-répertoire pour chaque serveur PostgreSQL à sauvegarder.

Puisqu’on a deja installé barman sur le serveur exécute donc :

sudo mkdir -p /var/lib/barman/pg
sudo chown -R barman:barman /var/lib/barman/pg

Tu peux aussi personnaliser l’emplacement via le fichier de configuration.

🧾 Fichier de configuration `barman.conf`

Le fichier global est/etc/barman.conf et chaque serveur pourra avoir sa propre configuration dans /etc/barman.d/.

Voici un exemple de configuration minimale pour notre serveur nommé pg :

# fichier pg.conf
[pg]
description = "Serveur PostgreSQL principal"
conninfo = host=192.168.58.11 user=barman dbname=test_db
ssh_command = ssh postgres@192.168.58.11
backup_method = rsync
streaming_archiver = on
slot_name = barman

📌 Explications des options importantes :

conninfo : comment se connecter à PostgreSQL.
ssh_command : connexion SSH utilisée par rsync.
backup_method : rsync.
streaming_archiver = on : permet de récupérer les WAL en continu.
slot_name : nom du slot de réplication utilisé par Barman pour les WAL.

⚙️ Paramètres avancés utiles

Tu peux adapter la configuration à ton usage :

reuse_backup = link
retention_policy = RECOVERY WINDOW OF 7 DAYS
compression = gzip

reuse_backup = link : évite les duplications de fichiers lors des backups incrémentaux.
retention_policy : conserve les sauvegardes nécessaires pour restaurer jusqu’à 7 jours en arrière.
compression : compresse les sauvegardes pour gagner de l’espace disque.

Toutes les options de configuration sont détaillées sur la documentation officielle de Barmn

Afin que barman puisse se connecter via l'utilisateur spécifié à la base de données, nous devons ajouter le mot de passe que nous avons spécifié à la création de l’utilisateur barman au fichier .pgpass.

su barman
cat <<'EOF' >>~/.pgpass
mon_serveur:5432:test_db:barman:password
EOF
chmod 0600 ~/.pgpass

Chaque ligne de ce fichier doit etre au format

[db_hote]:[db_port]:[db_nom]:[db_user]:[db_password]

✅ Vérifier que tout fonctionne

Avant de lancer un backup, vérifie la connexion entre Barman et PostgreSQL; à cette étape tous les voyants doivent etre au vert 🕺💃 et tu dois avoir:

$ barman check pg
Server pg:
    PostgreSQL: OK
    is_superuser: OK
    wal_level: OK
    directories: OK
    retention policy settings: OK
    backup maximum age: OK (no last_backup_maximum_age provided)
    compression settings: OK
    failed backups: OK (there are 0 failed backups)
    minimum redundancy requirements: OK (have 0 backups, expected at least 0)
    ssh: OK (PostgreSQL server)
    systemid coherence: OK
    archive_mode: OK
    archive_command: OK
    continuous archiving: OK
    archiver errors: OK

Tu peux aussi à présent lancer ton premier test de sauvegarde, si tout se passe bien tu dois avoir:

$ barman backup pg
Starting the backup using the rsync-concurrent method for the pg server in /var/lib/barman/pg/base/20250413T113210
Backup start at LSN: 0/12000060 (000000010000000000000012, 00000060)
This is the first backup for the pg server
The WAL segments preceding the current backup were found:
        000000010000000000000000F from pg server has been removed
        0000000100000000000000010 from server pg has been removed
Starting backup via rsync/SSH for 20250413T113210
Completed copy (duration: 3 seconds)
This is the first backup for the server pg
Asking the PostgreSQL server to finalize the backup.
Backup size: 38.8 MiB. Actual disk size: 38.8 MiB (-0.00% deduplication ratio).
Backup end at LSN: 0/12000138 (00000001000000000000012, 00000138)
Backup completed (start time: 2025-04-13 11:32:10.136973, time elapsed: 5 seconds)
Processing xlog segments from file archiving for pg
        000000010000000000000011
        000000010000000000000012
        000000010000000000000012.00000060.backup

🔁 Automatiser les sauvegardes incrémentales avec Barman

Une fois Barman et PostgreSQL correctement configurés, il est essentiel d’automatiser les sauvegardes pour garantir la protection continue de vos données. Heureusement, Barman s’intègre facilement avec les outils classiques de planification de tâches, comme cron.

🕒 Planifier les sauvegardes avec `cron`

Pour déclencher automatiquement une sauvegarde, il suffit d’ajouter une tâche cron sur le serveur Barman. Par exemple, pour lancer une sauvegarde complète tous les jours à 2h du matin :

Se connecter en tant que barman :

sudo -u barman crontab -e

Ajouter la tâche cron dans cette crontab :

0 2 * * * barman backup pg

💡 Pensez à tester votre commande manuellement avant de l’automatiser, pour vérifier que tout fonctionne comme prévu.

📉 Astuces pour optimiser l’espace disque

Voici quelques conseils pour conserver vos sauvegardes tout en maîtrisant l’utilisation du stockage :

🗃️ Compression des sauvegardes : Barman propose la compression automatique des fichiers; possible avec compression = gzip utilisée plus haut dans nos configurations:
🧹 Suppression automatique des anciennes sauvegardes : utilisez la politique de rétention pour ne conserver que les sauvegardes nécessaires; possible avec retention_policy = RECOVERY WINDOW OF 7 DAYS aussi utilisé dans notre fichier pg.conf .

🔍 Surveillance et gestion des sauvegardes avec Barman

Une fois les sauvegardes en place, il est crucial de les surveiller et de gérer leur cycle de vie pour garantir leur efficacité. Barman fournit plusieurs outils pour cela, directement utilisables en ligne de commande.

✅ Vérifier l’état des sauvegardes

Barman dispose de plusieurs commandes utiles pour suivre l'état de vos sauvegardes et de vos serveurs.

🔧 Lister les sauvegardes disponibles

$ barman list-backup pg
pg 20250415T201754 - Tue Apr 15 20:17:58 2025 - Size: 54.9 MiB - WAL Size: 16.0 MiB
pg 20250415T201516 - Tue Apr 15 20:15:19 2025 - Size: 54.9 MiB - WAL Size: 48.0 MiB
pg 20250413T113210 - Sun Apr 13 11:32:14 2025 - Size: 54.8 MiB - WAL Size: 32.0 MiB

Cette commande affiche entre autre :

l’ID de chaque sauvegarde,
la date
le point de récupération possible (PITR)

📊 Vérifier l’état général du serveur

$ barman check nom_du_serveur

Cette commande fait un diagnostic complet de la configuration : connexions SSH, configuration PostgreSQL, accès aux répertoires de sauvegarde, etc.

Obtenir des détails sur une sauvegarde spécifique

barman show-backup nom_du_serveur ID_sauvegarde

Utile pour voir entre autre:

les chemins utilisés,
la taille de la sauvegarde,
les fichiers WAL associés,
les options activées.

🧯 Et en cas de problème ?

En cas d’échec de sauvegarde :

Lance barman check pour diagnostiquer.
Consulte les logs postgres et barman dans respectivement /var/log/postgresql et /var/log/barman/.

🏁 Conclusion : Garder le contrôle sur vos sauvegardes PostgreSQL

Dans cette seconde partie, nous avons plongé dans les aspects techniques essentiels pour éléborer une stratégie de sauvegarde incrémentale fiable avec Barman. De la configuration fine de PostgreSQL, à la mise en place des connexions sécurisées en passant par l’automatisation via cron et la surveillance proactive, chaque étape renforce la robustesse et la résilience de votre base de données.

Grâce à Barman, vous disposez d’un outil puissant, souple et open source, capable de répondre aux besoins des environnements de production les plus exigeants. Mais la maîtrise des sauvegardes ne s’arrête pas là.

Dans la prochaine partie, nous verrons comment restaurer efficacement une base de données PostgreSQL, notamment via le Point In Time Recovery (PITR), ainsi que des cas pratiques pour tester vos sauvegardes.

👉 Restez connectés pour aller jusqu’au bout de votre stratégie de sauvegarde PostgreSQL !

Configurer des sauvegardes incrémentales avec PostgreSql - Introduction-Partie 1

ZINSOU Trinité — Mon, 02 Jun 2025 23:46:35 +0000

🧭 Introduction

PostgreSQL est un système de gestion de bases de données robuste, fiable, et très utilisé dans le monde du développement. Il respecte les standards SQL, il est open source, et surtout, il garde précieusement nos données.

Mais même le meilleur outil ne peut rien contre une mauvaise manip, un bug, ou un crash serveur. C’est là qu’intervient notre meilleure alliée : la sauvegarde.

Dans ce guide, on va découvrir comment configurer des sauvegardes incrémentales sur PostgreSQL.

L’objectif ? Que tu sois développeur, administrateur, étudiant ou simplement curieux, tu pourras mettre en place un système de sauvegarde automatique, efficace et rassurant.

On va :

comprendre ce qu’est une sauvegarde (et une sauvegarde incrémentale 🧠),
découvrir les outils disponibles dans PostgreSQL 🔧,
configurer étape par étape notre système de sauvegarde incrémentale 🛠️,
automatiser le tout avec des scripts et cron ⏰,
et même tester la restauration (parce qu’une sauvegarde non testée, c’est juste une illusion de sécurité 😉).

Prêt ? Alors on commence par les bases. 👇

🧠 Rappel : qu’est-ce qu’une sauvegarde (et une sauvegarde incrémentale) ?

Avant de plonger dans la configuration, prenons une minute pour poser les bases, parce qu’une bonne compréhension, c’est déjà la moitié du boulot.

🔐 Une sauvegarde, c’est quoi ?

C’est tout simplement une copie de données (fichiers, bases, configurations, etc.) qu’on garde à part, dans un coin sûr, pour pouvoir les récupérer en cas de pépin : erreur humaine, panne, piratage, ou juste un “Oups, j’ai tout supprimé”.

🧱 Les 3 grands types de sauvegardes

Il existe plusieurs façons de sauvegarder ses données. Voici les trois principales :

Sauvegarde complète : on copie tous les fichiers à chaque fois. C’est simple, mais ça peut vite devenir lourd en espace disque.
Sauvegarde différentielle : on copie uniquement les fichiers qui ont changé depuis la dernière sauvegarde complète. C’est plus léger, mais au fil du temps, ça peut s’accumuler.
Sauvegarde incrémentale : on copie les fichiers qui ont changé depuis la dernière sauvegarde, quelle qu’elle soit (complète ou incrémentale). C’est la plus optimisée en taille et en temps, mais un peu plus technique à gérer.

📌 Pourquoi les sauvegardes incrémentales sont cool ?

Parce qu’elles permettent de gagner du temps et de l’espace, tout en conservant l’historique des modifications. Et la bonne nouvelle, c’est que PostgreSQL permet ce type de sauvegarde en s’appuyant sur un mécanisme intégré de journalisation anticipée (WAL : Write-Ahead Logging).

👉 C’est justement ce qu’on va exploiter dans ce guide.

🔍 Comment Postgres permet-il les sauvegardes incrémentales ?

Nous allons nous intéresser dans un premier temps aux possibilités de sauvegarde offertes par PostgreSQL, afin de comprendre les différents mécanismes disponibles avant de se plonger dans la configuration des sauvegardes incrémentales.

🧬 Les différents types de sauvegarde avec PostgreSQL

Postgresql offre trois possibilités 👇:

1. Sauvegarde complète

Elle consiste à copier l’intégralité de la base de données à un instant donné. Ce type de sauvegarde est un instantané de la base et permet de restaurer une base de données dans son état précis au moment de la sauvegarde. Cela peut être effectué avec des outils comme pg_basebackup, ou manuellement en copiant les fichiers de données de PostgreSQL.

2. Sauvegarde logique (pg_dump)

Elle utilise l’outil pg_dump, qui exporte les données de la base sous forme de script SQL. Il s’agit d’une forme de sauvegarde complète qui permet de récupérer la base de données sous un format indépendant de PostgreSQL. Cette méthode est souvent utilisée pour migrer des bases de données ou pour effectuer des sauvegardes spécifiques (par exemple, d’une table ou d’un schéma). Toutefois, elle a des limites pour les sauvegardes incrémentales, car elle n’inclut pas directement les journaux de transactions (WAL).

3. Sauvegarde incrémentale (basée sur les WAL)

La sauvegarde incrémentale, comme son nom l’indique, permet de ne sauvegarder que les modifications effectuées après une première sauvegarde complète. Cela repose sur l’archivage des fichiers WAL (Write-Ahead Log) générés par PostgreSQL. Ces fichiers contiennent un enregistrement de toutes les transactions qui ont été appliquées à la base de données. En utilisant les fichiers WAL, il est possible de restaurer la base de données à un moment précis, ce qui permet d’atteindre un objectif RPO (Recovery Point Objective) très bas, souvent à quelques minutes seulement. Il s’agit ici de minimiser la quantité de donnée qu’on est prêt à perdre après un incident.

🧪 Les sauvegardes incrémentales

PostgreSQL offre une fonctionnalité clé qui permet de réaliser des sauvegardes incrémentales : le Write-Ahead Logging (WAL).

Chaque opération d’écriture sur la base de données est journalisée dans des fichiers de log. Ces fichiers enregistrent les modifications de la base de données avant que celles-ci ne soient réellement appliquées, garantissant ainsi l'intégrité des données.

Ce mécanisme, appelé WAL, permet de restaurer l'état de la base de données à un moment précis, une technique connue sous le nom de Point In Time Recovery (PITR). Cela signifie qu'après une première sauvegarde complète, vous pouvez restaurer une base de données à n'importe quel instant en récupérant les fichiers WAL générés depuis cette sauvegarde.

C'est exactement ce que nous allons exploiter dans notre configuration avec Barman.

⚙️ Principe de fonctionnement du WAL

Lorsque l'archivage des WAL est activé dans PostgreSQL, il génère des fichiers dans un dossier spécifique (/var/lib/postgresql/{version}/main/pg_wal/) à chaque opération d'écriture. Ces fichiers font l’objet d’une rotation dès qu’ils atteignent une taille de 16 Mo par défaut.

Chaque fois qu'un fichier WAL est modifié ou créé, PostgreSQL permet de définir une commande spécifique à exécuter. Cela permet de centrer l'archivage des fichiers WAL et de gérer plus facilement la récupération des données.

Barman va s’appuyer sur ces fichiers WAL pour faciliter la gestion des sauvegardes incrémentales et des restaurations à un moment précis.

🚀C'est quoi Barman ?

🍹Découverte de barman

Barman (Backup and Recovery Manager) est un outil écrit en Python qui facilite la gestion des sauvegardes et restaurations des bases de données PostgreSQL.

Ce gestionnaire de sauvegardes est spécialement conçu pour PostgreSQL et simplifie :

La planification et l’automatisation des sauvegardes.
La gestion des sauvegardes complètes et incrémentales.
La récupération Point-in-Time Recovery (PITR) en utilisant les fichiers WAL.

Il est particulièrement pratique pour gérer plusieurs serveurs PostgreSQL en centralisant les opérations de sauvegarde et de restauration en un seul endroit.

Ce sera l'outil que nous allons configurer et utiliser dans cet article.

🤔 Barman vs pg_dump

Avant d’aller plus loin, faisons une petite comparaison entre Barman et les outils classiques de sauvegarde PostgreSQL : pg_dump/pg_basebackup.

pg_dump / pg_basebackup : Ces outils permettent des sauvegardes complètes, où vous pouvez exporter l'état d'une base de données (sous forme de script SQL par exemple, avec des options pour une table, un schéma, ou toute la base). Cependant, pg_dump/pg_basebackup ne conviennent pas pour des restaurations rapides en cas de sinistre, car vous devez toujours restaurer à partir de l’heure précise de la sauvegarde.

Essayons nous à une petite expérience de pensée; vous faites régulièrement vos sauvegardes avec pg_dump par exemple à 3 heures du matin et vous avez un crash/incident à 18 heures. Vu que pg_dump récupère l'état de votre système à une heure bien précise (ici 3h), et qu’un incident survient à 18h, vous perdrez toutes les données ajoutées depuis la dernière sauvegarde. On parle bien de 15h de données, dans tous les scénarios, cette perte est inacceptable pour de nombreuses entreprises.
Barman : Contrairement à pg_dump, Barman opère au niveau physique de la base de données. Cela signifie qu'il prend des copies complètes et incrémentales de vos données, permettant de récupérer tout ce qui a changé depuis la dernière sauvegarde, sans risquer une perte importante de données. Ce système est particulièrement adapté pour des objectifs RPO (Recovery Point Objective) bas, réduisant ainsi la perte de données à quelques minutes seulement.

Bien sûr, cela nécessite un peu plus d’espace disque pour stocker les sauvegardes, mais le compromis en termes de sécurité et de récupération est largement justifié.

📦 Installation de barman

Avant de pouvoir utiliser Barman pour la gestion des sauvegardes incrémentales, il est nécessaire de s'assurer que les composants Postgresql sont bien installés. Pour les utilisateurs d’Ubuntu ce tutoriel est excellent pour l’installation de PostgreSQL. Pour ceux avec CentOs/RHEL vous pouvez suivre celui-ci.

Une fois PostgreSQL installé et pret à l’utilisation, nous reviendrons sur les configuration plus avancées nécessaire à notre sauvegarde. A présent passons maintenant à l’installation de Barman

a. Sur Ubuntu/Debian

Sur les distributions basées sur Debian comme Ubuntu, vous pouvez installer Barman directement depuis les dépôts officiels.

Installation depuis les depôts :

$ sudo apt update
$ sudo apt install barman

Vérifier l'installation :

Une fois l'installation terminée, vérifiez que Barman est bien installé en exécutant la commande suivante :
```
$ barman --version
```

b. Sur CentOS/RHEL

Sur CentOS ou RHEL, vous devez d’abord ajouter le dépôt officiel de Barman avant de l’installer.

Ajouter le dépôt officiel Barman :

$ sudo yum install -y https://dl.enterprisedb.com/barman/barman-2.16.0-1.rhel7.x86_64.rpm

Mettre à jour les paquets système et installer barman:
```
$ sudo yum update
$ sudo yum install barman
```
Vérifier l'installation :
```
$ barman --version
```

🧾 Conclusion

Dans cet article, nous avons exploré les concepts fondamentaux nécessaires à la mise en place de sauvegardes incrémentales sur PostgreSQL, en mettant l'accent sur le rôle essentiel des journaux de transactions (WAL) et le mécanisme de PITR. Nous avons également vu comment Barman, l'outil de gestion de sauvegarde et de restauration, s'intègre parfaitement dans ce processus.

L’objectif était de fournir une compréhension claire de ce qu'implique une sauvegarde incrémentale avec PostgreSQL avant de plonger dans la configuration technique elle-même. Ces bases vous permettent d’avoir une vue d’ensemble sur les enjeux et les outils à utiliser pour une gestion efficace des sauvegardes.

Dans la partie 2, nous entrerons dans le vif du sujet avec la configuration complète de Barman : : de l’installation à l’activation des sauvegardes incrémentales. Nous aborderons également les bonnes pratiques pour garantir la continuité et la fiabilité de vos sauvegardes.

Rendez-vous dans le prochain article pour découvrir comment configurer et automatiser vos sauvegardes de manière optimale.

DEV Community: ZINSOU Trinité

Maîtriser la gestion des branches avec Git

🚀 Introduction

🌱 Qu’est-ce qu’une branche Git ?

Pourquoi utiliser des branches ?

🪵 Les 6 principaux types de branches

🏷️ Nommer ses branches Git

🛠️ Les stratégies majeures

1. Feature Branching

2. Git Flow

3. GitHub Flow

4. GitLab Flow

5. Release Branching

6. Trunk-Based Development

🧭 Choisir la bonne stratégie de branches Git

🏁 Conclusion

Mastering Git Branching Strategies: Finding the Right Fit for Your Team

🚀 Introduction

🌱 What is a Git Branch, Anyway?

🏷️ Naming git branches

🛠️ The Big 6 Strategies

1. Feature Branching

2. Git Flow

3. GitHub Flow

4. GitLab Flow

5.Realease branching

6. Trunk-Based Development

🧭 Choosing the Right Git Branching Strategy

🏁 Conclusion

Getting Started with Vagrant

🧠 Introduction

🪄 What is Vagrant?

🔍 Why is it useful?

🛠️ How does it work?

🎓 Getting Started with Vagrant

🚀 Installing Vagrant

🛠️ Using Vagrant

Main Steps

🚀 Provisioning Vagrant VMs

1. Shell Provisioner

2. File Provisioner

3. Ansible Provisioner

🧪 Practical: Building the PostgreSQL + Barman Lab

scripts/setup_postgres.sh

scripts/setup_barman.sh

🧩 Conclusion

A la découverte de vagrant

🧠 Introduction

🪄 Vagrant, c’est quoi ce truc ?

🔍 Pourquoi c’est pratique ?

🛠️ Comment ça fonctionne ?

🎓 Premiers pas avec vagrant

🚀 Installation de Vagrant

🛠️ Manipulation de Vagrant

Étapes principales

🚀 Provisionner les VM vagrant

🧪 Phase pratique : mise en place du lab PostgreSQL + Barman

🧩 Conclusion

Setting up incremental backups with PostgreSql - Recovery - Part 3

🧭 Introduction

🕰️ What is PITR (Point-In-Time Recovery)?

🎯 RPO and RTO: The Two Pillars of a Solid Backup/Restore Strategy

📌 Recovery Point Objective (RPO)

⏱ Recovery Time Objective (RTO)

⚖️ Finding the Right Balance Between Ideal and Reality

💡 RPO and RTO with PostgreSQL and Barman

🧰 Prerequisites for PITR Restoration

🔄 Data Recovery with Barman (Practical Example)

🏁 Conclusion

Setting up incremental backups with PostgreSql - Implementation - Part 2

🧭 Introduction

🤔 Which Backup Strategy Should You Choose with Barman?

🔑 SSH Configuration Between Barman and PostgreSQL

🔧 PostgreSQL Configuration for Incremental Backups (via rsync)

🗂️ Enable WAL Archiving in postgresql.conf

🔐 Allow Barman Connections in pg_hba.conf

🛠️ Barman Configuration for Incremental Backups

📁 Set Up the Backup Directory

🧾 barman.conf Configuration

⚙️ Optional Advanced Settings

`scripts/setup_postgres.sh`

`scripts/setup_barman.sh`

🗂️ Enable WAL Archiving in `postgresql.conf`

🔐 Allow Barman Connections in `pg_hba.conf`

🧾 `barman.conf` Configuration

🔐 Store Passwords in `.pgpass`

🤔 Barman vs `pg_dump`

🤔 Quelle stratégie de sauvegarde choisir avec Barman ?

🗂️ Activer l’archivage WAL dans `postgresql.conf`

🧾 Fichier de configuration `barman.conf`

🕒 Planifier les sauvegardes avec `cron`