Sauvegardes automatisées dans Azure SQL Database

S’applique à :Azure SQL Database

• Base de données SQL Azure
• Azure SQL Managed Instance

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

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 traditionnelle de sauvegarde SQL Server, les grandes bases de données ont de longs temps de sauvegarde et de restauration. En utilisant des instantanés, Hyperscale offre des capacité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 des journaux de transaction dépend de la taille du calcul et de l’activité de la base de données. Lorsque vous restaurez une base de données, Azure SQL Database détermine quelles sauvegardes complètes, différentielles et de journaux de transactions restaurer.

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 stocke plusieurs copies de vos données afin de les protéger contre les événements planifiés et imprévus. 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. Vous pouvez contourner ces paramètres. 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 environnement Workload modifie aussi le paramètre initial pour le calcul, bien que vous puissiez contourner ce paramètre. 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 garantir que vos sauvegardes restent dans la même région où votre base de données est déployée, changez la redondance du stockage de sauvegarde du stockage géo-redondant par défaut vers d’autres types de stockage qui maintiennent vos données dans 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 lors de la création de votre base de données, et la mettre à jour plus tard. Les modifications que vous apportez à une base de données existante ne concernent que les sauvegardes futures. 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. LRS est l’option de stockage la moins coûteuse, mais il n’est pas recommandé pour les applications nécessitant une résilience face aux coupures régionales ou une garantie d’une grande durabilité 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. Il 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). Ensuite, il copie vos données de façon asynchrone trois fois dans un emplacement physique unique dans la région secondaire jumelée.

  Le résultat est le suivant :

  • Trois copies synchrones dans la région primaire.
  • Trois copies synchrones dans la région jumelée, transférées depuis la région primaire vers la région secondaire de manière asynchrone.

  

• Geo-Zone stockage redondant (GZRS) : le stockage géoredondant interzone (GZRS) combine la haute disponibilité fournie par la redondance entre les zones de disponibilité (ZRS) et la protection contre les pannes régionales fournies par la géoréplication (GRS). Dans GZRS, Azure copie vos sauvegardes de manière synchrone à travers trois zones de disponibilité Azure dans la région principale, et asynchrone trois fois vers un seul emplacement physique dans la région secondaire appariée.

  Microsoft recommande d'utiliser GZRS pour les applications nécessitant une cohérence maximale, une durabilité, une disponibilité, d'excellentes performances et une résilience optimale pour la reprise après sinistre.

  Le résultat est le suivant :

  • Trois copies synchrones à travers les zones de disponibilité, dans la région principale.

  • Trois copies synchrones sont effectuées dans la région jumelée, puis copiées de manière asynchrone de la région primaire vers la région secondaire.

    Le diagramme suivant montre comment vos données sont répliquées à l’aide du GZRS ou du RA-GZRS :

  

Avertissement

• La restauration géographique est désactivée dès qu’une base de données est mise à jour pour utiliser un stockage redondant localement ou par zone.
• Les diagrammes de redondance du stockage montrent tous des régions avec plusieurs zones de disponibilité (multi-az). Cependant, certaines régions ne proposent qu’une seule zone de disponibilité et ne prennent pas en charge ZRS.
• Vous pouvez configurer la redondance du stockage de sauvegarde pour les bases de données Hyperscale uniquement lors de 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

Utilisez des sauvegardes créées automatiquement dans les scénarios suivants :

• Restaurez une base de données existante à un point dans le temps 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 donné s’inscrivant dans la période de rétention, y compris le moment de la suppression. Vous ne pouvez restaurer la base de données supprimée que sur le même serveur où vous avez créé la base de données originale. Avant de supprimer une base de données, Azure SQL Database effectue une dernière sauvegarde du journal de transactions pour éviter toute perte de données.

• Restaurer une base de données dans une autre région géographique. La restauration géographique vous aide à vous remettre 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éorépliquées pour une base de données, vous pouvez modifier ce réglage 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 unique ou d’une base de données poolée, si la base de données est configurée avec une politique 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.

Avertissement

Lors de la restauration d’une base de données, si la redondance du stockage de sauvegarde source est configurée en stockage redondant interzone (GZRS), la nouvelle base de données hérite de la configuration du stockage de sauvegarde source si vous ne spécifiez pas explicitement la configuration de redondance du stockage de sauvegarde. Cet héritage s’applique à toute opération de restauration, telle que la restauration au moment donné, la copie de base de données, la restauration géographique et la restauration à partir d’une sauvegarde à long terme. Pendant cette opération, si la région Azure cible ne supporte pas la redondance spécifique du stockage de sauvegarde, l'opération de restauration échoue avec un message d'erreur approprié. Vous pouvez atténuer cette erreur en spécifiant explicitement les options de stockage disponibles pour la région.

Les sauvegardes automatiques sur les répliques secondaires

Le niveau de service Business Critical prend des sauvegardes automatiques à partir d’une réplique secondaire. É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 accessible en lecture est dédié aux charges de travail en lecture seule. Les sauvegardes automatiques dans le niveau de service Critique pour l’entreprise sont, la plupart du temps, extraites d’un réplica secondaire. Si une sauvegarde automatique échoue sur une réplique secondaire, le service de sauvegarde prend la sauvegarde de la réplique principale.

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 les fonctionnalités de la restauration à un instant donné, de la géo-restauration et de la conservation à long terme.

Pour plus d’informations sur les temps de récupération, consultez RTO et RPO.

Propriété de sauvegarde	Restauration à un instant dans le passé	La géorestauration	LTR
Types de sauvegardes SQL	Complète, différentielle, de journal.	Copies géo-répliquées les plus récentes des sauvegardes avec récupération jusqu’à une date et heure.	Uniquement les sauvegardes complètes.
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 redondant interzone ou localement redondant de manière optionnelle.	Disponible lorsque la redondance du stockage de sauvegarde avec récupération jusqu’à une date et heure est définie sur géoredondante ou géoredondante interzone (GZRS). Non disponible quand le stockage de sauvegarde avec restauration à un instant dans le passé est localement redondant ou redondant interzone.	Géoredondant par défaut. Vous pouvez configurer un stockage localement redondant ou redondant interzone.
Configurer des sauvegardes comme immuables	Non pris en charge	Non pris en charge	Supported
Restauration d’une nouvelle base de données dans la même région	Soutenu	Soutenu	Soutenu
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 métier critiques qui nécessitent des bases de données volumineuses et doivent garantir la continuité des activités, utilisez la section 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 plus d’informations sur la restauration d’une base de données, voir Restaurer une base de données à partir de sauvegardes. Pour explorer la configuration de sauvegarde et les opérations de restauration, utilisez les exemples suivants.

Opération	Portail Azure	Azure CLI (Interface de ligne de commande Azure)	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

Remarque

La restauration de bases de données entre le niveau de service Hyperscale et les autres niveaux de service de Azure SQL Database n’est actuellement pas prise en charge.

Exporter une base de données

Vous ne pouvez pas télécharger ou accéder directement aux sauvegardes automatiques effectuées par le service Azure. Azure n’utilise ces sauvegardes que pour les opérations de restauration.

Pour exporter une Azure SQL Database, envisagez d’autres alternatives.

• Lorsque vous devez exporter une base de données pour l’archivage ou pour la transférer vers une autre plateforme, exportez le schéma et les données de la base de données dans 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. Vous pouvez stocker un fichier BACPAC dans un stockage Blob Azure ou dans un stockage local sur site. Plus tard, vous pourrez le réimporter dans Azure SQL Database, Azure SQL Managed Instance ou une instance 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 programmée juste après avoir créé ou restauré 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 plus de temps sur une base de données restaurée ou une copie de base de données.

Après la première sauvegarde complète, Azure planifie et gère automatiquement toutes les sauvegardes ultérieures. Le service de base de données SQL détermine le moment exact de toutes les sauvegardes de base de données tout en équilibrant 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 est immédiate même si la base de données Hyperscale a été créée avec une grande quantité de données par copie ou restauration. Pour plus d’informations, voir 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 fournir PITR pendant toute la période de rétention, Azure doit stocker des sauvegardes complètes, différentielles et de journaux de transactions supplémentaires jusqu’à une semaine de plus que la période de rétention configurée.

En d'autres termes, pour tout point dans le temps durant la période de rétention, il doit y avoir une sauvegarde complète qui soit antérieure à la date la plus ancienne de la période de rétention. 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.

Azure supprime automatiquement les sauvegardes qui ne sont plus nécessaires pour fournir la fonctionnalité PIR. Parce que les sauvegardes différentielles et les sauvegardes de journaux nécessitent une sauvegarde complète antérieure pour être restaurables, Azure purge les trois types de sauvegarde ensemble en ensembles hebdomadaires.

Pour toutes les bases de données, y compris les bases de données chiffrées par TDE, Azure compresse toutes les sauvegardes complètes et différentielles afin de réduire la compression et les coûts de stockage de sauvegarde. Le taux moyen de compression des sauvegardes est de trois à quatre. 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 TDE, Azure ne compresse pas les fichiers de sauvegarde journalière pour des raisons de performance. Pour les bases de données non chiffrées avec TDE, les sauvegardes du journal sont compressées.

Azure SQL Database calcule votre stockage de sauvegarde total en tant que valeur cumulée. Chaque heure, Azure rapporte cette valeur au pipeline de facturation. Le pipeline est responsable de l’agrégation de cette consommation horaire afin de calculer votre consommation à la fin de chaque mois. Après avoir supprimé une base de données, 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 point dans le temps (PITR) n’est plus possible, la facturation s’arrête.

Important

Azure conserve les sauvegardes d’une base de données pour fournir le PITR même si vous supprimez la base de données. Bien que la suppression et la recréation d’une base de données puissent réduire les coûts de stockage et de calcul, cela peut augmenter les coûts de stockage de sauvegarde. La raison est qu’Azure conserve les sauvegardes pour chaque base de données supprimée, à chaque fois que vous la supprimez.

Surveiller la consommation

Pour les bases de données vCore dans Azure SQL Database, le volet de surveillance de la base de données rapporte le stockage que chaque type de sauvegarde (complète, différentielle et journal) consomme comme 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

Vous n’êtes pas facturé pour la consommation de sauvegarde jusqu’à la taille maximale de données d’une base de données. Pour réduire votre consommation de sauvegarde, considérez certaines des techniques de réglage suivantes :

• 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 vous avez des coûts de stockage de sauvegarde excédentaires élevés en continu, envisagez d’augmenter le stockage des données pour économiser 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 par défaut suffisamment de sauvegardes pour permettre PITR dans les sept derniers jours. Azure SQL Database effectue régulièrement des sauvegardes complètes, différentielles et de journaux afin de garantir que les bases de données sont restaurables à tout moment pendant la période de conservation de la base de données.

Vous pouvez configurer des sauvegardes différentielles pour qu’elles aient lieu soit toutes les 12 heures, soit toutes les 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 l’option de redondance de sauvegarde pour le stockage STR lors de la création de votre base de données, puis la modifier plus tard. Si vous changez votre option de redondance de sauvegarde sur une base de données existante, les nouvelles sauvegardes utilisent cette nouvelle option de redondance. Azure ne déplace pas et ne copie pas les copies de sauvegarde faites avec l'ancienne option de redondance à court terme. Azure les laisse dans le compte de stockage d’origine jusqu’à l’expiration de la période de conservation, qui peut être 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, Azure garde les sauvegardes de la même manière pour une base de données en ligne avec sa période de conservation 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 Azure SQL logique, vous supprimez aussi toutes les bases de données sur ce serveur logique. Vous ne pouvez pas récupérer les bases de données supprimées. On ne peut pas restaurer un serveur logique supprimé. Mais si vous avez configuré une rétention à long terme pour une base de données, les sauvegardes LTR ne sont pas supprimées. Vous pouvez ensuite utiliser ces sauvegardes pour restaurer des bases de données sur un autre serveur logique dans le même abonnement, jusqu’à un moment où une sauvegarde LTR a été prise. Pour plus d’informations, voir Restaurer la sauvegarde à long terme.

Rétention à long terme

Pour une base de données SQL, vous pouvez configurer des sauvegardes complètes de conservation à long terme (LTR) pour une durée allant jusqu'à 10 ans dans le Stockage Blob Azure. Après avoir configuré la politique LTR, Azure copie automatiquement les sauvegardes complètes dans un autre conteneur de stockage chaque semaine.

Pour répondre à diverses exigences de conformité, sélectionnez différentes périodes de rétention pour des sauvegardes complètes hebdomadaires, mensuelles et annuelles. La fréquence dépend de la stratégie. Par exemple, le paramètre W=0, M=1 crée une copie LTR chaque mois. Pour plus d’informations sur la rétention à long terme, consultez Rétention à long terme.

La mise à jour de la redondance du stockage de sauvegarde pour une base de données existante applique ce changement uniquement aux sauvegardes ultérieures effectuées et non aux sauvegardes existantes. Toutes les sauvegardes LTR existantes pour la base de données continuent de résider dans le 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. Utilisez le calculateur de tarification des LTR pour estimer le coût du stockage LTR.

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.

Vous pouvez activer la rétention à long terme pour les bases de données Hyperscale créées ou migrées depuis 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 permettre une rétention de sauvegarde à long terme. » Dans ce cas, contactez le support Microsoft et créez un ticket de support pour résoudre cela.

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. Vous payez pour le stockage de sauvegarde en fonction des gigaoctets consommés par mois, au même rythme pour toutes les sauvegardes.

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

Remarque

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 provisionnez 4 To de stockage de données, vous obtenez 4 To d’espace de sauvegarde gratuit. Si vous utilisez un total de 5,8 To d’espace de stockage de sauvegarde, la facture Azure n’indique que 1,8 To, car vous ne payez que pour l’excédent de stockage de sauvegarde que vous utilisez.

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 sept jours et plus. Le prix du stockage de sauvegarde PITR fait partie du prix de la base de données ou du pool.

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

Modèle vCore

Azure SQL Database calcule votre stockage total facturable de sauvegarde comme une valeur cumulative sur tous les fichiers de sauvegarde. Chaque heure, Azure envoie cette valeur au pipeline de facturation. Le pipeline agrège cette utilisation horaire pour déterminer votre utilisation du stockage de sauvegarde à la fin de chaque mois.

Si vous supprimez une base de données, la consommation de stockage de sauvegarde diminue progressivement à mesure que les sauvegardes anciennes vieillissent et sont supprimées. Parce que les sauvegardes différentielles et les sauvegardes de journaux nécessitent une sauvegarde complète antérieure pour être restaurables, Azure purge les trois types de sauvegarde ensemble en ensembles hebdomadaires. Une fois toutes les sauvegardes supprimées, la facturation s’arrête.

Les bases de données hyperscale utilisent une méthode différente pour calculer les coûts de stockage de sauvegarde. Pour plus d’informations, consultez Coûts du stockage des sauvegardes Hyperscale.

Pour les bases de données individuelles, vous obtenez un montant de sauvegarde égal à la taille maximale de stockage des données pour la base de données, sans frais supplémentaires. L’équation suivante calcule l’utilisation totale facturable du stockage de sauvegarde :

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

Pour les pools élastiques, vous obtenez une quantité de stockage de sauvegarde égale au stockage maximal de données pour la taille du pool 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

Vous payez le stockage total facturable de sauvegarde, le cas échéant, en gigaoctets par mois selon la redondance de sauvegarde. 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 simplifié, supposons qu’une base de données accumule 744 Go de stockage de sauvegarde et que ce montant reste constant tout au long d’un mois parce que 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 l’ensemble du 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. La base de données SQL rapporte 1 Go d’utilisation pour les heures 1 à 372 (la première moitié du mois). Il indique la consommation comme étant de 2 Go pour les heures 373 à 744 (la seconde moitié du mois). Cette consommation s’élève à une facture finale de 1 116 Go par mois.

Les scénarios de facturation de sauvegarde réels sont plus complexes. Comme le taux de modifications dans la base de données dépend de la charge de travail et varie dans le temps, la taille de chaque sauvegarde différentielle et de chaque sauvegarde de journaux 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 reconstruction de l’indice sont 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 les bases de données plus grandes, une optimisation dans Azure crée une sauvegarde complète au lieu d’une sauvegarde différentielle si une sauvegarde différentielle serait autrement excessivement importante. Cette optimisation réduit la taille de toutes les sauvegardes différentielles jusqu’à la sauvegarde complète suivante.

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 utilisée actuellement. Par exemple, les compteurs de stockage ne sont pas visibles pour les ressources qui ne consomment pas de stockage. S’il n’y a pas de consommation de stockage de secours PITR ou LTR, ces compteurs ne sont pas visibles.

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

Sauvegardes chiffrées

Si vous chiffrez votre base de données en utilisant 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

Azure SQL Database gère automatiquement certains types de corruption de données en utilisant des techniques intégrées lorsque cela est nécessaire, sans perte de données. Dans Azure SQL Database, le SQL Moteur de base de données effectue la vérification des pages lors des sauvegardes gérées par service et lors de chaque opération de restauration. 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.

Comme couche de protection supplémentaire, vous pouvez tester la restauration de sauvegarde et effectuer des vérifications d’intégrité. Pour plus d’informations, consultez Data Integrity in Azure SQL Database.

Toutes les sauvegardes de bases de données utilisent cette CHECKSUM option pour fournir une intégrité supplémentaire des sauvegardes.

Protection des sauvegardes

Les abonnements Azure détenus par Microsoft gèrent les sauvegardes Azure SQL Database en utilisant des comptes stockage Azure internes sécurisés. Vous ne pouvez pas accéder à ces sauvegardes en externe, elles offrent donc une forte isolation et protection des données. Au sein de Microsoft, seuls les services backend peuvent accéder, créer, copier ou restaurer ces sauvegardes. Les ingénieurs Microsoft, y compris les développeurs, n’ont pas d’accès permanent. Microsoft ne peut obtenir un accès Just-In-Time (JIT) que sous des contrôles d’audit stricts, quand il est absolument nécessaire de résoudre des problèmes spécifiques du client, pour réduire l’exposition et optimiser la sécurité.

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

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

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

Lorsque vous migrez votre base de données d’un niveau de service basé sur DTU vers un niveau de service basé sur vCore, la migration préserve la rétention PITR afin de garantir que la politique de récupération de données de votre application n’est pas compromise.

Remarque

Pour les étapes de suppression des données personnelles dans les sauvegardes Azure SQL Database afin de répondre à vos obligations en vertu du RGPD, consultez Modifier les paramètres de sauvegarde automatisée. 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 exigences de résidence des données qui vous obligent à garder toutes vos données dans une seule région Azure, vous pouvez imposer des sauvegardes redondantes par zone ou localement redondantes pour votre base de données SQL en utilisant 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. Azure Policy vous aide à maintenir ces ressources conformes aux normes de votre entreprise et aux accords 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 faire respecter les exigences de résidence des données au niveau organisationnel, attribuez des politiques à un abonnement en utilisant le portail Azure ou Azure PowerShell.

Par exemple, si vous activez la politique « Azure SQL DB doit éviter d'utiliser la sauvegarde GRS », les utilisateurs ne peuvent pas créer de bases de données avec le stockage par défaut comme stockage globalement redondant. La politique empêche les utilisateurs d’utiliser GRS et renvoie le message d’erreur « Configuration du type de compte de stockage de sauvegarde à 'Standard_RAGRS' échouée lors de la création ou mise à jour de la base de données. »

Pour une liste complète des définitions de politiques intégrées pour SQL Database, voir la référence de politique.

Important

Les politiques Azure ne sont pas appliquées lorsque vous créez 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 en utilisant T-SQL, utilisez LOCAL ou ZONE comme entrée du 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.