En bref — une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde : c'est un fichier dont on espère qu'il s'ouvrira le jour où tout aura brûlé. La vraie question n'est pas « est-ce que je sauvegarde ? » mais « quand ai-je restauré pour la dernière fois ? ». Voici comment je traite mes sauvegardes non comme une case à cocher, mais comme un processus qu'on éprouve : hors-site, chiffrées, et surtout testées automatiquement par des restaurations à blanc régulières.

Tout le monde sait qu'il faut faire des sauvegardes. C'est le conseil le plus rabâché de l'informatique, au point qu'on l'applique souvent en pilote automatique : un cron nocturne, un fichier qui atterrit quelque part, et la conscience tranquille. Le problème, c'est que ce sentiment de sécurité est presque entièrement fabriqué. Un pg_dump qui tourne chaque nuit ne prouve rien — ni que le fichier est complet, ni qu'il n'est pas corrompu, ni qu'on saura le remettre en marche sous pression, le jour de l'incident, à 3 h du matin. La sauvegarde n'est pas l'objectif. La restauration l'est.

Sauvegarder, c'est déjà un choix

Avant même de parler de restauration, il faut sauvegarder la bonne chose. Pour une base de données, j'ai une préférence tranchée : le dump logique — un pg_dumpall qui produit du SQL rejouable — plutôt que la copie brute des fichiers de la base. Le dump est portable : il se restaure sur une autre version du moteur, une autre machine, sans se soucier de l'état interne de PostgreSQL. Et il est vérifiable : c'est du SQL qu'on peut relire, recharger, compter. La copie brute d'un répertoire de données, elle, peut sembler intacte tout en étant subtilement incohérente si elle a été prise pendant une écriture.

Le reste suit une règle ancienne et increvable, le 3-2-1 : trois copies des données, sur deux supports différents, dont une hors-site. La copie hors-site est celle qui compte vraiment, parce qu'elle répond à la seule question qui fâche : que se passe-t-il si le serveur lui-même disparaît ?

Hors-site : parce que le serveur peut brûler

Une sauvegarde qui vit sur la même machine que les données qu'elle protège ne protège… de presque rien. Elle vous sauve d'un DROP TABLE malheureux, et c'est déjà ça. Mais un disque qui lâche, un datacenter qui prend feu — ça arrive —, un rançongiciel qui chiffre tout ce qu'il atteint, une commande qui efface le serveur entier : dans tous ces cas, la sauvegarde part avec ce qu'elle devait sauver.

Mes sauvegardes sont donc expédiées chaque nuit hors du serveur, vers un stockage objet distant, et chiffrées au repos. Le principe tient en un enchaînement : produire le dump, le compresser, le pousser vers le stockage distant — le tout en flux, sans jamais écrire de fichier en clair sur le disque.

pg_dumpall | gzip | rclone rcat r2:infra-backups/postgres/dump-$(date +%F).sql.gz

Le stockage distant applique de son côté une politique de rétention — les sauvegardes récentes sont gardées, les anciennes expirent automatiquement — pour ne pas accumuler indéfiniment. Chiffrées, à des kilomètres du serveur : même si la machine d'origine cesse d'exister, les données, elles, survivent ailleurs.

Le cœur du sujet : la restauration à blanc

Et maintenant, le seul test qui compte vraiment. Une sauvegarde n'a de valeur qu'au moment où on la restaure — donc tant qu'on ne l'a jamais fait, cette valeur est inconnue. Pas nulle : inconnue, ce qui est pire, parce qu'on se croit protégé. J'ai donc automatisé exactement ça : une restauration à blanc — un restore drill — qui se joue toute seule, à intervalle régulier.

Le mécanisme est volontairement paranoïaque. Un script récupère la dernière sauvegarde envoyée hors-site, démarre une base de données jetable — dans un conteneur éphémère, en mémoire vive, avec un mot de passe aléatoire, totalement isolée de la production — et y recharge le dump. Puis il vérifie que le chargement a réussi, et compare le nombre de lignes de chaque table à celui de la production. Si une base refuse de se charger, ou si elle a perdu des lignes en route, le test échoue bruyamment et je reçois une alerte.

Deux points sont non négociables dans cette conception. D'abord, la restauration s'exécute sur un environnement jetable et isolé : le drill ne touche jamais, au grand jamais, la production — pas de volume partagé, pas de réseau commun, rien. Un test de sauvegarde qui mettrait en danger la donnée vivante serait une absurdité. Ensuite, il tourne régulièrement et sans intervention — chez moi, chaque semaine. Parce qu'une sauvegarde peut se mettre à échouer silencieusement du jour au lendemain : une migration change un schéma, un volume grossit trop, un identifiant expire. La seule façon de le découvrir avant l'incident, c'est de restaurer en continu — pas une fois par an « pour voir ».

Se méfier du silence

Il y a un piège plus sournois encore que la sauvegarde non testée : la sauvegarde qui échoue sans le dire. Un cron qui plante, un stockage distant plein, un identifiant révoqué — et le job s'arrête, sans bruit. Or l'absence de nouvelle n'est pas une bonne nouvelle : c'est exactement l'état dans lequel on se croit protégé alors qu'on ne l'est plus depuis des semaines.

La parade s'appelle un interrupteur de l'homme mort — un dead man's switch. Le principe est inversé : ce n'est pas l'échec qui déclenche l'alerte, c'est l'absence de succès. À chaque sauvegarde et à chaque restauration réussies, le script envoie un signal de vie à un service externe. Si ce service ne reçoit rien dans la fenêtre attendue — parce que le job n'a même pas démarré —, c'est lui qui m'alerte. On ne surveille plus seulement ce qui casse : on surveille ce qui aurait dû arriver et n'est pas arrivé.

Restaurer les données ne suffit pas à repartir

Dernière leçon, apprise en posant la vraie question : combien de temps me faudrait-il pour tout reconstruire, à partir de zéro, si le serveur disparaissait ce soir ? Restaurer les bases de données, c'est nécessaire, mais ça ne remonte pas un service. Il reste la configuration du serveur, les règles de pare-feu, les clés d'accès, les tâches planifiées, les certificats — tout ce tissu d'état qui ne vit ni dans le code ni dans la base, et qu'un rebuild ne retrouve nulle part.

J'ai fini par sauvegarder cet état-là aussi : la configuration système vitale part hors-site avec les bases. La différence, c'est celle entre « mes données sont sauvées » et « je peux être de nouveau en ligne en trente minutes ». La première est un soulagement ; la seconde est un plan. Un bon dispositif de sauvegarde ne se mesure pas à la quantité de données qu'il protège, mais au temps qu'il vous faut pour vous relever.

Testez vos sauvegardes

Si vous ne deviez retenir qu'une chose : ouvrez un terminal et restaurez votre dernière sauvegarde, maintenant, sur une machine jetable. Pas en production, pas « un jour » — maintenant. Soit elle se recharge proprement, et vous dormirez mieux en connaissance de cause ; soit elle échoue, et vous venez de découvrir aujourd'hui, à froid, ce que vous auriez sinon découvert le pire jour possible.

Une sauvegarde n'est pas un fichier. C'est un processus, qui commence à la capture et ne se termine qu'à la restauration prouvée. Tant que vous n'avez pas rejoué ce dernier maillon, vous n'avez pas une sauvegarde — vous avez un espoir bien organisé. Et l'espoir n'a jamais restauré une base de données.