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 appareil de sauvegarde/restauration stocke les données d'application sur un disque de préproduction. Les instantanés sur le disque d'assemblage permettent à l'appareil 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 comprend quatre étapes:
Ajoutez des serveurs qui hébergent des bases de données Microsoft SQL Server.
Découvrez les VM et les bases de données Microsoft SQL Server.
Définissez des modèles de règles de sauvegarde et de reprise après sinistre, ainsi que des profils de ressources en fonction de vos RPOs et RTOs.
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 donné en avançant ses journaux.
Attribuez des modèles de stratégie de sauvegarde et de reprise après sinistre, ainsi que des profils de ressources, aux bases de données Microsoft SQL Server.
Capture de données
Lorsque vous collectez des données, tenez compte des points suivants:
Un disque de préproduction est automatiquement créé et installé sur un serveur.
Une copie complète initiale est effectuée sur le disque de préproduction. Les copies suivantes ne contiennent que les blocs modifiés.
Le disque de préproduction est démonté du serveur.
Un instantané du disque de préproduction est créé sur l'appareil 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 stratégie d'instantané. Il permet à une seule stratégie 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 la 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 la base de données est définie en minutes, et la fréquence à laquelle les journaux sont capturés ne doit pas dépasser la fréquence à 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 égale ou inférieure à 24 heures.
La conservation des journaux est également définie séparément de la base de données associée. Avoir des périodes de conservation distinctes vous permet de conserver suffisamment d'informations de journal pour couvrir toutes les versions d'instantanés et d'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 ses données OnVault pendant sept jours, vous pouvez définir la durée de 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 avancés sur toute la période.
Les journaux de la base de données sont mis en file d'attente sur un seul disque de mise en file d'attente dans le pool d'instantanés de sauvegarde et de reprise après sinistre. 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 appareil de sauvegarde/restauration à distance. Vous pouvez utiliser les journaux sur le site distant pour toute image de base de données dans la plage de conservation des journaux répliqués.
Redimensionner le disque de préproduction du journal de la base de données
L'espace physique requis pour accueillir 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éproduction de journaux, qui est distinct du stockage géré par le serveur source. Au minimum, Backup and DR évalue les tailles de journaux typiques et leur période de conservation, et utilise un disque plus volumineux si nécessaire.
Pour gérer plus efficacement les exigences 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. Disposer de taux de conservation distincts vous permet de conserver suffisamment d'informations de journal 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.
Augmentation de la taille du disque de préproduction des journaux: définit le pourcentage auquel augmenter automatiquement le disque de préproduction sur lequel se trouvent les journaux.
Taux de modification estimé: définit la modification quotidienne (en pourcentage), ce qui permet à l'appliance de sauvegarde/restauration de mieux calculer la taille du disque de préproduction nécessaire pour stocker les journaux.
Compresser la sauvegarde des journaux de la base de données: indique à la base de données source de compresser ses journaux avant de les capturer sur l'appliance de sauvegarde/restauration. Le serveur de base de données effectue la compression des journaux lors de la sauvegarde des journaux (par défaut, l'option Enabled (Activé) est sélectionnée).
Options de capture des 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 de sauvegarde et de reprise après sinistre 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 avez la possibilité de capturer l'instance entière ou des bases de données sélectionnées dans l'instance. Lorsque vous protégez l'ensemble de l'instance, les bases de données qui y sont ajoutées sont automatiquement incluses dans la prochaine tâche de capture de sauvegarde et de reprise après sinistre. Les bases de données d'une instance sont mises en veille et capturées avec un seul plan de sauvegarde.
Si la capture de la base de données et des journaux de sauvegarde et de DR est activée dans la stratégie de plan de sauvegarde, toutes les bases de données de cette instance peuvent être récupérées au même point temporel. La récupération et la migration des journaux pour toutes les bases de données d'une instance ou pour des bases de données individuelles sont effectuées à partir de l'interface utilisateur de sauvegarde et de reprise après sinistre en une seule action.
Vous pouvez accéder aux membres individuels d'une instance à l'aide des opérations de montage, de clonage, de LiveClone et de restauration, si nécessaire.
Groupes de cohérence de capture
Un groupe de cohérence est un groupe de bases de données qui sont mises en veille et capturées avec un seul modèle de stratégie de plan de sauvegarde et un seul profil de ressources. 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 une capture et une récupération cohérentes à un moment donné dans plusieurs bases de données. Si la technologie de capture de la base de données et des journaux de la sauvegarde et de la DR est activée dans la stratégie de plan de sauvegarde, toutes les bases de données de ce groupe peuvent être récupérées au même point temporel. La récupération et la migration des journaux pour toutes les bases de données ou des bases de données individuelles d'un groupe de cohérence sont effectuées à partir de l'interface utilisateur de sauvegarde et de reprise après sinistre 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 d'installation)
Les membres individuels d'un groupe de cohérence peuvent être accessibles via des opérations de montage, de clonage, de LiveClone 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 d'un cluster. Les tâches 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 la possibilité de capturer également le volume de démarrage de la VM. Lorsque le volume de démarrage d'une VM est capturé avec ses bases de données, une image peut être présentée, qui est une base de données et 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/restauration 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 été un frein à la gestion efficace des données dans un environnement géographiquement distribué. La réplication Backup and DR résout ces problèmes grâce à une compression qui:
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 appareils de sauvegarde/restauration est effectuée à l'aide de certificats 1 024 bits.
La réplication est contrôlée par les règles du modèle de règles de sauvegarde et de reprise après sinistre:
Les stratégies Production to Mirror (Production vers miroir) proposent plusieurs options pour répliquer des données sur un deuxième appareil de sauvegarde/de récupération.
Les règles de production vers OnVault utilisent un moteur propriétaire de sauvegarde et de DR pour transférer des données vers le stockage d'objets.
Répliquer les journaux
Lorsque l'option Enable Database Log Backup (Activer la sauvegarde des journaux de base de données) d'une règle est définie sur Enable (Activer), le paramètre avancé Replicate Logs (Répliquer les journaux) permet de répliquer les journaux de transactions de la base de données Microsoft SQL Server sur un appareil de sauvegarde/restauration à distance. Pour qu'une tâche de réplication de journaux s'exécute, une stratégie de réplication StreamSnap doit être incluse dans le modèle, ainsi qu'un profil de ressources spécifiant un appareil de sauvegarde/restauration à distance. Au moins une réplication de la base de données doit également être effectuée. 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/restauration locales et distantes. La réplication des journaux passe directement du pool d'instantanés local au pool d'instantanés de l'appliance distante.
Les journaux peuvent également être répliqués dans un pool OnVault. Lorsqu'elle est activée (pas par défaut), les journaux sont envoyés à chaque pool OnVault spécifié par une combinaison de règles ou de profils de ressources OnVault valide (par exemple, Pool 1 OnVault sélectionné dans la règle et pool 1 OnVault spécifié dans le profil de ressources). La durée de conservation des journaux dans le pool OnVault correspond toujours à celle du pool d'instantanés.
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, la sauvegarde et la DR peuvent présenter instantanément une copie de la base de données à un moment précis. L'opération de transfert 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, la sauvegarde et la reprise après sinistre peuvent présenter instantanément toute 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é, vous pouvez accéder aux données Microsoft SQL Server à 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, ainsi qu'aux ressources. Les données capturées peuvent être marquées comme sensibles, et les utilisateurs de la sauvegarde et de la reprise après sinistre peuvent être autorisés à y accéder.
Supports
La fonction d'installation de sauvegarde et de DR offre un accès instantané aux données sans les déplacer. Les copies capturées des bases de données peuvent être appliquées à l'aide de l'interface utilisateur de sauvegarde et de reprise après sinistre, puis montées sur n'importe quel serveur de base de données. Backup and DR propose deux méthodes pour 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. Vous pouvez ainsi créer et gérer des copies de bases de données de production pour un usage hors production. Les montages d'applications virtuels sont créés à partir de l'appliance de sauvegarde/récupération et ne nécessitent aucune intervention manuelle de la part des administrateurs de base de données, de serveur ou de stockage. Les montages d'applications virtuelles peuvent être utilisés pour les rapports de base de données, l'analyse, les tests d'intégrité, ainsi que pour les tests et le développement. Pour en savoir plus sur les bases de données virtuelles, consultez les articles 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 Always On.
Le montage standard, également appelé montage direct, présente et met à la disposition d'un serveur cible les données Microsoft SQL Server capturées en tant que système de fichiers, et non en tant que base de données. Cela est utile si une base de données est corrompue, 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 à leur emplacement d'origine sur le serveur de base de données. Les montages directs sont décrits dans la section 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 les données manuellement ni à interférer avec l'environnement de production.
Clones
La fonction de clonage déplace une copie des données de production vers un autre emplacement que la source. Le temps nécessaire pour effectuer une opération de clonage dépend de la quantité de données impliquées. Les clones sont décrits dans la section Cloner des bases de données SQL Server.
Restaurations
Une restauration rétablit les données de production à un moment spécifié. 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 impliquées.
Pour restaurer une base de données, puis appliquer des journaux, la base de données restaurée doit être en mode Restauration. Vous pouvez restaurer la base de données en mode Restoring Mode (Mode de restauration), puis faire avancer les journaux jusqu'à un moment spécifique. Si vous restaurez la base de données sans spécifier Restore with no Recovery (Restaurer sans récupération), la base de données sera restaurée et mise en ligne sans appliquer les journaux. Pour en savoir plus sur les restaurations, consultez Restaurer des bases de données SQL Server. Pour une restauration avec un temps d'arrêt quasi nul, installez d'abord les données, comme indiqué dans la section Installer et migrer des données SQL.
Workflows pour 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 la forme d'un montage direct ou d'un 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 montée des données 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.
Un LiveClone est une copie de vos données Microsoft SQL Server de production qui peut être mise à jour manuellement ou de manière planifiée. Vous pouvez masquer des données sensibles dans un LiveClone avant de les mettre à la disposition des utilisateurs.
En combinant la capture et le contrôle des accès des données Microsoft SQL Server automatisés de la sauvegarde et de la DR avec les workflows et leurs fonctionnalités de masquage de données facultatives, vous pouvez créer des environnements d'auto-provisionnement. Les utilisateurs peuvent provisionner leurs propres environnements presque instantanément.
Par exemple, un administrateur Backup and DR peut créer une stratégie de modèle de sauvegarde qui capture les données Microsoft SQL Server selon un calendrier spécifié. L'administrateur peut marquer les données Microsoft SQL Server de production capturées comme sensibles et accessibles uniquement par les utilisateurs disposant des droits d'accès appropriés.
Une fois les droits d'accès définis et les données collecté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.
Met à jour les données Microsoft SQL Server LiveClone ou montables de manière planifiée ou à la demande
Applique éventuellement automatiquement des scripts aux données Microsoft SQL Server de LiveClone après chaque mise à jour. Cela est utile pour masquer les données Microsoft SQL Server sensibles.
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 les données Microsoft SQL Server montables.
Sauvegarde et reprise après sinistre avec les produits de sauvegarde existants
Alors que de plus en plus d'entreprises cherchent à accélérer le développement d'applications à l'aide de bases de données de production, la sauvegarde et la reprise après sinistre sont souvent requises 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, si vous suivez ces bonnes pratiques.
La sauvegarde et la DR disposent d'une méthode propriétaire de suivi des blocs modifiés. Les solutions de sauvegarde utilisant SQL ou d'autres méthodes d'obtention des sauvegardes ne sont donc pas affectées par les tâches de capture de données de sauvegarde et de DR planifiées.
Les tâches de sauvegarde peuvent être très gourmandes en E/S. Elles peuvent avoir une durée longue et avoir un impact sur les performances de la base de données pendant les périodes de sauvegarde. La sauvegarde et la reprise après sinistre minimisent l'impact pendant les tâches, mais même une mise à jour incrémentielle au niveau des blocs doit générer des E/S et prendre un certain temps.
Exigence | Ne planifiez pas l'exécution des tâches par l'ancien logiciel de sauvegarde et par Backup and DR de manière à permettre des chevauchements dans le temps. |
Bonnes pratiques | Planifiez les tâches de base de données de sauvegarde et de reprise après sinistre de sorte qu'elles commencent à un moment où l'ancien logiciel de sauvegarde devrait être terminé. Ne planifiez pas l'exécution du logiciel de sauvegarde ancien immédiatement après la fin normale d'une tâche de sauvegarde et de reprise après sinistre. |
Motif | Si les anciennes tâches de sauvegarde et les tâches de sauvegarde et de reprise après sinistre 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é et éventuellement un arrêt. |
Les journaux de base de données sont utilisés pour capturer les transactions individuelles dans une base de données, ce qui permet de récupérer à un moment précis. La plupart des cas d'utilisation de l'agilité consistent à obtenir des instantanés de base de données de manière périodique à partir de la production. La fréquence courante 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 prod à un moment spécifique à partir de la source (production). Cela évite généralement de devoir capturer et gérer des journaux dans le cadre d'une solution d'agilité de sauvegarde et de reprise après sinistre.
Exigence | Un seul système peut gérer (capturer ou tronquer (purger)) les journaux, soit l'ancien logiciel de sauvegarde, soit Backup and DR. |
Bonnes pratiques | Autorisez toujours l'ancien logiciel de sauvegarde à gérer tous les journaux. N'utilisez pas la sauvegarde et la reprise après sinistre pour protéger les journaux dans cet environnement. |
Motif | Si votre système est configuré pour gérer (capturer ou tronquer/effacer) les journaux, et que l'ancien logiciel de sauvegarde capture également et/ou tronque/efface les journaux, un ou les deux systèmes peuvent se retrouver avec une chaîne de journaux incomplète, ce qui rend la récupération de la base de données à un moment spécifique difficile, voire impossible. |
Étape suivante
Préparer les bases de données SQL Server pour le service Backup and DR
Autre documentation sur 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, des binaires et des fichiers d'assistance Microsoft SQL Server avec la sauvegarde et la reprise après sinistre.
Pour en savoir plus:
- Sauvegarde et reprise après sinistre pour Microsoft SQL Server
- Préparer des bases de données SQL Server pour le service Backup and DR
- Ajouter un hôte de base de données SQL Server et découvrir des bases de données
- Configurer des plans de sauvegarde pour les instances et les bases de données Microsoft SQL Server
- Monter une base de données SQL Server
- Installer des bases de données dans des groupes de disponibilité Always On SQL
- Migrer une base de données SQL Server
- Cloner des bases de données SQL Server
- Récupérer des sauvegardes SQL Server