Sauvegardes automatisées dans Azure SQL Managed Instance

S’applique à :Azure SQL Managed Instance

Cet article décrit la fonctionnalité de sauvegarde automatisée pour Azure SQL Managed Instance.

Pour modifier les paramètres de sauvegarde, consultez Modifier les paramètres. Pour restaurer une sauvegarde, consultez Récupérer à l’aide de sauvegardes de base de données automatisées.

Qu'est-ce que les sauvegardes de base de données automatisées ?

Les sauvegardes de base de données sont une partie essentielle de toute stratégie de continuité d'activité et reprise d'activité, dans la mesure où elles protègent vos données des corruptions et des suppressions. Avec Azure SQL Managed Instance, les sauvegardes du moteur de base de données SQL Server sont automatiquement managées par Microsoft et stockées sur des comptes de stockage Azure managés par Microsoft.

Utilisez ces sauvegardes pour rétablir votre base de données à un point dans le temps spécifique pendant la période de rétention configurée, jusqu'à 35 jours. Cependant, si vos règles de protection des données nécessitent que vos sauvegardes soient disponibles pendant une période prolongée (jusqu'à 10 ans), vous pouvez configurer des stratégies de conservation à long terme (LTR) pour chaque base de données.

Fréquence de sauvegarde

Azure SQL Managed Instance crée les sauvegardes suivantes :

• Sauvegardes complètes toutes les semaines.
• Sauvegardes différentielles toutes les 12 heures.
• Sauvegardes du journal des transactions toutes les 10 minutes environ.

La fréquence des sauvegardes du journal des transactions est basée sur la taille de calcul et le volume d'activité de la base de données. Les journaux des transactions sont pris environ toutes les 10 minutes, mais cela peut varier. Quand vous restaurez une base de données, le service identifie les sauvegardes (complète, différentielle ou du journal des transactions) nécessitant une restauration dans l'ordre respectif.

Redondance du stockage de sauvegarde

Par défaut, Azure SQL Managed Instance stocke les données dans des objets blob de stockage géoredondants qui sont répliqués dans une région jumelée. La géoredondance permet de se protéger contre les pannes affectant le stockage de sauvegarde dans la région primaire. Elle vous permet également de restaurer votre instance dans une autre région en cas de sinistre.

Le mécanisme de redondance de stockage stocke plusieurs copies de vos données afin qu’elles soient protégées contre des événements planifiés et non planifiés. Ces événements peuvent inclure des défaillances matérielles temporaires, des pannes de réseau ou de courant, ou des catastrophes naturelles massives.

Pour vous assurer que vos sauvegardes restent dans la région où votre base de données est déployée, vous pouvez modifier la redondance du stockage de sauvegarde en passant du stockage géoredondant par défaut à d’autres types de stockage qui conservent vos données au sein de la région. Pour en savoir plus sur la redondance du stockage, consultez Redondance du stockage.

Vous pouvez configurer la redondance du stockage de sauvegarde lorsque vous créez votre instance, et la mettre à jour ultérieurement au niveau de l’instance. Les modifications que vous apportez à une instance existante s’appliquent uniquement aux sauvegardes ultérieures. Après avoir mis à jour la redondance du stockage de sauvegarde d’une instance existante, l’application des modifications peut prendre jusqu’à 24 heures. Les modifications apportées à la redondance du stockage de sauvegarde s’appliquent uniquement aux sauvegardes à court terme. Les stratégies de conservation à long terme héritent de l’option de redondance des sauvegardes à court terme lors de la création de la stratégie. L’option de redondance persiste pour les sauvegardes à long terme même si l’option de redondance pour les sauvegardes à court terme change par la suite.

Vous pouvez choisir l’une des redondances de stockage suivantes pour les sauvegardes :

• Stockage localement redondant (LRS) : copie vos sauvegardes de façon synchrone trois fois au sein d’un même emplacement physique dans la région primaire. L’option LRS est la moins coûteuse mais n’est pas recommandée pour des applications nécessitant haute disponibilité et durabilité.

  

• Stockage redondant interzone (ZRS) : copie vos sauvegardes de façon synchrone dans trois zones de disponibilité Azure au sein de la région primaire. L’option ZRS est actuellement disponible dans certaines régions.

  

• Stockage géoredondant (GRS) : copie vos sauvegardes de façon synchrone trois fois au sein d’un même emplacement physique dans la région primaire en utilisant un stockage localement redondant (LRS). Il copie ensuite vos données de façon asynchrone trois fois vers un emplacement physique unique dans la région secondaire associée.

  Le résultat est le suivant :

  • Trois copies synchrones dans la région primaire dans une seule zone de disponibilité.
  • Trois copies synchronisées dans la région jumelée dans une seule zone de disponibilité qui ont été copiées de la région primaire vers la région secondaire de façon asynchrone.

  

• Stockage géo-redondant interzone (GZRS) : combine la haute disponibilité fournie par la redondance entre zones de disponibilité avec la protection contre les pannes régionales assurée par la géo-réplication. Les données dans un compte GZRS sont copiées dans trois zones de disponibilité Azure dans la région primaire. Les données sont également répliquées dans une région géographique secondaire à des fins de protection contre des sinistres régionaux. Dans cette région, vous avez également trois copies synchronisées dans une seule zone de disponibilité qui ont été copiées de la région primaire vers la région secondaire de façon asynchrone.

  

Utilisation de la sauvegarde

Vous pouvez utiliser ces sauvegardes aux fins suivantes :

• Restaurer une base de données existante à un point dans le temps s’inscrivant dans la période de rétention, à l’aide du portail Azure, d’Azure PowerShell, d’Azure CLI ou de l’API REST. Cette opération crée une nouvelle base de données sur la même instance que la base de données d’origine, ou sur une autre instance dans le même abonnement et la même région. Elle utilise un autre nom pour éviter de remplacer la base de données d’origine. Vous pouvez également utiliser le portail Azure pour restaurer votre sauvegarde de base de données à un instant dans le passé sur une instance située dans un autre abonnement que celui de votre instance source.

  Une fois la restauration terminée, vous pouvez supprimer la base de données d’origine. Vous pouvez aussi renommer la base de données d’origine, puis renommer la base de données restaurée avec le nom de la base de données d’origine.

• Restaurer une base de données supprimée à un point dans le temps s’inscrivant dans la période de rétention incluant le temps de suppression. Vous pouvez restaurer la base de données supprimée sur l’instance managée où la sauvegarde a été effectuée, ou sur une autre instance située dans le même abonnement ou un autre abonnement que celui de l’instance source. Avant de supprimer une base de données, le service effectue une sauvegarde finale du journal des transactions afin d’éviter toute perte de données.

• Restaurer une base de données dans une autre région géographique. La géorestauration vous permet de procéder à la récupération après un sinistre géographique lorsque vous ne pouvez pas accéder à votre base de données ou aux sauvegardes dans la région primaire. Cela crée une base de données sur une instance gérée existant(e), dans n’importe quelle région Azure.

  Important

  La géorestauration n’est disponible que pour les bases de données configurées avec un stockage de sauvegarde géoredondant. Si vous n’utilisez pas actuellement de sauvegardes géo-répliquées pour une base de données, vous pouvez modifier cette configuration en configurant la redondance du stockage de sauvegarde.

• Restaurez une base de données à partir d'une sauvegarde à long terme si la base de données a été configurée avec une stratégie de conservation à long terme (LTR). La conservation à long terme (LTR) vous permet de restaurer une version plus ancienne de la base de données à l'aide du portail Azure, d'Azure CLI ou d'Azure PowerShell pour répondre à une requête de conformité ou exécuter une version plus ancienne de l'application. Pour plus d'informations, reportez-vous à la page Présentation de la conservation à long terme.

Capacités et fonctionnalités de restauration

Ce tableau synthétise les capacités et fonctionnalités de la restauration à un instant dans le passé, de la géo-restauration et de la conservation à long terme.

¹ Pour les applications critiques pour l’entreprise qui nécessitent de grosses bases de données et doivent assurer la continuité d’activité, reportez-vous à groupes de basculement.
² Toutes les sauvegardes PITR sont stockées sur un stockage géoredondant par défaut. Par conséquent, la géo-restauration est activée par défaut.
³ Sauvegardes de base de données effectuées à partir d’instances configurées avec la stratégie de mise à jour SQL Server 2022 peuvent être restaurées sur des instances configurées avec la stratégie de mise à jour SQL Server 2022 ou mise à jour permanente. Les sauvegardes de base de données effectuées à partir d’instances configurées avec la stratégie de mise à jour permanente ne peuvent être restaurées que sur des instances également configurées avec la stratégie de mise à jour permanente.
⁴ La solution de contournement consiste à effectuer la restauration sur un nouveau serveur et à utiliser Resource Move pour déplacer le serveur vers un autre abonnement.

Restaurer une base de données à partir d’une sauvegarde

Pour effectuer une restauration, consultez Restaurer une base de données à partir de sauvegardes. Vous pouvez essayer les opérations de configuration et de restauration de sauvegarde à l’aide des exemples suivants.

Planification de sauvegardes automatiques

Azure SQL Managed Instance gère automatiquement les sauvegardes en créant des sauvegardes complètes, différentielles et du journal des transactions. Ce processus est régi par une planification interne.

Sauvegarde initiale

Immédiatement après la création d'une base de données, sa restauration, ou une modification de la redondance des sauvegardes, la première sauvegarde complète est lancée. Cette sauvegarde se termine généralement dans les 30 minutes, même si elle peut prendre plus de temps. La durée de la sauvegarde initiale pour les bases de données restaurées varie et dépend de la taille de la base de données. Les bases de données restaurées ou les copies de base de données plus volumineuses peuvent nécessiter plus de temps pour la sauvegarde initiale.

Sauvegardes complètes planifiées

• Planification hebdomadaire : le système définit une fenêtre de sauvegarde complète hebdomadaire pour l’ensemble de l’instance.
• Fenêtre de sauvegarde complète : il s’agit d’une période désignée lorsque des sauvegardes complètes sont effectuées. Bien que le système vise à effectuer des sauvegardes complètes dans cette fenêtre, la sauvegarde peut, si nécessaire, continuer au-delà de la durée planifiée jusqu’à ce qu’elle se termine.
• Planification adaptative : l’algorithme de sauvegarde évalue l’impact de la fenêtre de sauvegarde sur la charge de travail environ une fois par semaine, en se basant sur l’utilisation de l’UC et du débit d’E/S comme indicateurs. Selon la charge de travail de la semaine précédente, la fenêtre de sauvegarde complète peut être ajustée.
• Configuration utilisateur : il est essentiel de noter que les utilisateurs ne peuvent pas modifier ni désactiver la planification de sauvegarde.

Consommation de stockage de sauvegarde

Avec la technologie de sauvegarde et de restauration de SQL Server, la restauration d’une base de données à un point dans le temps requiert une chaîne de sauvegarde ininterrompue. Cette chaîne est constituée d’une sauvegarde complète, éventuellement d’une sauvegarde différentielle, et d’une ou plusieurs sauvegardes du journal des transactions.

Les planifications de sauvegarde Azure SQL Managed Instance incluent une sauvegarde complète chaque semaine. Pour assurer la restauration à un instant dans le passé pour l’ensemble de la période de conservation, le système doit stocker des sauvegardes supplémentaires complètes, différentielles et du journal des transactions pendant une période plus longue d’une semaine que la période de conservation configurée.

En d’autres termes, pour tout point dans le temps pendant la période de rétention, il doit y avoir une sauvegarde complète antérieure à la période de rétention la plus ancienne. Il doit également y avoir une chaîne ininterrompue de sauvegardes différentielles et du journal des transactions à partir de cette sauvegarde complète jusqu’à la sauvegarde complète suivante.

Les sauvegardes qui ne sont plus nécessaires pour fournir la fonctionnalité PITR sont automatiquement supprimées. Étant donné que les sauvegardes différentielles et les sauvegardes de fichiers journaux requièrent une sauvegarde complète antérieure pour pouvoir être restaurées, les trois types de sauvegardes sont purgés par jeux hebdomadaires.

Pour toutes les bases de données, notamment les bases de données chiffrées TDE, toutes les sauvegardes complètes et différentielles sont compressées afin de réduire les coûts et la compression du stockage de sauvegarde. Le taux moyen de compression des sauvegardes est de 3 à 4 fois. Il peut cependant être sensiblement plus faible ou plus élevé selon la nature des données et l’utilisation ou non d’une compression des données dans la base de données.

SQL Managed Instance calcule votre stockage de sauvegarde total utilisé en tant que valeur cumulée. Toutes les heures, cette valeur est consignée dans le pipeline de facturation Azure. Celui-ci est responsable de l’agrégation de cette utilisation horaire afin de calculer votre consommation à la fin de chaque mois. Une fois la base de données supprimée, la consommation diminue à mesure que les sauvegardes vieillissent et sont supprimées. Une fois que toutes les sauvegardes ont été supprimées et que la restauration à un instant dans le passé (PITR) n’est plus possible, la facturation s’arrête.

Ajuster la consommation de stockage de sauvegarde

La consommation du stockage de sauvegarde jusqu'à la taille maximale des données pour une base de données n'est pas facturée. Une consommation de stockage de sauvegarde excessive dépend de la charge de travail et de la taille maximale des bases de données individuelles. Envisagez les diverses techniques d’ajustement suivantes pour réduire votre consommation de stockage de sauvegarde :

• Réduisez la période de rétention des sauvegardes des bases de données au minimum compte tenu de vos besoins.
• Évitez d’effectuer des opérations d’écriture volumineuses telles que des reconstructions d’index plus qu’il n’est nécessaire.
• Pour les opérations de chargement de données volumineuses, envisagez d’utiliser des index columnstore en cluster et de suivre les meilleures pratiques connexes. Envisagez également de réduire le nombre d'index non cluster.
• Au niveau de service Usage général, le stockage de données provisionné est moins onéreux que le prix du stockage de sauvegarde. Si vos coûts de stockage de sauvegarde sont sans cesse excessifs, vous pouvez envisager d’augmenter le stockage de données afin de réaliser des économies sur le stockage de sauvegarde.
• Utilisez tempdb au lieu de tables permanentes dans votre logique d’application pour le stockage des résultats ou des données temporaires.
• Utilisez le stockage de sauvegarde localement redondant chaque fois que cela est possible (par exemple, environnements de développement/test).

Rétention des sauvegardes

Azure SQL Managed Instance fournit une rétention à court et long terme des sauvegardes. La rétention à court terme permet une restauration à un instant dans le passé (PITR) s’inscrivant dans la période de rétention de la base de données. La conservation à long terme fournit des sauvegardes répondant à diverses exigences de conformité.

Durée de rétention à court terme

Pour toutes les bases de données nouvelles, restaurées et copiées, Azure SQL Managed Instance conserve des sauvegardes suffisantes pour autoriser la restauration à un instant dans le passé (PITR) s’inscrivant dans les 7 derniers jours par défaut. Cette configuration peut être modifiée dans une plage de 1 à 35 jours. Le service effectue des sauvegardes complètes, différentielles et de journal régulières sont effectuées pour garantir que les bases de données peuvent être restaurées à n’importe quel point dans le temps de la période de rétention définie pour la base de données ou l’instance gérée.

Vous pouvez spécifier votre option de redondance du stockage de sauvegarde pour conservation à court terme (STR) lorsque vous créez votre instance, puis la modifier ultérieurement. Si vous modifiez votre option de redondance de sauvegarde une fois votre instance créée, les nouvelles sauvegardes utilisent la nouvelle option de redondance. Les copies de sauvegarde effectuées avec l'option de redondance de conservation à court terme (STR) précédente ne sont pas déplacées ou copiées. Elles sont laissées dans le compte de stockage d'origine jusqu'à ce que la période de rétention expire. Comme décrit dans Consommation du stockage de sauvegarde, les sauvegardes stockées pour activer la restauration à un instant dans le passé (PITR) peuvent être antérieures à la période de rétention pour assurer une restauration des données précise.

Si vous supprimez une base de données, le système conserve les sauvegardes de la même façon que pour une base de données en ligne avec sa période de rétention spécifique. Toutefois, pour une base de données supprimée, la période de rétention est mise à jour, passant de la fourchette 1 à 35 jours à un fourchette 0 à 35 jours, permettant de supprimer des sauvegardes manuellement. Si vous avez besoin de conserver les sauvegardes pendant plus longtemps que la période de rétention à court terme maximale de 35 jours, vous pouvez activer la conservation à long terme.

Conservation à long terme (LTR)

Avec SQL Managed Instance, vous pouvez configurer des sauvegardes de conservation à long terme (LTR) jusqu'à 10 ans dans un Stockage Blob Azure. Si la stratégie de conservation à long terme est activée, les sauvegardes complètes sont automatiquement copiées vers un autre conteneur de stockage.

Pour répondre aux diverses exigences de conformité, vous pouvez sélectionner plusieurs périodes de rétention pour les sauvegardes complètes hebdomadaires, mensuelles et/ou annuelles. La fréquence dépend de la stratégie. Par exemple, le paramétrage de W=0, M=1, Y=0 créerait une copie de conservation à long terme (LTR) mensuelle. Pour plus d’informations sur la conservation à long terme, consultez Conservation à long terme.

La redondance du stockage de sauvegarde de conservation à long terme (LTR) dans Azure SQL Managed Instance est héritée de la redondance du stockage de sauvegarde utilisée par la conservation à court terme (STR) au moment où la stratégie LTR est définie. Vous ne pouvez pas la modifier, même si la redondance du stockage de sauvegarde pour conservation à court terme (STR) change à l’avenir.

La consommation du stockage dépend de la fréquence sélectionnée des sauvegardes LTR et des périodes de conservation. Vous pouvez utiliser la calculatrice de prix LTR pour estimer le coût du stockage de conservation à long terme.

Coûts du stockage de sauvegarde

SQL Managed Instance calcule votre stockage de sauvegarde total facturable en tant que valeur cumulée pour tous les fichiers de sauvegarde. Toutes les heures, cette valeur est consignée dans le pipeline de facturation Azure. Le pipeline qui agrège cette utilisation horaire afin d’obtenir votre consommation de stockage de sauvegarde à la fin de chaque mois.

Si une base de données est supprimée, la consommation de stockage de sauvegarde diminue progressivement à mesure que les sauvegardes plus anciennes vieillissent et sont supprimées. Étant donné que les sauvegardes différentielles et les sauvegardes de fichiers journaux requièrent une sauvegarde complète antérieure pour pouvoir être restaurées, les trois types de sauvegardes sont purgés par jeux hebdomadaires. Une fois toutes les sauvegardes supprimées, la facturation s’arrête.

Le prix du stockage de sauvegarde varie. Il dépend de l’option de redondance de stockage de sauvegarde que vous avez choisie et de votre région. Le stockage de sauvegarde est facturé sur la base des gigaoctets consommés par mois, au même taux pour toutes les sauvegardes.

La redondance du stockage de sauvegarde influe sur les coûts de sauvegarde de la façon suivante :

• Locally redundant price = published price
• Zone-redundant price = published price x 1.25
• Geo-redundant price = published price x 2
• Geo-zone-redundant price = published price x 3.4

Pour la tarification, consultez la page Tarification d’Azure SQL Managed Instance.

Pour les instances gérées, la taille totale du stockage de sauvegarde facturable est agrégée au niveau de l’instance, et calculée comme suit :

Total billable backup storage size = (total size of full backups + total size of differential backups + total size of log backups) – maximum instance data storage

Le stockage de sauvegarde facturable total, le cas échéant, est facturé en gigaoctets par mois pour chaque région, en fonction du taux de redondance du stockage de sauvegarde que vous avez utilisé. La consommation du stockage de sauvegarde dépend de la charge de travail et de la taille des bases de données et des instances gérées individuelles. Les bases de données fortement modifiées ont des sauvegardes différentielles et de fichier journal plus volumineuses, car la taille de ces sauvegardes est proportionnelle à la quantité de données modifiées. Par conséquent, ces bases de données ont des frais de sauvegarde plus élevés.

À titre d’exemple simplifié, supposons qu’une base de données ait accumulé 744 Go de stockage de sauvegarde et que cette quantité reste constante pendant un mois entier, car la base de données est complètement inactive. Pour convertir cette consommation de stockage cumulée en une utilisation horaire, nous la divisons par 744,0 (31 jours de 24 heures par mois). SQL Managed Instance signale au pipeline de facturation Azure que la base de données a consommé 1 Go de sauvegarde pour la restauration à un instant dans le passé (PITR) chaque heure, à un taux constant. La facturation Azure agrège cette consommation et affiche une utilisation de 744 Go pour le mois. Le coût est basé sur le tarif des gigaoctets par mois dans votre région.

Voici un autre exemple. Supposons que pour la même base de données inactive, la rétention est passée de 7 à 14 jours au milieu du mois. Cette augmentation entraîne un doublement du stockage total de sauvegarde, qui passe à 1 488 Go. SQL Managed Instance signale 1 Go d’utilisation pour les heures 1 à 372 (la première moitié du mois). Il signale l’utilisation de 2 Go pour les heures 373 à 744 (la deuxième moitié du mois). L’agrégation de cette utilisation aboutit à une facturation finale de 1,116 Go par mois. Les coûts de conservation n’augmentent pas immédiatement. Ils augmentent progressivement chaque jour, car les sauvegardes augmentent jusqu’à la fin de la période de rétention maximale de 14 jours.

Les scénarios de facturation de sauvegarde réels sont plus complexes. Étant donné que le taux de modifications dans la base de données dépend de la charge de travail et varie au fil du temps, la taille de chaque sauvegarde différentielle et de journal varie également. La consommation horaire de stockage de sauvegarde fluctue en conséquence.

Chaque sauvegarde différentielle contient également toutes les modifications apportées à la base de données depuis la dernière sauvegarde complète. Ainsi, la taille totale de toutes les sauvegardes différentielles augmente progressivement au cours d’une semaine. Elle chute ensuite brutalement quand un ensemble plus ancien de sauvegardes complètes, différentielles et de journal arrive à expiration.

Par exemple, supposons qu’une activité d’écriture intensive, telle qu’une régénération d’index, s’exécute juste après une sauvegarde complète. Les modifications apportées par la régénération d’index sont alors incluses :

• dans les sauvegardes du journal des transactions effectuées pendant la durée de la régénération ;
• dans la sauvegarde différentielle suivante ;
• dans chaque sauvegarde différentielle effectuée jusqu’à la sauvegarde complète suivante.

Pour réduire la taille de toutes les sauvegardes différentielles, les sauvegardes différentielles trop volumineuses qui dépassent 750 Go et deviennent égales à 75 % de la taille de la base de données sont promues en sauvegardes complètes, si la dernière sauvegarde complète a été effectuée il y a plus de 24 heures.

Superviser les coûts

Pour comprendre les coûts de stockage des sauvegardes, accédez à Gestion des coûts + Facturation dans le portail Azure. Sélectionnez Gestion des coûts, puis Analyse du coût. Sélectionnez l’abonnement souhaité comme Étendue, puis filtrez la période et le service qui vous intéressent, comme suit :

1. Ajoutez un filtre pour Nom du service.

2. Dans la liste déroulante, sélectionnez sql managed Instance pour une instance gérée.

3. Ajoutez un autre filtre pour Sous-catégorie du compteur.

4. Pour surveiller les coûts de sauvegarde pour restauration à un instant dans le passé (PITR), dans la liste déroulante, sélectionnez stockage de sauvegarde pitr d’instance gérée. Des compteurs s'affichent uniquement en cas de consommation du stockage de sauvegarde.

   Pour surveiller les coûts de sauvegarde pour conservation à long terme (LTR), dans la liste déroulante, sélectionnez stockage de sauvegarde ltr d’instance gérée. Des compteurs s'affichent uniquement en cas de consommation du stockage de sauvegarde.

Les sous-catégories Stockage et Calcul peuvent également vous intéresser, mais elles ne sont pas associées à des coûts de stockage de sauvegarde.

Sauvegardes chiffrées

Si votre base de données est chiffrée à l’aide de TDE, les sauvegardes sont automatiquement chiffrées au repos, y compris les sauvegardes LTR. Par défaut, TDE est activé sur toutes les nouvelles bases de données dans Azure SQL. Pour plus d’informations sur TDE, consultez Chiffrement transparent des données avec SQL Managed Instance.

Microsoft est tenu entièrement responsable de la conservation et de la rotation des clés pour les bases de données avec des clés gérées par le service (SMK). Les sauvegardes, qu’elles soient PITR ou LTR, extraites d’instances avec TDE et SMK activées peuvent être rétablies par Microsoft.

Les sauvegardes automatiques stockées dans des comptes de stockage managés par Azure sont automatiquement chiffrées par stockage Azure. Apprenez-en plus sur la fonctionnalité de chiffrement des données au repos de Stockage Azure.

Intégrité de la sauvegarde

Toutes les sauvegardes de base de données sont effectuées avec l’option CHECKSUM pour fournir une intégrité de sauvegarde supplémentaire. Les tests automatiques des sauvegardes de base de données automatisées par l'équipe d'ingénierie Azure SQL ne sont actuellement pas disponibles pour Azure SQL Managed Instance. Planifiez une restauration de sauvegarde test et DBCC CHECKDB sur vos bases de données dans SQL Managed Instance autour de votre charge de travail.

Bien que le système ne vérifie pas l'intégrité des sauvegardes, il existe toujours une protection intégrée de vos sauvegardes qui alerte Microsoft en cas de problème avec le service de sauvegarde. En outre, Microsoft vous vient en aide si un problème se produit avec une sauvegarde, par exemple si une sauvegarde complète n'est pas effectuée, si le service de sauvegarde est bloqué, si une sauvegarde de fichier journal est hors contrat SLA ou si le matériel de sauvegarde ou le logiciel est endommagé.

Utiliser Azure Policy pour appliquer la redondance du stockage de sauvegarde

Si vous avez des besoins de résidence des données qui vous obligent à conserver toutes vos données dans une seule région Azure, vous pouvez appliquer des sauvegardes redondantes interzones ou localement redondantes pour votre instance gérée SQL à l’aide d’Azure Policy.

Azure Policy est un service que vous pouvez utiliser pour créer, attribuer et gérer des stratégies qui appliquent des règles à des ressources Azure. Lorsque vous utilisez Azure Policy, ces ressources restent conformes à vos normes d’entreprise et contrats de niveau de service. Pour plus d’informations, consultez Vue d’ensemble d’Azure Policy.

Stratégies intégrées de redondance du stockage de sauvegarde

Pour appliquer les exigences de résidence des données au niveau de l’organisation, vous pouvez attribuer des stratégies à un abonnement en utilisant le portail Azure ou Azure PowerShell. Par exemple, si vous attribuez la stratégie intégrée suivante au niveau d’un abonnement ou d’un groupe de ressources, les utilisateurs de l’abonnement ne pourront pas créer d’instance gérée avec un stockage de sauvegarde géoredondant via le portail Azure ou Azure PowerShell : Les instances gérées SQL doivent éviter d’utiliser la redondance de sauvegarde de stockage géoredondant (GRS).

Pour obtenir la liste complète des définitions de stratégie intégrées pour SQL Managed Instance, consultez la Référence de stratégie.

Conformité

Si la conservation par défaut ne répond pas à vos exigences de conformité, vous pouvez modifier la période de conservation PITR. Pour plus d’informations, consultez Modifier la période de rétention des sauvegardes PITR.

Étapes suivantes

• Vue d’ensemble de la continuité des activités
• Gestion de la rétention des sauvegardes à long terme à l'aide du Portail Azure
• Récupérer à l'aide de sauvegardes de base de données automatisées
• Explication de la consommation du stockage de sauvegarde sur SQL Managed Instance
• Ajustement des coûts de stockage de sauvegarde sur SQL Managed Instance