Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
Azure SQL DatabaseAzure SQL Managed Instance
Cet article fournit une vue d’ensemble conceptuelle des sauvegardes de rétention à long terme (LTR) pour Azure SQL Database et Azure SQL Managed Instance. La rétention à long terme peut être configurée pendant jusqu’à 10 ans sur les sauvegardes pour Azure SQL Database (y compris dans le niveau de service Hyperscale) et Azure SQL Managed Instance.
Pour commencer à utiliser la fonctionnalité de sauvegarde de rétention à long terme, consultez :
- Guide pratique pour gérer la conservation à long terme des sauvegardes Azure SQL Database
- Gérer la conservation des sauvegardes à long terme 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 Sauvegardes automatisées dans Azure SQL Database ou sauvegardes automatisées dans 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. Le processus de copie est un travail en arrière-plan qui n’a aucun impact sur les performances sur la charge de travail de base de données. La stratégie LTR pour chaque base de données 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 contourner ce problème dans Azure SQL Managed Instance, vous pouvez effectuer des sauvegardes de base de données de copie uniquement et les conserver dans votre propre compte stockage Azure en tant que fichier immuable.
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.
Les modifications apportées à la stratégie LTR s’appliquent uniquement aux sauvegardes futures. Par exemple, si vous modifiez la rétention de sauvegarde hebdomadaire (W), la rétention mensuelle des sauvegardes (M) ou la rétention annuelle de sauvegarde (Y), le nouveau paramètre de rétention s’applique uniquement aux nouvelles sauvegardes. La rétention des sauvegardes existantes n’est pas modifiée. La stratégie LTR peut être configurée pour chaque base de données dans Azure SQL Database et Azure SQL Managed Instance. Si vous envisagez de supprimer les anciennes sauvegardes LTR avant l’expiration de leur période de rétention, vous pouvez supprimer manuellement les sauvegardes.
Remarque
Dans Azure SQL Database et Azure SQL Managed Instance, lorsque vous activez une stratégie LTR pour la première fois pour une base de données et que la stratégie spécifie une rétention annuelle, la sauvegarde complète la plus récente à partir d’une restauration à un point dans le temps (PITR) est copiée vers un stockage à long terme.
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 (3 650 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 | 13-05-2028 | ||
| 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 cette stratégie et définissez W=0 (aucune sauvegarde hebdomadaire), les sauvegardes hebdomadaires sont conservées jusqu’à leur expiration, puis le service conserve uniquement les sauvegardes mensuelles et annuelles. Aucune sauvegarde hebdomadaire future 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 minutage des sauvegardes LTR individuelles est contrôlé par Microsoft. Vous ne pouvez pas créer manuellement une sauvegarde LTR ni contrôler le calendrier de création de sauvegarde. Une fois que vous avez configuré une stratégie LTR, cela peut prendre jusqu’à sept jours avant que la première sauvegarde LTR ne s’affiche sur la liste des sauvegardes disponibles.
Si vous supprimez un serveur logique ou une instance managée SQL, toutes les bases de données sur ce serveur ou instance managée sont également supprimées. Vous ne pouvez pas restaurer un serveur logique supprimé ou une instance managée SQL. Toutefois, si vous avez configuré LTR pour une base de données, les sauvegardes LTR ne sont pas supprimées et peuvent être utilisées pour restaurer des bases de données sur un autre serveur ou instance managée dans le même abonnement, à un point dans le temps où une sauvegarde LTR a été effectuée.
De même, si vous supprimez une base de données, les sauvegardes LTR 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 des groupes de géoréplication ou de basculement actifs comme solution de continuité d’activité, préparez les basculements éventuels et configurez la même stratégie LTR sur la base de données ou l’instance secondaire que vous avez sur le serveur principal. Votre coût de stockage LTR n’augmente pas, car les sauvegardes ne sont pas générées à partir de fichiers secondaires. Les sauvegardes sont créées uniquement une fois que la base de données secondaire devient principale pour garantir une génération ininterrompue de sauvegardes LTR lorsqu’un basculement est déclenché et que le serveur principal passe à la région secondaire.
Lorsque la base de données primaire d’origine se remet d'une panne ayant provoqué un basculement, elle devient la nouvelle base de données secondaire. Par conséquent, la création de la sauvegarde ne reprendra pas sur la nouvelle base de données secondaire, et la stratégie LTR existante n’aura pas pris effet tant qu’elle ne sera plus la principale.
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.
- Gérer la rétention de sauvegarde à long terme d’Azure SQL Database.
- Gérer la rétention de sauvegarde à long terme d’Azure SQL Managed Instance.
Lorsqu’une demande de restauration est lancée au cours des sept derniers jours de la période de rétention LTR, la sauvegarde LTR est supprimée uniquement une fois l’opération de restauration terminée, même si la période de rétention a expiré.
Dans Azure SQL Managed Instance, vous pouvez utiliser des travaux SQL Agent pour planifier des sauvegardes de base de données de copie uniquement et les déplacer vers votre propre compte de stockage comme alternative à :
- Conservez les sauvegardes pendant plus de 10 ans.
- Conservez les copies quotidiennes de vos bases de données pendant plus de 35 jours.
- Stockez les sauvegardes de base de données sur un stockage immuable.
Conseil / Astuce
Si vous utilisez des sauvegardes LTR pour respecter la conformité ou d’autres exigences stratégiques, envisagez d’effectuer des exercices de récupération périodiques pour vérifier que les sauvegardes LTR peuvent être restaurées et que la restauration entraîne l’état de la base de données attendu.
Étape suivante
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.