Sauvegarde de base de données et réplication de base de données
La sauvegarde et la réplication ont des objectifs différents, mais elles sont souvent confuses. La réplication conserve une copie synchronisée de la base de données sur un serveur séparé, généralement pour une haute disponibilité et une mise à l’échelle en lecture. En cas de défaillance du serveur principal, la réplique peut prendre le relais presque immédiatement.
Mais la réplication n’est pas une sauvegarde. Une table corrompue, une commande DROP DATABASE accidentelle ou un événement de chiffrement de Ransomware se réplique en mode veille aussi rapidement que les modifications légitimes. La réplication protège contre les pannes matérielles. La sauvegarde protège contre la perte de données. Les environnements d’entreprise ont besoin des deux.
RTO et RPO : Planification de votre stratégie de sauvegarde de base de données
Deux indicateurs ancrent chaque stratégie de sauvegarde : l’objectif de temps de récupération (RTO) et l’objectif de Recovery Point Objective (RPO).
Le RTO définit le délai maximum acceptable pour restaurer une base de données et reprendre les opérations après une panne. Le RPO définit la quantité maximale acceptable de perte de données, mesurée dans le temps. Un RPO d’une heure signifie que vous pouvez tolérer de perdre jusqu’à une heure de transactions.
Ces deux indicateurs doivent orienter chaque décision concernant la fréquence, le type et l’emplacement de stockage des sauvegardes :
- Un RPO proche de zéro nécessite des sauvegardes continues des journaux de transaction ou des snapshots au niveau du stockage, prises toutes les quelques minutes.
- Un RTO de quatre heures peut être réalisable avec des restaurations sur disque standard, tandis qu’un RTO de moins d’une heure nécessite généralement des répliques pré-étagées ou une technologie de reprise instantanée.
- Les contraintes budgétaires et d’infrastructure déterminent ce qui est réaliste. Un RPO de zéro est techniquement réalisable grâce à la réplication synchrone, mais l’impact sur le coût et la latence peut ne pas le justifier pour chaque charge de travail.
Commencez par classer les bases de données en niveaux en fonction de la criticité de l’entreprise, puis attribuez des cibles RTO et RPO à chaque niveau. Toutes les bases de données ne garantissent pas le même niveau de protection, mais chaque base de données a besoin d’un plan.
La règle de sauvegarde 3-2-1-1-0
La règle traditionnelle de sauvegarde 3-2-1, à savoir trois copies de données, sur deux types de supports différents, avec une copie hors site, était la référence depuis des années. Le photographe Peter Krogh l’a popularisé en 2009, alors que la bande était toujours une cible de sauvegarde principale, et que le Ransomware n’était pas une préoccupation courante.
La règle moderne 3-2-1-1-0 étend ce cadre avec deux ajouts conçus pour le paysage actuel des menaces :
- 3 copies de vos données (l’original plus au moins deux sauvegardes)
- 2 types de supports différents (par exemple, stockage sur disque et objet cloud)
- 1 copie hors site (séparation géographique du datacenter principal)
- 1 copie hors ligne ou immuable (stockage « air-gapped » ou « write-once » que le Ransomware ne peut ni chiffrer ni supprimer)
- 0 erreur (vérifiée par des tests de restauration réguliers, vous savez donc que les sauvegardes fonctionnent réellement)
L’élément « 1 immuable » est la mise à niveau critique. Les attaques modernes ciblent spécifiquement les référentiels de sauvegarde pour éliminer les options de reprise avant de chiffrer les données de production.
Bonnes pratiques de sauvegarde de bases de données
Automatisez et planifiez de manière cohérente
Les sauvegardes manuelles ne sont pas fiables. Utilisez les outils de planification intégrés de votre SGBD (SQL Server Agent, tâches cron avec pg_dump, planification RMAN) ou une plateforme de sauvegarde centralisée pour appliquer un calendrier cohérent. Un modèle courant : sauvegardes complètes hebdomadaires avec différentiels quotidiens et sauvegardes des journaux de transactions toutes les 15 à 30 minutes.
Tester régulièrement les restaurations
Une sauvegarde que vous n’avez jamais restaurée est une sauvegarde à laquelle vous ne pouvez pas faire confiance. Planifiez des tests de restauration trimestriels au minimum, tous les mois pour les bases de données stratégiques. Restaurez dans un environnement séparé, vérifiez l’intégrité des données et documentez le temps de reprise réel par rapport à vos objectifs RTO.
Chiffrer les sauvegardes au REST et en transit
Les sauvegardes de bases de données contiennent les mêmes données sensibles que vos systèmes de production. Appliquez le chiffrement AES-256 aux fichiers de sauvegarde au REST et utilisez TLS pour toutes les données de sauvegarde qui se déplacent sur un réseau. Le chiffrement est souvent une exigence de conformité en vertu de réglementations telles que HIPAA, RGPD et PCI DSS.
Surveiller et alerter en cas de panne
Les tâches de sauvegarde échouent en silence plus souvent que la plupart des équipes ne le pensent. Configurer une surveillance qui alerte en cas de fenêtres de sauvegarde manquées, d’échec des tâches ou de modifications inattendues de la taille de la sauvegarde. Une chute soudaine de la taille de la sauvegarde peut indiquer une perte de données qui n’a pas encore été détectée.
Définir et appliquer des politiques de conservation
Les politiques de conservation déterminent la durée pendant laquelle les copies de sauvegarde sont conservées avant d’être recyclées ou supprimées. La bonne fenêtre de conservation dépend des exigences de conformité, de la capacité de stockage et de l’horizon temporel sur lequel vous devrez peut-être vous remettre d’un problème non détecté. De nombreuses entreprises conservent leurs sauvegardes quotidiennes pendant 30 jours, leurs sauvegardes hebdomadaires pendant 90 jours et leurs sauvegardes mensuelles pendant un an.
Séparer le stockage de sauvegarde de la production
Stockez des sauvegardes sur une infrastructure physiquement et logiquement distincte du stockage de production. Cela signifie des baies de stockage différentes, des segments de réseau différents et, idéalement, des emplacements géographiques différents. Si le Ransomware chiffre votre stockage de production et que vos sauvegardes se trouvent sur le même SAN, les deux sont compromises.
Problèmes courants de sauvegarde de bases de données
Même les stratégies de sauvegarde bien planifiées rencontrent des obstacles pratiques. Comprendre ces défis à l’avance vous aide à concevoir autour d’eux.
- Les bases de données de grande taille étendent les fenêtres de sauvegarde. Les bases de données de plusieurs téraoctets peuvent prendre des heures à sauvegarder, en particulier avec les sauvegardes complètes traditionnelles sur le stockage réseau. Les sauvegardes incrémentielles au niveau des blocs, les snapshots au niveau du stockage et les canaux de sauvegarde parallèles contribuent à comprimer la fenêtre de sauvegarde.
- La prolifération des sauvegardes augmente les coûts. Sans politiques de conservation et de déduplication claires, les coûts du stockage de sauvegarde augmentent plus rapidement que les données de production. La déduplication et la compression, associées à un stockage hiérarchisé (sauvegardes à chaud sur disque rapide, sauvegardes obsolètes sur un stockage d’objets moins cher), aident à contrôler les dépenses.
- Les environnements multi-bases de données ajoutent de la complexité. La plupart des entreprises exécutent un mélange de systèmes SQL Server, Oracle, PostGreSQL, MySQL et de plus en plus NoSQL comme MongoDB. Chacun dispose de ses propres outils de sauvegarde et procédures de restauration. Une plateforme de sauvegarde centralisée prenant en charge plusieurs moteurs de base de données simplifie les opérations et réduit le risque d’écarts.
- Les bases de données cloud natives nécessitent des approches différentes. Les services managés tels qu’Amazon RDS, Azure SQL Database et Google Cloud SQL gèrent les sauvegardes automatisées, mais les organisations doivent tout de même comprendre les fenêtres de rétention par défaut, les options de réplication interrégionale et la manière de récupérer à un moment précis. Le recours total aux paramètres par défaut du fournisseur sans personnaliser les paramètres de RPO et de rétention est une surveillance courante.
L’avenir de la sauvegarde de bases de données
La sauvegarde de bases de données passe d’opérations planifiées et basées sur des tâches à une protection continue et intégrée au stockage. La protection continue des données (CDP) capture chaque modification de la base de données en temps réel, ce qui permet une Point-in-Time Recovery à la seconde près, et pas seulement à la dernière fenêtre de sauvegarde programmée.
Les snapshots natifs du stockage modifient également les coûts de la sauvegarde. Au lieu de copier des ensembles de données entiers, la technologie de snapshot ne capture que les blocs modifiés, et se termine en quelques secondes, quelle que soit la taille de la base de données. Associée à des stratégies de snapshot immuables, cette approche garantit un RPO proche de zéro avec une protection intégrée contre les Ransomware.
La détection d’anomalies pilotée par l’AI émerge comme une autre couche de défense. En analysant les schémas de métadonnées de sauvegarde, à savoir la taille, la durée et les taux de modification, ces systèmes peuvent signaler une activité inhabituelle (comme un événement de chiffrement d’un Ransomware) avant qu’elle ne se propage vers des copies de sauvegarde.
