Conservation à long terme – Azure SQL Database et Azure SQL Managed Instance

  • Article
  • 6 minutes de lecture

De nombreuses applications sont dédiées à la réglementation, à la conformité ou à d’autres fins professionnelles qui vous obligent à conserver des sauvegardes de données au-delà des 7 à 35 jours offerts par les sauvegardes automatiques Azure SQL Database et Azure SQL Managed Instance. La fonctionnalité de conservation à long terme (LTR) vous permet de stocker certaines sauvegardes complètes de SQL Database et SQL Managed Instance dans le Stockage Blob Azure avec une redondance configurée pour jusqu’à 10 ans. Les sauvegardes LTR peuvent ensuite être restaurées en tant que nouvelle base de données.

La conservation à long terme peut être activée pour Azure SQL Database et pour Azure SQL Managed Instance. Cet article fournit une vue d’ensemble conceptuelle de la conservation à long terme. Pour configurer la conservation à long terme, consultez Configurer la conservation à long terme dans Azure SQL Database et Configurer la conservation à long terme dans Azure SQL Managed Instance.

Notes

  • Dans Azure SQL Managed Instance, utilisez les tâches de SQL Agent pour planifier des sauvegardes de bases de données en copie seule comme alternative à la conservation à long terme (LTR) au-delà de 35 jours.
  • La conservation des sauvegardes à long terme pour les bases de données Hyperscale est maintenant en préversion.

Fonctionnement de la conservation à long terme

La conservation des sauvegardes à long terme (LTR) s’appuie sur les sauvegardes de base de données complètes qui sont créées automatiquement pour permettre la récupération jusqu’à une date et heure. Si une stratégie LTR est spécifiée, ces sauvegardes sont copiées vers différents objets blob pour stockage à long terme. 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.

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 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 sera créée l’année suivante. Chaque sauvegarde est conservée dans le stockage à long terme en fonction des paramètres de stratégie qui sont configurés lors de la création de la sauvegarde LTR.

Notes

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=3

    La troisième sauvegarde complète de l’année est conservée pendant cinq ans.

  • W=0, M=3, Y=0

    La première sauvegarde complète du mois est conservée pendant trois mois.

  • W=12, M=0, Y=0

    Chaque sauvegarde complète hebdomadaire est conservée pendant 12 semaines.

  • W=6, M=12, Y=10, WeekOfYear=20

    Chaque sauvegarde complète hebdomadaire est conservée pendant six semaines. à l’exception de la 1re sauvegarde complète du mois qui est conservée pendant 12 mois et de la sauvegarde complète effectuée durant la 20e semaine de l’année, qui est quant à elle 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 semaines (84 jours), M=12 mois (365 jours), Y=10 ans (3650 jours), WeekOfYear=20 (semaine après le 13 mai)

Par exemple

Si vous modifiez la stratégie ci-dessus et définissez W=0 (aucune sauvegarde hebdomadaire), Azure 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. 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 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 ne peuvent pas être récupérées. 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.

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.

Notes

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 de conservation à long terme existante ne prend effet qu’après que 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.

Notes

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 produit l’état de base de données attendu.

Étapes suivantes

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.