Sauvegarde et réplication : ce qui vous protège vraiment

Si votre base de données est répliquée, êtes-vous protégé ? Pas contre tout. La réplication vous protège d'une panne. La sauvegarde vous protège d'une erreur. Il vous faut en général les deux, et surtout la preuve que vous savez restaurer.

Deux mots, deux protections

La réplication maintient une copie de vos données sur un autre serveur, mise à jour en continu. Si le premier tombe en panne, le second peut prendre le relais.

Une sauvegarde est une photographie de vos données à un instant donné, rangée à part. Vous pouvez revenir à l'état d'hier, ou de la semaine dernière.

L'analogie : le double des clés et la photo de l'appartement

La réplication, c'est un double de vos clés chez un voisin : si vous perdez les vôtres, vous entrez quand même.

La sauvegarde, c'est la photo de l'appartement avant les travaux : si on casse un mur par erreur, vous savez à quoi il ressemblait.

Le double des clés ne vous aide pas à retrouver le mur disparu. La photo ne vous fait pas entrer chez vous ce soir. Ce ne sont pas les mêmes problèmes.

Le piège classique

Une réplication copie fidèlement tout, y compris les erreurs. Si quelqu'un supprime par mégarde une table, ou si une mise à jour défectueuse corrompt des lignes, ou si un logiciel malveillant chiffre les données, la copie reçoit le même désastre presque immédiatement. Vous avez alors deux bases également abîmées.

C'est pourquoi une réplication ne remplace jamais une sauvegarde.

Ce que chacune couvre

• Panne d'un serveur ou de l'hébergeur : la réplication aide, une sauvegarde aide aussi mais avec un délai de remise en route.
• Suppression ou modification par erreur : seule une sauvegarde (ou un historique conservé) permet de revenir en arrière.
• Données corrompues par un bug : la sauvegarde, à condition qu'elle date d'avant le bug.
• Attaque qui chiffre ou efface les données : une sauvegarde isolée et conservée hors d'atteinte du système principal.

Ce qui fait une bonne sauvegarde

Quelques questions simples :

1. À quelle fréquence ? Si elle est faite chaque nuit, vous pouvez perdre jusqu'à une journée de données. Est-ce acceptable pour votre activité ?
2. Où est-elle rangée ? Une sauvegarde au même endroit que les données disparaît avec elles. Il faut au moins une copie ailleurs.
3. Combien de temps la garde-t-on ? Une erreur découverte trois semaines plus tard demande des sauvegardes plus anciennes.
4. Qui y a accès ? Elle contient toutes vos données : elle se protège comme la base elle-même.
5. A-t-on déjà restauré ? C'est la question la plus importante.

La sauvegarde qu'on n'a jamais restaurée

Une sauvegarde qui n'a jamais été testée est une hypothèse, pas une protection. Elle peut être vide, incomplète, illisible, ou demander des heures dont vous ne disposez pas. Le seul test fiable est de restaurer pour de vrai, dans un environnement à part, et de vérifier que l'application fonctionne avec ces données. Notez le temps que cela prend : c'est lui qui décide de la durée d'une panne.

Pour comprendre pourquoi on isole ces essais, voir staging et production. Et pour un autre exemple de changement risqué sur une base, voir la migration de base de données.

À retenir

La réplication protège de la panne, la sauvegarde protège de l'erreur, et seule une restauration réussie prouve que vous êtes protégé. Posez-vous la question : quand avons-nous restauré pour la dernière fois ?

Et pour votre produit ?

Où sont vos sauvegardes, combien de temps tiennent-elles, qui peut les restaurer : ce sont des questions qu'un audit de votre application peut passer en revue, avec le reste de l'exploitation. Si vous voulez savoir où vous en êtes, nous pouvons en parler pendant 30 minutes.