Continuité des activités dans Azure SQL Database

2025-04-10

S’applique à :Base de données Azure SQL Base de données SQL dans Fabric

La Continuité d’activité dans la base de données Azure SQL fait référence aux mécanismes, stratégies et procédures qui permettent à votre entreprise de continuer à fonctionner en cas de perturbation en fournissant disponibilité, haute disponibilité et récupération d’urgence.

Pour obtenir des recommandations prescriptives pour optimiser la disponibilité et obtenir une continuité d’activité plus élevée, consultez :

Dans la plupart des cas, SQL Database gère les événements perturbateurs qui peuvent se produire dans un environnement cloud et préserve l’exécution de vos applications et processus métier. Toutefois, il existe certains événements perturbants où la prévention peut prendre un certain temps, comme :

Un utilisateur supprime ou met à jour accidentellement une ligne dans une table.
Un attaquant a réussi à supprimer des données ou à éliminer une base de données.
Un événement catastrophique naturel neutralise un centre de données ou une zone de disponibilité ou une région.
Un centre de données rare, une zone de disponibilité ou une panne à l’échelle de la région causée par une modification de configuration, un bogue logiciel ou une défaillance matérielle.

Haute disponibilité

Une base de données Azure SQL est fournie avec une résilience de base et une promesse de fiabilité qui les protège contre les défaillances logicielles ou matérielles. Les sauvegardes de base de données sont automatisées pour protéger vos données contre la corruption ou la suppression accidentelle. En tant que Platform-as-a-service (PaaS), le service Azure SQL Database fournit une disponibilité en tant que fonctionnalité hors service avec un contrat SLA de disponibilité de 99,99 %.

Pour obtenir une haute disponibilité dans l’environnement cloud Azure, activez la redondance de zone. Avec la redondance de zone, la base de données ou le pool élastique utilise des zones de disponibilité Azure pour garantir la résilience aux défaillances zonales.

De nombreuses régions Azure fournissent des zones de disponibilité, qui sont des groupes séparés de centres de données au sein d’une région qui dispose d’une alimentation indépendante, d’un refroidissement et d’une infrastructure réseau.
Les zones de disponibilité sont conçues pour fournir des services régionaux, une capacité et une haute disponibilité dans les zones restantes si une zone rencontre une panne.

En activant la redondance de zone, la base de données ou le pool élastique est résiliente aux défaillances matérielles et logicielles zonales et la récupération est transparente pour les applications. Lorsque la haute disponibilité est activée, le service Base de données Azure SQL est en mesure de fournir un contrat SLA de disponibilité plus élevé de 99,995 %.

Récupération d’urgence

Pour obtenir une disponibilité et une redondance plus élevées entre les régions, vous pouvez activer les fonctionnalités de récupération d’urgence pour récupérer rapidement la base de données à partir d’une défaillance régionale catastrophique. Les options de récupération d’urgence pour une base de données Azure SQL :

La géoréplication active vous permet de créer une base de données secondaire synchronisée accessible en lecture en permanence pour une base de données primaire.
Les groupes de basculement, en plus d’assurer une synchronisation continue entre une base de données primaire et une base de données secondaire, vous permettent également de gérer la réplication et le basculement de certaines ou de toutes les bases de données d’un serveur logique vers un serveur logique secondaire situé dans une autre région. Les groupes de basculement fournissent des points de terminaison de l’écouteur en lecture-écriture et en lecture seule qui restent inchangés, de sorte qu'il n'est pas nécessaire de mettre à jour les chaînes de connexion d’application après le basculement.
La géorestauration vous permet de récupérer à partir d’une panne régionale en effectuant une restauration à partir de sauvegardes géorépliquées lorsque vous ne pouvez pas accéder à votre base de données dans la région primaire en créant une base de données sur n’importe quel serveur existant dans n’importe quelle région Azure.

Le tableau suivant compare les groupes de géoréplication et de basculement actifs, deux options de récupération d’urgence pour la base de données Azure SQL :

	Géoréplication active	Groupes de basculement
Synchronisation de données continue entre le serveur principal et le secondaire	Oui	Oui
Basculement simultanément de plusieurs bases de données	Non	Oui
La chaîne de connexion reste inchangée après le basculement	Non	Oui
Prise en charge de l’échelle lecture	Oui	Oui
Réplicas multiples	Oui	Non
Peut être dans la même région que le principal	Oui	Non

RTO et RPO

Lorsque vous élaborez votre plan de continuité d’activité, comprenez le délai maximum acceptable avant que l’application ne se rétablisse complètement après l’événement perturbateur. Deux façons courantes de quantifier les exigences métier relatives à la reprise d’activité sont les suivantes :

Objectif de temps de récupération (RTO) : temps nécessaire à une application pour récupérer entièrement après un événement de perturbation non planifié.
Objectif de point de récupération (RPO) : durée de perte de données pouvant être tolérée à partir d’un événement de perturbation non planifié.

Le tableau suivant compare l’objectif de point de récupération (RPO) et l’objectif de délai de récupération (RTO) de chaque option de continuité d’activité :

Options de continuité d’activité	RTO (temps d’arrêt)	RPO (perte de données)
Haute disponibilité (utilisation de la redondance de zone)	En général, moins de 30 secondes	0
Récupération d’urgence (utilisation de groupes de basculement avec une stratégie de basculement gérée par le client ou une géoréplication active)	En général, moins de 60 secondes	Égal ou supérieur à 0 (Dépend des modifications de données avant l’événement perturbant qui n’a pas été répliqué)
Récupération d’urgence (en utilisant la géo-restauration)	En règle générale, minutes ou heures, en fonction de la réplication du stockage Azure	En règle générale, minutes ou heures, en fonction de la taille de la sauvegarde de base de données

Fonctionnalités garantissant la continuité d’activité

Du point de vue de la base de données, il existe quatre scénarios d’interruption potentiels. Le tableau suivant répertorie les fonctionnalités de continuité d’activité SQL Database que vous pouvez utiliser pour atténuer un scénario de perturbation potentielle d’activité :

Scénario d’interruption d’activité	Fonctionnalité de continuité des activités
Des défaillances matérielles ou logicielles locales affectant le nœud de base de données.	Pour atténuer les défaillances matérielles et logicielles locales, Azure SQL Database inclut une architecture de disponibilité, qui garantit la récupération automatique de ces défaillances avec jusqu’à 99,99% contrat SLA de disponibilité.
Une suppression ou une altération des données se produit, généralement à la suite d’un bogue d’application ou d’une erreur humaine. Ces défaillances sont spécifiques à l’application et ne peuvent généralement pas être détectées par le service de base de données.	Pour protéger votre entreprise contre la perte de données, SQL Database crée automatiquement des sauvegardes de bases de données complètes (toutes les semaines), des sauvegardes de bases de données différentielles (toutes les 12 ou 24 heures) et des sauvegardes de fichiers journaux (toutes les 5 à 10 minutes). Par défaut, les sauvegardes sont stockées dans le stockage géoredondant pendant sept jours pour tous les niveaux de service. Tous les niveaux de service, à l’exception du support De base, prennent en charge une période de rétention des sauvegardes configurable pour la récupération jusqu’à une date et heure (PITR) jusqu’à 35 jours. Vous pouvez restaurer une base de données supprimée au point où sa suppression s’est produite si le serveur n’a pas été supprimé ou si vous avez configuré une conservation à long terme (LTR).
Une panne rare de centre de données ou de zone de disponibilité, peut-être causée par un événement de sinistre naturel, une modification de configuration, un bogue logiciel ou une défaillance matérielle.	Pour atténuer la panne au niveau du centre de données ou de la zone de disponibilité, activez la redondance de zone pour la base de donnée ou le pool élastique afin d’utiliser les Zones de disponibilité Azure et de fournir une redondance entre plusieurs zones physiques au sein d’une région Azure. L’activation de la redondance de zone garantit que la base de données ou le pool élastique est résilient aux défaillances zonales avec une SLA de haute disponibilité allant jusqu’à 99,995 %.
Une panne régionale rare affectant toutes les zones de disponibilité et les centres de données qui l’composent, peut-être causée par un événement catastrophique de catastrophe naturelle.	Pour atténuer une panne à l’échelle de la région, activez la récupération d’urgence à l’aide de l’une des options suivantes : - Options de synchronisation de données continues telles que les groupes de basculement (recommandé) ou la géoréplication active qui vous permettent de créer des réplicas dans une région secondaire pour le basculement. – Configuration de la redondance du stockage de sauvegarde en stockage de sauvegarde géoredondant pour utiliser la géorestauration.

Préparer une panne régionale

Quelles que soient les fonctionnalités de continuité d’activité que vous utilisez, vous devez préparer la base de données secondaire dans une autre région. Si la préparation n’est pas effectuée correctement, la mise en ligne de vos applications après un basculement ou une récupération dure plus longtemps et nécessite probablement de résoudre certains problèmes, ce qui peut retarder le RTO. Suivez la liste de contrôle pour préparer le système secondaire en cas de panne régionale.

Restaurer une base de données dans la même région Azure

Vous pouvez utiliser des sauvegardes de base de données automatiques pour restaurer une base de données à un point dans le temps passé. Vous pouvez ainsi récupérer suite à des altérations de données dues à des erreurs humaines. La restauration dans le temps (PITR) vous permet de créer une base de données sur le même serveur qui représente l’état des données avant l’événement endommagé. Pour connaître les temps de récupération, consultez RTO et RPO.

Si la période de rétention maximale de sauvegarde prise en charge pour la restauration dans le temps n’est pas suffisante pour votre application, vous pouvez l’étendre en configurant une stratégie de rétention à long terme (LTR). Pour plus d’informations, consultez Rétention à long terme.

Mettre à niveau une application avec un temps d’arrêt minimal

Parfois, une application doit être déconnectée en raison d’une maintenance, par exemple, une mise à niveau. Vous pouvez gérer les mises à niveau propagées d’applications cloud à l’aide de la géoréplication active SQL Database. La géoréplication peut également fournir un chemin de récupération si un problème se produit.

Réduisez les coûts avec une réplique standby

Si votre réplica secondaire n'est utilisé que pour la reprise après sinistre (DR) et n'a pas de charge de travail en lecture ou en écriture, vous pouvez réduire les coûts de licence en désignant la base de données comme base de données de réserve lorsque vous configurez une nouvelle relation de géoréplication active.

Pour en savoir plus, consultez la réplique de secours sans licence.

Étape suivante

Liste de contrôle pour la haute disponibilité et la reprise après sinistre