Sauvegardes automatisées dans Azure SQL Database

S’applique à : Azure SQL Database

• Azure SQL Database
• Azure SQL Managed Instance

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

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

Qu’est-ce 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 (LTR) à la fois pour les bases de données uniques et mises en pool.

Pour les niveaux de service autres que Hyperscale, Azure SQL Database utilise la technologie du moteur SQL Server pour sauvegarder et restaurer des données. Les bases de données Hyperscale utilisent une sauvegarde et une restauration basées sur des instantanés de stockage. Avec la technologie de sauvegarde SQL Server traditionnelle, les sauvegardes ou restaurations de bases de données volumineuses prennent un temps considérable. Grâce à l’utilisation d’instantanés, Hyperscale offre des fonctionnalités de sauvegarde instantanée et de restauration rapide, quelle que soit la taille de la base de données. Pour plus d’informations, consultez Sauvegardes Hyperscale.

Fréquence de sauvegarde

Azure SQL Database crée les sauvegardes suivantes :

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

La fréquence exacte 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.

L'architecture Hyperscale ne nécessite pas de sauvegardes complètes, différentielles ou de fichier journal. Pour plus d’informations, consultez Sauvegardes Hyperscale.

Redondance du stockage de sauvegarde

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 être des défaillances matérielles temporaires, des pannes de réseau ou de courant, ou des catastrophes naturelles massives.

Par défaut, les nouvelles bases de données dans Azure SQL Database stockent les sauvegardes dans des objets blob de stockage géoredondants qui sont répliqués dans une région jumelée. La géoredondance permet de se protéger contre les pannes affectant le stockage de sauvegarde dans la région primaire. Elle vous permet également de restaurer vos bases de données dans une autre région en cas de panne régionale.

Le portail Azure fournit une option d'environnement de charge de travail qui permet de prédéfinir certains paramètres de configuration. Ces paramètres peuvent être remplacés. Cette option s’applique uniquement à la page du portail Créer une base de données SQL.

• Le choix de l'environnement de charge de travail de développement définit l'option de redondance du stockage de sauvegarde pour utiliser le stockage localement redondant. Le stockage localement redondant est moins coûteux et convient aux environnements de préproduction qui ne nécessitent pas la redondance d'un stockage répliqué par zone ou géorépliqué.
• Le choix de l’environnement de charge de travail de production définit la redondance du stockage de sauvegarde sur le stockage géoredondant, la valeur par défaut.
• L’option d’environnement de charge de travail modifie également le paramètre initial pour le calcul, bien que cela puisse être remplacé. Sinon, l’option d’environnement de charge de travail n’a aucun impact sur les licences ou d’autres paramètres de configuration de la base de données.

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. La redondance du stockage de sauvegarde configurée est appliquée aux sauvegardes de rétention à court terme (STR) et à long terme (LTR). 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 base de données, et la mettre à jour ultérieurement. Les modifications que vous apportez à une base de données existante s’appliquent uniquement aux sauvegardes ultérieures. Après une 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.

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

• Stockage localement redondant (LRS) : copie vos sauvegardes de façon synchrone trois fois au sein d’un même emplacement physique dans la région primaire. Le LRS est l’option de stockage la moins coûteuse, mais nous ne la recommandons pas pour des applications nécessitant une résilience aux pannes régionales ou une garantie de durabilité élevée des données.

  

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

  

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

  Le résultat est le suivant :

  • Trois copies synchrones dans la région primaire.
  • Trois copies synchrones dans la région jumelée qui ont été copiées de la région primaire vers la région associée de façon asynchrone.

  

Avertissement

• La géo-restauration est désactivée dès qu’une base de données est mise à jour pour utiliser un stockage localement redondant ou redondant interzone.
• Les diagrammes de redondance du stockage montrent tous des régions avec plusieurs zones de disponibilité (multi-az). Toutefois, certaines régions ne fournissent qu’une seule zone de disponibilité et ne prennent pas en charge le stockage redondant interzone.
• La redondance du stockage de sauvegarde pour les bases de données Hyperscale ne peut être définie que durant la création. Vous ne pourrez plus modifier ce paramètre après l’approvisionnement de la ressource. Pour mettre à jour les paramètres de redondance du stockage de sauvegarde pour une base de données Hyperscale existante moyennant un minimum de temps d’arrêt, utilisez une géoréplication active. Vous pouvez également utiliser une copie de base de données. Plus d’informations sur Sauvegardes Hyperscale et redondance du stockage.

Utilisation de la sauvegarde

Vous pouvez utiliser des sauvegardes créées automatiquement dans les scénarios suivants :

• Restaurez une base de données existante à un instant dans le passé s’inscrivant dans la période de rétention, en utilisant le portail Azure, Azure PowerShell, Azure CLI ou l’API REST. 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 utilise un nom différent pour éviter le remplacement de la base de données d’origine.

  Une fois la restauration terminée, vous pouvez supprimer la base de données d’origine et utiliser son nom pour renommer la base de données restaurée. Au lieu de supprimer la base de données d’origine, vous pouvez aussi larenommer, puis utiliser son nom d’origine pour renommer la base de données restaurée.

• Restaurer une base de données supprimée à un instant dans le passé s’inscrivant dans la période de rétention incluant le temps de suppression. La base de données supprimée ne peut être restaurée que sur le serveur utilisé pour créer la base de données d’origine. 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éo-restauration vous permet de récupérer d’une panne régionale 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 une un serveur existant dans n’importe quelle région Azure.

  Important

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

• Restaurez une base de données à partir d’une sauvegarde à long terme spécifique d’une base de données simple 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 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 Rétention à long terme.

Les sauvegardes automatiques sur les réplicas secondaires

Les sauvegardes automatiques sont désormais extraites d’un réplica secondaire dans le niveau de service Critique pour l'entreprise. Étant donné que les données sont répliquées entre les processus SQL Server sur chaque nœud, le service de sauvegarde effectue la sauvegarde à partir des réplicas secondaires non lisibles. Cette conception garantit que le réplica principal reste dédié à votre charge de travail principale et que le réplica secondaire lisible est dédié aux charges de travail en lecture seule. Les sauvegardes automatiques dans le niveau de service Critique pour l'entreprise sont extraites d’un réplica secondaire la plupart du temps. Si une sauvegarde automatique échoue sur un réplica secondaire, le service de sauvegarde effectue la sauvegarde à partir du réplica principal.

Les sauvegardes automatiques sur les réplicas secondaires :

• Sont activés par défaut.
• Sont inclus sans frais supplémentaires au-delà du prix du niveau de service.
• Apportez des performances et une prévisibilité améliorées au niveau de service Critique pour l'entreprise.

Remarque

• Créez un ticket de support Microsoft pour désactiver la fonctionnalité de votre instance.

Capacités et fonctionnalités de restauration

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

Propriété de sauvegarde	Restauration à un instant dans le passé	La géorestauration	LTR
Types de sauvegardes SQL	Complète, différentielle, de journal.	Les copies géorépliquées les plus récentes des sauvegardes PITR.	Uniquement les sauvegardes complètes.
Objectif de point de récupération (RPO)	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	Valeur par défaut : 7 jours. Configurable entre 1 et 35 jours (à l’exception des bases de données De base, où la valeur est configurable entre 1 et 7 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 quand la redondance du stockage de sauvegarde avec récupération jusqu’à une date et heure est définie comme géoredondante. Non disponible quand le stockage de sauvegarde avec restauration à un instant dans le passé est localement redondant ou redondant interzone.	Géoredondant par défaut. Vous pouvez configurer un stockage localement redondant ou redondant interzone.
Configurer des sauvegardes comme immuables	Non pris en charge	Non pris en charge	Non pris en charge
Restauration d’une nouvelle base de données dans la même région	Prise en charge	Prise en charge	Prise en charge
Restauration d’une nouvelle base de données dans une autre région	Non pris en charge	Prise en charge dans toutes les régions Azure	Prise en charge dans toutes les régions Azure
Restauration d’une nouvelle base de données dans un autre abonnement	Non pris en charge	Non pris en charge3	Non pris en charge3
Restauration via le portail Azure	Oui	Oui	Oui
Restauration via PowerShell	Oui	Oui	Oui
Restauration via 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é d'activité, utilisez des groupes de basculement.
² Toutes les sauvegardes PITR sont stockées par défaut sur un espace de stockage géoredondant, la géo-restauration 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, ou à utiliser une copie de base de données d'abonnement inter-abonnements.

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

Pour effectuer une restauration, consultez Restaurer une base de données à partir de sauvegardes. Vous pouvez explorer 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

Exporter une base de données

Les sauvegardes automatiques effectuées par le service Azure ne sont pas disponibles en téléchargement ou accès direct. Elles ne peuvent être utilisées que pour les opérations de restauration via Azure.

Il existe des alternatives pour exporter une base de données Azure SQL. Si vous avez besoin d’exporter une base de données afin de l’archiver ou de la déplacer vers une autre plateforme, vous pouvez exporter le schéma et les données de cette base de données vers un fichier BACPAC. Un fichier BACPAC est un fichier ZIP avec extension BACPAC contenant les métadonnées et les données de la base de données. Il peut être stocké dans Stockage Blob Azure ou dans un stockage local, à un emplacement local, puis réimporté vers Azure SQL Database, Azure SQL Managed Instance ou une instance de SQL Server.

Vous pouvez également Importer ou exporter une instance Azure SQL Database à l’aide d’une liaison privée ou Importer ou exporter une instance Azure SQL Database sans autoriser les services Azure à accéder au serveur.

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 prend généralement 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 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.

Important

• Pour une base de données nouvelle, restaurée ou copiée, la fonction de restauration à un instant dans le passé est disponible dès la création de la sauvegarde initiale du journal des transactions qui suit la sauvegarde complète initiale.
• Les bases de données Hyperscale sont protégées dès leur création, contrairement aux autres bases de données dont la sauvegarde initiale prend du temps. La protection de la base de données Hyperscale est immédiate, même si elle a été créée avec une grande quantité de données copiées ou restaurées. Pour en savoir plus, consultez Sauvegardes automatisées Hyperscale.

Consommation de stockage de sauvegarde

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

Azure SQL Database planifie 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 bases de données Hyperscale utilisent un mécanisme de planification de sauvegarde différent. Pour plus d’informations, consultez Planification des sauvegardes Hyperscale.

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

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

Important

Pour les bases de données chiffrées par TDE, les fichiers de sauvegarde des journaux ne sont pas compressés pour des raisons de performances. Les sauvegardes de journaux pour les bases de données non chiffrées TDE sont compressées.

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

Important

Les sauvegardes d’une base de données 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, elles peuvent augmenter les coûts de stockage de sauvegarde. La raison à cela est que le service conserve des 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. La capture d’écran suivante montre comment surveiller la consommation de stockage des sauvegardes pour une base de données unique.

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

Rétention des sauvegardes

Azure SQL Database fournit une rétention à court terme 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 Database conserve des sauvegardes suffisantes pour autoriser la récupération jusqu’à une date et heure au cours des 7 derniers jours par défaut. 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.

Les sauvegardes différentielles peuvent être configurées pour se produire une fois en 12 heures ou une fois en 24 heures. Une fréquence de sauvegarde différentielle de 24 heures allonger le temps de restauration de la base de données, par rapport à la fréquence de 12 heures. Dans le modèle vCore, la fréquence par défaut des sauvegardes différentielles est une fois en 12 heures. Dans le modèle DTU, la fréquence par défaut est une fois en 24 heures.

Vous pouvez spécifier votre option de redondance du stockage de sauvegarde pour conservation à court terme (STR) lorsque vous créez votre base de données, puis la modifier ultérieurement. Si vous modifiez votre option de redondance de sauvegarde une fois votre base de données créée, les nouvelles sauvegardes utilisent la nouvelle option de redondance. Les copies de sauvegarde effectuées avec l'option de redondance de conservation à court terme (STR) précédente ne sont pas déplacées ou copiées. Elles sont laissées dans le compte de stockage d’origine jusqu’à ce que la période de rétention expire, à l’issue de 1 à 35 jours.

Vous pouvez modifier la période de rétention des sauvegardes pour chaque base de données active dans une fourchette de 1 à 35 jours, à l'exception des bases de données de base pour lesquelles cette valeur est configurable entre 1 et 7 jours. 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. 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.

Si vous supprimez une base de données, le système conserve les sauvegardes de la même façon pour une base de données en ligne avec sa période de rétention spécifique. Vous ne pouvez pas modifier la durée de rétention des sauvegardes pour une base de données supprimée.

Important

Si vous supprimez un serveur, toutes les bases de données stockées sur celui-ci sont également supprimées, et deviennent irrécupérables. Vous ne pouvez pas restaurer un serveur supprimé. Toutefois, si vous avez configuré une conservation à long terme pour une base de données, les sauvegardes de conservation à long terme (LTR) ne sont pas supprimées. Vous pouvez ensuite les utiliser pour restaurer des bases de données sur un serveur différent dans le même abonnement, à un instant dans le passé où une sauvegarde LTR a été effectuée. Pour en savoir plus, consultez Restaurer une sauvegarde à long terme.

Rétention à long terme

Pour SQL Database, vous pouvez configurer des sauvegardes de conservation à long terme (LTR) pendant 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 fréquence dépend de la stratégie. Par exemple, le paramétrage de W=0, M=1 créerait une copie de conservation à long terme (LTR) mensuelle. Pour plus d’informations sur la conservation à long terme, consultez Conservation à long terme.

La mise à jour de la redondance du stockage de sauvegarde pour une base de données existante s’applique uniquement aux sauvegardes à avenir, non aux sauvegardes existantes. Toutes les sauvegardes LTR existantes pour la base de données continuent de résider dans l'objet blob de stockage existant. Les nouvelles sauvegardes sont répliquées en fonction de la redondance du stockage de sauvegarde configurée.

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.

Lors de la restauration une base de données Hyperscale à partir d’une sauvegarde LTR, la propriété d’échelle lecture est désactivée. Pour activer la propriété échelle lecture sur la base de données restaurée, mettez à jour la base de données après sa création. Vous devez spécifier l’objectif de niveau de service cible quand vous effectuez une restauration à partir d’une sauvegarde LTR.

La conservation à long terme peut être activée pour les bases de données Hyperscale créées ou migrées à partir d'autres niveaux de service. Si vous tentez d'activer LTR pour une base de données hyperscale dans laquelle elle n'est pas encore prise en charge, vous recevez le message d'erreur suivant : « Une erreur s'est produite lors de l'activation de la rétention de sauvegarde à long terme pour cette base de données. Veuillez contacter le support Microsoft pour activer la rétention des sauvegardes à long terme ». Dans ce cas, contactez le support Microsoft et créez un ticket de support pour résoudre ce problème.

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 de la région. Le stockage de sauvegarde est facturé sur la base des gigaoctets consommés par mois, au même taux pour toutes les sauvegardes.

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

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

Pour obtenir des informations sur les prix, consultez la page Tarification d’Azure SQL Database.

Notes

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

Modèle DTU

Dans le modèle DTU, pour les bases de données et les pools élastiques, il n’y a pas de frais supplémentaires pour le stockage de sauvegarde PITR pour la conservation par défaut de 7 jours et au-delà. Le prix du stockage de sauvegarde PITR est inclus dans celui de la base de données ou du pool.

Important

Dans le modèle DTU, les bases de données et les pools élastiques sont facturés pour le stockage de sauvegarde LTR en fonction du stockage réel consommé par les sauvegardes LTR.

Modèle vCore

Azure SQL Database 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 coût du stockage de sauvegarde est calculé différemment pour les bases de données Hyperscale. Pour plus d’informations, consultez Coûts du stockage des sauvegardes Hyperscale.

Pour les bases de données uniques, une quantité de stockage de sauvegarde égale à 100 % de la taille maximale de stockage des données est fournie sans frais supplémentaires. L’équation suivante 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 des pools élastiques, une quantité de stockage de sauvegarde égale à 100 % du stockage maximal de données correspondant la taille du pool est fournie sans frais supplémentaires. 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

Le stockage de sauvegarde facturable total, le cas échéant, est facturé en gigaoctets par mois, en fonction du taux de redondance du stockage de sauvegarde que vous avez utilisé. Cette consommation de stockage de sauvegarde dépendra 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.

À 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 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ège cette consommation et affiche une utilisation de 744 Go pour le mois. Le coût est basé sur le tarif des gigaoctets par mois dans votre région.

Voici un autre exemple. Supposons que pour la même base de données inactive, la rétention est passée de 7 à 14 jours au milieu du mois. Cette augmentation entraîne un doublement du stockage total de sauvegarde, qui passe à 1 488 Go. SQL 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 par 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. La consommation horaire de stockage de sauvegarde fluctue en conséquence.

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

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

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

Pour le dernier scénario dans des bases de données volumineuses, une optimisation du service crée une sauvegarde complète au lieu d’une sauvegarde différentielle si celle-ci promet d’être excessivement volumineuse. 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.

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 Database pour une base de données unique ou un pool de bases de données élastique.

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. Des compteurs s'affichent uniquement en cas de consommation du stockage de sauvegarde.

   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. Des compteurs s'affichent uniquement en cas de consommation du stockage de sauvegarde.

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

Important

Des compteurs sont visibles uniquement s’ils sont en cours d’utilisation. Si un compteur n’est pas disponible, il est probable que la catégorie n’est pas en cours d’utilisation. Par exemple, les compteurs de stockage ne seront pas visibles pour les ressources qui ne consomment pas de stockage. S’il n’existe pas de consommation de stockage de sauvegarde PITR ni LTR, ces compteurs ne s’afficheront pas.

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 en savoir plus sur le TDE, consultez Transparent Data Encryption avec Azure SQL Database.

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. 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 d'une vérification de l'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

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

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 base de données 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 activez la stratégie « Azure SQL DB doit éviter d’utiliser la sauvegarde GRS », les bases de données ne peuvent pas être créées avec le stockage par défaut comme stockage globalement redondant, et les utilisateurs ne peuvent pas utiliser GRS avec le message d’erreur « La configuration du type de compte de stockage de sauvegarde sur " Standard_RAGRS " a échoué lors de la création ou de la mise à jour de la base de données ».

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

Important

Les stratégies Azure ne sont pas appliquées lors de la création d’une base de données via T-SQL. Pour spécifier 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.

Contenu connexe

• Pour en savoir plus sur d’autres solutions de continuité des activités SQL Database, consultez Vue d’ensemble de la continuité des activités.
• Pour modifier les paramètres de sauvegarde, consultez Modifier les paramètres.
• Pour restaurer une sauvegarde, consultez Récupérer à l’aide de sauvegardes ou Restaurer une base de données à un instant dans le passé à l’aide de PowerShell.
• Pour plus d’informations sur la façon de configurer, gérer et restaurer des données à partir d’une conservation à long terme de sauvegardes automatisées dans Stockage Blob Azure, consultez Gérer la rétention des sauvegardes à long terme.
• Pour Azure SQL Managed Instance, consultez sauvegardes automatisées pour SQL Managed Instance.