Actuellement, de nombreuses technologies de reprise après sinistre (DR) existent dans le secteur, notamment le miroir de base de données, le clustering et les solutions de réplication. Toutefois, la copie des journaux (log shipping) est une méthode plus simple, facile à configurer et à maintenir. Cet article présentera les étapes de reprise après sinistre SQL Server à l'aide de la copie des journaux.
Solution de reprise après sinistre avec la livraison des journaux
La livraison des journaux maintient principalement les sauvegardes sur un serveur secondaire et prend le relais du serveur principal si nécessaire, afin d'améliorer la disponibilité globale de la base de données. En d'autres termes, lorsque la base de données principale devient indisponible en cas de sinistre, vous pouvez manuellement rendre la base de données secondaire accessible pour continuer à fournir les services.
Pour configurer la copie des journaux pour une base de données, SQL Server crée les trois travaux d'agent suivants afin d'automatiser les opérations de sauvegarde, de copie et de restauration :
La première tâche s'exécute sur l'instance principale. Elle sauvegarde le journal des transactions sur la base de données principale.
La deuxième tâche s'exécute sur le serveur secondaire. Elle copie les sauvegardes des journaux depuis le serveur principal vers le serveur secondaire.
Le troisième travail s'exécute également sur le serveur secondaire. Il restaure les sauvegardes des journaux et met à jour les entrées de journal dans la base de données secondaire.
Considérations avant de configurer le transfert des journaux dans SQL Server
Bien que la configuration du transfert des journaux ne soit pas difficile, plusieurs éléments doivent être pris en compte avant sa mise en œuvre :
Protection au niveau de la base de données : Si vous avez seulement besoin de protéger un petit nombre de bases de données en cas de sinistre, ce niveau est suffisant. Toutefois, si vous souhaitez préserver plusieurs bases de données au niveau de l'instance SQL Server, une solution log shipping autonome s'avère insuffisante.
Basculer manuellement sur le serveur secondaire : Le log shipping seul ne permet pas de basculer automatiquement du serveur principal vers le serveur secondaire. Vous devez activer manuellement la base de données secondaire.
Configuration manuelle de la connexion SQL : Les connexions SQL ne sont pas automatiquement transférées du serveur principal vers le serveur secondaire. Vous devez transférer les informations d'identification de connexion depuis l'instance du serveur principal vers l'instance du serveur secondaire pour synchroniser les connexions. En outre, vous avez souvent besoin de créer manuellement divers plans de maintenance, des serveurs liés, et des packages SSIS (SQL Server Integration Services) sur le serveur secondaire.
Risque de perte de données : En général, lorsque la base de données principale n'est plus disponible, seule la dernière sauvegarde du journal des transactions peut être restaurée. Cela signifie que toutes les transactions survenues après l'envoi de la dernière sauvegarde du journal vers le serveur secondaire seront perdues. Par exemple, si le serveur principal tombe en panne à 9h00 et que la dernière sauvegarde copiée sur l'instance B du serveur secondaire a eu lieu à 8h45, alors toutes les données entre 8h45 et 9h00 seront perdues.
Reverse log shipping : Cela s'avère utile lorsqu'on modifie les rôles des serveurs sans effectuer une sauvegarde complète de la base de données. Par exemple, si vous avez une grande sauvegarde et que vous devez transférer les données depuis le serveur secondaire vers un serveur principal distant, la copie de l'intégralité de la sauvegarde pourrait prendre beaucoup de temps.
Comment configurer et utiliser la copie des journaux (Log Shipping) ?
Généralement, le processus de configuration de la copie des journaux peut être divisé en deux étapes distinctes :
Étape 1 – Initialiser la base de données sur le serveur secondaire
Supposons que nous avons deux bases de données sur l'instance du serveur principal, et que nous devions transférer les journaux pour TestDB1 vers un serveur secondaire qui ne possède initialement aucune base de données. Il est important de noter que, pour configurer le transfert des journaux, la base de données doit être en mode de récupération FULL ou BULK-LOGGED. Si la base de données est en mode de récupération SIMPLE, le transfert des journaux échouera car les sauvegardes du journal des transactions ne pourront pas être utilisées.
1. Tout d'abord, nous devons effectuer une sauvegarde complète de la base de données et une sauvegarde du journal des transactions. Vous pouvez exécuter les requêtes T-SQL suivantes pour créer des sauvegardes « complètes » et « du journal des transactions » :
backup database TestDB1 to disk = 'c:\backup\TestDB1.bak'
backup log TestDB1 to disk = 'c:\backup\TestDB1.bak'
2. Ensuite, restaurez la sauvegarde sur le serveur secondaire .
3. Dans l'interface Restore Database, sélectionnez Device comme source de données et cliquez sur son icône.
4. Dans la boîte de dialogue Select backup devices, cliquez sur Add.
5. Sélectionnez le fichier de sauvegarde à restaurer et cliquez sur OK.
6. Exécutez la restauration de la sauvegarde TestDB1.
7. Cliquez sur Select a page et accédez à Files pour modifier les emplacements des fichiers physiques de la base de données si nécessaire.
8. Ensuite, cliquez sur Options à gauche. Dans la page Options, sélectionnez RESTORE WITH STANDBY dans la liste déroulante Recovery state. Notez que le choix de RESTORE WITH STANDBY permet de garder la base de données en lecture seule. Si vous choisissez RESTORE WITH NORECOVERY, la base de données deviendra inaccessible.
9. Après avoir sélectionné l'état de récupération approprié, cliquez sur OK pour assurer une restauration réussie. Cela permettra de restaurer TestDB1 en mode Standby (lecture seule) sur l'instance du serveur secondaire.
À ce stade, la base de données a été initialisée avec succès sur le serveur secondaire.
Étape 2 – Activer la base de données principale
1. Cliquez avec le bouton droit sur TestDB1 dans l'instance du serveur principal, puis cliquez sur Properties.
2. Sélectionnez Enable this as the primary database in the log shipping configuration.
Par défaut, le journal des transactions est sauvegardé toutes les 15 minutes. Cependant, parfois le journal des transactions peut devenir trop volumineux pour être copié et restauré dans la limite de temps prédéfinie. Pour résoudre ce problème, vous devez planifier des sauvegardes supplémentaires du journal. Cliquez sur Paramètres de sauvegarde, spécifiez l'emplacement du fichier de sauvegarde dans l'interface Paramètres de sauvegarde du journal des transactions, puis cliquez sur Planifier et modifiez la fréquence de sauvegarde pour qu'elle s'exécute toutes les 1 à 2 minutes.
3. Cliquez sur Add pour configurer la base de données secondaire. Le système vous invite à vous connecter à l'instance du serveur secondaire.
4. Comme configuré à l'étape 1, dans l'interface Secondary Database Settings , sélectionnez No, the secondary database is initialized.
5. Procédez à la copie des fichiers en spécifiant l'emplacement du dossier de sauvegarde du serveur secondaire, en définissant la fréquence de sauvegarde, puis cliquez sur OK.
6. Dans l'interface Restore Transaction Log, définissez l'état de la base de données sur Standby mode et cochez Disconnect users in the database when restoring backups. Après avoir configuré l'intervalle de sauvegarde, cliquez sur OK.
7. Pour ajouter l'instance du serveur secondaire et la base de données, cliquez sur OK pour créer les travaux de l'agent SQL Server.
Sous l'Agent SQL Server sur le serveur principal, vous trouverez la tâche de sauvegarde du journal des transactions.
Sous l'Agent SQL Server sur le serveur secondaire, vous trouverez deux travaux nouvellement créés : l'un qui copie les sauvegardes du journal des transactions à partir de la base de données principale et un autre qui restaure les sauvegardes du journal des transactions sur la base de données secondaire.
8. À ce stade, la solution de reprise après sinistre avec la copie des journaux est entièrement configurée. Si la base de données principale tombe en panne, vous pouvez immédiatement rendre la base de données secondaire accessible. Vous pouvez également exécuter la requête suivante pour vérifier que la base de données secondaire a quitté le mode veille :
Select * from Products
RESTORE DATABASE TestDB1 WITH RECOVERY
9. En actualisant la base de données, vous verrez que TestDB1 sur le serveur secondaire est maintenant en ligne.
Stratégie de protection des données plus complète pour SQL Server
Lors de la mise en œuvre de solutions de reprise après sinistre telles que le transport des journaux, les entreprises ont souvent besoin d'une stratégie de protection des données plus complète et efficace. Vinchin Backup & Recovery propose une solution automatisée de sauvegarde et de récupération spécialement conçue pour les machines virtuelles et les bases de données telles que SQL Server, prenant en charge les sauvegardes complètes, incrémentielles et différentielles. Grâce aux technologies intégrées de déduplication et de compression des données, elle réduit considérablement la consommation de stockage et le temps de sauvegarde.
De plus, la solution de sauvegarde de Vinchin élimine la nécessité d'une intervention manuelle complexe, permettant une protection automatique des bases de données tout en prenant en charge la migration multiplateforme et le stockage cloud. En cas de défaillance d'un serveur SQL, Vinchin aide les administrateurs à restaurer rapidement les bases de données, évitant ainsi la perte de données et des temps d'arrêt prolongés, offrant par conséquent une garantie de reprise après sinistre plus complète pour les entreprises.
Pour créer des tâches de sauvegarde de bases de données SQL Server, veuillez accéder à la page Physical Backup > Database Backup > Backup :
1. Sélectionnez les bases de données à sauvegarder.
2. Sélectionnez un nœud de sauvegarde sur lequel les données de sauvegarde doivent être traitées et stockées.
3. Configurez les stratégies de sauvegarde en fonction de vos besoins.
4. Vérifiez et confirmez les paramètres.
Cliquez sur le bouton ci-dessous pour profiter de l'essai gratuit de 60 jours de Vinchin et découvrir une solution de sauvegarde et de récupération de données efficace et fiable !
Questions fréquemment posées sur la reprise après sinistre SQL Server
1. Quelle est la différence entre la haute disponibilité (HA) et la reprise après sinistre (DR) ?
La haute disponibilité (HA) garantit un temps d'arrêt minimal en utilisant le clustering de basculement, les groupes de disponibilité Always On ou la mise en miroir des bases de données, tandis que la reprise après sinistre (DR) se concentre sur la restauration du service après des défaillances catastrophiques, impliquant souvent des sauvegardes hors site ou des centres de données secondaires.
2. Qu'est-ce qu'une instance de cluster de basculement SQL Server (FCI) et comment contribue-t-elle à la reprise après sinistre (DR) ?
Un FCI est une solution haute disponibilité utilisant le clustering de basculement Windows Server (WSFC) pour assurer un basculement automatique au niveau de l'instance SQL Server. Il nécessite un stockage partagé (SAN, Storage Spaces Direct ou solutions basées sur le cloud). C'est une solution idéale pour la haute disponibilité sur site, mais ce n'est pas à lui seul une solution de reprise après sinistre, car il ne protège pas contre les défaillances généralisées d'un site.
Conclusion
Le log shipping est une solution économique, efficace et simple de reprise après sinistre pour SQL Server. C'est un choix idéal pour la reprise après sinistre au niveau des bases de données. Toutefois, pour la reprise après sinistre au niveau des instances, d'autres techniques de reprise après sinistre telles que le miroir de base de données ou le clustering de basculement devraient être envisagées. En outre, le log shipping peut entraîner une perte de données. Si vous devez récupérer des données supprimées ou inaccessibles à partir d'une base de données SQL endommagée, envisagez d'utiliser un outil professionnel de récupération SQL.
