4.4Sauvegarder et restaurer les volumes
L'essentiel en 30 secondes
- Dump logique + snapshot volume, complémentaires : le dump (export portable) avant migration, le snapshot (archive brute de tout l'état) avant changement — en pratique : dump régulier + snapshot avant chaque opération.
- On sauvegarde sans arrêter : un conteneur jetable monte le volume en lecture seule et écrit l'archive hors du volume — la production continue pendant la sauvegarde.
- Réflexe d'Idir : une sauvegarde non testée n'existe pas — on restaure sur un volume neuf, on démarre une base dessus, on vérifie les données.
Mini-cas filé — Idir prouve que la sauvegarde marche avant la mise à jour
Idir, devops junior à Alger, doit mettre à jour la base de production : avant de toucher à quoi que ce soit, il dumpe la base vers un dossier daté et snapshotte le volume via un conteneur jetable en lecture seule, sans arrêter la production. Puis il restaure sur un volume de test, démarre une base dessus et vérifie les tables. Quatrième jalon du fil rouge : les données sont sauvegardées ET restaurables, preuve à l'appui.
Suite des cas 4.1-4.3 — Idir protège maintenant les données des services exposés.
1. Deux écoles : dump ou snapshot
Le dump logique (export via exec) donne un fichier portable, idéal avant migration. Le snapshot du volume (conteneur utilitaire qui archive le volume) capture tout l'état. En pratique : dump régulier + snapshot avant changement — comme Idir avant sa mise à jour.
Les deux se complètent : le dump se relit et migre facilement, le snapshot restaure tout à l'identique. Un seul des deux, c'est une demi-sauvegarde.
2. Sauvegarder sans arrêter
On ne stoppe pas la base : on lance un conteneur jetable qui monte le même volume en lecture et écrit l'archive hors du volume (dossier local ou stockage distant). La production continue pendant la sauvegarde — Idir n'interrompt aucun service.
Automatiser et dater : sauvegarde planifiée, archives datées, durée de conservation définie (quotidiens + hebdos). Archiver dans le volume lui-même, c'est perdre la sauvegarde avec lui.
3. Une sauvegarde non testée n'existe pas
Rituel : restaurer sur un volume neuf, démarrer une base dessus, vérifier les données. Sans ce test, vous découvrirez le jour J que l'archive est vide ou illisible. Et on ne restaure jamais « pour voir » sur le volume de production.
Tester, c'est prouver : archive rejouée, tables vérifiées, puis suppression du volume de test. La sauvegarde d'Idir n'est validée qu'après ce rituel.
🔎 Exemple concret — 🔎 Exemple concret — Backup Postgres sans arrêt
Le rituel d'Idir : dump + snapshot, restauration sur volume neuf.
docker compose exec bdd pg_dump -U app appdb > backups/appdb-$(date +%F).sql
# snapshot du volume :
docker run --rm -v projet_pgdata:/data:ro -v ./backups:/backup ubuntu:24.04 tar czf /backup/pgdata-$(date +%F).tgz -C /data .
# restauration test :
docker volume create pgdata_test
docker run --rm -v pgdata_test:/data -v ./backups:/backup ubuntu:24.04 tar xzf /backup/pgdata-2026-09-22.tgz -C /dataLecture : dump SQL + snapshot volume, restauration sur volume neuf.
Leçon : on ne restaure jamais « pour voir » sur le volume de production.
Vocabulaire de la section
- Dump
- Export LOGIQUE portable (fichier rejouable) de la base, idéal avant migration.
Exemple simple : Idir exporte sa base vers un fichier daté avant la mise à jour.
Ce que ce n'est pas : une archive brute du disque.
Réflexe : avant migration : penser dump portable.
- Snapshot
- Archive BRUTE de tout l'état du volume, qui restaure à l'identique.
Exemple simple : Idir archive tout le volume avant le changement risqué.
Ce que ce n'est pas : un export partiel qu'on relit à la main.
Réflexe : avant changement : snapshotter tout l'état.
- Montage ro
- Volume monté en LECTURE SEULE pour la sauvegarde : on lit sans risquer d'écrire.
Exemple simple : Le conteneur jetable d'Idir lit le volume sans pouvoir le modifier.
Ce que ce n'est pas : un montage inscriptible qui expose le volume.
Réflexe : sauvegarder : toujours monter en lecture seule.
- Restauration test
- Rejeu de l'archive sur un VOLUME NEUF + vérification des données : la seule preuve.
Exemple simple : Idir démarre une base de test et vérifie les tables avant de valider.
Ce que ce n'est pas : une archive jamais rejouée.
Réflexe : sauvegarde terminée : restaurer et vérifier avant de se croire protégé.
En pratique — En pratique — Votre première sauvegarde testée
- Dumpez votre base vers ./backups avec la date.
- Snapshotez le volume via un conteneur --rm en lecture seule.
- Restaurez sur pgdata_test et démarrez une base test.
- Vérifiez les tables, puis supprimez le volume test.
Script prêt à dire — annoncer la sauvegarde avant la mise à jour (30 s)
« C'est Idir : avant la mise à jour, j'ai dumpé la base et snapshotté le volume sans arrêter la production, et j'ai rejoué l'archive sur un volume de test avec les tables vérifiées. Si la mise à jour échoue, on restaure en quelques minutes. »
À dire avant toute opération risquée : montrez la vérification sur le volume de test.
Modèle copier-coller — dump + snapshot + restauration test
docker compose exec bdd pg_dump -U app appdb > backups/appdb-$(date +%F).sql
docker run --rm -v projet_pgdata:/data:ro -v ./backups:/backup ubuntu:24.04 tar czf /backup/pgdata-$(date +%F).tgz -C /data .
docker volume create pgdata_test
docker run --rm -v pgdata_test:/data -v ./backups:/backup ubuntu:24.04 tar xzf /backup/pgdata-2026-09-22.tgz -C /dataAvant chaque mise à jour
Comme Idir : dump + snapshot juste avant, restauration testée — le filet de sécurité de l'opération.
Routine quotidienne
Dump planifié daté chaque jour, hebdos conservés : la fréquence suit le coût d'une perte.
Archives hors machine
Copie sur disque externe ou stockage distant chiffré : une sauvegarde sur le même disque n'en est pas une.
Restauration qui échoue en test
Bonne nouvelle découverte tôt : corriger la procédure maintenant plutôt que le jour du sinistre.
✓ Bonnes pratiques
- Automatiser et dater les archives.
- Archiver hors du volume, sur un autre support.
- Tester chaque restauration sur volume neuf.
✗ Pièges fréquents
- Sauvegarder dans le volume (perdu avec lui).
- Stopper la production pour dumper (inutile).
- Ne jamais restaurer pour tester.
Points clés à retenir
- Dump SQL + snapshot volume : complémentaires.
- Jetable --rm en lecture seule, prod non stoppée.
- Restauration test sur volume neuf.
- Rétention + automatisation = routine.
Défi 48h — appliquez demain
Sur votre vraie base : dumpez + snapshottez sans arrêter, restaurez sur un volume neuf et vérifiez les données.
- Je sais dumper et snapshotter sans arrêter la production.
- Je sais archiver hors du volume avec rétention.
- Je sais restaurer sur volume neuf et vérifier.
Questions fréquentes
Quelle fréquence ?
Au minimum quotidienne pour une base vivante, avant chaque migration ou mise à jour, avec rétention (quotidiens + hebdos). Ajustez au coût d'une perte de données.
Où stocker les archives ?
Ailleurs que sur la machine : disque externe, stockage distant chiffré. Une sauvegarde sur le même disque n'en est pas une.
Quelle sauvegarde est valable ?