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

S’applique à Azure SQL Database

Cet article décrit les étapes pour récupérer n’importe quelle base de données, y compris Hyperscale, à partir d’une sauvegarde dans Azure SQL Database. Pour Azure SQL Managed Instance, consultez Restaurer une base de données à partir d’une sauvegarde dans Azure SQL Managed Instance.

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 le même serveur, récupérée à un moment donné durant la période de rétention.
  • Créer une base de données sur le même serveur, récupérée à un moment donné de la suppression d’une base de données.
  • Créer une nouvelle base de données sur un serveur dans la même région, récupérée au moment d’une sauvegarde récente.
  • Créer une nouvelle base de données sur tout serveur dans n’importe quelle autre région, récupérée au point des sauvegardes répliquées 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 quel serveur.

Important

  • Vous ne pouvez pas remplacer une base de données existante lors de la restauration.
  • Les opérations de restauration de base de données ne restaurent pas les étiquettes de la base de données d’origine.

Quand vous utilisez le niveau de service Standard ou Premium dans le modèle d’achat DTU, la restauration de votre base de données peut entraîner un coût de stockage supplémentaire. Le coût supplémentaire s’applique si la taille maximale de la base de données restaurée est supérieure à la quantité de stockage incluse dans le niveau et l’objectif de service de la base de données cible.

Pour les détails de la tarification du stockage supplémentaire, consultez la page Tarification des bases de données SQL. Si la quantité réelle d’espace utilisé est inférieure à la quantité de stockage incluse, ce coût supplémentaire peut être évité en fixant la taille maximale de la base de données sur la quantité incluse.

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.

Pour un seul abonnement, le nombre de requêtes de restauration simultanées présente les limitations suivantes. Ces limitations s’appliquent à toutes les combinaisons de limites de restauration dans le temps, de géorestaurations et de restaurations issues d’une sauvegarde de conservation à long terme.

Option de déploiement Nombre maximum de requêtes simultanées traitées Nombre maximum de requêtes simultanées soumises
Base de données unique (par abonnement) 30 100
Pool élastique (par pool) 4 2 000

Autorisations

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

  • Membre du rôle Contributeur ou du rôle Contributeur SQL Server dans l’abonnement ou le groupe de ressources contenant le serveur logique
  • Propriétaire de l’abonnement ou du groupe de ressources

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 n’importe quelle base de données à un instant dans le passé s’inscrivant dans sa période de rétention. La demande de restauration peut spécifier un niveau de service ou une taille de calcul quelconques pour la base de données restaurée. Lorsque vous restaurez une base de données dans un pool élastique, assurez-vous que vous disposez de ressources suffisantes dans le pool pour accueillir la base de données.

Une fois terminée, la restauration crée une nouvelle base de données sur le même serveur que la base de données d’origine. 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 pouvez effectuer une restauration à un instant dans le passé d’une base de données sur le même serveur. La restauration à un instant dans le passé dans différents serveurs, abonnements et régions n’est actuellement pas prise en charge. Pour restaurer une base de données dans une autre région à l’aide de sauvegardes géorépliquées, consultez Géorestauration.
  • 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.
  • Le BackupFrequency paramètre n’est pas pris en charge pour les bases de données Hyperscale.
  • Les opérations de restauration de base de données consomment beaucoup de ressources et peuvent nécessiter un niveau de service S3 ou supérieur pour la base de données (cible) de restauration. Une fois la restauration terminée, la base de données ou le pool élastique peut être redimensionné (scale down), si nécessaire.
  • 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 à un point dans le temps à l'aide du portail Azure, ouvrez la page de présentation de la base de données et sélectionnez Restaurer sur la barre d'outils. Choisissez une source de sauvegarde, puis sélectionnez le point de sauvegarde dans le temps à partir duquel une nouvelle base de données sera créée.

Capture d’écran des options de restauration de base de données pour SQL Database.

Restauration de sauvegarde à long terme

Pour effectuer une opération de restauration sur une sauvegarde à long terme, vous pouvez utiliser le portail Azure, Azure CLI, Azure PowerShell ou l’API REST. Pour plus d’informations, consultez Restaurer une sauvegarde à long terme.

Pour récupérer une sauvegarde à long terme à l’aide du portail Azure, accédez à votre serveur logique. Sélectionnez Sauvegardes sous Gestion des données, puis Gérer sous Sauvegardes LTR disponibles pour la base de données que vous essayez de restaurer.

Capture d’écran du portail Azure montrant les sauvegardes de rétention à long terme disponibles.

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

Pour restaurer une base de données supprimée à l’heure de sa suppression ou avant, sur le même serveur, vous pouvez utiliser le Portail Azure, Azure CLI, Azure PowerShell et l’API REST.

Important

Si vous supprimez un serveur, toutes ses bases de données et leurs sauvegardes PITR sont également supprimées. Vous ne pouvez pas restaurer un serveur supprimé et vous ne pouvez pas restaurer les bases de données supprimées des sauvegardes PITR. Si vous avez configuré des sauvegardes LTR pour ces bases de données, vous pouvez utiliser ces sauvegardes pour restaurer les bases de données sur un autre serveur.

Pour récupérer une base de données qui a été supprimée telle qu’elle était au moment de sa suppression à partir du portail Azure, ouvrez la page de présentation du serveur et sélectionnez Bases de données supprimées. Sélectionnez une base de données supprimée que vous souhaitez restaurer, puis entrez le nom de la nouvelle base de données qui sera créée avec les données restaurées à partir de la sauvegarde.

Capture d’écran du portail Azure montrant comment restaurer une base de données supprimée.

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 par programme.

La géorestauration

Vous pouvez utiliser la géo-restauration pour restaurer une base de données supprimée à l’aide du Portail Azure, d’Azure CLI, d’Azure PowerShell et de l’API REST.

Important

  • La géo-restauration n’est disponible que pour des bases de donné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 ne pouvez effectuer une géo-restauration que sur des instances résidant dans le même abonnement.

La géo-restauration utilise des sauvegardes géo-répliquées comme source. Vous pouvez restaurer une base de données sur n’importe quel serveur logique dans n’importe quelle région Azure à partir de la dernière sauvegarde géo-répliquée. Vous pouvez demander une géo-restauration même si une panne a rendu la base de données ou la région entière inaccessibles.

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 sur un serveur dans n’importe quelle autre région.

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 d’une géo-restauration.

Dans le portail Azure, créez une nouvelle base de données, puis sélectionnez une sauvegarde de géo-restauration disponible. La nouvelle base de données contient les données de sauvegarde géorestaurées.

Pour géorestaurer une base de données unique à partir du portail Azure dans la région et le serveur de votre choix, effectuez les étapes suivantes :

  1. À partir du Tableau de bord, sélectionnez Ajouter>Créer une base de données SQL. Sous l’onglet De base, entrez les informations nécessaires.
  2. Sélectionnez Paramètres supplémentaires.
  3. Pour Utiliser des données existantes, sélectionnez Sauvegarde.
  4. Sélectionnez une sauvegarde dans la liste des sauvegardes de géorestauration disponibles.

Capture d’écran du portail Azure affichant des options pour créer une base de données.

Terminez le processus de création d’une base de données à partir la sauvegarde. Quand vous créez une base de données dans Azure SQL Database, elle contient la sauvegarde de géorestauration restaurée.

Considérations en matière de géorestauration

Pour plus d’informations sur l’utilisation de la géorestauration, consultez Récupération à l’aide de la géorestauration.

La géo-restauration est la solution de récupération d’urgence la plus basique disponible dans SQL Database. Elle s’appuie sur des sauvegardes géorépliquées créées automatiquement, dont l’objectif de point de récupération (RPO) est jusqu’à 1 heure, et l’objectif de délai de récupération (RTO) estimé est jusqu’à 12 heures. Elle ne garantit pas que la région cible aura la capacité de restaurer les bases de données après une panne régionale, car il se produira probablement un pic de demande. Si votre application utilise des bases de données relativement petites et qu’elle n’est pas vitale pour l’entreprise, la géorestauration est une solution de reprise d’activité adaptée.

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.

Notes

Si vous envisagez d’utiliser la géo-restauration comme solution de récupération d’urgence, nous vous recommandons d’effectuer des exercices réguliers pour vérifier la tolérance de l’application à toute perte de modifications de données récentes, ainsi que tous les aspects opérationnels de la procédure de récupération.

Étapes suivantes