Restaurer une base de données à partir d’une sauvegarde dans Azure SQL Managed Instance

  • Article

S’applique à :Azure SQL Managed Instance

Cet article décrit les étapes de récupération d’une base de données à partir d’une sauvegarde dans Azure SQL Managed Instance. Pour Azure SQL Database, consultez Restaurer une base de données à partir d’une sauvegarde dans Azure SQL Database.

Vue d’ensemble

Les sauvegardes de base de données automatisées protègent vos bases de données des erreurs d’utilisateurs et d’applications, de la suppression accidentelle de base de données et des interruptions prolongées. Cette fonctionnalité intégrée est disponible pour tous les niveaux de service et tailles de calcul. Les options suivantes sont disponibles pour la récupération des bases de données via des sauvegardes automatisées :

  • Créer une nouvelle base de données sur la même instance gérée, récupérée à un point dans le temps spécifié de la période de rétention.
  • Créer une base de données sur la même instance managée ou sur une autre instance managée, récupérée à un point dans le temps spécifié de la période de rétention.
  • Créer une base de données sur la même instance managée ou sur une autre instance managée, récupérée au moment de la suppression d’une base de données supprimée.
  • Créer une base de données sur n’importe quelle instance managée du même abonnement ou d’un abonnement différent dans le même locataire et dans la même région, récupérée au point des sauvegardes les plus récentes.

Si vous avez configuré une conservation à long terme (LTR), vous pouvez également créer une nouvelle base de données à partir de toute sauvegarde de conservation à long terme, sur n’importe quelle instance.

Important

Vous ne pouvez pas remplacer une base de données existante lors de la restauration.

Temps de récupération

Plusieurs facteurs affectent le temps de récupération pour restaurer une base de données par le biais de sauvegardes de base de données automatisées :

  • la taille de la base de données ;
  • la taille de calcul de la base de données ;
  • le nombre de journaux d’activité de transactions impliqués ;
  • la quantité d’activité devant être relue pour effectuer une récupération au point de restauration ;
  • la bande passante du réseau, si la restauration s’effectue dans une autre région ;
  • le nombre de demandes de restauration simultanées en cours de traitement dans la région cible.

Pour une base de données volumineuse ou très active, la restauration peut prendre plusieurs heures. Une panne prolongée dans une région peut occasionner un grand nombre de requêtes de géo-restauration pour la récupération d’urgence. S’il y a un grand nombre de requêtes, le temps de récupération des bases de données individuelles peut s’en trouver augmenté. La plupart des restaurations de bases de données s’effectuent en moins de 12 heures.

Conseil

Pour Azure SQL Managed Instance, les mises à jour système sont prioritaires sur les restaurations de base de données en cours. S’il existe une mise à jour système pour SQL Managed Instance, toutes les restaurations en attente sont suspendues, puis reprises après l’application de la mise à jour. Ce comportement du système peut prolonger la durée des restaurations et peut avoir un effet particulièrement important pour les restaurations de longue durée.

Pour obtenir une durée prévisible des restaurations de base de données, envisagez de configurer des fenêtres de maintenance permettant la planification de mises à jour système à un jour et une heure spécifiques. Envisagez également d’exécuter des restaurations de base de données en dehors de la fenêtre de maintenance planifiée.

Autorisations

Pour effectuer une récupération à l’aide de sauvegardes automatisées, vous devez être :

  • un membre du rôle Contributeur SQL Server ou Contributeur SQL Managed Instance (selon la destination de la récupération) dans l’abonnement ;
  • le propriétaire de l’abonnement.

Pour plus d’informations, consultez Azure RBAC : pour les ressources Azure.

Vous pouvez effectuer une récupération en utilisant le portail Azure, PowerShell ou l’API REST. Vous ne pouvez pas utiliser Transact-SQL.

Restauration dans le temps

Vous pouvez restaurer une base de données à un point antérieur dans le temps. La demande peut spécifier n’importe quel niveau de service ou taille de calcul pour la base de données restaurée. Assurez-vous d’avoir suffisamment de ressources sur l’instance vers laquelle vous restaurez la base de données.

Une fois la restauration terminée, une nouvelle base de données est créée sur l’instance cible, qu’il s’agisse de la même instance ou d’une autre instance. La base de données restaurée est facturée aux tarifs habituels, en fonction du niveau de service et de la taille de calcul. Aucun frais ne vous sera facturé jusqu’à ce que la restauration de la base de données soit terminée.

En règle générale, vous restaurez une base de données à un point antérieur à des fins de récupération. Il est possible d’utiliser la base de données restaurée pour remplacer la base de données d’origine ou comme source de données afin de mettre à jour la base de données d’origine.

Important

Vous ne pouvez pas effectuer une limite de restauration dans le temps sur une base de données géosecondaire. Vous ne pouvez le faire que sur une base de données primaire.

  • Remplacement de la base de données

    Si la base de données restaurée est destinée à remplacer la base de données d’origine, vous devez spécifier la taille de calcul et le niveau de service de la base de données d’origine. Vous pouvez alors renommer la base de données d’origine et donner le nom d’origine à la base de données restaurée avec la commande ALTER DATABASE dans T-SQL.

  • Récupération des données

    Si vous prévoyez récupérer des données de la base de données restaurée suite à une erreur due à l’utilisateur ou à l’application, écrivez et exécutez un script de récupération de données qui extrait des données de la base de données restaurée et les applique à la base de données d’origine. Bien que l’opération de restauration puisse prendre un certain temps, la base de données en cours de restauration sera visible dans la liste de bases de données pendant tout le processus de restauration.

    Si vous supprimez la base de données pendant la restauration, l’opération de restauration sera annulée. Vous ne serez pas facturé pour la base de données dont la restauration est inachevée.

Pour récupérer une base de données dans SQL Managed Instance à un instant dans le passé à l’aide du portail Azure, vous pouvez accéder à la base de données dans le portail et choisir Restaurer. Vous pouvez également ouvrir la page de vue d’ensemble de l’instance cible SQL Managed Instance, puis sélectionner + Nouvelle base de données dans la barre d’outils pour ouvrir la page Créer une base de données managée Azure SQL.

Capture d’écran montrant le volet de la vue d’ensemble de SQL Managed Instance dans le portail Azure avec l’option Ajouter une base de données sélectionnée.

Fournissez les informations sur l’instance gérée cible sous l’onglet De base, puis choisissez un type de sauvegarde sous l’onglet Source de données.

Capture d’écran du portail Azure qui montre l’onglet source de données de la page Créer une base de données managée Azure SQL, avec la restauration à un instant dans le passé sélectionnée.

Pour plus d’informations, consultez l’article Restauration à un instant dans le passé.

Restauration d’une base de données supprimée

Vous pouvez restaurer une base de données supprimée telle qu’elle était au moment de sa suppression, ou à un point dans le temps antérieur, dans la même instance ou dans une instance différente de l’instance source. L’instance cible peut être dans le même abonnement ou d’un abonnement différent de l’instance source. Vous restaurez une base de données supprimée en créant une nouvelle base de données à partir de la sauvegarde.

Important

Vous ne pouvez pas restaurer une instance gérée supprimée. Si vous supprimez une Managed Instance, toutes ses bases de données sont également supprimées et ne peuvent pas être restaurées à l’heure de suppression ou à un point antérieur dans le temps. Si vous avez configuré la conservation à long terme (LTR), vous pouvez toujours restaurer une base de données d’une instance supprimée vers une autre instance et pointer dans le temps au moment où la sauvegarde LTR a été effectuée.

Pour récupérer une base de données à partir du portail Azure, ouvrez la page de vue d’ensemble de l’instance managée, puis sélectionnez Sauvegardes. Choisissez d’afficher les sauvegardes supprimées, puis sélectionnez Restaurer en regard de la sauvegarde supprimée à récupérer pour ouvrir la page Créer une base de données managée Azure SQL. Fournissez les détails de l’instance managée cible sous l’onglet Informations de base et les détails de l’instance managée source sous l’onglet Source de données. Configurez les paramètres de rétention sous l’onglet Paramètres supplémentaires.

Capture d’écran du portail Azure, page Sauvegardes de SQL Managed Instance, montrant les bases de données supprimées et la sélection de l’action Restaurer.

Conseil

Quelques minutes peuvent s’écouler avant que des bases de données récemment supprimées s’affichent sur la page Bases de données supprimées dans le portail Azure, ou lorsque vous souhaitez afficher des bases de données supprimées à l’aide de la ligne de commande.

La géorestauration

Important

  • La géorestauration est disponible uniquement pour des instances géré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.
  • Vous pouvez effectuer opérer une géorestauration uniquement sur des instances gérées qui résident dans le même abonnement.

La géorestauration constitue l’option de récupération par défaut lorsque la base de données n’est pas disponible en raison d’un incident dans la région d’hébergement. Vous pouvez restaurer la base de données dans une instance située dans toute autre région. Vous pouvez restaurer une base de données sur toute instance gérée dans n’importe quelle région Azure à partir des dernières sauvegardes géorépliquées. La géorestauration utilise une sauvegarde géorépliquée comme source. Vous pouvez demander une géorestauration même si une panne a rendu la base de données ou le centre de données inaccessibles.

Il peut y avoir un délai entre le moment où une sauvegarde est effectuée et celui où elle est géorépliquée dans un objet blob Azure dans une autre région. C’est pourquoi la base de données restaurée peut avoir jusqu’à une heure de retard par rapport à la base de données d’origine. L’illustration ci-dessous montre la restauration d’une base de données à partir de la dernière sauvegarde disponible dans une autre région.

Illustration de la restauration d’une base de données dans plusieurs régions à des fins de géorestauration.

À partir du portail Azure, vous pouvez restaurer une sauvegarde géorépliquée dans une instance existante, ou bien créer une instance managée et sélectionner une sauvegarde de géorestauration disponible. La nouvelle base de données contient les données de sauvegarde géorestaurées.

Pour effectuer une restauration dans une instance existante, suivez les étapes décrites dans Restauration à un instant dans le passé et veillez à choisir les instances source et cible appropriées pour restaurer votre base de données dans l’instance prévue.

Pour géorestaurer dans une nouvelle instance à partir du portail Azure, effectuez ces étapes :

  1. Accédez à votre nouveau Azure SQL Managed Instance.
  2. Sélectionnez Nouvelle base de données.
  3. Entrez un nom de base de données.
  4. Sous Source de données, choisissez le type de sauvegarde approprié, puis fournissez des détails pour la source de données.
  5. Sélectionnez une sauvegarde dans la liste des sauvegardes de géorestauration disponibles.

Une fois le processus de création d’une base de données d’instance terminé, elle contient la sauvegarde de géorestauration restaurée.

Considérations en matière de géorestauration

La géorestauration est la solution de récupération d'urgence la plus basique disponible dans Azure SQL Managed Instance. Il s’appuie sur des sauvegardes géorépliquées créées automatiquement dans une région secondaire (jumelée). Voici quelques considérations relatives à la géorestauration :

  • L’objectif de point de récupération (RPO) est jusqu’à 1 heure.
  • Les processus de restauration (objectif de temps de récupération - RTO) prennent généralement moins de 12 heures, mais peuvent varier en fonction de la taille et de l’activité de la base de données afin que la restauration puisse s’étendre au-delà de ce délai d'exécution.
  • La région secondaire (jumelée) est les paramètres de stockage Azure pour la région primaire. Vous ne pouvez pas modifier la région secondaire.
  • Les bases de données nouvellement créées/restaurées peuvent ne pas apparaître immédiatement comme pouvant être restaurées dans d’autres régions en raison d’un décalage dans le remplissage de nouvelles données. Si les clients ne voient pas les sauvegardes de nouvelles bases de données, ils doivent anticiper un délai d’attente allant jusqu’à 24 heures.

Il est essentiel de reconnaître que la géorestauration sert de solution de récupération d’urgence appropriée pour les applications avec des bases de données relativement petites qui ne sont pas critiques pour l’entreprise. Pour les applications vitales pour l’entreprise qui nécessitent de grosses bases de données et doivent assurer la continuité de l’activité, utilisez des groupes de basculement. Cette fonctionnalité offre un RPO et un RTO beaucoup plus faibles, et la capacité est toujours garantie.

Pour plus d’informations sur les choix de continuité d’activité, consultez Vue d’ensemble de la continuité des activités.

Limites

Prenez en compte les limitations suivantes lors de l’utilisation des sauvegardes et d’Azure SQL Managed Instance :

  • La géorestauration d’une base de données peut être effectuée seulement sur une instance dans le même abonnement que l’instance SQL managée source.
  • Les sauvegardes natives effectuées sur des bases de données Azure SQL Managed Instance ne peuvent être restaurées vers SQL Server 2022 (soit sur site, soit sur une machine virtuelle) que si l'instance SQL Managed Instance source s'est inscrite dans la vague de fonctionnalités de novembre 2022.
  • Les bases de données Azure SQL Managed Instance sont chiffrées avec TDE par défaut. Lorsque la base de données source utilise une clé gérée par le client (CMK) comme protecteur TDE, pour restaurer votre base de données sur une instance source autre que SQL Managed Instance, l’instance cible doit avoir accès à la même clé que celle utilisée pour chiffrer la base de données source dans Azure Key Vault, ou bien vous devez désactiver le chiffrement TDE sur la base de données source avant d’effectuer la sauvegarde.
  • Vous pouvez uniquement suivre la progression du processus de restauration par le biais des vues de gestion dynamique sys.dm_exec_requests et sys.dm_operation_status.
  • Quand des stratégies de point de terminaison de service sont activées sur Azure SQL Managed Instance, le fait de placer une stratégie de point de terminaison de service sur un sous-réseau empêche les restaurations à un instant dans le passé à partir d’instances situées dans différents sous-réseaux.
  • L’objectif de point de récupération (RPO) est jusqu’à 1 heure.
  • L’objectif de temps de récupération (RTO) est d’environ 12 heures, mais peut varier en fonction de la taille de la base de données et de l’activité peut aller au-delà de cette période.
  • La région secondaire (jumelée) ne peut pas être modifiée.
  • Les bases de données nouvellement créées/restaurées peuvent ne pas apparaître immédiatement comme pouvant être restaurées dans d’autres régions en raison d’un décalage dans le remplissage de nouvelles données. La visibilité des sauvegardes de la nouvelle base de données peut prendre jusqu’à 24 heures.
  • Le nombre maximal de bases de données que vous pouvez restaurer en parallèle est de 200 par abonnement unique. Dans certains cas, il est possible d’augmenter cette limite en ouvrant un ticket de support.

Contenu connexe