Conservation à long terme – Azure SQL Database et Azure SQL Managed Instance
S’applique à : 
Azure SQL Database Azure SQL Managed Instance
Cet article fournit une vue d’ensemble conceptuelle de la conservation à long terme des sauvegardes pour base de données Azure SQL et Azure SQL Managed Instance. La conservation à long terme peut être configurée jusqu’à 10 ans sur les sauvegardes pour la base de données Azure SQL (y compris dans le niveau de service Hyperscale) et Azure SQL Managed Instance.
Pour commencer, voir configurer la rétention de sauvegarde à long terme pour la Base de données Azure SQL et Azure SQL Managed Instance.
Fonctionnement de la conservation à long terme
De nombreuses applications ont des objectifs en matière de réglementation, de conformité ou d’autres raisons commerciales qui vous obligent à conserver des sauvegardes de bases de données au-delà des 1 à 35 jours fournis par la période de rétention à court terme des sauvegardes automatiques. La rétention de sauvegarde à long terme (LTR) repose sur les sauvegardes complètes de base de données créées automatiquement par le service Azure SQL. Pour plus d’informations, consultez les sauvegardes automatisées dans Base de données Azure SQL ou Azure SQL Managed Instance.
En utilisant la fonctionnalité LTR, vous pouvez stocker des sauvegardes SQL Database et SQL Managed Instance spécifiées dans un stockage Blob Azure redondant avec une stratégie de rétention configurable pouvant durer jusqu’à 10 ans. Les sauvegardes LTR peuvent ensuite être restaurées en tant que nouvelle base de données. Si une stratégie LTR est configurée, les sauvegardes automatisées sont copiées dans différents objets blob pour le stockage à long terme, que vous pouvez ensuite utiliser pour restaurer votre base de données à un point spécifique dans le temps. La copie est un travail en arrière-plan qui n’a aucun impact en matière de performance sur la charge de travail de la base de données. La stratégie LTR pour chaque base de données dans SQL Database peut également spécifier la fréquence à laquelle les sauvegardes LTR sont créées.
Remarque
- Il n’est actuellement pas possible de configurer des sauvegardes de base de données Azure SQL et d’Azure SQL Managed Instance comme immuables. Les sauvegardes LTR ne sont pas modifiables, mais vous pouvez les supprimer via le Portail Azure, Azure CLI, PowerShell ou l’API REST. Pour plus d’informations, consultez Configurer les sauvegardes LTR.
- Dans Azure SQL Managed Instance, utilisez des travaux SQL Agent pour planifier des sauvegardes de base de données de copie uniquement et les conserver sur votre propre compte de stockage. Il peut s’agir d’une alternative à la fonctionnalité LTR qui peut conserver vos sauvegardes pendant 10 ans.
Pour activer LTR, vous pouvez définir une stratégie utilisant une combinaison de quatre paramètres : rétention hebdomadaire des sauvegardes (W), rétention mensuelle des sauvegardes (M), rétention annuelle des sauvegardes (Y) et semaine de l’année (WeekOfYear). Si vous indiquez W, une sauvegarde est copiée sur le dispositif de stockage à long terme toutes les semaines. Si vous indiquez M, la première sauvegarde de chaque mois est copiée sur le dispositif de stockage à long terme. Si vous indiquez Y, une sauvegarde est copiée sur le dispositif de stockage à long terme pendant la semaine définie par WeekOfYear. Si la valeur WeekOfYear spécifiée est dans le passé lorsque la stratégie est configurée, la première sauvegarde LTR est créée l’année suivante. Chaque sauvegarde est conservée dans le dispositif de stockage à long terme en fonction des paramètres de stratégie qui sont configurés lors de la création de la sauvegarde LTR.
Toute modification apportée à la stratégie LTR s’applique uniquement aux sauvegardes ultérieures. Par exemple, si la rétention hebdomadaire des sauvegardes (W), la rétention mensuelle des sauvegardes (M) ou la rétention annuelle des sauvegardes (Y) est modifiée, le nouveau paramètre de rétention s’applique uniquement aux nouvelles sauvegardes. La rétention des sauvegardes existantes ne sera pas modifiée. Si vous souhaitez supprimer les anciennes sauvegardes LTR avant l’expiration de leur période de rétention, vous devez supprimer manuellement les sauvegardes.
Exemples de stratégie LTR :
W=0, M=0, Y=5, WeekOfYear=3La troisième sauvegarde complète de l’année est conservée pendant cinq ans.
W=0, M=3, Y=0La première sauvegarde complète du mois est conservée pendant trois mois.
W=12, M=0, Y=0Chaque sauvegarde complète hebdomadaire est conservée pendant 12 semaines.
W=6, M=12, Y=10, WeekOfYear=20Chaque sauvegarde complète hebdomadaire est conservée pendant six semaines. Sauf la première sauvegarde complète de chaque mois, qui est conservée pendant 12 mois. Sauf la sauvegarde complète effectuée la 20e semaine de l'année, qui est conservée pendant 10 ans.
Le tableau suivant illustre la cadence et l’expiration des sauvegardes à long terme pour la stratégie suivante :
W=12 weeks (84 jours), M=12 months (365 jours), Y=10 years (3650 jours), WeekOfYear=20 (la semaine après le 13 mai)
Les dates suivantes sont dans ISO 8601 (YYYY-MM-DD).
| Sauvegarde PITR vers LTR | Expiration W | Expiration M | Expiration Y |
|---|---|---|---|
| 2018-03-07 | 2019-03-02 | ||
| 2018-03-14 | 2018-06-06 | ||
| 2018-03-21 | 2018-06-13 | ||
| 2018-03-28 | 2018-06-20 | ||
| 2018-04-04 | 2019-03-30 | ||
| 2018-04-11 | 2018-07-04 | ||
| 2018-04-18 | 2018-07-11 | ||
| 2018-04-25 | 2018-07-18 | ||
| 2018-05-02 | 2019-04-27 | ||
| 2018-05-09 | 2018-08-01 | ||
| 2018-05-16 | 2028-05-13 | ||
| 2018-05-23 | 15-08-2018 | ||
| 2018-05-30 | 2018-08-22 | ||
| 2018-06-06 | 2019-06-01 | ||
| 2018-06-13 | 2018-09-05 | ||
| 2018-06-20 | 2018-09-12 | ||
| 27/06/2018 | 2018-09-19 | ||
| 2018-07-04 | 2019-06-29 | ||
| 2018-07-11 | 2018-10-03 | ||
| 2018-07-18 | 2018-10-10 | ||
| 2018-07-25 | 2018-10-17 | ||
| 2018-08-01 | 2019-07-27 | ||
| 2018-08-08 | 2018-10-31 | ||
| 15-08-2018 | 2018-11-07 | ||
| 2018-08-22 | 2018-11-14 | ||
| 2018-08-29 | 2018-11-21 |
Si vous modifiez la stratégie ci-dessus et définissez W=0 (aucune sauvegarde hebdomadaire), le service conserve uniquement les sauvegardes mensuelles et annuelles. Aucune sauvegarde hebdomadaire n’est stockée sous la stratégie LTR. La quantité de stockage nécessaire pour conserver ces sauvegardes diminue en conséquence.
Important
Le calendrier des sauvegardes LTR individuelles est contrôlé par Azure SQL Database. Vous ne pouvez pas créer manuellement une sauvegarde LTR ni contrôler le calendrier de création de sauvegarde. Après avoir configuré une stratégie de conservation à long terme (LTR), vous devrez peut-être patienter jusqu’à sept jours avant que la première sauvegarde LTR n’apparaisse dans la liste des sauvegardes disponibles.
Si vous supprimez un serveur logique ou une instance gérée, toutes les bases de données de ce serveur ou de cette instance gérée sont également supprimées et il n’est pas possible de les récupérer. Vous ne pouvez pas restaurer un serveur ou une instance managée supprimé(e). Toutefois, si vous avez configuré LTR pour une base de données ou une instance gérée, les sauvegardes LTR ne sont pas supprimées et peuvent permettre de restaurer les bases de données sur un autre serveur ou une autre instance gérée dans le même abonnement, à un moment où une sauvegarde LTR a été effectuée.
De même, si vous supprimez une base de données, les sauvegardes de conservation à long terme ne sont pas supprimées et sont conservées pendant la période de rétention configurée. Ces sauvegardes peuvent être restaurées sur le même serveur ou sur un autre serveur du même abonnement.
Géo-réplication et conservation de sauvegarde à long terme
Si vous utilisez une géoréplication active ou des groupes de basculement en tant que solution de continuité des activités, vous devez vous préparer à d’éventuels basculements et configurer la même stratégie LTR sur l’instance ou la base de données secondaire. Le coût de votre stockage LTR n’augmente pas, car les sauvegardes ne sont pas générées à partir des bases de données secondaires. Les sauvegardes sont créées uniquement quand la base de données secondaire devient primaire. Cela garantit une génération ininterrompue des sauvegardes LTR lorsque le basculement est déclenché et lorsque la base de données primaire est déplacée vers la région secondaire.
Remarque
Lorsque la base de données primaire d’origine récupère après une panne ayant entraîné le basculement, elle devient une nouvelle base de données secondaire. Par conséquent, la création de sauvegarde ne reprend pas, et la stratégie LTR existante ne prend effet que lorsque la base de données est redevenue primaire.
Configurer la rétention des sauvegardes à long terme
Vous pouvez configurer la conservation des sauvegardes à long terme à l’aide du Portail Azure et de PowerShell pour Azure SQL Database et Azure SQL Managed Instance. Pour restaurer une base de données à partir du stockage LTR, vous pouvez sélectionner une sauvegarde spécifique en fonction de son horodatage. Vous pouvez restaurer la base de données sur n’importe quel serveur ou instance managée existant en utilisant le même abonnement que celui de la base de données d’origine.
Pour apprendre à configurer la conservation à long terme ou à restaurer une base de données à partir d’une sauvegarde pour SQL Database à l’aide du Portail Azure ou de PowerShell, consultez Gérer la conservation à long terme des sauvegardes Azure SQL Database.
Pour savoir comment configurer la conservation à long terme ou restaurer une base de données à partir d’une sauvegarde pour Azure SQL Managed Instance à l’aide du portail Azure ou de PowerShell, consultez Gérer la conservation à long terme des sauvegardes Azure SQL Managed Instance.
Lorsqu’une demande de restauration est lancée au cours des 7 derniers jours de la période de rétention LTR, Azure étend automatiquement la date d’expiration de toutes les sauvegardes de +7 jours pour empêcher une sauvegarde LTR d’expirer pendant la restauration.
Remarque
Si vous utilisez des sauvegardes LTR pour respecter la conformité ou d’autres exigences stratégiques, songez à effectuer des exercices de récupération périodiques pour vérifier que les sauvegardes LTR peuvent être restaurées et que la restauration aboutie à l’état de base de données voulu.
Contenu connexe
Dans la mesure où les sauvegardes de base de données protègent les données des corruptions et des suppressions accidentelles, elles sont une partie essentielle de toute stratégie de continuité d’activité ou de récupération d’urgence.
- Vue d’ensemble de la continuité d’activité pour Azure SQL Database
- Vue d’ensemble de la continuité d’activité pour Azure SQL Managed Instance
- Sauvegardes automatisées dans Azure SQL Database
- Sauvegardes automatisées dans Azure SQL Managed Instance
Pour obtenir un tutoriel sur la configuration et la gestion des sauvegardes LTR, consultez :