Sauvegardes automatisées dans Azure SQL Managed Instance

S’applique à : Azure SQL Managed Instance

• Azure SQL Database
• 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.

Attention

Les sauvegardes complètes automatiques sont initialisées une fois par semaine en fonction d’une planification déterminée par Microsoft. Les sauvegardes initialisées par l’utilisateur ont la priorité sur les sauvegardes complètes automatiques. Par conséquent, une sauvegarde de copie durable uniquement peut affecter le moment de la sauvegarde complète automatique suivante.

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.

Remarque

La modification de la redondance de sauvegarde est une opération de gestion des mises à jour qui initialise un basculement.

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.

  

Avertissement

• La géo-restauration est désactivée dès qu’une base de données est mise à jour pour utiliser un stockage localement redondant ou redondant interzone.
• Les diagrammes de redondance du stockage montrent tous des régions avec plusieurs zones de disponibilité (multi-az). Toutefois, certaines régions ne fournissent qu'une seule zone de disponibilité et ne prennent pas en charge les stockages redondant interzone (ZRS) ou géo-redondant interzone (GZRS).

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.

Propriétés de sauvegarde	Restauration à un instant dans le passé	La géorestauration	LTR
Types de sauvegardes SQL	Sauvegardes complètes, différentielles et du journal des transactions.	Copies répliquées des sauvegardes avec récupération jusqu`à une date et heure.	Sauvegardes complètes uniquement.
Objectif de point de récupération (RPO)	Environ 10 minutes selon la taille de calcul et le volume d'activité de la base de données.	Jusqu’à 1 heure en fonction de la géoréplication. 1	Une semaine (ou stratégie de l’utilisateur).
Objectif de délai de récupération (RTO)	La restauration prend généralement moins de 12 heures, mais elle peut prendre plus de temps selon la taille et l’activité. Consultez Temps de récupération.	La restauration prend généralement moins de 12 heures, mais elle peut prendre plus de temps selon la taille et l’activité. Consultez Temps de récupération.	La restauration prend généralement moins de 12 heures, mais elle peut prendre plus de temps selon la taille et l’activité. Consultez Temps de récupération.
Rétention	1 à 35 jours.	Activée par défaut, identique à la source. 2	Désactivé par défaut. Rétention jusqu’à 10 ans.
Azure Storage	Géoredondant par défaut. Vous pouvez configurer un stockage localement redondant ou redondant interzone.	Disponible quand la redondance du stockage de sauvegarde avec récupération jusqu’à une date et heure est définie comme géoredondante. Non disponible quand le stockage de sauvegarde avec restauration à un instant dans le passé est localement redondant ou redondant interzone.	Géoredondant par défaut. Vous pouvez configurer un stockage localement redondant ou redondant interzone.
Configurer des sauvegardes comme immuables	Non pris en charge	Non pris en charge	Non pris en charge
Mettre à jour la stratégie3	Doit correspondre ou mettre à niveau	Doit correspondre ou mettre à niveau	Doit correspondre ou mettre à niveau
Restauration d’une nouvelle base de données dans la même région	Prise en charge	Prise en charge	Prise en charge
Restauration d’une nouvelle base de données dans une autre région	Non pris en charge	Prise en charge dans toutes les régions Azure	Prise en charge dans toutes les régions Azure
Restauration d’une nouvelle base de données dans un autre abonnement	Pris en charge	Non pris en charge 4	Non pris en charge 4
Restauration via le portail Azure	Oui	Oui	Oui
Restauration via PowerShell	Oui	Oui	Oui
Restauration via Azure CLI	Oui	Oui	Oui

¹ 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.

Opération	Portail Azure	Azure CLI	Azure PowerShell
Modifier la rétention des sauvegardes	SQL Database / SQL Managed Instance	SQL Database / SQL Managed Instance	SQL Database / SQL Managed Instance
Modifier la rétention des sauvegardes à long terme	SQL Database / SQL Managed Instance	SQL Database / SQL Managed Instance	SQL Database / SQL Managed Instance
Restaurer une base de données à partir d’un point dans le temps	SQL Database / SQL Managed Instance	SQL Database / SQL Managed Instance	SQL Database / SQL Managed Instance
Restaurer une base de données supprimée	SQL Database / SQL Managed Instance	SQL Database / SQL Managed Instance	SQL Database / SQL Managed Instance
Restaurer une base de données à partir d’un stockage Blob Azure			SQL Managed Instance

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

• Nouvelles bases de données : la première sauvegarde complète est initiée immédiatement après la création ou la restauration d’une base de données, ou après une modification de la redondance de la sauvegarde de la base de données. Cette sauvegarde se termine généralement dans les 30 minutes, même si elle peut prendre plus longtemps pour les bases de données plus volumineuses.

• Bases de données restaurées : la durée de la sauvegarde initiale des 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 bases de données, qui sont souvent plus volumineuses, peuvent nécessiter plus de temps pour la sauvegarde initiale.

Important

La première sauvegarde complète d’une nouvelle base de données prend la priorité sur d’autres sauvegardes de base de données. Il s’agit donc de la première sauvegarde effectuée lors de la première fenêtre de sauvegarde complète. Si la fenêtre de sauvegarde complète est déjà active et que d’autres bases de données sont en cours de sauvegarde, la première sauvegarde complète de la nouvelle base de données est effectuée immédiatement après la fin de la sauvegarde complète d’une autre base de données.

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.

Important

Pour une base de données nouvelle, rétablie ou copiée, la capacité de restauration à un instant dans le passé (PITR) est disponible dès la fin de la sauvegarde initiale du journal des transactions qui suit la sauvegarde complète initiale.

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.

Important

Pour les bases de données chiffrées par TDE, les fichiers de sauvegarde des journaux ne sont pas compressés pour des raisons de performances. Les sauvegardes de journaux pour les bases de données non chiffrées TDE sont compressé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.

Important

Les sauvegardes d'une base de données supprimée sont conservées pour la restauration à un instant dans le passé (PITR), ce qui peut augmenter les coûts de stockage à mesure que les sauvegardes sont conservées même si la base de données est supprimée. Pour réduire les coûts, vous pouvez définir la période de rétention sur 0 jour, mais uniquement pour des bases de données supprimées. Pour les bases de données régulières, la période de rétention minimale est de 1 jour.

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.

Important

Si vous supprimez une instance gérée, toutes les bases de données sur celle-ci sont également supprimées et ne peuvent pas être récupérées. Vous ne pouvez pas restaurer une instance gérée supprimée. Toutefois, si vous avez configuré une conservation à long terme pour une instance gérée, les sauvegardes de conservation à long terme (LTR) ne sont pas supprimées. Vous pouvez ensuite les utiliser pour restaurer des bases de données vers une instance gérée différente dans le même abonnement, à un point dans le temps où une sauvegarde LTR a été effectuée. Pour en savoir plus, consultez Restaurer une sauvegarde à 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.

Notes

Une facture Azure n’indique que l’excédent de consommation de stockage de sauvegarde, pas la consommation totale de stockage de sauvegarde. Par exemple, dans un scénario hypothétique, si vous avez configuré 4 To de stockage de données, vous obtiendrez 4 To d’espace de stockage de sauvegarde gratuit. Si vous utilisez un total de 5,8 To d'espace de stockage de sauvegarde, la facture Azure affiche uniquement 1,8 To, car vous n'êtes facturé que pour le stockage de sauvegarde excédentaire que vous avez utilisé.

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.

Important

Des compteurs sont visibles uniquement s’ils sont en cours d’utilisation. Si un compteur n’est pas disponible, il est probable que la catégorie n’est pas en cours d’utilisation. Par exemple, les compteurs d’instance gérée ne seront pas présents pour les clients qui n’ont pas d’instance gérée déployée. De même, les compteurs de stockage ne seront pas visibles pour les ressources qui ne consomment pas de stockage. S’il n’existe pas de consommation de stockage de sauvegarde PITR ni LTR, ces compteurs ne s’afficheront pas.

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.

Important

Les stratégies Azure ne sont pas appliquées lors de la création d’une base de données via T-SQL. Pour appliquer la résidence des données lors de la création d’une base de données à l’aide de T-SQL, utilisez « LOCAL » ou « ZONE » comme entrée pour le paramètre BACKUP_STORAGE_REDUNDANCY dans l’instruction CREATE DATABASE.

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.

Notes

L’article Modifier les paramètres de sauvegarde automatisée explique comment supprimer des données personnelles de l’appareil ou du service et peut être utilisé dans le cadre de vos obligations en vertu du RGPD. Pour obtenir des informations générales concernant le Règlement général sur la protection des données (RGPD), consultez la section relative au RGPD du Centre de gestion de la confidentialité de Microsoft et la section relative au RGPD du Portail d’approbation de services.

É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