Part 2 of the translation for the French version of the Disaster Recovery for SQL Server Databases - comments welcome. Donc, cela veut dire corrigez-moi SVP, surtout quand il y a des phrases mal formées.
1e partie – La restitution automatique des fichiers de sauvegarde vers un serveur de relève
La méthodologie de relève utilisée est de se servir d'une instance en mode standby, dorénavant appelée SQL2, qui est déjà installée, stable et une copie exacte de la configuration en production. Le serveur de relève, SQL2, devrait déjà avoir les bases de données opérationnelles critiques restaurées au complet en mode de recouvrement norecovery.
Le mode de recouvrement de SQL Server norecovery conserve la base de données stable et prête à appliquer constamment les changements récents venant du processus automatisé de sauvegarde. Cela implique qu'il est nécessaire d'appliqué uniquement la plus récente copie de sauvegarde différentielle ou du journal de transactions (log file) afin de rendre la base de données disponible à vos utilisateurs et vos applications.
L'Implantation du serveur de relève
Suite à l'installation de SQL Server sur l'instance de relève, vous devez premièrement vous assurez que Robocopy existe dans le dossier sysroot\Windows\system32. Deuxièmement, assurez-vous que le logiciel SQL Backup de Red Gate soit correctement installé et connecté au serveur de relève en cliquant sur le petit bouton gris à coté du serveur dans la liste des serveurs à gauche de la fenêtre du logiciel. Cliquer sur ce petit bouton installera et configurera automatiquement SQL Backup si cela n'est pas déjà fait.
Image 1 – le système automatisé de configuration de SQL Backup
Ensuite, en ce qui concerne les procédures stockées qui exploitent Robocopy (nous allons placer ces procédures dans une base de donnée qui s'appel DBA_outils), nous devons permettre la configuration avancée xp_cmdshell à exécuté :
-- pour permettre les changements et les configurations avancées.
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
-- permettre l'exécution de xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 1
GO
-- Mettre à jour la configuration actuelle
RECONFIGURE
GO
Robocopy est le meilleur outil intégré par Windows à utilisé, car Xcopy disparaîtra sous peu, confirmé par le fait que depuis Windows Server 2003, Robocopy est l'outil de copie recommandé. Selon ce que je comprends de ces gestes, Xcopy ne serai plus disponible dans les prochaines versions du système d'exploitation Windows.
Afin de faire la copie des fichiers de sauvegarde, chaque base de données sur le serveur de relève (SQL2) devrait avoir son propre processus automatisé (local SQL Server Agent Job) qui roule Robocopy à l'heure convenue, et qui copie la sauvegarde au complet ou différentielle du serveur en production (SQL1) vers SQL2. La cédule de ces processus automatisés peut être exécutée à la fréquence désirée et/ou étalée selon vos besoins.
L'exécution de Robocopy est la première étape à exécutée dans le processus automatisé par l'agent de SQL, à moins que vous désiriez ajouter une étape de validation de l'existence des fichiers de sauvegarde courants avant que Robocopy effectue sa copie. Voici un exemple qui démontre comment copier des sauvegardes de SQL1 vers SQL2.
EXEC dbo.usp_RoboCopy '\\PRODserver\drive$\ProdServerBackupShare\Diff', '\\DRPserver\Drive$\ProdServerDbBackupFolder\Diff', 'database1_* database2_*'
-- la création des dossiers \Diff\ , \Full\ et \Tlog\ sont un pré-requis
La restitution des fichiers de sauvegarde sur le serveur de relève se fait par l'agent SQL avec un processus mis en place pour chacune des bases de données qui appelle les procédures stockées suivantes qui ont été crées spécifiquement pour ce plan de relève, tel que :
- usp_DB_Restore_Master or usp_DB_Restore_Master_Multi
- usp_DB_Restore
- usp_DB_Restore_NoRecovery
- usp_DB_Restore_differential
- usp_DB_Restore_Log
