Sauvegarde de SQL Server sur Azure en tant que charge de travail DPM

Article
12/24/2024

Cet article explique comment sauvegarder et restaurer les bases de données SQL Server à l’aide de Sauvegarde Azure.

Sauvegarde Azure vous permet de sauvegarder des bases de données SQL Server dans Azure par le biais d’un compte Azure. Si vous n’en avez pas, vous pouvez en créer un gratuitement en quelques minutes. Pour plus d’informations, voir Créer votre compte Azure gratuit.

Remarque

Lorsque le découpage est effectué dans le système d’exploitation invité, le suivi des blocs incrémentiels est réinitialisé et entraîne ainsi une sauvegarde complète. Le découpage dans le système d’exploitation invité libère des blocs inutilisés du disque virtuel (VHDX) et optimise la taille du disque. Toutefois, cette opération réduit la taille du VHDX et change le SequenceNumber des blocs incrémentiels suivis, ce qui entraîne une taille de sauvegarde complète. Sauf si l’objectif est d’améliorer l’efficacité du stockage sur le côté hôte Hyper-V, nous vous recommandons d’arrêter le processus de découpage dans l’hôte pour éviter une augmentation de la taille de sauvegarde.

Flux de sauvegarde pour la base de données SQL Server

Pour sauvegarder une base de données SQL Server sur Azure et la récupérer à partir d’Azure :

Créez une stratégie de sauvegarde pour protéger les bases de données SQL Server dans Azure.
Créez des copies de sauvegarde à la demande dans Azure.
Récupérer la base de données à partir d’Azure.

Scénarios pris en charge

DPM 2019 UR2 prend en charge les instances de cluster de basculement (FCI) SQL Server à l’aide des volumes de cluster partagés (Cluster Shared Volumes).
Cette fonctionnalité prend en charge les instances de cluster de basculement SQL Server avec espaces de stockage direct sur Azure et les instances de cluster de basculement SQL Server avec disques partagés Azure. Le serveur DPM doit être déployé sur la machine virtuelle Azure pour protéger l'instance FCI SQL déployée sur les machines virtuelles Azure.

Conditions préalables et limitations

Si vous avez une base de données avec des fichiers sur un partage de fichiers distant, la protection échouera avec l’ID d’erreur 104. Data Protection Manager (DPM) ne prend pas en charge la protection des données SQL Server sur un partage de fichiers distant.
DPM ne peut pas protéger les bases de données stockées sur des partages SMB distants.
Assurez-vous que les réplicas de groupe de disponibilité sont configurés en lecture seule.
Vous devez explicitement ajouter le compte système NTAuthority\System au groupe Sysadmin sur SQL Server.
Lorsque vous effectuez une récupération sur l'autre emplacement pour une base de données partiellement autonome, vous devez vous assurer que la fonctionnalité relative aux bases de données autonomes est activée sur l'instance SQL cible.
Lorsque vous effectuez une récupération sur l'autre emplacement pour une base de données de flux de fichiers, vous devez vous assurer que la fonctionnalité relative à la base de données de flux de fichiers est activée sur l'instance SQL cible.
Protection pour SQL Server Always On :
- DPM détecte les groupes de disponibilité lorsqu’une demande de renseignements est exécutée lors de la création d’un groupe de protection.
- DPM détecte un basculement et poursuit la protection de la base de données.
- DPM prend en charge les configurations de cluster multisites d’une instance de SQL Server.
Lorsque vous protégez des bases de données qui utilisent la fonctionnalité Always On, DPM présente les limitations suivantes :
- DPM honorera la stratégie de sauvegarde des groupes de disponibilité définie dans SQL Server en fonction des préférences de sauvegarde, comme suit :
  - Préférer le réplica secondaire : les sauvegardes doivent être effectuées sur un réplica secondaire, sauf lorsque le réplica principal est le seul réplica en ligne. Si plusieurs réplicas secondaires sont disponibles, le nœud ayant la plus haute priorité de sauvegarde sera sélectionné pour la sauvegarde. Si seul le réplica principal est disponible, la sauvegarde doit s’effectuer sur le réplica principal.
  - Secondaire uniquement : la sauvegarde ne doit pas être effectuée sur le réplica principal. Si le réplica principal est le seul réplica en ligne, la sauvegarde ne doit pas s'effectuer.
  - Principal : les sauvegardes doivent toujours s'effectuer sur le réplica principal.
  - Sur n'importe quel réplica : les sauvegardes peuvent s'effectuer sur n'importe quel réplica de disponibilité dans le groupe de disponibilité. Le nœud à sauvegarder dépendra des priorités de sauvegarde pour chacun des nœuds.
  Remarque
  - Les sauvegardes peuvent s’effectuer à partir de n’importe quel réplica lisible, c’est-à-dire un réplica principal, secondaire synchrone ou secondaire asynchrone.
  - Si un réplica est exclus de la sauvegarde, par exemple si Exclure des réplicas est activé ou marqué comme étant non lisible, alors ce réplica ne sera pas sélectionné pour la sauvegarde quelle que soit l'option.
  - Si plusieurs réplicas sont disponibles et lisibles, alors le nœud ayant la plus haute priorité de sauvegarde sera sélectionné pour la sauvegarde.
  - Si la sauvegarde échoue sur le nœud sélectionné, alors l'opération de sauvegarde échoue.
  - La récupération à l'emplacement d'origine n'est pas prise en charge.
Problèmes de sauvegarde avec SQL Server 2014 ou versions ultérieures :
- SQL Server 2014 a ajouté une nouvelle fonctionnalité pour créer une base de données pour une instance SQL Server locale dans le stockage Blob Microsoft Azure. DPM ne peut pas être utilisé pour protéger cette configuration.
- Il existe certains problèmes connus avec la préférence de sauvegarde « Préférer secondaire » pour l’option SQL Always On. DPM effectue toujours une sauvegarde de la base de données secondaire. Si aucune base de données secondaire n’est trouvée, la sauvegarde échoue.

Avant de commencer

Avant de commencer, assurez-vous que vous respectez les conditions préalables pour l’utilisation de Sauvegarde Azure afin de protéger des charges de travail. Voici quelques-unes des tâches préalables :

Créer un coffre de sauvegarde.
Télécharger les informations d’identification du coffre.
Installer l’agent de Sauvegarde Azure.
Inscrire le serveur auprès du coffre.

Créer une stratégie de sauvegarde

Pour protéger des bases de données SQL Server dans Azure, commencez par créer une stratégie de sauvegarde :

Sur le serveur Data Protection Manager (DPM), sélectionnez l’espace de travail Protection.
Sélectionnez Nouveau pour créer un groupe de protection.
Sur la page de démarrage, passez en revue les instructions relatives à la création d'un groupe de protection. Sélectionnez ensuite Suivant.
Sélectionnez Serveurs.
Développez la machine virtuelle SQL Server sur laquelle se trouvent les bases de données que vous souhaitez sauvegarder. Vous accédez aux sources de données qui peuvent être sauvegardées à partir de ce serveur. Développez Tous les partages SQL, puis sélectionnez les bases de données que vous souhaitez sauvegarder. Dans cet exemple, nous sélectionnons ReportServer$MSDPM2012 et ReportServer$MSDPM2012TempDB. Sélectionnez ensuite Suivant.
Nommez le groupe de protection, puis sélectionnez Je souhaite une protection en ligne.
Sur la page Spécifier les objectifs à court terme, incluez les entrées nécessaires à la création de points de sauvegarde sur le disque.

Dans cet exemple, la Période de rétention est définie sur 5 jours. La Fréquence de synchronisation de la sauvegarde est définie sur 15 minutes. La Sauvegarde complète rapide est définie sur 20h00.

Notes

Dans cet exemple, un point de sauvegarde est créé à 20h00 quotidiennement. Les données qui ont été modifiées depuis le point de sauvegarde de la veille à 20h00 sont transférées. Ce processus est appelé Sauvegarde expresse rapide. Bien que les journaux des transactions soient synchronisés toutes les 15 minutes, si nous devons récupérer la base de données à 21h00, le point est créé en relisant les journaux à partir du dernier point de sauvegarde complète rapide, à savoir 20h00 dans cet exemple.
Sélectionnez Suivant. DPM affiche l’espace de stockage global disponible. Il montre également l’utilisation potentielle de l’espace disque.

Par défaut, DPM crée un volume par source de données (base de données SQL Server). Le volume est utilisé pour la copie de sauvegarde initiale. Dans cette configuration, le Gestionnaire de disque logique limite la protection de DPM à 300 sources de données (bases de données SQL Server). Pour contourner cette limitation, sélectionnez Colocaliser les données dans le pool de stockage DPM. Si vous utilisez cette option, DPM utilise un seul volume pour plusieurs sources de données. Cette configuration permet à DPM de protéger jusqu’à 2 000 bases de données SQL Server.

Si vous sélectionnez l’option Augmenter automatiquement les volumes, DPM peut gérer l’augmentation du volume de sauvegarde à mesure que les données de production augmentent. Si vous ne sélectionnez pas l’option Augmenter automatiquement les volumes, DPM limite le stockage de sauvegarde aux sources de données figurant dans le groupe de protection.
Si vous êtes un administrateur, vous pouvez décider de transférer cette sauvegarde initiale Automatiquement sur le réseau et choisir l’heure de transfert. Vous pouvez également choisir de transférer Manuellement la sauvegarde. Sélectionnez ensuite Suivant.

La copie de sauvegarde initiale nécessite le transfert de la totalité de la source de données (base de données SQL Server). Les données de sauvegarde sont déplacées du serveur de production (ordinateur SQL Server) vers le serveur DPM. Si cette sauvegarde est volumineuse, le transfert des données sur le réseau peut entraîner une saturation de la bande passante. Pour cette raison, les administrateurs peuvent choisir d'utiliser des supports amovibles pour transférer la sauvegarde initiale Manuellement. Ils peuvent également transférer les données Automatiquement sur le réseau à une heure spécifiée.

Une fois la sauvegarde initiale terminée, les sauvegardes se poursuivent de façon incrémentielle sur la copie de sauvegarde initiale. Les sauvegardes incrémentielles sont en général très limitées et sont faciles à transférer sur le réseau.
Choisissez quand exécuter une vérification de cohérence. Sélectionnez ensuite Suivant.

DPM peut exécuter une vérification de cohérence sur l’intégrité du point de sauvegarde. Il calcule la somme de contrôle du fichier de sauvegarde sur le serveur de production (ordinateur SQL Server dans cet exemple) et les données sauvegardées pour ce fichier dans DPM. Si la vérification détecte un conflit, le fichier sauvegardé dans DPM est supposé endommagé. DPM corrige les données sauvegardées en envoyant les blocs correspondant à l’incohérence de somme contrôle. La vérification de cohérence étant une opération exigeante en matière de performances, les administrateurs peuvent la planifier ou l’exécuter automatiquement.
Sélectionnez les sources de données à protéger dans Azure. Sélectionnez ensuite Suivant.
Si vous êtes un administrateur, vous pouvez choisir des planifications de sauvegarde et des stratégies de rétention correspondant aux stratégies de votre organisation.

Dans cet exemple, les sauvegardes sont effectuées quotidiennement à 12h00 et 20h00.

Conseil

Pour une récupération rapide, conservez quelques points de récupération à court terme sur votre disque. Ces points de récupération sont utilisés pour la restauration opérationnelle. Azure constitue un bon emplacement hors site, adossé à des contrats de niveau plus avantageux et dont la disponibilité est garantie.

Utilisez DPM pour planifier les sauvegardes Azure après la fin des sauvegardes sur disque local. Lorsque vous suivez cette pratique, la dernière sauvegarde sur disque est copiée sur Azure.
Cliquez sur la planification de stratégie de rétention. Pour plus d'informations sur le fonctionnement de la stratégie de rétention, consultez Utilisation de Sauvegarde Azure pour remplacer votre infrastructure sur bande.

Dans cet exemple :
- les sauvegardes sont effectuées quotidiennement à 12h00 et 20h00. Elles sont conservées pendant 180 jours.
- La sauvegarde du samedi à 12h00 est conservée pendant 104 semaines.
- La sauvegarde du dernier samedi du mois à 12h00 est conservée pendant 60 mois.
- La sauvegarde du dernier samedi de mars à 12h00 est conservée pendant 10 ans.
Après avoir choisi une stratégie de rétention, sélectionnez Suivant.
Choisissez comment transférer la copie de sauvegarde initiale vers Azure.
- L'option Automatiquement sur le réseau suit votre planification de sauvegarde pour transférer les données vers Azure.
- Pour plus d'informations sur la sauvegarde en mode hors connexion, consultez Vue d'ensemble de la sauvegarde hors connexion.
Après avoir choisi un mécanisme de transfert, sélectionnez Suivant.
Sur la page Résumé, examinez les détails de la stratégie. Sélectionnez ensuite Créer un groupe. Vous pouvez sélectionner Fermer et surveiller la progression du travail dans l'espace de travail Surveillance.

Créer des copies de sauvegarde à la demande d'une base de données SQL Server

Un point de récupération est créé lors de la première sauvegarde. Au lieu d'attendre l'exécution de la planification, vous pouvez déclencher manuellement la création d'un point de récupération :

Dans le groupe de protection, assurez-vous que l'état de la base de données est OK.
Cliquez avec le bouton droit sur la base de données, puis sélectionnez Créer un point de récupération.
Dans le menu déroulant, sélectionnez Protection en ligne. Sélectionnez ensuite OK pour démarrer la création d'un point de récupération dans Azure.
Vous pouvez voir la progression du travail dans l'espace de travail Surveillance.

Récupération d'une base de données SQL Server à partir d'Azure

Pour récupérer une entité protégée, telle qu'une base de données SQL Server, à partir d'Azure :

Ouvrez la Console de gestion du serveur DPM. Accédez à l'espace de travail Récupération pour afficher les serveurs que DPM sauvegarde. Sélectionnez la base de données (dans cet exemple, ReportServer$MSDPM2012). Sélectionnez une Heure de récupération qui se termine par En ligne.
Cliquez avec le bouton droit sur le nom de la base de données, puis sélectionnez Récupérer.
DPM affiche les détails du point de récupération. Sélectionnez Suivant. Pour remplacer la base de données, sélectionnez le type de récupération Récupérer l’instance d’origine de SQL Server. Sélectionnez ensuite Suivant.

Dans cet exemple, DPM permet de récupérer la base de données dans une autre instance SQL Server ou dans un dossier réseau autonome.
Dans la page Spécifier les options de récupération, vous pouvez sélectionner les options de récupération. Par exemple, vous pouvez choisir Limitation de l'utilisation de la bande passante réseau pour limiter la bande passante que la récupération utilise. Sélectionnez ensuite Suivant.
Sur la page Résumé, vous voyez la configuration actuelle de la récupération. Sélectionnez Récupérer.

L'état de récupération indique la base de données en cours de récupération. Vous pouvez sélectionner Fermer pour fermer l'Assistant et afficher la progression dans l'espace de travail Surveillance.

Une fois la récupération terminée, la base de données restaurée est cohérente avec l'application.