Une sauvegarde que vous n’avez jamais restaurée n’est pas une sauvegarde

Le pire moment pour découvrir qu’une sauvegarde ne fonctionne pas, c’est au moment où vous en avez besoin. Et pourtant, le scénario le plus courant est exactement celui-là : des sauvegardes configurées une fois, une coche verte dans un dashboard pendant dix-huit mois, puis une restauration qui produit une base de données vide.

Tester la restauration d’une sauvegarde de base de données n’est pas une bonne pratique facultative comme tant d’autres. Une sauvegarde est une affirmation et, tant que vous n’en avez pas restauré une, cette affirmation n’est pas vérifiée.

Voici comment elles échouent et ce qu’une véritable vérification doit contrôler.

Les quatre façons dont une sauvegarde devient inutile sans que personne ne s’en aperçoive

1. Elle est vide et personne ne l’a vérifiée

Un pg_dump qui échoue en cours d’exécution peut tout de même produire un fichier. Un dump exécuté sur le mauvais nom de base de données produit un fichier valide, correct et vide. Pour tout système qui vérifie uniquement un code de sortie différent de zéro ou l’existence d’un fichier, ces deux cas ressemblent à une réussite.

La vérification la moins chère au monde : regardez la taille et comparez-la à celle d’hier. Une sauvegarde de 400 octets alors que celle d’hier faisait 40 Mo vous a déjà tout dit. Une sauvegarde de 400 octets depuis six mois vous le dit depuis le début.

2. Elle contient les données, mais pas tout ce qui les entoure

Un pg_dump d’une seule base de données n’inclut pas les rôles ni les autres bases de données. Restaurez-le sur un serveur vierge : les tables sont bien présentes, mais chaque GRANT fait référence à un rôle inexistant. Votre application se connecte et reçoit une erreur de permission sur tout.

C’est la même histoire avec les extensions. Si votre schéma dépend de pgcrypto ou de uuid-ossp et que la cible ne les possède pas, la restauration échoue en cours de route, vous laissant avec quelques tables seulement.

3. Les flags ne correspondent pas au type de restauration nécessaire

pg_dump produit des résultats différents selon le format, et l’erreur est généralement découverte dans l’urgence :

• SQL brut se restaure avec psql et est lisible par un humain. Il ne peut pas être restauré de manière sélective et il est lent pour les grandes bases de données.
• Format custom (-Fc) se restaure avec pg_restore, prend en charge le parallélisme et la restauration sélective, et c’est celui qu’il vous faut pour toute base de taille importante.

Faire une sauvegarde au format brut parce que le tutoriel l’indiquait, puis découvrir pendant un incident qu’il est impossible de restaurer une seule table, c’est une forme précise et évitable de mauvaise journée.

4. Vous ne pouvez pas la déchiffrer

Si les sauvegardes sont chiffrées — et elles devraient l’être — la clé fait partie de la sauvegarde. Une clé qui n’existe que sur la machine perdue ou uniquement dans une variable d’environnement du service hors service est une clé que vous n’avez plus au moment où elle devient indispensable.

À quoi ressemble une véritable vérification

Le test ne consiste pas à vérifier que « le fichier existe ». Il faut le restaurer ailleurs et lui poser une question.

# 1. Restore into a scratch database, not the live one
createdb verify_$(date +%Y%m%d)
pg_restore -d verify_$(date +%Y%m%d) --no-owner --no-privileges latest.dump

# 2. Ask it something only real data can answer
psql -d verify_$(date +%Y%m%d) -c "
  select
    (select count(*) from users)            as users,
    (select count(*) from orders)           as orders,
    (select max(created_at) from orders)    as newest_order;
"

# 3. Drop it
dropdb verify_$(date +%Y%m%d)

L’étape 2 est l’objectif même du test. Une restauration qui se termine sans erreur ne vous apprend toujours rien sur la présence effective des données. Les nombres de lignes et une vérification de la récence, si.

Trois points méritent d’être vérifiés :

• Les nombres de lignes sont du bon ordre de grandeur. Ils ne seront pas exacts — les données changent — mais une table qui comptait 200 000 lignes et n’en contient plus que 12 signale un échec.
• L’enregistrement le plus récent est récent. Si la commande la plus récente de votre sauvegarde « quotidienne » date de mars, votre job de sauvegarde s’est arrêté en mars.
• L’application peut réellement se connecter. Configurez une instance de staging pour utiliser la base restaurée et chargez une page.

Faites-le selon un calendrier, pas quand vous y pensez

La fréquence réaliste est mensuelle, automatisée, avec un résultat à un endroit où vous le remarquerez. Un rappel dans votre agenda pour « tester les sauvegardes » est un rappel que vous mettrez en sommeil.

Pour que cela fonctionne durablement, il faut rendre l’échec bruyant : si la requête de vérification renvoie moins de lignes qu’un seuil donné, quelqu’un doit recevoir une alerte, comme ce serait le cas pour une erreur de production. Un système de sauvegarde qui échoue silencieusement est impossible à distinguer d’une absence de système de sauvegarde, jusqu’au jour où cela devient important.

Comment Dockup gère ce problème

Trois décisions, chacune ciblant un échec précis décrit plus haut.

Les sauvegardes sont stockées ailleurs. Une sauvegarde sur le même disque que la base de données n’est pas une sauvegarde — c’est une copie qui disparaît avec le disque. Dockup envoie directement les sauvegardes de bases de données vers un stockage objet au fur et à mesure de leur création : le fichier ne dépend donc jamais de l’hôte qui l’a produit.

Elles sont chiffrées et la clé n’est pas présente sur la machine. Les sauvegardes sont chiffrées avec AES-256-GCM pendant leur envoi. Pour la récupération, l’essentiel est que la clé soit conservée par la plateforme plutôt que dans l’environnement du service sauvegardé.

Une sauvegarde qui n’a rien produit n’est pas enregistrée comme une sauvegarde. C’est ce qui traite directement le problème des fichiers vides : si le dump renvoie un code différent de zéro ou produit zéro octet, l’upload est supprimé et la sauvegarde est marquée comme ayant échoué. Vous ne vous retrouvez pas avec une liste d’entrées vertes dont l’une est un fichier de 400 octets.

dockup db backup my-project/main-db --json     # take one now
dockup db backups my-project/main-db --json    # list them with sizes

Les tailles affichées dans cette liste sont le contrôle de santé le plus simple dont vous disposez. Surveillez leur évolution.

La question inconfortable

Si votre base de données de production était détruite dans les dix prochaines minutes, combien de temps vous faudrait-il pour la remettre en service et quelle quantité de données auriez-vous perdue ?

Si vous ne pouvez pas répondre à ces deux questions, vous n’avez pas de stratégie de sauvegarde — vous avez des fichiers de sauvegarde. La différence tient entièrement au fait que quelqu’un ait déjà effectué la restauration ou non.

Foire aux questions

À quelle fréquence dois-je tester une restauration ? Une fois par mois est un bon défaut, de manière automatisée plutôt que manuelle. L’important est qu’un échec soit signalé clairement, pas que la fréquence soit particulièrement élevée.

Pourquoi ma restauration s’est-elle terminée sans erreur, mais sans produire de données ? Le plus souvent, le dump a été créé à partir de la mauvaise base de données ou a échoué en cours d’écriture tout en continuant à produire un fichier. Comparez les tailles des sauvegardes au fil du temps : un dump vide est évident dans l’évolution de la taille et invisible dans une colonne de statut.

Les sauvegardes doivent-elles être chiffrées ? Oui, et la clé doit être conservée dans un endroit qui survivra à la perte de la machine. Une sauvegarde chiffrée dont la clé se trouvait sur le serveur perdu ne peut pas être récupérée.

Un snapshot est-il la même chose qu’une sauvegarde ? Non. Un snapshot de volume capture le disque, y compris l’état dans lequel se trouvait la base de données à cet instant. Un dump logique est cohérent par construction. La plupart des équipes veulent les deux, pour faire face à des types d’incidents différents.