En tant qu’utilisateur de SQL Server, vous êtes probablement conscient de l’importance de sauvegarder régulièrement vos bases de données et de tester ces sauvegardes par le biais de restaurations. Cependant, parfois des problèmes inattendus peuvent survenir pendant le processus de restauration, entraînant une perte potentielle de données ou une période d’indisponibilité. Dans cet article, nous explorerons un scénario réel où un processus de sauvegarde et de restauration a rencontré une défaillance importante et discuterons des leçons apprises.
L’histoire commence avec un administrateur de base de données qui lance une restauration de test d’une grande base de données vers un site de reprise après sinistre (DR). Le processus a commencé par la restauration de la sauvegarde complète de la base de données, ce qui a pris un temps inattendu de plus de 16 heures. Une fois la sauvegarde complète restaurée, l’étape suivante consistait à restaurer les sauvegardes différentielles et de journal les plus récentes. Cependant, un message d’erreur est apparu, indiquant que la sauvegarde différentielle ne pouvait pas être restaurée car la base de données n’avait pas été restaurée à l’état antérieur correct.
Cette erreur a intrigué l’administrateur, car il avait vérifié que la sauvegarde complète n’avait été effectuée qu’une seule fois selon le calendrier de sauvegarde habituel. Pour enquêter davantage, l’administrateur a exécuté un script pour vérifier l’historique et les tailles des sauvegardes. Étonnamment, le script ne renvoyait que la sauvegarde complète attendue des derniers jours. Cependant, lorsque l’administrateur a supprimé une ligne spécifique du script, une nouvelle sauvegarde complète est apparue pour chaque jour depuis la sauvegarde complète planifiée. Ces nouvelles sauvegardes avaient une convention de nom unique qui indiquait qu’elles étaient liées aux instantanés SAN.
Il est devenu clair que la prise d’instantanés SAN, un processus utilisé pour créer des copies ponctuelles des données, faisait enregistrer une sauvegarde complète dans SQL Server. Cela expliquait la taille constante des sauvegardes différentielles, car les instantanés SAN capturaient essentiellement l’intégralité de la base de données à chaque instantané. L’administrateur a réalisé que l’exclusion des sauvegardes avec la convention de nom spécifique avait involontairement exclu ces sauvegardes d’instantanés SAN dans le passé.
Si vous utilisez des instantanés SAN en conjonction avec les sauvegardes SQL Server, il est essentiel de reconsidérer votre plan de sauvegarde différentielle. Le script fourni dans cet article peut vous aider à identifier les sauvegardes complètes et différentielles qui ont été effectuées, vous permettant ainsi de garantir l’intégrité de vos processus de sauvegarde et de restauration.
N’oubliez pas qu’une stratégie complète de sauvegarde et de restauration est cruciale pour maintenir la disponibilité et la récupérabilité de vos bases de données SQL Server. Tester régulièrement vos sauvegardes par le biais de restaurations et rester vigilant face à d’éventuels problèmes, tels que des sauvegardes inattendues causées par des instantanés SAN, peut vous aider à éviter la perte de données et à réduire au minimum les périodes d’indisponibilité en cas de sinistre.
Merci d’avoir lu cet article. Nous espérons qu’il vous a fourni des informations précieuses sur les processus de sauvegarde et de restauration de SQL Server. Restez à l’écoute pour d’autres articles informatifs sur les meilleures pratiques et les astuces de SQL Server.