Partager via


Configuration de la sauvegarde managée de SQL Server sur Azure pour les groupes de disponibilité

Cette rubrique est un tutoriel sur la configuration de SQL Server sauvegarde managée sur Microsoft Azure pour les bases de données participant à des groupes de disponibilité AlwaysOn.

Configurations de groupe de disponibilité

SQL Server sauvegarde managée sur Microsoft Azure est prise en charge pour les bases de données de groupe de disponibilité, que les réplicas soient tous configurés localement ou entièrement sur Azure, ou qu’il s’agisse d’une implémentation hybride entre des machines virtuelles locales et sur une ou plusieurs machines virtuelles Azure. Cependant, tenez compte des éléments suivants pour une ou plusieurs implémentations :

  • Fréquence de sauvegarde du journal : la fréquence de sauvegarde du fichier journal dépend de la croissance du journal au cours d'une plage de temps déterminée. Par exemple, la sauvegarde de fichier journal est effectuée une fois toutes les 2 heures sauf si l'espace de journal utilisé pendant la période de 2 heures est de 5 Mo ou plus. Ceci s'applique à toutes les implémentations, locales, dans le cloud, ou hybrides.

  • Bande passante réseau : cela s’applique aux implémentations où les réplicas se trouvent à différents emplacements physiques, comme dans un cloud hybride, ou dans différentes régions Azure dans une configuration cloud uniquement. La bande passante réseau peut affecter la latence des serveurs secondaires, et si les serveurs secondaires sont configurés avec la réplication synchrone, cela peut entraîner une croissance du journal sur le serveur principal. Si les serveurs secondaires utilisent la réplication synchrone, il est possible qu'ils n'arrivent pas à garder le pas en raison du temps de réponse du réseau, ce qui peut entraîner une perte de données en cas de basculement vers le réplica secondaire.

Configuration de SQL Server sauvegarde managée sur Microsoft Azure pour les bases de données de disponibilité.

Autorisations :

  • Nécessite l’appartenance à db_backupoperator rôle de base de données, avec des autorisations ALTER ANY CREDENTIAL et EXECUTE des autorisations sur sp_delete_backuphistoryprocédure stockée.

  • Nécessite des autorisations SELECT sur la fonction smart_admin.fn_get_current_xevent_settings.

  • Nécessite EXECUTE des autorisations sur la procédure stockée smart_admin.sp_get_backup_diagnostics . En outre, nécessite les autorisations VIEW SERVER STATE, car elle appelle en interne d'autres objets système qui nécessitent cette autorisation.

  • Nécessite des EXECUTE autorisations sur les smart_admin.sp_set_instance_backup procédures stockées et .smart_admin.sp_backup_master_switch

Voici les étapes de base de la configuration d’un groupe de disponibilité AlwaysOn avec SQL Server sauvegarde managée sur Microsoft Azure. Un didacticiel pas à pas détaillé est décrit plus loin dans cette rubrique.

  1. Une fois que vous avez créé le groupe de disponibilité, configurez le réplica de sauvegarde par défaut. Ce paramètre pour le groupe de disponibilité est également utilisé par SQL Server sauvegarde managée sur Microsoft Azure pour déterminer les réplica à utiliser pour la sauvegarde. Pour obtenir des instructions pas à pas sur la configuration de la préférence de sauvegarde, consultez Configurer la sauvegarde sur les réplicas de disponibilité (SQL Server). Si vous créez un groupe de disponibilité AlwaysOn, consultez Prise en main avec les groupes de disponibilité AlwaysOn (SQL Server).

  2. Configurez l'accès à la connexion en lecture seule sur les réplicas secondaires. Pour obtenir des instructions pas à pas sur la configuration de l’accès en lecture seule, consultez Configurer l’accès Read-Only sur un réplica de disponibilité (SQL Server)

  3. Spécifiez le réplica de sauvegarde. Le paramètre de réplica de sauvegarde par défaut est utilisé par SQL Server Sauvegarde managée sur Microsoft Azure pour déterminer la base de données à partir de laquelle planifier les sauvegardes.. Pour déterminer si le réplica actuel est le réplica de sauvegarde par défaut, utilisez la fonction sys.fn_hadr_backup_is_preferred_replica (Transact-SQL).

  4. Sur chaque réplica exécutez SQL Server sauvegarde managée sur la configuration Microsoft Azure pour la base de données à l’aide de la procédure stockée smart-admin.sp_set_db_backup.

    SQL Server comportement de la sauvegarde managée sur Microsoft Azure après un basculement : SQL Server sauvegarde managée sur Microsoft Azure continuera de fonctionner et de gérer les copies de sauvegarde et la récupération après un événement de basculement. Aucune action spécifique n'est requise après un basculement.

Conditions requises et éléments à prendre en compte :

La configuration de SQL Server sauvegarde managée sur Microsoft Azure pour les bases de données participant au groupe de disponibilité AlwaysOn nécessite des considérations et des exigences spécifiques. Voici la liste des éléments à prendre en considération et des conditions requises :

  • Les paramètres de configuration SQL Server Sauvegarde managée sur Microsoft Azure doivent être les mêmes pour toutes les bases de données sur tous les nœuds de SQL Server participant au même groupe de disponibilité. Pour ce faire, vous pouvez définir les mêmes SQL Server sauvegarde managée sur les configurations Microsoft Azure pour le réplica principal et tous les réplicas au niveau de la base de données, ou en définissant les mêmes paramètres par défaut SQL Server Sauvegarde managée sur Microsoft Azure sur tous les nœuds participant aux groupes de disponibilité. Nous vous recommandons de définir SQL Server sauvegarde managée sur Microsoft Azure sur la base de données, car la configuration de SQL Server sauvegarde managée sur Microsoft Azure au niveau de la base de données vous permet d’isoler les paramètres des bases de données et les modifications apportées aux paramètres par défaut affectent toutes les autres bases de données sur le instance.

  • Spécifiez le réplica de sauvegarde. Le paramètre de réplica de sauvegarde par défaut est utilisé par SQL Server Sauvegarde managée sur Microsoft Azure pour planifier les sauvegardes. Pour déterminer si le réplica actuel est le réplica de sauvegarde par défaut, utilisez la fonction sys.fn_hadr_backup_is_preferred_replica (Transact-SQL).

  • Si le réplica secondaire est configuré comme réplica par défaut, il doit avoir au moins un accès à la connexion en lecture seule. Les groupes de disponibilité qui n'ont pas d'accès à la connexion sur les bases de données secondaires ne sont pas pris en charge. Pour plus d’informations, consultez Configurer l’accès en lecture seule sur un réplica de disponibilité (SQL Server).

  • Si vous configurez SQL Server sauvegarde managée sur Microsoft Azure après avoir configuré le groupe de disponibilité, SQL Server Sauvegarde managée sur Microsoft Azure tente de copier les sauvegardes existantes basées et de les copier dans le conteneur de stockage. Si SQL Server sauvegarde managée sur Microsoft Azure ne parvient pas à trouver ou à accéder aux sauvegardes existantes, il planifie une sauvegarde complète de la base de données. Cela vise précisément à optimiser les opérations de sauvegarde pour les bases de données d'un groupe de disponibilité.

  • Vous pouvez envisager de désactiver les paramètres de niveau instance si vous créez une base de données de disponibilité et que vous n’avez pas l’intention d’appliquer les paramètres de niveau instance à la base de données

  • Lorsque vous utilisez le chiffrement, utilisez le même certificat sur tous les réplicas. Cela permet des opérations de sauvegarde continues et ininterrompues en cas de basculement ou de restauration sur un réplica différent.

Activer et configurer SQL Server sauvegarde managée sur Microsoft Azure pour une base de données de disponibilité

Ce tutoriel décrit les étapes permettant d’activer et de configurer SQL Server sauvegarde managée sur Microsoft Azure pour une base de données (AGTestDB) sur les ordinateurs Node1 et Node2, suivies des étapes permettant d’activer la surveillance de la SQL Server sauvegarde managée sur microsoft Azure health status.

  1. Créez un compte de stockage Azure : Les sauvegardes sont stockées dans le service stockage Blob Azure. Vous devez d’abord créer un compte de stockage Azure, si vous n’en avez pas déjà un. Pour plus d’informations, consultez Création d’un compte de stockage Azure. Notez le nom du compte de stockage, les clés d'accès et l'URL du compte de stockage. Le nom du compte de stockage et les informations de clé d'accès sont utilisés pour créer un objet contenant les informations d'identification SQL. Les informations d’identification SQL sont utilisées par SQL Server sauvegarde managée sur Microsoft Azure pendant les opérations de sauvegarde pour s’authentifier auprès du compte de stockage.

  2. Créez des informations d’identification SQL : Créez des informations d’identification SQL en utilisant le nom du compte de stockage comme identité et la clé d’accès au stockage comme mot de passe.

  3. Vérifiez que le service SQL Server Agent est démarré et exécuté : Démarrez SQL Server Agent s’il n’est pas exécuté actuellement. Sauvegarde managée SQL Server sur Microsoft Azure nécessite l'exécution de SQL Server Agent sur l'instance pour effectuer les opérations de sauvegarde. Vous pouvez configurer l'exécution automatique de l'Agent SQL, pour vous assurer que les opérations de sauvegarde se déroulent régulièrement.

  4. Déterminez la période de rétention : Déterminez la période de rétention souhaitée pour les fichiers de sauvegarde. La période de rétention est spécifiée en jours, sur une plage de 1 à 30. Elle détermine le délai de récupérabilité de la base de données.

  5. Créez un certificat ou une clé asymétrique à utiliser pour le chiffrement pendant la sauvegarde : Créez le certificat sur le premier nœud Node1, puis exportez-le dans un fichier à l’aide de BACKUP CERTIFICATE (Transact-SQL).. Sur le nœud 2, créez un certificat en utilisant le fichier exporté du nœud 1. Pour plus d’informations sur la création d’un certificat à partir d’un fichier, consultez l’exemple dans CREATE CERTIFICATE (Transact-SQL).

  6. Activer et configurer SQL Server sauvegarde managée sur Microsoft Azure pour AGTestDB sur Node1 : démarrez SQL Server Management Studio et connectez-vous au instance sur Node1 où la base de données de disponibilité est installée. Dans la fenêtre de requête, exécutez l'instruction suivante après avoir modifié les valeurs du nom de la base de données, de l'URL de stockage, des informations d'identification SQL et de la période de rétention selon vos besoins.

    Use msdb;  
    GO  
    EXEC smart_admin.sp_set_db_backup   
                    @database_name='AGTestDB'   
                    ,@retention_days=30   
                    ,@credential_name='MyCredential'  
                    ,@encryption_algorithm ='AES_128'  
                    ,@encryptor_type= 'Certificate'  
                    ,@encryptor_name='MyBackupCert'  
                    ,@enable_backup=1;  
    GO  
    

    Pour plus d’informations sur la création d’un certificat pour le chiffrement, consultez l’étape Créer un certificat de sauvegarde dans Créer une sauvegarde chiffrée.

  7. Activer et configurer SQL Server sauvegarde managée sur Microsoft Azure pour AGTestDB sur Node2 : démarrez SQL Server Management Studio et connectez-vous au instance sur Node2 où la base de données de disponibilité est installée. Dans la fenêtre de requête, exécutez l'instruction suivante après avoir modifié les valeurs du nom de la base de données, de l'URL de stockage, des informations d'identification SQL et de la période de rétention selon vos besoins.

    Use msdb;  
    GO  
    EXEC smart_admin.sp_set_db_backup   
                    @database_name='AGTestDB'   
                    ,@retention_days=30   
                    ,@credential_name='MyCredential'  
                    ,@encryption_algorithm ='AES_128'  
                    ,@encryptor_type= 'Certificate'  
                    ,@encryptor_name='MyBackupCert'  
                    ,@enable_backup=1;  
    GO  
    

    Sauvegarde managée SQL Server sur Microsoft Azure est maintenant activée sur la base de données spécifiée. Un délai de 15 minutes au maximum peut être nécessaire pour le démarrage des opérations de sauvegarde sur la base de données. La sauvegarde aura lieu sur le réplica de sauvegarde par défaut.

  8. Passez en revue la configuration par défaut des événements étendus : Passez en revue la configuration de l’événement étendu en exécutant l’instruction transact-SQL suivante sur le réplica que SQL Server Sauvegarde managée sur Microsoft Azure utilise pour planifier les sauvegardes. Il s'agit généralement des paramètres du réplica de sauvegarde par défaut pour le groupe de disponibilité auquel appartient la base de données.

    SELECT * FROM smart_admin.fn_get_current_xevent_settings(); 
    

    Vous devez voir que les événements de canal Administration, opérationnels et analytiques sont activés par défaut et ne peuvent pas être désactivés. Cela est en principe suffisant pour surveiller les événements qui nécessitent une intervention manuelle. Vous pouvez activer les événements de débogage, mais ces canaux incluent des événements d’information et de débogage que SQL Server sauvegarde managée sur Microsoft Azure utilise pour détecter les problèmes et les résoudre. Pour plus d’informations, consultez Surveiller SQL Server sauvegarde managée sur Azure.

  9. Activez et configurez les notifications de l’état d’intégrité : Sauvegarde managée SQL Server sur Microsoft Azure fournit une procédure stockée qui crée un travail d’agent pour envoyer des notifications par e-mail des erreurs ou des avertissements susceptibles de nécessiter une intervention. Pour recevoir ces notifications, vous devez activer l'exécution de la procédure stockée qui crée un travail SQL Server Agent. Les étapes suivantes décrivent la procédure d'activation et de configuration des notifications par courrier électronique :

    1. Configurez la messagerie de base de données si elle n'est pas déjà activée sur l'instance. Pour plus d'informations, consultez Configure Database Mail.

    2. Configurez la notification SQL Server Agent afin qu'elle utilise la messagerie de base de données. Pour plus d’informations, consultez Configurer la messagerie de SQL Server Agent en vue de l’utilisation de la messagerie de base de données.

    3. Activez les notifications par e-mail afin de recevoir les erreurs de sauvegarde et les avertissements : Dans la fenêtre de requête, exécutez les instructions Transact-SQL suivantes :

      EXEC msdb.smart_admin.sp_set_parameter  
      @parameter_name = 'SSMBackup2WANotificationEmailIds',  
      @parameter_value = '<email>'  
      

      Pour plus d’informations et un exemple de script complet, consultez Surveiller SQL Server sauvegarde managée sur Azure.

  10. Affichez les fichiers de sauvegarde dans le compte stockage Azure : Connectez-vous au compte de stockage à partir de SQL Server Management Studio ou du portail de gestion Azure. Vous verrez un conteneur pour le instance de SQL Server qui héberge la base de données que vous avez configurée pour utiliser SQL Server sauvegarde managée sur Microsoft Azure. Vous pouvez également voir une base de données et une sauvegarde de journal dans les 15 minutes suivant l’activation de SQL Server sauvegarde managée sur Microsoft Azure pour la base de données.

  11. Surveiller l’état d’intégrité : Vous pouvez surveiller via les notifications par e-mail que vous avez configurées précédemment, ou surveiller activement les événements enregistrés. Voici quelques exemples d'instructions Transact SQL utilisées pour afficher les événements :

    --  view all admin events  
    Use msdb;  
    Go  
    DECLARE @startofweek datetime  
    DECLARE @endofweek datetime  
    SET @startofweek = DATEADD(Day, 1-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP)   
    SET @endofweek = DATEADD(Day, 7-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP)  
    
    DECLARE @eventresult TABLE  
    (event_type nvarchar(512),  
    event varchar (512),  
    timestamp datetime  
    )  
    
    INSERT INTO @eventresult  
    
    EXEC smart_admin.sp_get_backup_diagnostics @begin_time = @startofweek, @end_time = @endofweek  
    
    SELECT * from @eventresult  
    WHERE event_type LIKE '%admin%'  
    
    -- to enable debug events  
    Use msdb;  
    Go  
    EXEC smart_admin.sp_set_parameter 'FileRetentionDebugXevent', 'True'  
    
    --  View all events in the current week  
    Use msdb;  
    Go  
    DECLARE @startofweek datetime  
    DECLARE @endofweek datetime  
    SET @startofweek = DATEADD(Day, 1-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP)   
    SET @endofweek = DATEADD(Day, 7-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP)  
    
    EXEC smart_admin.sp_get_backup_diagnostics @begin_time = @startofweek, @end_time = @endofweek;  
    

Les étapes de cette section sont propres à la configuration initiale de la Sauvegarde managée SQL Server sur Microsoft Azure sur la base de données. Vous pouvez modifier les configurations existantes à l’aide de la même procédure stockée système smart_admin.sp_set_db_backup et fournir les nouvelles valeurs. Pour plus d’informations, consultez SQL Server Sauvegarde managée sur Azure - Paramètres de rétention et de stockage.

Éléments à prendre en considération lors de la suppression d'une base de données de la configuration d'un groupe de disponibilité AlwaysOn

Si une base de données est supprimée de la configuration du groupe de disponibilité AlwaysOn et qu’elle est désormais une base de données autonome, nous vous recommandons d’effectuer une sauvegarde à l’aide de smart_admin.sp_backup_on_demand (Transact-SQL). Lorsque vous créez une sauvegarde de base de données de cette façon, une nouvelle chaîne de sauvegarde est établie et le fichier est placé dans le instance conteneur spécifique, par opposition au conteneur de disponibilité où les sauvegardes ont été stockées lorsque la base de données faisait partie du groupe de disponibilité.

Avertissement

Dans ce scénario, la récupérabilité de la base de données à partir de sauvegardes antérieures à la modification de l'état du groupe de disponibilité n'est pas garantie.