• Article

Planification de la récupération d'urgence

Lorsque vous administrez une base de données SQL Server, il est important d'anticiper les récupérations d'urgence. Vous devez disposer d'un plan de sauvegarde et de restauration bien conçu et testé pour vos sauvegardes SQL Server pour la récupération de vos bases de données après un problème grave. Pour plus d'informations, consultez Présentation des stratégies de sauvegarde et de restauration dans SQL Server. De plus, pour garantir une restauration rapide de tous vos systèmes et données et revenir à un fonctionnement normal en cas de sinistre naturel, vous devez créer un plan de récupération d'urgence. Lorsque vous créez ce plan, envisagez des scénarios pour différents types de sinistres qui pourraient nuire à vos activités. Ceux-ci comprennent les sinistres naturels (ex. incendie) et techniques (ex. défaillance de deux disques dans une pile de disques de niveau RAID 5). Lors de la création de ce plan, identifiez et prévoyez toutes les opérations permettant de remédier à chaque type de sinistre. Le test de ces opérations de récupération pour chaque scénario est nécessaire. Nous vous recommandons de vérifier votre plan de récupération d'urgence en simulant une catastrophe.

Lors de la création de votre plan de sauvegarde et de restauration, examinez votre plan de récupération d'urgence en fonction de votre environnement et des besoins de votre activité. Supposons, par exemple, qu'un incendie détruise votre centre de données opérationnel 24 heures sur 24. Êtes-vous certain de pouvoir récupérer ? Combien de temps vous faudra-t-il pour récupérer et faire en sorte que votre système soit à nouveau disponible ? Quelle quantité de perte de données peuvent tolérer vos utilisateurs ?

L'idéal est que le plan de récupération d'urgence mentionne la durée du processus de récupération et l'état final dans lequel les utilisateurs sont susceptibles de retrouver la base de données. Par exemple, vous pouvez déterminer qu'après l'acquisition du matériel spécifié, la récupération doit être terminée sous 48 heures et les données restaurées dans l'état où elles se trouvaient à la fin de la semaine précédente.

Un plan de récupération d'urgence peut être structuré d'une multitude de manières différentes et peut contenir de nombreux types d'information. Les divers types de plans de récupération d'urgence comprennent les éléments suivants :

  • un plan pour l'obtention du matériel ;

  • un plan de communication ;

  • une liste des personnes à contacter en cas de sinistre ;

  • des instructions pour contacter les personnes impliquées dans la réponse au sinistre ;

  • des informations sur la personne assurant l'administration du plan ;

  • la liste de vérification des tâches indispensables pour chaque scénario de récupération. Pour examiner plus facilement la progression de la récupération, marquez chaque tâche terminée et indiquez l'heure de sa réalisation sur la liste de vérification.

Modes de récupération SQL Server

SQL Server propose trois modes de récupération : simple, complète et utilisant les journaux de transactions. Un mode de récupération est une propriété d'une base de données qui contrôle le comportement de base des sauvegardes et des restaurations. La sélection du mode de récupération optimal pour chacune de vos bases de données est intégrée à la planification de votre stratégie de sauvegarde et de restauration. Le choix du mode de récupération pour une base de données spécifique dépend dans une certaine mesure de votre disponibilité et des besoins de récupération. Le choix du mode, à son tour, a une influence sur les possibilités de récupération d'urgence pour une base de données.

Pour une présentation des modes de récupération, consultez Vue d'ensemble du mode de récupération.

Gestion des supports de sauvegarde

Nous recommandons que votre plan de sauvegarde comporte des mesures de gestion des supports, telles que :

  • un plan de gestion et de suivi pour stocker et recycler les jeux de sauvegarde ;

  • une planification de l'écrasement du support de sauvegarde ;

  • un choix d'utiliser les sauvegardes distribuées ou centralisées dans un environnement multi-serveur ;

  • un moyen d'assurer le suivi de la durée de vie des supports ;

  • une procédure pour minimiser les effets de la perte d'un jeu ou support de sauvegarde (perte d'une bande par exemple) ;

  • une décision de stocker les jeux de sauvegarde sur site ou hors site, et une analyse de l'impact sur le temps de récupération.

Pour plus d'informations sur la façon dont SQL Server utilise les unités et les supports de sauvegarde, consultez Utilisation de supports de sauvegarde dans SQL Server.

Exécution d'un script des fonctionnalités de base

De manière générale, vous incluez un script des fonctionnalités de base en tant que partie intégrante de votre plan de récupération d'urgence afin de confirmer que tout fonctionne comme prévu. Un script des fonctionnalités de base est un outil fiable qui permet aux administrateurs système et aux administrateurs de base de données de vérifier que la base de données est revenue à un état acceptable, sans qu'il soit nécessaire de demander aux utilisateurs finaux de faire des vérifications.

Un script des fonctionnalités de base dépend en grande partie de l'application et peut se présenter sous différentes formes. Par exemple, sur un système d'aide à la décision ou de rapports, le script peut se contenter d'être une copie de plusieurs de vos principales requêtes de rapport. Pour une application de traitement des transactions en ligne (OLTP, online transaction processing), le script peut exécuter un traitement de procédures stockées pour exécuter les instructions INSERT, UPDATE et DELETE. Il peut par exemple s'agir d'un fichier .sql qui envoie des traitements SQL à un serveur au moyen de l'utilitaire sqlcmd. Dans un autre exemple, un fichier .bat contenant deux commandes bcp et sqlcmd est utilisé.

Garantie de disponibilité du plan d'urgence

Pour garantir que vous êtes paré en cas de sinistre, nous vous recommandons d'effectuer régulièrement les actions suivantes :

  • Testez en détail vos procédures de sauvegarde et de récupération avant qu'un véritable sinistre ne se produise. Le test vous aide à vous assurer que vous disposez des sauvegardes indispensables à la récupération de vos données après différents types d'échec, que vos procédures sont clairement définies et documentées et qu'un opérateur qualifié peut les exécuter facilement et rapidement.

  • Pour limiter les pertes de données, effectuez régulièrement des sauvegardes du journal des transactions et des bases de données ; Nous vous recommandons de sauvegarder les bases de données système et utilisateur.

  • Conservez les journaux système en mode sécurisé. Notez tous les Service Packs installés sur Microsoft Windows et SQL Server. Notez également les bibliothèques réseau utilisées et le mode de sécurité. En outre, si SQL Server s'exécute en mode mixte d'authentification (SQL Server et mode d'authentification Windows), enregistrez le mot de passe sa dans un emplacement sécurisé. Pour plus d'informations, consultez Sécurité et protection (moteur de base de données).

    Important

    L'authentification Windows est plus sûre que l'authentification SQL Server SQL Server. Lorsque c'est possible, utilisez l'authentification Windows.

  • Sur un autre serveur, évaluez les opérations nécessaires à la récupération d'urgence. Si nécessaire, modifiez ces opérations pour les adapter à l'environnement de votre serveur local et testez ces modifications.

  • Conservez un script des fonctionnalités de base pour évaluer rapidement les capacités minimales.

Audit et réduction des erreurs utilisateur potentiellement nuisibles

L'un des scénarios de récupération les plus complexes est la récupération à partir d'une erreur utilisateur grave, comme des objets de base de données supprimés par inadvertance. Cette section répertorie les outils qui peuvent vous aider dans l'audit, et parfois dans la régulation, des modifications apportées aux bases de données.

  • Déclencheurs de langage de définition de données (DDL)

    Ces déclencheurs peuvent être créés pour l'audit et la régulation de certaines modifications apportées au schéma de votre base de données. Les déclencheurs DDL lancent des procédures stockées en réponse à différentes instructions DDL (Data Definition Language). Ces instructions commencent généralement par CREATE, ALTER et DROP. L'étendue d'un déclencheur DDL est une base de données spécifique ou la totalité d'une instance serveur. Pour plus d'informations, consultez Description des déclencheurs DDL.

  • Notifications d'événements

    Les notifications d'événements sont exécutées en réponse à une variété d'instructions en langage de définition de données (DDL) Transact-SQL et d'événements SQL Trace, et envoient des informations relatives à ces événements à un service Service Broker.

    Elles peuvent être programmées pour de nombreux événements capturés par SQL Trace. Toutefois, à la différence de la création des traces, les notifications d'événements permettent d'effectuer une action dans une instance de SQL Server en réponse aux événements. Étant donné que les notifications d'événements sont exécutées de façon asynchrone, ces actions ne consomment aucune ressource définie par la transaction immédiate. Pour plus d'informations, consultez Notifications d'événements (moteur de base de données).

    Notes

    Tous les événements DDL ne peuvent pas être utilisés dans les déclencheurs DDL. Certains événements sont destinés uniquement aux instructions asynchrones non transactionnelles. Par exemple, un événement CREATE DATABASE n'est pas utilisable dans un déclencheur DDL. Vous devez utiliser les notifications d'événements dans ces situations.

  • Agent SQL Server

    Il s'agit d'un service Windows qui exécute des tâches administratives planifiées, appelées travaux. L'Agent SQL Server utilise SQL Server pour stocker les informations sur les travaux. Entre autres choses, l'Agent SQL Server peut exécuter un travail en réponse à un événement particulier comme des erreurs présentant un degré de gravité spécifique ou un numéro de message.

    Pour obtenir une présentation de l'Agent SQL Server, consultez Automatisation des tâches administratives (Agent SQL Server). Pour plus d'informations sur l'utilisation de l'Agent SQL Server pour les événements, consultez Surveillance et réponse aux événements.

  • SQL Trace

    SQL Trace fournit des procédures stockées Transact-SQL système pour créer des traces sur les classes d'événements sélectionnées par l'utilisateur dans une instance du moteur de base de données SQL Server. Ces procédures stockées système permettent, à partir de vos propres applications, de créer des traces manuellement. Pour plus d'informations, consultez Présentation de SQL Trace.

    Notes

    Le Générateur de profils SQL Server est une interface utilisateur graphique de SQL Trace permettant de surveiller une instance du moteur de base de données ou Analysis Services. Pour plus d'informations, consultez Utilisation du Générateur de profils SQL Server.