Partager via

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 de sauvegarde automatisés pour Azure SQL Managed Instance. Pour restaurer une sauvegarde, consultez Restaurer une base de données à partir d’une sauvegarde dans Azure SQL Managed Instance.

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 gérées par Microsoft et stockées sur des comptes de stockage Azure gérés par Microsoft.

Utilisez ces sauvegardes pour restaurer votre base de données à un moment précis dans le temps, dans la période de conservation configurée, jusqu’à 35 jours. Toutefois, si vos règles de protection des données exigent 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 :

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 lancées une fois par semaine selon un calendrier déterminé par Microsoft. Les sauvegardes lancées par l’utilisateur ont priorité sur les sauvegardes complètes automatiques. Par conséquent, une sauvegarde de longue durée qui ne copie que des fichiers peut affecter le moment où la prochaine sauvegarde complète automatique sera effectuée.

Une sauvegarde de fichier journal de fin est effectuée chaque fois qu’une base de données ou une SQL Managed Instance est supprimée.

Les bases de données système sont automatiquement sauvegardées (à l’exclusion de la base de données physique master ), mais ces sauvegardes ne sont pas actuellement connectées msdb.

Redondance du stockage de sauvegarde

Par défaut, Azure SQL Managed Instance stocke les sauvegardes dans des blobs de stockage géo-redondants qui sont répliqués dans une région appairé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.

Note

La modification de la redondance des sauvegardes est une opération de gestion des mises à jour qui déclenche un basculement.

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

  • Stockage local redondant (LRS) : copie vos sauvegardes de manière synchrone trois fois au sein d’un seul 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é.

    Diagramme illustrant l’option de stockage localement redondant (LRS).

  • Stockage redondant par zone (ZRS) : copie vos sauvegardes de manière synchrone sur trois zones de disponibilité Azure dans la région primaire. L’option ZRS est actuellement disponible dans certaines régions.

    Diagramme montrant l’option de stockage redondant interzone (ZRS).

  • Stockage géo-redondant (GRS) : copie vos sauvegardes de manière synchrone trois fois au sein d’un seul emplacement physique dans la région primaire à l’aide du 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.

    Diagramme montrant l’option de stockage géoredondant (GRS).

  • Stockage redondant dans plusieurs zones géographiques (GZRS) : combine la haute disponibilité offerte par la redondance entre les zones de disponibilité et la protection contre les pannes régionales assurée par la réplication géographique. 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.

    Diagramme montrant l’option de stockage géo-redondant interzone (GZRS).

Warning

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

Utilisation de la sauvegarde

Vous pouvez utiliser ces sauvegardes aux fins suivantes :

  • Restaurez une base de données existante à un moment donné dans le passé, au cours de la période de conservation, à 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.

  • Restaurez une base de données supprimée à un moment donné au cours de la période de conservation, y compris au moment de la 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.

    Importante

    La géo-restauration 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 dispose d’une stratégie LTR configurée. 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, consultez sauvegardes de rétention à long terme - Azure SQL Database et Azure SQL Managed Instance.

Capacités et fonctionnalités de restauration

Ce tableau résume les capacités et fonctionnalités de la restauration à un instant donné (PITR), de la restauration géographique et de la conservation à long terme.

Propriétés de sauvegarde Restauration à un instant dans le passé La géorestauration LTR
Types de sauvegarde 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.
Stockage Azure Géoredondant par défaut. Vous pouvez configurer un stockage localement redondant ou redondant interzone. Disponible lorsque la redondance du stockage de sauvegarde PITR est définie sur géoredondante ou géozone redondante (GZRS). 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 les sauvegardes comme immuables Non pris en charge Non pris en charge Non pris en charge
Stratégie de mise à jour3 Doit correspondre ou être mis à niveau Doit correspondre ou être mis à niveau Doit correspondre ou être mis à niveau
Restauration d’une nouvelle base de données dans la même région Pris en charge Pris en charge Pris 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

1 Pour les applications métier critiques qui nécessitent des bases de données volumineuses et doivent garantir la continuité des activités, consultez la section Groupes de basculement.
2 Toutes les sauvegardes PITR sont stockées sur un stockage géo-redondant par défaut, ce qui signifie que la restauration géographique est activée par défaut.
3 Les sauvegardes de base de données peuvent uniquement être restaurées sur des instances avec des stratégies de mise à jour correspondantes ou vers une stratégie de mise à jour d’une version supérieure de SQL Server. Par exemple, une sauvegarde de base de données effectuée à partir d’une instance avec une stratégie de mise à jour SQL Server 2022 peut être restaurée sur une instance avec la stratégie de mise à jour SQL Server 2022, SQL Server 2025 ou Always-up-to-date de mise à jour.
4 La solution consiste à restaurer sur un nouveau serveur et à utiliser le déplacement de ressources 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 d’une sauvegarde dans Azure SQL Managed Instance. Vous pouvez essayer les opérations de configuration et de restauration de sauvegarde à l’aide des exemples suivants.

Opération Portail Azure Azure CLI (Interface de ligne de commande Azure) Azure PowerShell
Modifier la conservation des sauvegardes SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance
Modifier la conservation 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 du stockage Blob Azure SQL Managed Instance

Planification automatique des sauvegardes

Azure SQL Managed Instance gère automatiquement les sauvegardes en créant des sauvegardes complètes, différentielles et de journaux de transactions. Ce processus est régi par un calendrier 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 cela peut prendre plus de temps. La durée de la sauvegarde initiale pour les bases de données restaurées varie en fonction 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.

Importante

La première sauvegarde complète d’une nouvelle base de données est prioritaire par rapport aux autres sauvegardes de base de données. Il s’agit donc de la première sauvegarde effectuée pendant 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 sauvegardées, la première sauvegarde complète de la nouvelle base de données est effectuée immédiatement après 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 pendant laquelle les sauvegardes complètes sont effectuées. Bien que le système vise à effectuer des sauvegardes complètes dans cette fenêtre, si nécessaire, la sauvegarde peut continuer au-delà du temps planifié 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 utilisant l’utilisation du processeur et le 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 : les utilisateurs ne peuvent pas modifier ou désactiver la planification de sauvegarde.

Importante

Pour une base de données nouvelle, restaurée ou copiée, la fonctionnalité de restauration à un instant donné (PITR) devient disponible une fois la sauvegarde initiale du journal des transactions terminée, après 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 instant dans le passé 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, y compris celles chiffrées par TDE, toutes les sauvegardes complètes et différentielles sont compressées afin de réduire la compression et les coûts de stockage des sauvegardes. 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.

Importante

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

Importante

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 de stockage de sauvegarde jusqu’à la taille maximale de données pour une base de données n’est pas facturée. La consommation de stockage de sauvegarde excédentaire 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 clusterisés.
  • 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 comprise entre 1 et 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 STR précédente ne sont ni déplacées ni 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.

Importante

Si vous devez restaurer des bases de données à partir d’une instance managée SQL supprimée involontairement, contactez l’équipe du support technique Microsoft dans les 5 jours suivant l’opération de suppression.

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 LTR, consultez sauvegardes de rétention à long terme - Azure SQL Database et Azure SQL Managed Instance.

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 (LRS) = Zone-redundant price (ZRS) = published price
  • Geo-redundant price (GRS) = Geo-zone-redundant price (GZRS) = published price x 2

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

Note

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 n’indique que 1,8 To, car vous n’êtes facturé que pour l’excédent de stockage de sauvegarde 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 PITR chaque heure, à un taux constant. La facturation Azure agrège cette consommation et affiche une utilisation de 744 Go pour l’ensemble du mois. Le coût est basé sur le tarif par gigaoctet et 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 du stockage de sauvegarde varie 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 converties 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. Les compteurs s’affichent uniquement si la consommation de stockage de sauvegarde existe.

    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. Les compteurs s’affichent uniquement si la consommation de stockage de sauvegarde existe.

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.

Capture d’écran montrant une analyse des coûts de stockage de sauvegarde.

Importante

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 utilisée actuellement. Par exemple, les compteurs d’instance managée ne sont pas présents pour les clients qui n’ont pas d’instance managée déployée. De même, les compteurs de stockage ne sont pas visibles pour les ressources qui ne consomment pas de stockage. S’il n’existe aucune consommation de stockage de sauvegarde PITR ou LTR, ces compteurs ne seront pas visibles.

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 entièrement responsable de la conservation et de la rotation des clés pour les bases de données avec clés gérées par le service (SMK). Les sauvegardes, qu’elles soient PITR ou LTR, effectuées à partir d’instances sur lesquelles TDE avec SMK est activé peuvent être restaurées par Microsoft.

Les sauvegardes automatiques stockées dans des comptes de stockage gérés par Azure sont automatiquement chiffrées par le stockage Azure. En savoir plus sur le chiffrement du stockage Azure pour les données au repos.

Problèmes courants liés aux sauvegardes automatisées en raison d’actions du client

Bien qu’Azure SQL Managed Instance fournit des sauvegardes automatisées pour garantir la protection et la récupération des données, certaines configurations ou actions côté client peuvent entraîner des défaillances de sauvegarde. Scénarios courants :

  • Stockage insuffisant pour l’instance managée SQL. Si le stockage alloué à votre instance est complet, les sauvegardes automatisées ne sont pas effectuées.
  • Les travaux ou scripts définis par l’utilisateur qui tuent les processus système peuvent arrêter les opérations de sauvegarde automatisées.
  • Les paramètres DNS incorrects peuvent empêcher l’instance managée SQL d’accéder aux points de terminaison Azure requis, y compris ceux utilisés pour les sauvegardes, ce qui entraîne des échecs de sauvegarde.
  • Le journal des transactions peut se remplir en raison d’une troncature empêchée par une réplication mal configurée, CDC ou un stockage complet (au niveau de l’instance). Si le journal des transactions est plein et ne peut pas être tronqué, les sauvegardes complètes et différentielles échouent, mais les sauvegardes de journal réussissent toujours sans tronquer le fichier journal.

Pour garantir des sauvegardes fiables, il est important de surveiller les ressources système, de valider les paramètres de configuration et d’éviter d’interférer avec les opérations de service intégrées. Veillez à surveiller le stockage alloué, à disposer de paramètres DNS corrects et à passer en revue les tâches personnalisées et les configurations de réplication.

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 automatisées de bases de donné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, une protection intégrée de vos sauvegardes alerte Microsoft en cas de problème avec le service de sauvegarde. En outre, Microsoft vous assiste en cas de problème 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 journal n’est pas conforme au contrat SLA ou si le matériel ou le logiciel de sauvegarde 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.

Importante

Les stratégies Azure ne sont pas appliquées lorsque vous créez 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.

Protection des sauvegardes

Les sauvegardes Azure SQL Managed Instance sont entièrement gérées dans les abonnements Azure appartenant à Microsoft à l’aide de comptes de stockage Azure sécurisés et internes. Ces sauvegardes ne sont pas accessibles en externe, ce qui garantit une isolation et une protection des données fortes. Dans Microsoft, seuls les services principaux tels que le service Backup-Restore ont accès à la création, à la copie ou à la restauration de ces sauvegardes. Les ingénieurs Microsoft, y compris les développeurs, n’ont pas d’accès permanent. Pour minimiser l’exposition et maximiser la sécurité, Microsoft ne peut obtenir un accès juste à temps (JIT) que sous des contrôles d’audit stricts, lorsque cela est absolument nécessaire pour résoudre des problèmes spécifiques des clients

Les sauvegardes sont automatiquement supprimées après l’expiration de la rétention.

Conformité par le biais de la rétention des sauvegardes

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.

Note

L’article Modifier les paramètres de sauvegarde automatisée pour Azure SQL Managed Instance décrit comment supprimer des données personnelles de l’appareil ou du service et peut être utilisé pour prendre en charge vos obligations en vertu du RGPD. Pour des informations générales sur le RGPD, consultez la section RGPD du Centre de gestion de la confidentialité Microsoft et la section RGPD du portail d’approbation de services.

Contenu connexe

  • Last updated on