Sauvegarde de base de données : RPO, RTO et test de restauration

Une sauvegarde réussie n'est pas un fichier présent dans un bucket. C'est une base restaurée dans un environnement propre, ouverte par l'application et revenue dans le délai promis. Tant que ce scénario n'a pas été exécuté, l'équipe connaît la date et la taille d'une copie, pas sa capacité de reprise.

Cette nuance devient critique avec une base de données. Les fichiers évoluent pendant la copie, les journaux doivent rester continus, les rôles et extensions comptent autant que les tables, et une réplication fidèle peut propager instantanément une suppression. Une stratégie crédible relie donc le risque métier, la méthode de sauvegarde et une preuve de restauration.

Choisir la bonne protection en une vue

Ces mécanismes se complètent. Une réplique réduit l'interruption provoquée par une panne matérielle ; elle ne remplace pas une copie historique. Un dump facilite la récupération d'une table ; il ne remplace pas forcément une chaîne PITR sur une base volumineuse.

Commencer par le RPO et le RTO

Le RPO, ou objectif de point de reprise, exprime la quantité maximale de données que l'entreprise accepte de perdre. Un RPO de quinze minutes impose de capturer les transactions au moins à cette fréquence, souvent par archivage des journaux plutôt que par un dump complet toutes les quinze minutes.

Le RTO, ou objectif de délai de reprise, indique le temps maximal pour rendre le service utilisable. Il comprend le téléchargement, le déchiffrement, la restauration, les contrôles, le redémarrage de l'application et la décision de rouvrir. Mesurer uniquement la durée de pg_restore ou de mysql sous-estime le délai réel.

Une cible identique pour toutes les bases gaspille de l'argent ou protège mal les données importantes. Le métier doit valider la perte et l'interruption tolérables ; l'équipe technique choisit ensuite l'architecture capable de les respecter.

Sauvegarder tout ce qui rend la donnée exploitable

Une base ne se limite pas aux lignes métier. L'inventaire de reprise doit couvrir :

• schémas, contraintes, index, séquences et vues ;
• rôles, droits, propriétaires et politiques de sécurité ;
• extensions et leur version ;
• fonctions, procédures, événements et déclencheurs ;
• paramètres indispensables au moteur ;
• secrets de déchiffrement, stockés séparément des sauvegardes ;
• fichiers externes référencés par la base ;
• version de l'image du moteur et migrations de l'application.

PostgreSQL distingue par exemple les bases de données des objets globaux du cluster, tels que certains rôles et tablespaces. MySQL demande des options explicites pour inclure routines et événements dans mysqldump. Un test qui ne vérifie que le nombre de tables peut donc réussir alors que l'application reste inutilisable.

Dump logique ou sauvegarde physique

Le dump logique reconstruit la base par des instructions et des données interprétées par le moteur. Il convient bien aux volumes raisonnables, aux restaurations sélectives et aux migrations compatibles. Son coût apparaît à la reprise : recréer les index, contraintes et gros volumes peut prendre beaucoup plus de temps que produire le fichier.

La sauvegarde physique copie la représentation interne complète. Elle devient intéressante quand le volume ou le RTO rend le dump trop lent. En contrepartie, elle impose de documenter les versions compatibles, les tablespaces, le stockage et la procédure exacte du moteur.

Ne tranchez pas sur une intuition. Chronométrez une restauration des deux méthodes avec un volume proche de la production et le débit réseau réel. Une sauvegarde très rapide mais impossible à rapatrier dans le RTO n'atteint pas son objectif.

Pourquoi copier un volume Docker actif est dangereux

La documentation Docker montre comment archiver et restaurer le contenu d'un volume. Cette recette est adaptée à des fichiers ordinaires, mais elle ne crée pas à elle seule une sauvegarde cohérente d'une base en écriture.

PostgreSQL précise qu'une simple copie de son répertoire de données nécessite l'arrêt du serveur, sauf snapshot cohérent ou protocole de sauvegarde physique prévu à cet effet. Un tar, un docker cp ou la copie du dossier monté peut lire des fichiers à des instants différents et oublier les journaux nécessaires.

Pour une base conteneurisée, utilisez donc d'abord l'outil du moteur. Si la stratégie repose sur un snapshot, coordonnez-le avec la base et tous les volumes concernés. Documentez aussi la façon de restaurer le volume, l'image exacte du moteur et les permissions de fichiers.

Exemple PostgreSQL avec Docker Compose

Pour une petite ou moyenne base, un dump au format personnalisé facilite les contrôles et la restauration sélective :

mkdir -p backups
docker compose exec -T postgres \
  pg_dump -U app --format=custom --no-owner --file=- app \
  > "backups/app-$(date +%F-%H%M).dump"

Adaptez postgres, app et l'authentification à votre Compose. Protégez le fichier dès sa création et vérifiez que la redirection locale dispose de suffisamment d'espace. Restaurez toujours le test dans une base distincte :

docker compose exec -T postgres createdb -U app -T template0 app_restore
docker compose exec -T postgres \
  pg_restore -U app --dbname=app_restore --no-owner --exit-on-error \
  < backups/app-2026-08-01-1435.dump

--exit-on-error évite de déclarer le test réussi après des erreurs ignorées. Pour les rôles et autres objets globaux, prévoyez une sauvegarde complémentaire avec pg_dumpall --globals-only, puis testez son application avec les privilèges adéquats.

Sur une base importante ou avec un RPO court, utilisez une base backup supportée, par exemple via pg_basebackup, et archivez les WAL en continu. PostgreSQL peut alors rejouer les changements et s'arrêter juste avant une suppression accidentelle. Cette chaîne exige tous les segments depuis la base backup : une seule lacune peut supprimer le point de reprise attendu.

Exemple MySQL avec Docker Compose

Pour des tables transactionnelles, --single-transaction permet généralement un dump cohérent sans verrouillage global prolongé :

mkdir -p backups
docker compose exec -T mysql \
  mysqldump -u app --single-transaction \
  --routines --triggers --events app \
  > "backups/app-$(date +%F-%H%M).sql"

Ne placez pas le mot de passe directement dans l'historique du shell. Utilisez le secret ou le mécanisme d'authentification déjà injecté dans le conteneur. Évitez aussi les changements de schéma pendant le dump : la cohérence transactionnelle ne rend pas les opérations DDL sans conséquence.

docker compose exec -T mysql mysql -u app -e 'CREATE DATABASE app_restore'
docker compose exec -T mysql mysql -u app app_restore \
  < backups/app-2026-08-01-1435.sql

Pour le PITR, conservez une sauvegarde complète cohérente et les binary logs produits ensuite. La restauration recharge la base, puis rejoue les événements jusqu'à une position ou un instant choisi. Vérifiez la continuité, la rétention et l'horodatage des journaux avant d'en dépendre en incident.

Rendre les copies résistantes à une compromission

Une sauvegarde accessible avec le même compte administrateur que la production peut disparaître pendant la même attaque. La CISA recommande des copies hors ligne, chiffrées, régulièrement testées et, lorsque cela convient, immuables.

1. Séparez les identités de production et de sauvegarde.
2. Donnez au processus d'écriture le minimum de droits, sans suppression des anciennes versions.
3. Conservez plusieurs générations avec une politique de rétention explicite.
4. Répliquez au moins une copie vers un autre périmètre de panne.
5. Chiffrez les données et sauvegardez la clé par un canal distinct.
6. Testez aussi l'accès aux comptes, clés et procédures d'urgence.

L'immutabilité protège contre la suppression, mais elle ne détecte ni un dump vide ni une donnée déjà corrompue. Elle complète les contrôles et la restauration ; elle ne les remplace pas.

Organiser un vrai exercice de restauration

Un exercice utile part d'un scénario, pas du dernier fichier disponible. Par exemple : « une migration a supprimé des commandes à 10 h 18 ; revenir au dernier état sain avant cette transaction et rouvrir en moins de 60 minutes ».

1. Démarrez le chronomètre au déclenchement de l'alerte.
2. Choisissez le point de reprise sans modifier la production.
3. Récupérez, contrôlez et déchiffrez la copie.
4. Créez une infrastructure isolée avec une version compatible du moteur.
5. Restaurez les données, objets globaux, extensions et fichiers associés.
6. Démarrez l'application avec les services externes neutralisés.
7. Vérifiez droits, contraintes, volumes, dates et transactions métier.
8. Calculez les RPO et RTO réellement obtenus.
9. Détruisez proprement l'environnement de test après conservation des preuves.

Les contrôles doivent inclure une connexion avec un compte applicatif, quelques requêtes métier, l'écriture puis la lecture d'une donnée de test, les tâches asynchrones et les objets stockés hors base. Comparez aussi des agrégats connus : nombre de commandes par jour, solde total, dernière transaction valide ou nombre de documents.

Surveiller la capacité de reprise, pas seulement le job

Un tableau de bord vert parce qu'un fichier a été envoyé chaque nuit donne une confiance excessive. Suivez au minimum :

• âge de la dernière sauvegarde complète réussie ;
• âge de la dernière restauration validée ;
• durée et taille par rapport à la tendance ;
• continuité et retard des WAL ou binary logs ;
• disponibilité de la copie distante ;
• échec de chiffrement, contrôle d'intégrité ou politique d'immutabilité ;
• RPO et RTO observés au dernier exercice.

Déclenchez une alerte sur les anomalies silencieuses : volume divisé par dix, journal qui n'avance plus, rétention plus courte que prévu ou test reporté. L'observabilité des pipelines data fournit une méthode complémentaire pour définir propriétaires, fraîcheur et alertes exploitables.

Le runbook minimal

Le document de reprise doit rester disponible quand le SI principal ne l'est plus. Il précise le décideur, l'opérateur, les accès d'urgence, l'ordre des systèmes, le point de reprise choisi, les commandes validées et les critères de réouverture.

Ajoutez un retour arrière si la base restaurée échoue aux contrôles. Pour un incident de sécurité, ne reconnectez pas automatiquement l'ancien environnement : restaurer les données et éradiquer la compromission sont deux chantiers liés mais distincts. Notre guide ransomware et sauvegardes couvre cette stratégie générale, et le guide cybersécurité pour PME replace la reprise parmi les autres priorités.

Un plan réaliste sur trente jours

La première restauration échouera peut-être sur une extension absente, un secret oublié ou un téléchargement trop lent. C'est précisément la valeur de l'exercice : découvrir ces dépendances pendant une fenêtre choisie, pas pendant l'incident.

Une sauvegarde devient une capacité de reprise lorsque l'équipe sait quoi restaurer, jusqu'à quel instant, dans quel délai, avec quels accès et selon quels contrôles. Le bon indicateur n'est donc pas « backup terminé », mais « service restauré et preuve validée ».