Here is Part 3 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.
Considérations à prendre par l'analyste de la base de données (DBA) concernant le niveau de recouvrement
Le modèle de recouvrement FULL [recovery] est recommandé pour vos bases de données les plus critiques, et qui requiert une attestation d’audit.
Dans le cas d'un désastre, le plus récent fichier du journal des transactions (Transaction Log File) ou de sauvegarde différentielle est prêt à être appliqué sur la base de données en relève qui reste en mode de recouvrement NORECOVERY, et voilà vous êtes prêts à revenir à vos opérations normales, avec un temps de panne minimal.
Une autre méthode pour une base de données en petite taille, c'est-à-dire avec un temps de restauration de moins de cinq minutes, est d'appliquer la restitution complète chaque heure vers le serveur de relève. Dans cet exemple, la nécessité de garder le mode norecovery n'est pas avantageux.
Si vous utiliser actuellement le mode de recouvrement Simple, et que vous faites régulièrement vos sauvegardes des fichiers de journaux de transactions et différentielles (tel que plusieurs fois par jour), vous pouvez changer le mode de recouvrement à Bulk-Logged en production afin de permettre la restitution jusqu'à un point spécifique dans le passé. Cette modification minimisera la perte de données lors de désastre. Les vrais DBAs vous diront qu’il faut aimer les fichiers de journaux de transactions pour exécuter un plan de relève comme le mien.
2e partie – Les étapes à suivre lors d’un désastre en production
-
1. Contactez le DBA du support en première ligne (insérez numéro de téléphone/pagette/mobile) ou le DBA secondaire à (insérez numéro).
2. Suite à la panne du serveur en production principal (SQL1), le serveur de relève (SQL2) devient le serveur principal de base de données. Avisez toutes les personnes impliquées de ce changement par courriel (départements internes ainsi que les clients externes si nécessaire). Ces personnes devraient déjà y être préparées.
3. Dès que le serveur de relève (SQL2) est prêt à accepter les connexions, et que SQL1 (ancien serveur principal) est bel et bien mort, changez tous les liens applicatifs vers SQL2. Si vos applications ont un fichier de configuration pour effectuer ce genre de changements vers le serveur SQL2, il est recommandé de tester cette configuration, par exemple pendant une fin de semaine, avant de terminer l'implantation de ce plan.
4. Désactivez vos processus automatisés de restitution des sauvegardes sur SQL2.
5. Désactivez vos processus automatisés de sauvegardes sur SQL1 (si possible).
6. Activez tous les processus automatisés de maintien et de sauvegarde (essential Jobs) sur le serveur de relève qui héberge les bases de données principaux.
