Sauvegardes automatisées - Azure SQL Database & Azure SQL Managed Instance

S’APPLIQUE À : Azure SQL Database Azure SQL Managed Instance

Notes

Cet article explique comment supprimer les données personnelles de l’appareil ou du service et il peut être utilisé dans le cadre de vos obligations en vertu du Règlement général sur la protection des données. 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.

Qu’est-ce qu’une sauvegarde de base de données ?

Les sauvegardes de base de données sont une partie essentielle de toute stratégie de continuité d’activité ou de récupération d’urgence, dans la mesure où elles protègent vos données des corruptions et des suppressions. Ces sauvegardes permettent de restaurer la base de données à un point dans le temps pendant la période de rétention configurée. 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 une stratégie de conservation à long terme à la fois pour les bases de données uniques et mises en pool.

Sauvegarde et restauration d'Essentials

Les bases de données dans Azure SQL Managed Instance et les bases de données non Hyperscale dans Azure SQL Database utilisent la technologie de moteur SQL Server pour sauvegarder et restaurer les données. Les bases de données Hyperscale ont une architecture unique et tirent parti d’une technologie différente pour la sauvegarde et la restauration. Pour plus d’informations, consultez Sauvegardes et redondance de stockage Hyperscale.

Fréquence de sauvegarde

Azure SQL Database et Azure SQL Managed Instance utilisent la technologie SQL Server pour créer des sauvegardes complètes (chaque semaine), différentielles (toutes les 12 à 24 heures) et du journal des transactions (toutes les 5 à 10 minutes). 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.

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.

Les bases de données Hyperscale utilisent la technologie de sauvegarde de capture instantanée.

Redondance du stockage de sauvegarde

Par défaut, Azure SQL Database et Azure SQL Managed Instance stockent les données dans des objets BLOB de stockage géoredondants qui sont répliqués dans une région couplée. La géoredondance permet de se protéger contre les pannes impactant le stockage de sauvegarde dans la région primaire et vous permet de restaurer votre serveur dans une autre région en cas de sinistre.

L’option de configuration de la redondance du stockage de sauvegarde offre la possibilité de choisir entre des objets blob de stockage localement redondant, redondant interzone ou géoredondant. Pour vous assurer que vos données restent dans la même région que celle où votre instance managée ou base de données dans Azure SQL Database est déployée, vous pouvez modifier la redondance par défaut du stockage de sauvegarde géoredondant et configurer des blobs de stockage localement redondant ou redondant interzone pour les sauvegardes. La redondance de stockage stocke toujours plusieurs copies de vos données afin qu’elles soient protégées contre des événements planifiés ou non, notamment des défaillances matérielles temporaires, des pannes de réseau ou de courant et des catastrophes naturelles majeures. La redondance du stockage de sauvegarde configurée est appliquée aux paramètres de rétention de sauvegarde à court terme utilisés pour la récupération jusqu’à une date et heure (PITR) et les sauvegardes de rétention à long terme utilisées pour les sauvegardes à long terme (LTR).

Pour Azure SQL Database, la redondance du stockage de sauvegarde peut être configurée au moment de la création de la base de données ou peut être mise à jour pour une base de données existante ; les modifications apportées à une base de données existante s’appliquent uniquement aux sauvegardes ultérieures. Après la mise à jour de la redondance du stockage de sauvegarde d’une base de données existante, l’application des modifications peut prendre jusqu’à 48 heures. La géorestauration est désactivée dès qu’une base de données est mise à jour pour utiliser un stockage localement redondant ou redondant interzone. Pour les bases de données Hyperscale, l’option de redondance de stockage sélectionnée sera utilisée pendant la durée de vie de la base de données pour la redondance de stockage de données et la redondance de stockage de sauvegarde. Plus d’informations sur Sauvegardes et redondance du stockage Hyperscale.

Important

Pour le moment, le stockage redondant interzone est uniquement disponible dans certaines régions.

Utilisation de la sauvegarde

Vous pouvez utiliser ces sauvegardes aux fins suivantes :

  • Restaurer une base de données existante - à un point dans le temps situé dans le passé pendant la période de rétention, à l’aide du portail Azure, d’Azure PowerShell, d’Azure CLI ou de l’API REST. Pour SQL Database, cette opération crée une nouvelle base de données sur le même serveur que la base de données d’origine, mais sous un nom différent pour éviter de remplacer la base de données d’origine. 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 et renommer la base de données restaurée pour obtenir le nom de la base de données d’origine. De même, pour SQL Managed Instance, cette opération peut aussi créer une copie de la base de données sur une instance managée, identique ou non, dans le même abonnement et dans la même région.
  • Restaurer une base données à un instant dans le passé - Restaurer une base de données supprimée au moment de sa suppression ou à tout point dans le temps pendant la période de rétention. La base de données supprimée ne peut être restaurée que sur le serveur ou la même instance gérée où la base de données d’origine a été créée. Lors de la suppression d’une base de données, le service effectue une sauvegarde finale du journal des transactions avant sa suppression, afin d’éviter toute perte de données.
  • Géo-restaurer - 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 principale. Cela crée une base de données sur un serveur ou une instance gérée existant(e), dans n’importe quelle région Azure.

    Important

    La géorestauration est disponible uniquement pour des bases de données dans Azure SQL Database ou les instances géré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 enconfigurant la redondance de stockage de sauvegarde.

  • Restaurer une base de données à partir d’une sauvegarde à long terme - Restaurer une base de données à partir d’une sauvegarde spécifique à long terme d’une base de données unique ou mise en pool, 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 ancienne version 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 ancienne version de l’application. Pour plus d’informations, consultez Rétention à long terme.

Notes

Dans Stockage Azure, le terme réplication fait référence à la copie d’objets blob d’un emplacement à un autre. Dans SQL, la réplication de base de données fait référence aux diverses technologies utilisées pour conserver plusieurs bases de données secondaires synchronisées avec une base de données principale.

Capacités et fonctionnalités de restauration d’Azure SQL Database et Azure SQL Managed Instance

Ce tableau synthétise les capacités et fonctionnalités de la récupération jusqu’à une date et heure, de la géorestauration et des sauvegardes avec conservation à long terme.

Propriétés de sauvegarde  Récupération jusqu’à une date et heure Géorestauration Restauration de sauvegarde à long terme
Types de sauvegardes SQL Complète, différentielle, de fichier journal Copies répliquées des sauvegardes avec récupération jusqu’à une date et heure Uniquement les sauvegardes complètes
Objectif de point de récupération (RPO)   5-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.*   Une semaine (ou stratégie de l’utilisateur).
Objectif de délai de récupération (RTO) Le temps de restauration est généralement <12 heures, mais le processus peut prendre plus de temps selon la taille et l’activité. Consultez Temps de récupération Le temps de restauration est généralement <12 heures, mais le processus peut prendre plus de temps selon la taille et l’activité. Consultez Temps de récupération. Le temps de restauration est généralement <12 heures, mais le processus peut prendre plus de temps selon la taille et l’activité. Consultez Temps de récupération.
Rétention 7 jours par défaut, jusqu’à 35 jours   Activée par défaut, identique à la source.** Non activée par défaut, conservation jusqu’à 10 ans.
Azure Storage   Géoredondant par défaut. Possibilité de configuration d’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 magasin de sauvegarde avec récupération jusqu’à une date et heure est un stockage localement redondant ou redondant interzone.  Géoredondant par défaut. Possibilité de configuration d’un stockage localement redondant ou redondant interzone.
Utilisation pour créer une base de données dans la même région Pris en charge Prise en charge  Pris en charge
Utilisation pour créer une 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
Utilisation pour créer une base de données dans un autre abonnement Non pris en charge Non pris en charge *** Non pris en charge ***
Restauration par le biais du portail Azure Oui Oui Oui
Restauration par le biais de PowerShell Oui Oui Oui
Restauration par le biais d’Azure CLI Oui Oui Oui

*Pour les applications vitales pour l’entreprise qui nécessitent de grosses bases de données et doivent assurer la continuité de l’activité, utilisez des groupes de basculement automatique.

** Toutes les sauvegardes avec récupération jusqu’à une date et heure sont stockées sur un stockage géoredondant par défaut. La géorestauration est donc activée par défaut.

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

Restauration d’une base de données à partir de sauvegardes

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 Base de données SQL
SQL Managed Instance
Base de données SQL
SQL Managed Instance
Base de données SQL
SQL Managed Instance
Modifier la rétention des sauvegardes à long terme Base de données SQL
SQL Managed Instance
Base de données SQL
SQL Managed Instance
Base de données SQL
SQL Managed Instance
Restaurer une base de données à partir d’un point dans le temps Base de données SQL
SQL Managed Instance
Base de données SQL
SQL Managed Instance
Base de données SQL
SQL Managed Instance
Restaurer une base de données supprimée Base de données SQL
SQL Managed Instance
Base de données SQL
SQL Managed Instance
Base de données SQL
SQL Managed Instance
Restaurer une base de données à partir d’un stockage Blob Azure
SQL Managed Instance

Planification de la sauvegarde

La première sauvegarde complète est planifiée immédiatement après la création ou la restauration d’une nouvelle base de données. Elle s’exécute généralement en 30 minutes, mais elle peut nécessiter davantage de temps si la base de données est volumineuse. Par exemple, la sauvegarde initiale peut prendre davantage de temps sur une base de données restaurée ou une copie de base de données, qui est généralement plus volumineuse qu’une nouvelle base de données. Après la première sauvegarde complète, toutes les sauvegardes sont planifiées et gérées automatiquement. Le moment exact de toutes les sauvegardes de base de données est déterminé par le service SQL Database ou SQL Managed Instance en fonction de l’équilibrage de la charge de travail globale du système. Vous ne pouvez pas modifier la planification des travaux de sauvegarde ni les désactiver. Hyperscale utilise un autre mécanisme de planification des sauvegardes. Pour en savoir plus, consultez Planification des sauvegardes Hyperscale.

Important

Pour une base de données nouvelle, restaurée ou copiée, la fonction de restauration à un point dans le temps est disponible dès la création 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 SQL Server, la restauration d’une base de données à un point dans le temps requiert une chaîne de sauvegarde ininterrompue composée d’une sauvegarde complète, éventuellement d’une sauvegarde différentielle et d’une ou plusieurs sauvegardes du journal des transactions. La planification de sauvegarde Azure SQL Database et Azure SQL Managed Instance inclut une sauvegarde complète chaque semaine. Pour assurer la récupération jusqu’à une date et heure pour l’ensemble de la période de conservation, le système doit donc 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, ainsi qu’une chaîne ininterrompue de sauvegardes différentielles et du journal des transactions à partir de cette sauvegarde complète jusqu’à la prochaine sauvegarde complète. Les bases de données Hyperscale utilisent un autre mécanisme de planification des sauvegardes. Pour en savoir plus, consultez Planification des sauvegardes Hyperscale. Pour plus d’informations sur le monitoring des coûts de stockage, consultez Coûts du stockage des sauvegardes Hyperscale.

Notes

Pour assurer la récupération jusqu’à une date et heure, les sauvegardes supplémentaires sont stockées pendant une période plus longue d’une semaine que la période de conservation configurée. Le stockage de sauvegarde est facturé au même tarif pour toutes les sauvegardes.

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, les sauvegardes 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, mais il peut être nettement plus faible ou plus élevé selon la nature des données et de l’utilisation ou non de la compression des données dans la base de données.

Azure SQL Database et Azure SQL Managed Instance calculent 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, qui 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 récupération jusqu’à une date et heure (PITR) n’est plus possible, la facturation s’arrête.

Important

Les sauvegardes d’une base de données sont conservées pour assurer la récupération jusqu’à une date et heure même si la base de données a été supprimée. Si la suppression et la recréation d’une base de données peuvent réduire les coûts de stockage et de calcul, cela peut augmenter les coûts de stockage de sauvegarde, car le service conserve les sauvegardes pour chaque base de données supprimée, à chaque fois qu’elle est supprimée.

Surveiller la consommation

Pour les bases de données vCore dans Azure SQL Database, le stockage consommé par chaque type de sauvegarde (complète, différentielle et de fichier journal) est signalé sur le volet de supervision de la base de données sous la forme d’une métrique distincte. Le diagramme suivant montre comment surveiller la consommation de stockage des sauvegardes pour une base de données unique. Cette fonctionnalité n’est pas disponible actuellement pour les instances gérées.

Monitor database backup consumption in the Azure portal

Pour obtenir des instructions sur le monitoring de la consommation dans Hyperscale, consultez Monitoring de la consommation des sauvegardes Hyperscale

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 de la sauvegarde au minimum possible pour 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 bonnes pratiques connexes, et/ou de réduire le nombre d’index non en 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 et/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

La Base de données SQL Azure et l’Instance managée SQL Azure fournissent toutes deux une rétention à court et long terme des sauvegardes. Les sauvegardes de rétention à court terme autorisent une limite de restauration dans le temps (PITR) avec la période de rétention de la base de données, tandis que la rétention à long terme fournit des sauvegardes pour différentes 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 Database et Azure SQL Managed Instance conservent des sauvegardes suffisantes pour autoriser la récupération jusqu’à une date et heure au cours des sept derniers jours par défaut. 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 au cours de la période de rétention définie pour la base de données ou l’instance managée. En outre, pour les bases de données Azure SQL, les sauvegardes différentielles peuvent être configurées sur une fréquence de 12 heures ou 24 heures.

Notes

Une fréquence de sauvegarde différentielle de 24 heures peut augmenter le temps nécessaire pour restaurer la base de données.

À l’exception des bases de données de niveau De base, vous pouvez modifier la période de conservation de la sauvegarde selon une plage comprise entre 1 et 35 jours pour chaque base de données active. Comme décrit dans Consommation du stockage de sauvegarde, les sauvegardes stockées pour activer la récupération jusqu’à une date et heure (PITR) peuvent être antérieures à la période de rétention. Pour Azure SQL Managed Instance uniquement, il est possible de définir le taux de rétention des sauvegardes PITR une fois qu’une base de données a été supprimée dans la plage de 0-35 jours.

Notes

La conservation de sauvegarde à court terme (1 à 35 jours) pour les bases de données Hyperscale est actuellement en préversion. Pour plus d’informations, consultez Gestion de la conservation des sauvegardes dans Hyperscale.

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. Vous ne pouvez pas modifier la période de rétention de sauvegarde pour une base de données supprimée.

Important

Si vous supprimez un serveur ou une instance managée, toutes les bases de données sur ce serveur ou cette instance sont également supprimées et ne peuvent pas être récupérées. Vous ne pouvez pas restaurer un serveur ou une instance gérée supprimé(e). Toutefois, si vous avez configuré la rétention à long terme (LTR) pour une base de données ou une instance gérée, les sauvegardes de rétention à long terme ne sont pas supprimées et peuvent être utilisées pour restaurer des bases de données sur un(e) autre serveur ou instance gérée dans le même abonnement, à un point dans le temps où une sauvegarde de rétention à long terme a été effectuée.

La rétention des sauvegardes à des fins de récupération jusqu’à une date et heure (PITR) dans les 1-35 derniers jours est parfois appelée rétention des sauvegardes à court terme. 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 rétention à long terme.

Rétention à long terme

Pour SQL Database et SQL Managed Instance, vous pouvez configurer une conservation à long terme (LTR) des sauvegardes complètes allant jusqu’à 10 ans dans un stockage Blob Azure. Si la stratégie de conservation à long terme est activée, les sauvegardes complètes hebdomadaires 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 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.

Important

La mise à jour de la redondance du stockage de sauvegarde pour une base de données Azure SQL existante s’applique uniquement aux sauvegardes ultérieures effectuées pour la base de données. Toutes les sauvegardes LTR existantes pour la base de données continueront de résider dans le blob de stockage existant et les nouvelles sauvegardes seront stockées sur le type de blob de stockage demandé.

Pour plus d’informations sur la conservation à long terme, consultez Conservation des sauvegardes à long terme.

Coûts du stockage de sauvegarde

Le prix du stockage de sauvegarde varie et dépend de votre modèle d’achat (DTU ou vCore), de l’option de redondance de stockage de sauvegarde choisie et également de votre région. Le stockage de sauvegarde est facturé par Go/mois consommés. Pour connaître la tarification, consultez la page Tarification Azure SQL Database et la page Tarification Azure SQL Managed Instance.

Pour plus d’informations sur les modèles d’achat, consultez Choisir entre les modèles d’achat vCore et DTU.

Notes

La facture Azure n’indiquera que l’excédent de stockage de sauvegarde consommé, et non 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 avez utilisé le total de 5,8 To d’espace de stockage de sauvegarde, la facture Azure n’indiquera que 1,8 To, car seul le stockage de sauvegarde excédentaire utilisé est facturé.

Modèle DTU

Dans le modèle DTU, aucuns frais supplémentaires ne sont facturés pour le stockage de sauvegarde des bases de données et des pools élastiques. Le prix du stockage de sauvegarde est inclus dans le prix de la base de données ou du pool.

Modèle vCore

Pour les bases de données uniques dans SQL Database, une quantité de stockage de sauvegarde égale à 100 % de la taille maximale de stockage des données pour la base de données est fournie sans frais supplémentaires. Pour les pools élastiques et les instances gérées, une quantité de stockage de sauvegarde égale à 100 % du stockage maximal de données pour le pool ou la taille maximale de stockage d’instance, respectivement, est fournie sans frais supplémentaires.

Pour les bases de données uniques, cette équation est utilisée pour calculer l’utilisation totale du stockage de sauvegarde facturable :

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

Pour les bases de données mises en pool, la taille totale de stockage de sauvegarde facturable est agrégée au niveau du pool et calculée comme suit :

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

Pour les instances gérées, la taille totale de 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 total facturable, le cas échéant, sera facturé en Go/mois conformément au tarif de la redondance du stockage de sauvegarde utilisé. Cette consommation de stockage de sauvegarde dépend de la charge de travail et de la taille des bases de données, des pools élastiques et des instances gérées individuels. 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.

Les formules utilisées pour calculer les coûts de stockage des sauvegardes de bases de données Hyperscale sont disponibles ici : Coûts du stockage des sauvegardes Hyperscale.

Azure SQL Database et Azure SQL Managed Instance calculent votre stockage total de sauvegarde 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, 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.

À 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 par mois * 24 heures par jour). SQL Database 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ègera cette consommation et affichera une utilisation de 744 Go pour le mois. Le coût sera basé sur le taux par quantité/Go/mois dans votre région.

À présent, un exemple plus complexe. Supposons que pour la même base de données inactive, la conservation 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 Database 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/mois.

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, provoquant la fluctuation de la consommation de stockage de sauvegarde horaire. En outre, chaque sauvegarde différentielle contient toutes les modifications apportées dans la base de données depuis la dernière sauvegarde complète ; par conséquent, la taille totale de toutes les sauvegardes différentielles augmente progressivement au cours d’une semaine, puis chute brusquement une fois qu’un ensemble plus ancien de sauvegardes complètes, différentielles et de journaux arrive à expiration. Par exemple, si une activité d’écriture intensive telle que la reconstruction d’index a été exécutée juste après la fin d’une sauvegarde complète, alors les modifications apportées par la reconstruction de l’index seront incluses dans les sauvegardes du journal des transactions effectuées pendant la durée de la reconstruction, dans la prochaine sauvegarde différentielle et dans chaque sauvegarde différentielle effectuée jusqu’à la prochaine sauvegarde complète. Pour le dernier scénario dans les bases de données plus volumineuses, une optimisation du service crée une sauvegarde complète au lieu d’une sauvegarde différentielle si une sauvegarde différentielle devait être excessivement importante. Cela réduit la taille de toutes les sauvegardes différentielles jusqu’à la prochaine sauvegarde complète.

Vous pouvez surveiller la consommation totale du stockage de sauvegarde pour chaque type de sauvegarde (complète, différentielle, journal des transactions) au fil du temps, comme décrit dans Surveiller la consommation.

Redondance du stockage de sauvegarde

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

  • prix localement redondant = x
  • prix localement redondant = 1,25 x
  • prix géoredondant = 2x

Pour connaître la tarification du stockage de sauvegarde, consultez la page Tarification Azure SQL Database et la page Tarification Azure SQL Managed Instance.

Important

La redondance du stockage de sauvegarde pour Hyperscale peut être définie uniquement durant la création de la base de données. Ce paramètre ne peut pas être modifié après le provisionnement de la ressource. Le processus de copie de base de données peut être utilisé pour mettre à jour les paramètres de redondance du stockage de sauvegarde pour une base de données Hyperscale existante. Plus d’informations sur Sauvegardes et redondance du stockage Hyperscale.

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 sélectionnez 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 base de données sql pour une seule base de données ou un pool de bases de données élastique, ou sélectionnez instance managée sql pour une instance managée.
  3. Ajoutez un autre filtre pour Sous-catégorie du compteur.
  4. Pour surveiller les coûts de sauvegarde PITR, dans la liste déroulante, sélectionnez le stockage de sauvegarde PITR unique/de pool élastique pour une base de données unique ou un pool de bases de données élastique, ou sélectionnez le stockage de sauvegarde PITR d’instance managée pour une instance managée. Les compteurs ne s’afficheront que s’il existe une consommation.
  5. Pour surveiller les coûts de sauvegarde LTR, dans la liste déroulante, sélectionnez le stockage de sauvegarde LTR pour une base de données unique ou un pool de bases de données élastique, ou sélectionnez sql managed instance – stockage de sauvegarde LTR pour une instance managée. Les compteurs ne s’afficheront que s’il existe une consommation.

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

Backup storage cost analysis

Important

Les guichets sont visibles uniquement pour les compteurs en cours d’utilisation. Si un compteur n’est pas disponible, il est probable que la catégorie ne soit pas en cours d’utilisation. Par exemple, les compteurs d’instance managé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. Par exemple, s’il n’existe pas de consommation de stockage de sauvegarde PITR ni LTR, ces compteurs ne s’afficheront pas.

Pour plus d’informations, consultez Gérer les coûts d’Azure SQL Database.

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 Database & SQL Managed Instance.

Intégrité de la sauvegarde

L’équipe d’ingénieurs Azure SQL teste régulièrement et automatiquement la restauration des sauvegardes automatisées de bases de données. (Actuellement, ces tests ne sont pas disponibles dans SQL Managed Instance. Vous devez planifier DBCC CHECKDB sur vos bases de données dans SQL Managed Instance en fonction de votre charge de travail.)

Lors d’une restauration à un point dans le temps, les bases de données font également l’objet de vérifications d’intégrité DBCC CHECKDB.

Tout problème détecté lors de la vérification d’intégrité est traduit par une alerte envoyée à l’équipe d’ingénieurs. Pour plus d’informations, consultez Intégrité des données dans SQL Database.

Toutes les sauvegardes de base de données sont effectuées avec l’option CHECKSUM pour fournir une intégrité de sauvegarde supplémentaire.

Conformité

Lorsque vous migrez votre base de données à partir d’un niveau de service basé sur DTU vers un niveau de service basé sur vCore, la conservation PITR est préservée pour garantir que la stratégie de récupération de données de votre application ne soit pas compromise. 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

Cet article explique comment supprimer les données personnelles de l’appareil ou du service et il peut être utilisé dans le cadre de vos obligations en vertu du Règlement général sur la protection des données. 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.

Modifier la stratégie de rétention à court terme

Vous pouvez modifier la période de rétention des sauvegardes PITR par défaut et la fréquence de sauvegarde différentielle à l’aide du portail Azure, de PowerShell ou de l’API REST. Les exemples suivants montrent comment modifier la rétention PITR à 28 jours et les sauvegardes différentielles à un intervalle de 24 heures.

Avertissement

Si vous réduisez la période de rétention actuelle, vous perdez la possibilité de restaurer à des points dans le temps antérieurs à la nouvelle période de rétention. Les sauvegardes qui ne sont plus nécessaires pour fournir la fonctionnalité PITR dans la nouvelle période de rétention sont supprimées. Si vous augmentez la période de rétention actuelle, vous n’avez pas immédiatement la possibilité de restaurer à des points dans le temps antérieurs dans la nouvelle période de rétention. Vous obtenez cette possibilité dans le temps, car le système commence à conserver les sauvegardes plus longtemps.

Notes

Ces API impactent uniquement la période de rétention avec récupération jusqu’à une date et heure. Si vous avez configuré la conservation à long terme pour votre base de données, cette configuration n’est pas affectée. Pour plus d’informations sur la modification des périodes de conservation à long terme, consultez Conservation à long terme.

Modifier la stratégie de rétention à court terme à l’aide du portail Azure

Pour modifier la période de rétention des sauvegardes PITR ou la fréquence de sauvegarde différentielle pour les bases de données actives via le Portail Azure, accédez au serveur ou à l’instance managée contenant les bases de données dont vous souhaitez modifier la période de rétention. Sélectionnez Sauvegardes dans le volet gauche, puis sélectionnez l’onglet Stratégies de conservation. Sélectionnez la ou les bases de données pour lesquelles vous souhaitez modifier la conservation de la sauvegarde PITR. Sélectionnez ensuite Configurer la conservation dans la barre d’action.

Modifier la stratégie de conservation à court terme à l’aide d’Azure CLI

Préparez votre environnement pour l’interface Azure CLI.

  • Utilisez l’environnement Bash dans Azure Cloud Shell. Pour plus d’informations, consultez Démarrage rapide d’Azure Cloud Shell - Bash.

    Launch Cloud Shell in a new window

  • Si vous préférez exécuter les commandes de référence de l’interface de ligne de commande localement, installez l’interface Azure CLI. Si vous exécutez sur Windows ou macOS, envisagez d’exécuter Azure CLI dans un conteneur Docker. Pour plus d’informations, consultez Guide pratique pour exécuter Azure CLI dans un conteneur Docker.

    • Si vous utilisez une installation locale, connectez-vous à Azure CLI à l’aide de la commande az login. Pour finir le processus d’authentification, suivez les étapes affichées dans votre terminal. Pour connaître les autres options de connexion, consultez Se connecter avec Azure CLI.

    • Lorsque vous y êtes invité, installez les extensions Azure CLI lors de la première utilisation. Pour plus d’informations sur les extensions, consultez Utiliser des extensions avec Azure CLI.

    • Exécutez az version pour rechercher la version et les bibliothèques dépendantes installées. Pour effectuer une mise à niveau vers la dernière version, exécutez az upgrade.

Modifiez la durée de conservation des sauvegardes PITR (limite de restauration dans le temps) et la fréquence des sauvegardes différentielles pour les bases de données Azure SQL actives à l’aide de l’exemple suivant.

# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be between 1 and 35 days
# Valid differential backup frequency must be ether 12 or 24
az sql db str-policy set \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --retention-days 28 \
    --diffbackup-hours 24

Modifier la stratégie de rétention à court terme à l’aide de PowerShell

Notes

Cet article utilise le module Azure Az PowerShell, qui est le module PowerShell recommandé pour interagir avec Azure. Pour démarrer avec le module Az PowerShell, consulter Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.

Important

Le module PowerShell AzureRM est toujours pris en charge par SQL Database et SQL Managed Instance, mais tout développement futur concerne le module Az.Sql. Pour plus d’informations, consultez la page AzureRM.Sql. Les arguments des commandes dans le module Az sont essentiellement identiques à ceux utilisés dans les modules AzureRm.

Pour modifier la rétention de sauvegarde PITR et la fréquence de sauvegarde différentielle pour les bases de données SQL Azure actives, utilisez l’exemple PowerShell suivant.

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28
# SET new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24. 
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24

Modifier la stratégie de rétention à court terme à l’aide de l’API REST

La demande ci-dessous met à jour la période de rétention à 28 jours et définit également la fréquence de sauvegarde différentielle sur 24 heures.

Exemple de demande

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2021-02-01-preview

Corps de la demande

{ 
    "properties":{
        "retentionDays":28,
        "diffBackupIntervalInHours":24
  }
}

Exemple de réponse :

{ 
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28,
    "diffBackupIntervalInHours":24
  }
}

Pour plus d’informations, consultez API REST de conservation des sauvegardes.

Sauvegardes et redondance du stockage Hyperscale

Les bases de données Hyperscale dans Azure SQL Database utilisent une architecture unique avec un stockage hautement évolutif et des niveaux de performances de calcul.

Les sauvegardes Hyperscale sont basées sur des instantanés et sont presque instantanées. Le journal généré est stocké dans le stockage Azure à long terme pour la période de rétention des sauvegardes. L’architecture Hyperscale n’utilise pas de sauvegardes complètes de base de données ou de sauvegardes de fichiers journaux. Par conséquent, la fréquence de sauvegarde, les coûts de stockage, la planification, le stockage et la redondance, et les fonctionnalités de restauration mentionnés dans les sections précédentes de cet article ne s’appliquent pas.

Performances de la sauvegarde et de la restauration Hyperscale

La séparation du stockage et du calcul permet à Hyperscale de pousser l’opération de sauvegarde et restauration vers la couche de stockage afin de réduire la charge de traitement sur le réplica de calcul principal. Par conséquent, les sauvegardes de base de données n’influencent pas les performances du nœud de calcul principal.

Les opérations de sauvegarde et de restauration pour les bases de données Hyperscale sont rapides, quelle que soit la taille des données en raison de l’utilisation de captures instantanées de stockage. Une base de données peut être restaurée à n’importe quel point dans le temps dans la période de conservation de sauvegarde. La restauration à un instant dans le passé est effectuée en rétablissant les instantanés de fichier et n’a donc pas la taille d’une opération de données. La restauration d’une base de données Hyperscale dans la même région Azure est une opération à temps constant, et même les bases de données de plusieurs téraoctets peuvent être restaurées en quelques minutes au lieu de plusieurs heures ou jours. La création de nouvelles bases de données en restaurant une sauvegarde existante ou la copie de base de données tire également parti de cette fonctionnalité : la création de copies de base de données à des fins de développement ou de test, notamment des bases de données de plusieurs téraoctets, est réalisable en minutes dans la même région, lorsque le même type de stockage est utilisé.

Rétention de sauvegarde Hyperscale

Par défaut, la durée de conservation de sauvegarde à court terme pour les bases de données Hyperscale est de 7 jours. Les stratégies de conservation à long terme ne sont pas prises en charge.

Notes

La conservation de sauvegarde à court terme (35 jours maximum) pour les bases de données Hyperscale est actuellement en préversion.

Planification des sauvegardes Hyperscale

Il n’existe pas de sauvegardes complètes, différentielles et de fichier journal traditionnelles pour les bases de données Hyperscale. Au lieu de cela, des captures instantanées de stockage de fichiers de données sont effectuées. Le journal des transactions généré est conservé en l’état pendant la période de conservation configurée. Au moment de la restauration, les enregistrements de journal des transactions pertinents sont appliqués à l’instantané du stockage restauré, ce qui génère une base de données cohérente d’un point de vue transactionnel, sans aucune perte de données, à compter du moment spécifié au sein de la période de conservation.

Coûts du stockage des sauvegardes Hyperscale

Le coût de stockage de sauvegarde Hyperscale dépend de la région et de la redondance du stockage de sauvegarde choisies. Cela dépend également du type de charge de travail. Les charges de travail intenses en écriture sont davantage susceptibles de modifier fréquemment les pages de données, ce qui entraîne des captures instantanées de stockage plus volumineuses. Ces charges de travail génèrent également des journaux de transactions plus volumineux, contribuant ainsi aux coûts de sauvegarde globaux. Le stockage de sauvegarde est facturé en fonction de la consommation de Go/mois. Pour connaître les tarifs, consultez la page Tarifs Azure SQL Database.

Pour Hyperscale, le stockage de sauvegarde facturable est calculé de la façon suivante :

Total billable backup storage size = (Data backup storage size + Log backup storage size)

La taille du stockage de données n’est pas incluse dans la sauvegarde facturable car elle est déjà facturée en tant que stockage de base de données alloué.

Les bases de données Hyperscale supprimées entraînent des coûts de sauvegarde liés à la capacité d’effectuer une récupération à un point dans le temps avant la suppression. Pour une base de données Hyperscale supprimée, le stockage de sauvegarde facturable est calculé de la façon suivante :

Total billable backup storage size for deleted Hyperscale database = (Data storage size + Data backup size + Log backup storage size) * (remaining backup retention period after deletion/configured backup retention period)

La taille du stockage de données est incluse dans la formule, car le stockage de base de données alloué n’est pas facturé séparément pour une base de données supprimée. Pour une base de données supprimée, les données sont stockées après suppression pour permettre leur récupération pendant la période de conservation de sauvegarde configurée. Le stockage de sauvegarde facturable pour une base de données supprimée diminue progressivement au fil du temps après sa suppression. Il atteint zéro lorsque les sauvegardes ne sont plus conservées et que la récupération n’est plus possible. Toutefois, s’il s’agit d’une suppression définitive et que les sauvegardes ne sont plus nécessaires, pour optimiser les coûts, vous pouvez réduire la période de conservation avant de supprimer la base de données.

Monitoring de la consommation des sauvegardes Hyperscale

Dans Hyperscale, la taille du stockage de sauvegarde de données (taille de la sauvegarde d’instantanés), la taille du stockage des données (taille de la base de données) et la taille du stockage de sauvegarde de journaux (taille de la sauvegarde des journaux de transactions) sont indiquées dans les métriques Azure Monitor.

Pour afficher les métriques de sauvegarde et de stockage des données dans le portail Azure, effectuez les étapes suivantes :

  1. Accédez à la base de données Hyperscale dans laquelle vous souhaitez monitorer les métriques de sauvegarde et de stockage des données.
  2. Sélectionnez la page Métriques dans la section Monitoring.

Screenshot of the Azure portal showing the Hyperscale Backup storage metrics

  1. Dans la liste déroulante Métrique, sélectionnez les métriques Stockage des sauvegardes de données et Stockage des sauvegardes de journaux avec une règle d’agrégation appropriée.

Réduire la consommation du stockage de sauvegarde

Pour une base de données Hyperscale, la consommation du stockage de sauvegarde dépend de la période de conservation, du choix de la région, de la redondance du stockage de sauvegarde et du type de la charge de travail. Envisagez les diverses techniques d’ajustement suivantes pour réduire votre consommation de stockage de sauvegarde pour une base de données Hyperscale :

  • Réduisez la période de rétention de la sauvegarde au minimum possible pour vos besoins.
  • N’effectuez pas d’opérations d’écriture volumineuses (comme la maintenance d’index) plus fréquemment que nécessaire. Pour connaître les recommandations relatives à la maintenance des index, consultez Optimiser la maintenance des index pour améliorer les performances des requêtes et réduire la consommation des ressources.
  • Pour les opérations de chargement de données volumineuses, nous vous conseillons d’utiliser la compression des données.
  • Utilisez la base de données tempdb au lieu de tables permanentes dans votre logique d’application pour stocker les résultats et/ou les données temporaires.
  • Utilisez le stockage de sauvegarde localement redondant ou redondant interzone lorsque la fonctionnalité de géorestauration n’est pas nécessaire (par exemple, dans les environnements dev/test).

La redondance de stockage Hyperscale s’applique à la fois au stockage de données et au stockage de sauvegarde

Hyperscale prend en charge la redondance de stockage configurable. Lors de la création d’une base de données Hyperscale, vous pouvez choisir votre type de stockage préféré : stockage géo-redondant avec accès en lecture (RA-GRS), stockage redondant interzone (ZRS) ou stockage localement redondant (LRS) stockage standard Azure. L’option de redondance de stockage sélectionnée est utilisée pendant la durée de vie de la base de données pour la redondance de stockage de données et la redondance de stockage de sauvegarde.

Envisagez la redondance de stockage avec précaution lorsque vous créez une base de données Hyperscale

La redondance du stockage de sauvegarde pour les bases de données Hyperscale peut être définie uniquement durant la création de la base de données. Ce paramètre ne peut pas être modifié après le provisionnement de la ressource. La géorestauration n’est disponible que lorsque le stockage géoredondant (RA-GRS) est choisi pour la redondance du stockage de bases de données. Le processus de copie de base de données peut être utilisé pour mettre à jour les paramètres de redondance du stockage pour une base de données Hyperscale existante. La copie d’une base de données vers un type de stockage différent sera une opération de taille de données. Pour obtenir un exemple de code, consultez Configurer la redondance du stockage de sauvegarde.

Important

Pour le moment, le stockage redondant interzone est uniquement disponible dans certaines régions.

Restauration d’une base de données Hyperscale dans une autre région

Si vous avec besoin de restaurer une base de données Hyperscale dans Azure SQL Database dans une région autre que celle dans laquelle elle est actuellement hébergée, à des fins de récupération d’urgence, d’exploration, de relocalisation ou pour tout autre motif, la méthode principale consiste à opérer une géo-restauration de la base de données. La procédure à suivre est exactement la même que celle utilisée pour restaurer une base de données dans SQL Database dans une autre région :

  1. Créez un serveur dans la région cible si vous n'y disposez pas encore d'un serveur approprié. Ce serveur doit appartenir au même abonnement que le serveur (source) d’origine.
  2. Suivez les instructions de la section géo-restauration sur la page consacrée à la restauration d’une base de données dans Azure SQL Database à partir de sauvegardes automatiques.

Notes

Étant donné que la source et la cible se trouvent dans des régions distinctes, la base de données ne peut pas partager de stockage de captures instantanées avec la base de données source, comme c’est le cas dans le cadre de restaurations non géographiques qui s’opèrent rapidement quelle que soit la taille de la base de données. Dans le cas d’une géo-restauration d’une base de données Hyperscale, il s’agit d’une opération tributaire de la taille des données, même si la cible se trouve dans la région associée du stockage géo-répliqué. Par conséquent, la géo-restauration prend un temps proportionnel à la taille de la base de données restaurée. Si la cible se trouve dans la région associée, le transfert de données est effectué au sein d’une région, ce qui est beaucoup plus rapide qu’un transfert de données entre régions, mais il s’agit toujours d’une opération à l’échelle des données.

Si vous préférez, vous pouvez également copier la base de données dans une autre région. En savoir plus sur la Copie de base de données pour Hyperscale.

Configuration de la redondance du stockage de sauvegarde

La redondance de stockage de sauvegarde pour les base de données dans Azure SQL Database peut être configurée au moment de la création de la base de données ou peut être mise à jour pour une base de données existante ; les modifications apportées à une base de données existante s’appliquent uniquement aux sauvegardes ultérieures. La valeur par défaut est le stockage géoredondant. Pour connaître les différences de prix entre le stockage de sauvegarde localement redondant, redondant interzone et géoredondant, consultez la page Tarification Azure SQL Managed Instance. La redondance de stockage pour les bases de données Hyperscale est unique : en savoir plus sur Sauvegardes et redondance de stockage Hyperscale.

Pour Azure SQL Managed Instance, la redondance du stockage de sauvegarde est définie au niveau de l’instance et elle est appliquée à toutes les bases de données managées y appartenant. Elle peut être configurée au moment de la création d’une instance ou mise à jour pour des instances existantes. La modification de la redondance du stockage de sauvegarde déclencherait alors une nouvelle sauvegarde complète par base de données et cette modification s’appliquera à toutes les sauvegardes futures. Le type de redondance de stockage par défaut est une redondance géographique (RA-GRS).

Configurez la redondance du stockage de sauvegarde à l’aide du Portail Azure

Dans le portail Azure, vous pouvez configurer la redondance du stockage de sauvegarde dans le volet Créer une base de données SQL. L’option est disponible sous la section Redondance du stockage de sauvegarde.

Open Create SQL Database pane

Configurer la redondance du stockage de sauvegarde à l’aide d’Azure CLI

Pour configurer la redondance du stockage de sauvegarde lors de la création d’une base de données, vous pouvez spécifier le paramètre --backup-storage-redundancy avec la commande az sql db create. Les valeurs possibles sont Geo, Zone et Local. Par défaut, toutes les bases de données d’Azure SQL Database utilisent le stockage géoredondant pour les sauvegardes. La géorestauration est désactivée si une base de données est créée ou mise à jour avec un stockage de sauvegarde localement redondant ou redondant interzone.

Cet exemple crée une base de données dans le niveau de service Usage général avec la redondance de sauvegarde locale :

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier GeneralPurpose \
    --backup-storage-redundancy Local

Examinez attentivement l’option de configuration de --backup-storage-redundancy lors de la création d’une base de données hyperscale. La redondance de stockage ne peut être spécifiée que lors du processus de création de la base de données pour les bases de données Hyperscale. L’option de redondance de stockage sélectionnée sera utilisée pendant la durée de vie de la base de données pour la redondance de stockage de données et la redondance de stockage de sauvegarde. Plus d’informations sur Sauvegardes et redondance du stockage Hyperscale.

Les bases de données Hyperscale existantes peuvent migrer vers différentes redondances de stockage à l’aide de la copie de base de données ou la restauration dans le temps : exemple de code pour copier une base de données hyperscale se trouve dans cette section.

Cet exemple crée une base de données dans le niveau de service hyperscale avec redondance de zone :

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier Hyperscale \
    --backup-storage-redundancy Zone

Pour plus d’informations, consultez la page sur les commandes az sql db create et az sql db update.

À l’exception des bases de données Hyperscale et de niveau de base, vous pouvez mettre à jour le paramètre de redondance du stockage de sauvegarde pour une base de données existante à l’aide du paramètre --backup-storage-redundancy et de la commande az sql db update. Il peut falloir jusqu’à 48 heures pour que les modifications soient appliquées à la base de données. Le passage d’un stockage de sauvegarde géoredondant à un stockage localement redondant ou redondant interzone désactive la géorestauration.

Cet exemple de code modifie la redondance de stockage de sauvegarde en Local .

az sql db update \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --backup-storage-redundancy Local

Vous ne pouvez pas mettre à jour la redondance de stockage de sauvegarde d’une base de données Hyperscale directement. Toutefois, vous pouvez la modifier à l’aide de la commande de copie de base de données avec le paramètre --backup-storage-redundancy. Cet exemple copie une base de données Hyperscale vers une nouvelle base de données à l’aide du matériel Gen5 et de deux vCores. La redondance de sauvegarde de la nouvelle base de données est définie sur Zone.

az sql db copy \
    --resource-group myresourcegroup \ 
    --server myserver 
    --name myHSdb 
    --dest-resource-group mydestresourcegroup 
    --dest-server destdb 
    --dest-name myHSdb 
    --service-objective HS_Gen5_2 
    --read-replicas 0 
    --backup-storage-redundancy Zone

Pour plus d’informations sur la syntaxe, consultez az sql db copy. Pour obtenir une vue d’ensemble de la copie de la base de données, consultez Copier une copie cohérente d’un niveau transactionnel d’une base de données dans Azure SQL Database.

Configurer la redondance du stockage de sauvegarde à l’aide de PowerShell

Pour configurer la redondance du stockage de sauvegarde lors de la création d’une base de données, vous pouvez spécifier le paramètre -BackupStorageRedundancy avec l’applet de commande New-AzSqlDatabase. Les valeurs possibles sont Geo, Zone et Local. Par défaut, toutes les bases de données d’Azure SQL Database utilisent le stockage géoredondant pour les sauvegardes. La géorestauration est désactivée si une base de données est créée avec un stockage de sauvegarde localement redondant ou redondant interzone.

Cet exemple crée une base de données dans le niveau de service Usage général avec la redondance de sauvegarde locale :

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Local

Examinez attentivement l’option de configuration de --backup-storage-redundancy lors de la création d’une base de données hyperscale. La redondance de stockage ne peut être spécifiée que lors du processus de création de la base de données pour les bases de données Hyperscale. L’option de redondance de stockage sélectionnée sera utilisée pendant la durée de vie de la base de données pour la redondance de stockage de données et la redondance de stockage de sauvegarde. Plus d’informations sur Sauvegardes et redondance du stockage Hyperscale.

Les bases de données existantes peuvent migrer vers différentes redondances de stockage à l’aide de la copie de base de données ou la restauration dans le temps : exemple de code pour copier une base de données hyperscale se trouve dans cette section.

Cet exemple crée une base de données dans le niveau de service hyperscale avec redondance de zone :

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "Hyperscale" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Zone

Pour plus d’informations sur la syntaxe, consultez New-AzSqlDatabase.

À l’exception des bases de données Hyperscale et de niveau de base, vous pouvez utiliser le paramètre -BackupStorageRedundancy avec l’applet de commande Set-AzSqlDatabase pour mettre à jour le paramètre de redondance de stockage de sauvegarde pour une base de données existante. Les valeurs possibles sont Geo, Zone et Local. Il peut falloir jusqu’à 48 heures pour que les modifications soient appliquées à la base de données. Le passage d’un stockage de sauvegarde géoredondant à un stockage localement redondant ou redondant interzone désactive la géorestauration.

Cet exemple de code modifie la redondance de stockage de sauvegarde en Local .

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Local

Pour plus d’informations, consultez la page Set-AzSqlDatabase.

La redondance de stockage de sauvegarde d’une base de données hyperscale existante ne peut pas être mise à jour. Toutefois, vous pouvez utiliser la commande de copie de base de données pour créer une copie de la base de données et utiliser le paramètre -BackupStorageRedundancy pour mettre à jour la redondance du stockage de sauvegarde. Cet exemple copie une base de données Hyperscale vers une nouvelle base de données à l’aide du matériel Gen5 et de deux vCores. La redondance de sauvegarde de la nouvelle base de données est définie sur Zone.

# Change the backup storage redundancy for Database01 to zone-redundant. 
New-AzSqlDatabaseCopy -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "HSSourceDB" -CopyResourceGroupName "DestResourceGroup" -CopyServerName "DestServer" -CopyDatabaseName "HSDestDB" -Vcore 2 -ComputeGeneration "Gen5" -ComputeModel Provisioned -BackupStorageRedundancy Zone

Pour plus d’informations sur la syntaxe, consultez New-AzSqlDatabaseCopy.

Pour obtenir une vue d’ensemble de la copie de la base de données, consultez Copier une copie cohérente d’un niveau transactionnel d’une base de données dans Azure SQL Database.

Notes

Pour utiliser le paramètre -BackupStorageRedundancy avec les opérations « database restore », « database copy » ou « create secondary », utilisez Azure PowerShell version Az.Sql 2.11.0.

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 souhaiterez peut-être appliquer des sauvegardes redondantes interzones ou localement redondantes pour votre base de données SQL ou votre instance managée à 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

Les nouvelles stratégies intégrées suivantes sont ajoutées et peuvent être attribuées au niveau de l’abonnement ou du groupe de ressources pour bloquer la création de nouvelles bases de données ou instances avec un stockage de sauvegarde géoredondant.

SQL Database doit éviter d’utiliser la redondance de sauvegarde GRS

Les instances managées SQL doivent éviter d’utiliser la redondance de sauvegarde GRS

Vous trouverez une liste complète des définitions de stratégies intégrées pour SQL Database et Managed Instance ici.

Pour appliquer les exigences en matière de résidence des données au niveau de l’organisation, ces stratégies peuvent être attribuées à un abonnement. Une fois ces stratégies attribuées au niveau de l’abonnement, les utilisateurs de l’abonnement en question ne pourront pas créer de base de données ni d’instance managée avec un stockage de sauvegarde géoredondant via le portail Azure ou Azure PowerShell.

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.

Découvrez comment attribuer des stratégies à l’aide du portail Azure ou d’Azure PowerShell.

Étapes suivantes