Des sauvegardes qui se restaurent vraiment

Les modes de défaillance que personne ne teste

Les échecs de sauvegarde sont rarement spectaculaires. La tâche cron s'est exécutée, le fichier est arrivé, le tableau de bord est resté vert — et le dump est silencieusement corrompu, ou les segments WAL et les binlogs nécessaires à la récupération à un instant donné n'ont jamais été expédiés. Rien ne se plaint tant que vous n'essayez pas de le charger.

Les défaillances humaines sont tout aussi courantes : les identifiants du bucket de sauvegarde ont expiré il y a des mois, ou la restauration fonctionne techniquement mais prend une journée entière parce que personne ne l'a jamais mesurée sur un jeu de données de taille production. Chacun de ces cas passe la checklist « avons-nous des sauvegardes ? ». Aucun ne passe une restauration.

Ce que nous sauvegardons, et à quelle fréquence

Chaque base de données managée sur Anested Cloud — PostgreSQL, MongoDB et MySQL — reçoit un instantané quotidien, automatiquement, sans aucune configuration. Les fenêtres de rétention évoluent avec votre offre, pour remonter plus loin dans l'historique à mesure que vos besoins grandissent, et la planification ne dépend jamais de quelqu'un qui se souvient d'une tâche cron.

Tout aussi important : l'endroit où vivent ces sauvegardes. Elles résident dans un domaine de panne séparé de la base elle-même, sur une infrastructure de stockage indépendante. Un incident qui emporte l'hôte de votre base ne peut pas emporter ses sauvegardes en même temps — cette séparation est précisément le but.

La restauration est une fonctionnalité produit, pas un runbook

Dans trop de stacks, « restaurer » signifie une page wiki écrite il y a deux ans, trois sessions ssh et une prière. Nous traitons la restauration comme une fonctionnalité produit de premier ordre : depuis le tableau de bord, choisissez un instantané et restaurez-le vers une nouvelle base en un clic, pendant que l'originale continue de tourner sans être touchée.

Cette conception supprime la partie la plus effrayante d'une mauvaise journée — la peur d'aggraver les choses. Vous inspectez la copie restaurée, vous la vérifiez avec le rapport que nous générons, et vous ne basculez votre chaîne de connexion que lorsque vous êtes satisfait.

• Restaurer vers une instance neuve — ne jamais écraser en place
• Vérifier avec un rapport de checksum et de comptage de lignes
• Conserver l'originale pendant 7 jours

Faites votre part : testez une restauration

Nous nous occupons de la mécanique, mais vous seul savez à quoi ressemble « correct » pour vos données. La meilleure habitude est un exercice de restauration trimestriel : chargez une sauvegarde fraîche dans une base de staging et vérifiez que les chiffres ont du sens. Cela prend environ 10 minutes, et cela transforme vos sauvegardes d'un espoir en une preuve.

Pour une base PostgreSQL, tout l'exercice tient en trois lignes. Mettez-le dans un script, ajoutez un rappel dans votre calendrier et exécutez-le une fois par trimestre :

# restore drill
pg_dump "$PROD_URL" | psql "$STAGING_URL"
psql "$STAGING_URL" -c "select count(*) from users;"

Des sauvegardes pour les fichiers aussi

Les bases de données ne sont pas la seule chose qui mérite d'être protégée. Les fichiers envoyés par vos utilisateurs et vos ressources statiques sur Nest Storage peuvent être protégés par le versioning d'objets : un écrasement ou une suppression accidentels laissent la version précédente récupérable au lieu de la faire disparaître.

Et pour tout ce qui vit sur un VPS — configurations, code applicatif, ce fameux répertoire dont personne ne se souvient — les options d'instantanés permettent de capturer l'état complet de la machine et d'y revenir. Le principe est le même partout : une copie que vous pouvez réellement restaurer, conservée à l'écart de ce qu'elle protège.