Service Backup and DR pour Microsoft SQL Server

Capturer des données SQL Server

Le service Backup and DR vous permet de capturer les types d'applications Microsoft SQL Server suivants :

  • Instances

  • Bases de données dans les groupes de disponibilité Always On

  • Groupes de cohérence des bases de données

  • Bases de données individuelles

  • Bases de données du système

  • Bases de données de l'utilisateur

  • Bases de données dans les VM

Backup and DR déplace et gère les données Microsoft SQL Server séparément de l'emplacement où Microsoft SQL Server écrit son stockage principal.

Un dispositif de sauvegarde/récupération stocke les données d'application sur un disque intermédiaire. Les instantanés sur le disque de préparation permettent à l'appliance de sauvegarde/restauration de conserver les données historiques.

Préparer la sauvegarde des données Microsoft SQL Server

La préparation de la sauvegarde des données Microsoft SQL Server se compose de quatre étapes :

  1. Ajoutez des serveurs qui hébergent des bases de données Microsoft SQL Server.

  2. Découvrez les VM et les bases de données Microsoft SQL Server.

  3. Définissez des modèles de règles Backup and DR et des profils de ressources en fonction de vos RPO et RTO.

    Les bases de données qui utilisent le modèle de récupération complet Microsoft SQL Server peuvent capturer à la fois la base de données et ses journaux. Par conséquent, une base de données capturée peut être récupérée à un moment précis en faisant avancer ses journaux.

  4. Attribuez des modèles de règles et des profils de ressources Backup and DR aux bases de données Microsoft SQL Server.

Capture de données

Lorsque vous capturez des données, tenez compte des points suivants :

  • Un disque intermédiaire est automatiquement créé et installé sur un serveur.

  • Une copie complète initiale est effectuée sur le disque intermédiaire. Les copies suivantes ne sont constituées que des blocs modifiés.

  • Le disque de préparation est démonté du serveur.

  • Un instantané du disque de préparation est créé sur l'appliance de sauvegarde/restauration.

Capturer les journaux de base de données SQL Server

La capture des journaux de base de données est définie dans la section Détails et paramètres d'une règle d'instantané. Il permet à une seule règle d'instantané de capturer les journaux des bases de données Microsoft SQL Server et des groupes de cohérence contenant des bases de données Microsoft SQL Server.

La fréquence à laquelle les journaux de base de données sont capturés est définie séparément de celle de la base de données. Par exemple, une base de données peut être capturée tous les jours et ses journaux toutes les heures.

La fréquence de sauvegarde des journaux de base de données est définie en minutes. La fréquence à laquelle les journaux sont capturés ne doit pas dépasser celle à laquelle la base de données associée est capturée. Par exemple, si la fréquence de capture de la base de données est de 24 heures, la fréquence de capture du fichier journal doit être inférieure ou égale à 24 heures.

La durée de conservation des journaux est également définie séparément de la base de données associée. Des périodes de conservation distinctes vous permettent de conserver suffisamment d'informations de journaux pour couvrir toutes les versions d'instantanés et OnVault d'une base de données. Par exemple, si les données d'instantané d'une base de données sont conservées pendant trois jours et que ses données OnVault sont conservées pendant sept jours, vous pouvez définir la conservation des journaux sur sept jours. Dans cet exemple, une seule image de base de données capturée peut être sélectionnée et ses journaux peuvent être transférés sur toute la période.

Les journaux de base de données sont transférés vers un seul disque intermédiaire dans le pool d'instantanés Backup and DR. Pour économiser de l'espace dans le pool d'instantanés, vous pouvez utiliser un paramètre avancé pour demander à la base de données de compresser ses journaux.

Vous pouvez spécifier de répliquer les journaux de transactions de la base de données Microsoft SQL Server sur un dispositif de sauvegarde/récupération à distance. Vous pouvez utiliser les journaux du site distant pour n'importe quelle image de base de données dans la plage de conservation des journaux répliqués.

Redimensionner le disque intermédiaire du journal de base de données

L'espace physique requis pour stocker les sauvegardes des journaux d'une base de données est géré automatiquement par Backup and DR. Il s'agit d'un disque de préparation des journaux, distinct du stockage géré par le serveur source. Au minimum, Backup and DR évalue la taille habituelle des journaux et leur période de conservation, et utilise un disque plus grand si nécessaire.

Pour gérer plus efficacement les besoins de stockage des journaux d'une base de données, les règles d'instantanés fournissent les paramètres avancés suivants :

  • Durée de conservation des sauvegardes de journaux : la conservation des journaux est définie séparément de la base de données associée. Le fait d'avoir des taux de conservation distincts vous permet de conserver suffisamment d'informations de journaux pour couvrir toutes les versions d'instantanés d'une base de données. La durée de conservation des journaux est un paramètre obligatoire.

  • Croissance de la taille du disque de préparation des journaux : définit le pourcentage d'augmentation automatique du disque de préparation sur lequel résident les journaux.

  • Taux de variation estimé : définit la variation quotidienne (en pourcentage), ce qui permet à l'appliance de sauvegarde/récupération de mieux calculer la taille du disque intermédiaire nécessaire pour stocker les journaux.

  • Compresser la sauvegarde des journaux de base de données : indique à la base de données source de compresser ses journaux avant la capture sur l'appliance de sauvegarde/récupération. Le serveur de base de données effectue la compression des journaux lors de la sauvegarde des journaux (l'option par défaut est Activé).

Options de capture de données SQL Server

Les sections suivantes présentent les options de capture de données SQL Server.

Capturer des instances, des bases de données individuelles et des groupes de bases de données

L'agent Backup and DR permet de capturer des instances, des bases de données utilisateur, des bases de données système et des groupes de bases de données sur des serveurs physiques et virtuels.

Lorsque vous capturez une instance SQL Server, vous pouvez choisir de capturer l'intégralité de l'instance ou certaines bases de données de l'instance. Lorsque vous protégez l'intégralité de l'instance, les bases de données qui y sont ajoutées sont automatiquement incluses dans la prochaine tâche de capture Backup and DR. Les bases de données d'une instance sont mises au repos et capturées ensemble avec un seul plan de sauvegarde.

Si la capture de la base de données et des journaux de sauvegarde et de reprise après sinistre est activée dans la règle du plan de sauvegarde, toutes les bases de données de cette instance peuvent être récupérées au même moment. La récupération et la restauration des journaux pour toutes les bases de données d'une instance ou pour certaines d'entre elles s'effectuent en une seule action depuis l'interface utilisateur Backup and DR.

Les membres individuels d'une instance sont accessibles par des opérations de montage, de clonage, de LiveClone et de restauration, selon les besoins.

Groupes de cohérence de capture

Un groupe de cohérence est un groupe de bases de données mises au repos et capturées ensemble avec un seul modèle de règle de plan de sauvegarde et un seul profil de ressource. L'appartenance à un groupe de cohérence est attribuée manuellement et convient aux groupes de bases de données dont les membres ne changent pas très souvent. Pour protéger automatiquement les nouveaux membres d'un groupe de bases de données, créez et protégez ces bases de données dans une instance SQL Server.

Comme leur nom l'indique, les groupes de cohérence garantissent la cohérence de la capture et de la récupération à un moment précis sur plusieurs bases de données. Si la technologie de capture de journaux et de base de données de Backup and DR est activée dans la règle du plan de sauvegarde, toutes les bases de données de ce groupe peuvent être récupérées au même moment précis. La récupération et l'avancement des journaux pour toutes les bases de données d'un groupe de cohérence ou pour certaines d'entre elles sont effectués à partir de l'interface utilisateur Backup and DR en une seule action. Les membres d'un groupe de cohérence doivent résider dans la même instance.

Un groupe de cohérence peut être composé des éléments suivants :

  • Une ou plusieurs bases de données système

  • Une ou plusieurs bases de données utilisateur

  • Bases de données système ou utilisateur ensemble

  • Zéro ou plusieurs systèmes de fichiers (lettres de lecteur ou points de montage)

Les membres individuels d'un groupe de cohérence sont accessibles par les opérations de montage, de clonage, de Live Clone et de restauration.

Les bases de données d'une instance de basculement en cluster doivent être détectées à partir du nœud actif. Une fois protégé, GO suit le nœud SQL actif dans un cluster. Les jobs de protection continuent de s'exécuter même en cas de basculement. En plus d'accélérer les opérations de capture et d'accès, les groupes de cohérence consomment moins de ressources système (VDisks) que la protection individuelle des bases de données.

Vous pouvez valider régulièrement l'intégrité de la sauvegarde de la base de données en montant une image de sauvegarde sur un serveur et en exécutant une vérification de la cohérence de la base de données. Vous pouvez utiliser la fonctionnalité de workflow pour automatiser le processus de validation.

Capturer les bases de données et le volume de démarrage d'une VM

Lorsque vous capturez des bases de données sur des VM, vous avez également la possibilité de capturer le volume de démarrage de la VM. Lorsqu'un volume de démarrage de VM est capturé avec ses bases de données, une image peut être présentée. Il s'agit d'une base de données et d'une VM entièrement fonctionnelles. L'image peut ensuite être migrée vers un nouvel emplacement permanent.

Répliquer des données SQL Server

Les données peuvent être répliquées sur un deuxième appareil de sauvegarde/récupération ou dans le cloud à des fins de récupération, de reprise après sinistre, de test ou de développement. La réplication des données a longtemps empêché une gestion efficace des données dans un environnement géographiquement distribué. La réplication Backup and DR résout ces problèmes de compression :

  • Réduit l'utilisation globale du réseau.

  • Élimine le besoin d'un accélérateur ou d'un optimiseur WAN dédié.

  • Chiffre les données à l'aide de la norme de chiffrement AES-256. L'authentification entre les appliances de sauvegarde/récupération s'effectue à l'aide de certificats de 1 024 bits.

La réplication est contrôlée par les règles des modèles de règles Backup and DR :

  • Les règles Production to Mirror proposent plusieurs options pour répliquer les données sur un deuxième appareil de sauvegarde/récupération.

  • Les règles Production vers OnVault utilisent un moteur propriétaire Backup and DR pour transférer les données vers le stockage d'objets.

Répliquer les journaux

Lorsque le paramètre Activer la sauvegarde des journaux de base de données d'une règle est défini sur Activer, le paramètre avancé Répliquer les journaux permet de répliquer les journaux de transactions de la base de données Microsoft SQL Server vers un dispositif de sauvegarde/récupération à distance. Pour qu'un job de réplication de journaux s'exécute, un profil de ressource doit être inclus dans le modèle. Il doit spécifier un dispositif de sauvegarde/récupération à distance et une stratégie de réplication StreamSnap. De plus, au moins une réplication de la base de données doit avoir été effectuée avec succès. Vous pouvez ensuite utiliser les journaux sur le site distant pour n'importe quelle image de base de données dans la plage de conservation des journaux répliqués. Cette fonctionnalité est activée par défaut.

La réplication des journaux utilise la technologie StreamSnap pour effectuer la réplication entre les appliances de sauvegarde/récupération locales et distantes. La réplication des journaux s'effectue directement du pool d'instantanés local vers le pool d'instantanés sur l'appliance distante.

Les journaux peuvent également être répliqués dans un pool OnVault. Lorsqu'elle est activée (et non par défaut), les journaux sont envoyés à chaque pool OnVault spécifié par une combinaison valide de règle OnVault ou de profil de ressource (par exemple, Le pool OnVault 1 est sélectionné dans la règle et spécifié dans le profil de ressource. La durée de conservation des journaux dans le pool OnVault correspond toujours à celle du pool de snapshots.

Accéder aux données SQL Server

Pour les bases de données Microsoft SQL Server qui utilisent le modèle de récupération complet, Backup and DR peut présenter instantanément une copie de la base de données restaurée à un moment précis. L'opération de report est spécifiée dans la console de gestion.

Pour les bases de données Microsoft SQL Server qui utilisent le modèle de récupération de base, Backup and DR peut présenter instantanément n'importe quelle sauvegarde de la base de données qui n'a pas dépassé sa période de conservation.

Quel que soit le modèle de récupération Microsoft SQL Server utilisé, les données Microsoft SQL Server sont accessibles à l'aide de l'interface iSCSI. Si vous utilisez VMware (GCVE), vous pouvez également accéder aux données à l'aide d'un datastore NFS présenté à l'hôte ESXi.

Contrôle des accès basé sur les rôles

Vous pouvez contrôler les utilisateurs qui ont accès aux données, aux fonctionnalités de sauvegarde et de reprise après sinistre, et aux ressources. Les données capturées peuvent être marquées comme sensibles, et les utilisateurs Backup and DR peuvent se voir accorder l'autorisation d'accéder aux données sensibles.

Supports

La fonction de montage de sauvegarde et de reprise après sinistre permet d'accéder instantanément aux données sans les déplacer. Les copies capturées des bases de données peuvent être transférées à l'aide de l'interface utilisateur Backup and DR et montées sur n'importe quel serveur de base de données. Backup and DR propose deux façons de monter une base de données Microsoft SQL Server :

  • Le montage d'application virtuelle présente et met les données Microsoft SQL Server capturées à la disposition d'un serveur cible en tant que base de données Microsoft SQL Server. Cela vous permet de créer et de gérer des copies de bases de données de production pour une utilisation hors production. Les montages d'applications virtuelles sont créés à partir de l'appliance de sauvegarde/récupération et ne nécessitent pas d'intervention manuelle de la part des administrateurs de bases de données, de serveurs ou de stockage. Les montages d'applications virtuelles peuvent être utilisés pour les rapports de base de données, les analyses, les tests d'intégrité, ainsi que les tests et le développement. Les bases de données virtuelles sont décrites en détail dans Monter une base de données SQL Server en tant que nouvelle base de données virtuelle et Monter des bases de données dans des groupes de disponibilité SQL AlwaysOn.

  • La configuration standard, également appelée configuration directe, présente et met les données Microsoft SQL Server capturées à la disposition d'un serveur cible sous forme de système de fichiers, et non de base de données. Cela peut être utile si une base de données est corrompue ou perdue, ou si un serveur de base de données est remplacé. Dans ce cas, vous ne pouvez pas utiliser une opération de restauration pour récupérer la base de données. Vous pouvez plutôt monter une image et copier les fichiers de base de données de l'image montée vers leur emplacement d'origine sur le serveur de base de données. Les montages directs sont décrits dans Monter les données Microsoft SQL capturées.

LiveClones

Un LiveClone est une copie indépendante des données Microsoft SQL Server qui peut être actualisée et masquée avant d'être mise à la disposition des utilisateurs. Cela permet aux équipes de développement et de test de travailler sur le dernier ensemble de données sans avoir à gérer manuellement les données ni à interférer avec l'environnement de production.

Clones

La fonction de clonage déplace une copie des données de production vers un emplacement différent de celui de la source. Le temps nécessaire pour effectuer une opération de clonage dépend de la quantité de données concernées. Les clones sont décrits dans Cloner des bases de données SQL Server.

Restaurations

Une restauration rétablit les données de production à un moment précis. Les opérations de restauration déplacent réellement les données. Les opérations de restauration sont généralement effectuées après une corruption massive des données. Le temps nécessaire pour effectuer une opération de restauration dépend de la quantité de données concernées.

Pour restaurer une base de données et appliquer ensuite des journaux, la base de données restaurée doit être en mode Restauration. Vous pouvez restaurer la base de données en mode restauration, puis faire défiler les journaux jusqu'à un moment précis. Si vous restaurez la base de données sans spécifier Restaurer sans récupération, elle sera restaurée et mise en ligne sans appliquer les journaux. Les restaurations sont détaillées dans Restaurer des bases de données SQL Server. Pour une restauration avec un temps d'arrêt quasi nul, commencez par installer les données comme indiqué dans Installer et migrer des données SQL.

Workflows permettant d'automatiser l'accès aux données SQL Server

Les workflows automatisent l'accès aux données Microsoft SQL Server capturées. Les workflows peuvent présenter les données sous forme de montage direct ou de LiveClone :

  • Les montages directs (standards ou compatibles avec les applications) fonctionnent bien pour les données Microsoft SQL Server qui n'ont pas besoin d'être masquées avant d'être présentées. Une copie de données associée peut être actualisée manuellement ou automatiquement selon un calendrier. Les montages directs vous permettent d'accéder instantanément aux données Microsoft SQL Server capturées sans les déplacer réellement.

  • Un LiveClone est une copie de vos données de production Microsoft SQL Server qui peut être mise à jour manuellement ou de manière planifiée. Vous pouvez masquer les données sensibles d'un LiveClone avant de le mettre à la disposition des utilisateurs.

En combinant la capture automatisée des données Microsoft SQL Server et le contrôle des accès de Backup and DR avec les workflows et leurs fonctionnalités de masquage des données facultatives, vous pouvez créer des environnements de provisionnement automatique. Les utilisateurs peuvent provisionner leurs propres environnements presque instantanément.

Par exemple, un administrateur Backup and DR peut créer un modèle de stratégie de sauvegarde qui capture les données Microsoft SQL Server selon une planification spécifiée. L'administrateur peut marquer les données Microsoft SQL Server de production capturées comme sensibles et accessibles uniquement aux utilisateurs disposant des droits d'accès appropriés.

Une fois les droits d'accès définis et les données capturées, l'administrateur peut créer un workflow qui :

  • Rend les données Microsoft SQL Server capturées disponibles en tant que LiveClone ou en tant que montage direct.

  • Mise à jour des données LiveClone ou Microsoft SQL Server montables de manière planifiée ou à la demande

  • Applique éventuellement automatiquement des scripts aux données Microsoft SQL Server du LiveClone après chaque mise à jour. Cela est utile pour masquer les données sensibles de Microsoft SQL Server.

Une fois le workflow terminé, les utilisateurs disposant des droits d'accès appropriés peuvent provisionner leurs environnements avec les données LiveClone ou Microsoft SQL Server montables.

Backup and DR fonctionne avec les produits de sauvegarde existants

De plus en plus d'entreprises cherchent à accélérer le développement d'applications à l'aide de bases de données de production. Backup and DR est donc souvent nécessaire pour coexister avec les anciens produits de sauvegarde fonctionnant sur les mêmes environnements de base de données de production. La sauvegarde et la reprise après sinistre peuvent parfaitement coexister avec d'autres produits qui capturent des données à partir de bases de données de production, à condition de suivre ces bonnes pratiques.

Backup and DR utilise une méthode propriétaire de suivi des blocs modifiés. Par conséquent, les solutions de sauvegarde utilisant SQL ou d'autres méthodes d'obtention des sauvegardes ne sont pas affectées par les tâches planifiées de capture de données Backup and DR.

Les tâches de sauvegarde peuvent être très gourmandes en E/S. Elles peuvent durer longtemps et avoir un impact sur les performances de la base de données pendant les périodes de sauvegarde. Backup and DR minimise l'impact pendant les tâches, mais même une mise à jour incrémentielle éternelle au niveau des blocs doit générer des E/S et prendre un peu de temps.

Exigence Ne planifiez pas l'exécution de tâches avec l'ancien logiciel de sauvegarde et Backup and DR de manière à ce qu'elles se chevauchent dans le temps.
Bonne pratique Planifiez les jobs de sauvegarde et de reprise après sinistre de la base de données pour qu'ils commencent à une heure où l'ancien logiciel de sauvegarde devrait avoir terminé. Ne programmez pas l'exécution de l'ancien logiciel de sauvegarde immédiatement après la fin normale d'un job Backup and DR.
Motif Si les anciens jobs de sauvegarde et les jobs Backup and DR s'exécutent simultanément, cela peut avoir un impact important sur les performances du serveur de base de données, ce qui peut entraîner une instabilité, voire une panne.

Les journaux de base de données sont utilisés pour capturer les transactions individuelles dans une base de données, ce qui permet d'effectuer des récupérations à un moment précis. La plupart des cas d'utilisation de l'agilité consistent à obtenir des instantanés de base de données de production à intervalles réguliers. La fréquence habituelle varie de quotidienne à hebdomadaire ou une fois toutes les deux semaines, selon le cas d'utilisation. Par conséquent, les développeurs d'applications n'ont généralement pas besoin de positionner leur instance non destinée à la production à un moment précis à partir de la source (production). Cela élimine généralement la nécessité de capturer et de gérer les journaux dans le cadre d'une solution d'agilité Backup and DR.

Exigence Un seul système peut gérer (capturer ou tronquer (purger)) les journaux : l'ancien logiciel de sauvegarde ou Backup and DR.
Bonne pratique Continuez à autoriser l'ancien logiciel de sauvegarde à effectuer toute la gestion des journaux. N'utilisez pas Backup and DR pour protéger les journaux dans cet environnement.
Motif Si votre système est configuré pour gérer (capturer ou tronquer/purger) les journaux, et que l'ancien logiciel de sauvegarde capture et/ou tronque/purge également les journaux, il est possible qu'un ou les deux systèmes se retrouvent avec une chaîne de journaux incomplète, ce qui rendra difficile, voire impossible, la récupération de la base de données à un moment précis.

Autre documentation pour Backup and DR pour Microsoft SQL Server

Cette page fait partie d'une série de pages spécifiques à la protection et à la récupération des bases de données Microsoft SQL Server avec Backup and DR. Pour en savoir plus, consultez les ressources suivantes :

Étape suivante

Préparez les bases de données SQL Server pour le service Backup and DR.