Fiabilité dans Sauvegarde Azure

Sauvegarde Azure est un service intégré Azure qui protège en toute sécurité les charges de travail cloud et locales. La sauvegarde peut étendre sa protection à plusieurs charges de travail et offre une intégration native avec les charges de travail Azure, y compris les machines virtuelles (VMs), SAP HANA sur des VMs Azure, SQL sur des VMs Azure, Azure Files, Stockage Blob Azure, Azure Data Lake Storage, disques managés Azure, volumes Azure Elastic SAN et Azure Kubernetes Service (AKS). Vous n’avez pas besoin de gérer l’automatisation ou l’infrastructure, écrire des scripts ou approvisionner le stockage.

Lorsque vous utilisez Azure, reliability est une responsabilité partagée. Microsoft offre une gamme de fonctionnalités permettant de prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment la sauvegarde peut être résiliente à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il met également en évidence certaines informations clés sur le contrat de niveau de service de sauvegarde (SLA).

Recommandations de déploiement de production pour la fiabilité

Pour sauvegarder vos charges de travail de production, nous vous recommandons de configurer votre coffre de la manière suivante :

Les sections suivantes de cet article fournissent plus de détails sur ces configurations.

Pour obtenir la liste des autres recommandations relatives à la sauvegarde, notamment les recommandations axées sur la fiabilité, consultez Le cloud de sauvegarde et les charges de travail locales dans le cloud.

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

La sauvegarde peut sauvegarder et restaurer une variété de sources de données. Vous configurez des sauvegardes différemment en fonction de la source de données avec laquelle vous travaillez. Les sources de données suivantes sont courantes :

• machines virtuelles Azure
• Différentes bases de données
• comptes Stockage Blob
• Clusters AKS
• Serveurs locaux via l’agent MICROSOFT AZURE Recovery Services (MARS)

La sauvegarde stocke vos données dans des coffres. Les coffres sont des entités de stockage en ligne dans Azure qui contiennent des données, telles que des copies de sauvegarde, des points de récupération et des stratégies de sauvegarde. Les coffres Recovery Services et les coffres de sauvegarde sont deux types de coffres. Vous pouvez utiliser un ou les deux types en fonction de ce que vous devez protéger. Pour obtenir la liste des sources de données prises en charge par chaque type de coffre, consultez la FAQ sur les coffres pris en charge pour la sauvegarde et la restauration.

Les travaux représentent l’activité de sauvegarde ou de restauration de vos données. Les travaux de sauvegarde incluent des opérations planifiées ou à la demande qui copient vos données de la source vers le coffre de sauvegarde. Les travaux de restauration incluent des opérations qui récupèrent vos données du stockage de sauvegarde vers un emplacement cible. Chaque travail dispose d’un identificateur unique et d’un suivi de l’état pour vous permettre de surveiller la progression et de résoudre les problèmes qui se produisent pendant les opérations de sauvegarde et de restauration. Vous créez également des stratégies de sauvegarde associées à des travaux. Les stratégies spécifient la configuration comme la planification de sauvegarde et la durée pendant laquelle vous souhaitez conserver les données.

Les coffres stockent vos stratégies de sauvegarde et votre configuration ainsi que les métadonnées relatives aux travaux, ce qui vous permet de suivre les travaux et de résoudre les problèmes.

Architecture physique

Microsoft gère l’infrastructure de service de sauvegarde principale. Cette infrastructure est responsable de la gestion et du fonctionnement du service, notamment le déclenchement et la surveillance des travaux.

La sauvegarde stocke les sauvegardes dans le coffre. Les coffres sont construits sur la base de stockage Azure. Les coffres répliquent automatiquement vos données de sauvegarde, et la durabilité et la résilience des sauvegardes dépendent de la redondance du stockage du coffre.

• Stockage localement redondant (LRS) réplique les données dans votre coffre vers une ou plusieurs zones de disponibilité Azure situées dans la région principale de votre choix. Vous ne pouvez pas choisir votre zone de disponibilité préférée, mais Azure pouvez déplacer ou développer des comptes LRS entre les zones pour améliorer l'équilibrage de charge. Vos données ne sont pas garanties d’être réparties entre les zones. Pour plus d’informations, consultez Vue d’ensemble des zones de disponibilité.

• ZRS et GRS offrent des protections supplémentaires. Cet article décrit ces options en détail.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Lorsque vous utilisez la sauvegarde, les flux de travail de sauvegarde et de restauration sont résilients aux défaillances intermittentes. Le service réessaye automatiquement lorsqu’il rencontre des erreurs réseau temporaires ou des interruptions de service temporaires. Vous ne configurez aucune logique de nouvelle tentative. Si vous rencontrez des erreurs répétées, consultez Résoudre les problèmes liés aux opérations de gestion du coffre de sauvegarde.

Résilience aux échecs de zone de disponibilité

Zones d’indisponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

La sauvegarde gère séparément la configuration de la zone de disponibilité du service et de vos données.

• Service: Le service de sauvegarde est automatiquement résilient dans les régions prises en charge. Toutefois, cette résilience de zone intégrée ne s’applique pas à vos données sauvegardées.

• Redondance du stockage de sauvegarde : Sélectionnez le niveau de redondance souhaité pour vos données de sauvegarde en configurant votre coffre Recovery Services ou votre coffre de sauvegarde. Si vous sélectionnez ZRS, les copies de vos données de sauvegarde sont automatiquement stockées dans plusieurs zones de disponibilité dans la région Azure que vous utilisez.

  Si vous n’utilisez pas ZRS, vos données de sauvegarde sont considérées comme nonzonales et peuvent être stockées dans n’importe quelle zone. Si une zone de la région présente un problème, les données de sauvegarde nonzonales peuvent ne pas être disponibles.

Spécifications

• Prise en charge régionale : Le service est automatiquement résilient aux zones de disponibilité dans toutes les régions qui en disposent. Les coffres ZRS bénéficient d'un support dans les mêmes régions.

• Nouveaux coffres uniquement : Configurez ZRS sur votre coffre avant la première sauvegarde.

Coûts

Lorsque vous activez ZRS pour vos sauvegardes, vous êtes facturé à un débit différent de celui de LRS en raison de la surcharge supplémentaire de réplication et de stockage. Pour plus d’informations, consultez la tarification de la sauvegarde.

Configurez la prise en charge des zones de disponibilité

• Créez un coffre qui utilise ZRS : Configurez la redondance du stockage lorsque vous créez un coffre. Vous suivez différentes étapes en fonction du type de coffre-fort. Pour plus d’informations, consultez les articles suivants :

  • Créer et supprimer des coffres de sauvegarde
  • Créer et configurer un coffre Recovery Services

• Configurez ZRS sur les coffres existants : Pour les coffres de sauvegarde, configurez la redondance du stockage lorsque vous créez le coffre. Une fois que vous avez créé un coffre de sauvegarde, le paramètre est verrouillé et vous ne pouvez pas le modifier.

  Pour les coffres Recovery Services, vous devez configurer la redondance du stockage avant de protéger les charges de travail. Après avoir protégé une charge de travail, le paramètre est verrouillé et vous ne pouvez pas le modifier.

  Vous pouvez créer un coffre configuré pour utiliser ZRS et réaffecter vos charges de travail au nouveau coffre. Toutefois, cette approche nécessite un temps d’arrêt. Pour plus d’informations, consultez Modifier les paramètres par défaut. Vous êtes également responsable de la suppression manuelle des points de récupération existants et d’autres données, car les politiques de rétention de l’ancien coffre ne s’appliquent plus. Pour plus d’informations, consultez Supprimer un coffre de sauvegarde ou Supprimer un coffre Recovery Services.

Comportement lorsque toutes les zones sont saines

Cette section décrit à quoi s'attendre lorsque vous configurez des coffres pour ZRS et que toutes les zones sont en fonctionnement.

• Opération interzone : Les travaux de sauvegarde s’exécutent sur l’infrastructure répliquée entre les zones. Azure gère les travaux de l’infrastructure dans n’importe quelle zone.

• Réplication des données interzones : ZRS réplique les données sauvegardées entre les zones. La réplication se produit de manière synchrone, ce qui signifie que plusieurs zones reconnaissent chaque opération d’écriture avant qu’elle ne se termine.

Comportement lors d’une défaillance de zone

Cette section décrit à quoi s'attendre lorsque vous configurez des coffres pour ZRS et qu'une panne survient dans l’une des zones.

• Detection et response : Pour le service de sauvegarde lui-même, Microsoft est responsable de la détection des défaillances dans les zones de disponibilité et de la réponse. Vous n’avez rien à faire pour initier un failover de zone.

  Important

  Pour toutes les données ou ressources qui ne sont pas disponibles en raison de la panne de zone, vous êtes responsable de la détection de la panne et de l’exécution d’actions de récupération, notamment la restauration de sauvegardes dans une zone saine.

• Notification : Microsoft ne vous avertit pas automatiquement lorsqu'une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle et configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes d’intégrité Service Health pour vous avertir des problèmes.

• Demandes actives : Le comportement des travaux actifs dépend de la zone qui échoue.

  • Pour toute source de données dans la zone de disponibilité défaillante, la défaillance de la zone rend les sources de données indisponibles. Les tâches actives peuvent être suspendues ou échouer.

  • Pour toutes les sources de données dans des zones de disponibilité saines qui exécutent des travaux actifs, une petite quantité de temps d’arrêt, généralement quelques secondes, peuvent se produire pendant que la plateforme bascule vers des zones de disponibilité saines pour le service de sauvegarde.

• Perte de données attendue : La quantité attendue de perte de données est également appelée objectif de point de récupération (RPO). Le RPO de vos données de sauvegarde dépend de plusieurs facteurs, notamment votre planification de sauvegarde. En règle générale, pour une panne de zone, aucune perte de données sauvegardées n’est attendue, car toutes les données sont répliquées de manière synchrone entre les zones.

• Temps d’arrêt attendu : Le temps d’arrêt attendu est également appelé objectif de temps de récupération (RTO). Le RTO est différent pour chacun des scénarios suivants :

  • Pour toutes les sources de données dans la zone de disponibilité en panne, il est possible qu'elles ne soient pas disponibles tant que la zone n’est pas rétablie. Les travaux de sauvegarde peuvent échouer jusqu’à ce que la source de données soit à nouveau disponible. Le RTO n’est pas défini.

  • Pour toutes les sources de données dans des zones de disponibilité saines, une petite quantité de temps d’arrêt, généralement quelques secondes, peut se produire pendant que la plateforme bascule vers des zones de disponibilité saines pour le service de sauvegarde.

• Redistribution: Les exécutions de travaux suivantes utilisent automatiquement l’infrastructure dans des zones saines tant que les sources de données sont disponibles.

  Vous êtes responsable de la restauration de votre sauvegarde sur l’infrastructure dans une zone saine et de la reconfiguration des équilibreurs de charge, des clients et d’autres systèmes pour rediriger le trafic vers une infrastructure saine dans la nouvelle zone.

Récupération de la zone

Lorsque la zone de disponibilité récupère, la sauvegarde restaure automatiquement les opérations dans la zone de disponibilité et redirige le trafic entre les zones normalement. Les travaux continuent d’être exécutés et les données restent disponibles.

Tester les pannes de zone

La plateforme de sauvegarde gère le routage du trafic, la réplication des données, le basculement et la restauration après panne. Cette fonctionnalité est entièrement gérée. Vous n’avez donc pas besoin de lancer ou de valider les processus d’échec de zone de disponibilité.

Résilience aux défaillances à l’échelle de la région

La sauvegarde prend en charge la géoredondance et le basculement automatique via GRS et CRR.

Stockage géoredondant et restauration transrégionale

Pour obtenir une redondance régionale pour vos données de sauvegarde, utilisez Backup pour répliquer vos sauvegardes dans une région jumelée Azure à l’aide de GRS. GRS protège vos sauvegardes contre les pannes régionales.

La région dans laquelle vous déployez votre coffre est appelée région primaire. Vos sources de données doivent se trouver dans la région primaire. Vous ne pouvez pas configurer les sauvegardes vers un coffre situé dans une autre région.

La région jumelée est également appelée région secondaire.

Si vous ne configurez pas GRS et qu’une panne se produit dans la région du coffre-fort, vous pourrez peut-être accéder au coffre-fort et consulter les éléments de sauvegarde. Toutefois, sans redondance régionale, les données de sauvegarde sous-jacentes restent indisponibles pour les opérations de restauration.

Effectuer une restauration interrégion

Lorsque vous configurez GRS sur un coffre, Microsoft rend les sauvegardes dans la région jumelée disponible après une panne dans la région primaire. Si votre source de données prend en charge CRR, vous pouvez effectuer une restauration à partir de points de récupération de région secondaire, même quand aucune panne ne se produit dans la région primaire. La CRR vous permet également d’exécuter des exercices pour évaluer la résilience contre les pannes régionales. Lorsque vous activez CRR, Microsoft met à niveau votre stockage de sauvegarde à partir de GRS vers un stockage géoredondant avec accès en lecture (RA-GRS).

Spécifications

• Region support : GRS for Backup fonctionne uniquement dans les régions paired Azure.

• Nouveaux coffres uniquement : Vous devez configurer GRS sur votre coffre avant la première sauvegarde.

Considérations

• CRR : Après avoir activé CRR, les éléments de sauvegarde peuvent prendre jusqu’à 48 heures pour être disponibles dans la région secondaire.

Coûts

Les coffres GRS entraînent des frais supplémentaires liés à la réplication interrégionale et au stockage dans la région secondaire. Le transfert de données entre les régions Azure est facturé en fonction des taux de bande passante interrégionale standard. Le CRR est facturé à un tarif différent, car Microsoft met à niveau votre stockage de coffre de GRS vers RA-GRS. Pour plus d’informations, consultez la tarification de la sauvegarde.

Configurer la prise en charge multirégion

• Créez un coffre qui utilise GRS et CRR : Lorsque vous créez un coffre, vous devez également configurer la redondance du stockage. Après avoir sélectionné GRS, vous pouvez éventuellement activer CRR sur le coffre. Les étapes que vous suivez dépendent du type de coffre. Pour plus d’informations, consultez les articles suivants :

  • Créer et supprimer des coffres de sauvegarde
  • Créer et configurer un coffre Recovery Services

• Configurez GRS et CRR sur les coffres existants : Pour les coffres de sauvegarde, vous devez configurer la redondance du stockage lorsque vous créez le coffre.

  Pour les coffres Recovery Services, vous devez configurer la redondance du stockage avant de protéger les charges de travail. Une fois qu’une charge de travail est protégée, le paramètre est verrouillé et vous ne pouvez pas le modifier.

  Vous pouvez activer CRR sur les coffres GRS existants. Après avoir activé CRR, vous ne pouvez pas le désactiver.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce à quoi vous attendre lorsque vous configurez des coffres pour utiliser GRS et toutes les régions sont opérationnelles.

• Opération inter-régionale : Les sauvegardes sont toujours effectuées dans la région primaire, qui est la région où le coffre-fort et la source de données sont déployés.

• Réplication des données interrégions : Lorsque vous configurez le coffre pour utiliser GRS, les sauvegardes sont d’abord répliquées dans la région primaire en utilisant LRS. Une fois l’achèvement réussi dans la région primaire, les données sont répliquées de manière asynchrone dans la région secondaire. La région secondaire utilise LRS pour stocker des données. Les données de sauvegarde peuvent prendre jusqu’à 12 heures pour répliquer de la région primaire vers la région secondaire.

Comportement lors d’une défaillance de région

Cette section décrit à quoi s'attendre lorsque vous configurez des coffres pour utiliser GRS et qu'une panne se produit dans la région principale.

• Détection et réponse : Pour les sources de données qui prennent en charge CRR et où CRR est activé sur le coffre, vous pouvez lancer votre propre CRR vers la région jumelée à tout moment, y compris lors d’une panne de région ou d’un sinistre. Vous êtes responsable de la détection de la panne et de l’exécution d’actions de récupération, notamment la restauration de sauvegardes dans une région saine.

  Pour tous les autres scénarios, les données répliquées vers la région secondaire sont disponibles pour la restauration dans la région secondaire uniquement si Azure déclare un sinistre dans la région primaire. Microsoft est responsable de la déclaration d’un sinistre. Le temps nécessaire à la déclaration d’un sinistre dépend de la gravité de l’incident et du temps nécessaire pour évaluer la situation. Microsoft déclare généralement une catastrophe uniquement après une période prolongée.

• Notification : Microsoft ne vous avertit pas automatiquement lorsqu'une région est en panne. Toutefois:

  • Vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle et configurer des alertes Resource Health pour vous avertir des problèmes.

  • Vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes d’intégrité Service Health pour vous avertir des problèmes.

• Perte de données attendue : Le RPO de vos données de sauvegarde dépend de plusieurs facteurs, notamment votre planification de sauvegarde. En général, pour une panne de région, prévoyez jusqu’à 36 heures de perte de données, car le RPO dans la région primaire est de 24 heures et peut prendre jusqu’à 12 heures pour répliquer les données de sauvegarde de la région primaire vers la région secondaire.

• Temps d’arrêt attendu : Le RTO est différent pour chacun des scénarios suivants :

  • Les sources de données et d’autres ressources de la région ayant échoué peuvent ne pas être disponibles tant que la région n’est pas récupérée, de sorte que le RTO n’est pas défini.

  • La sauvegarde peut ne pas être en mesure d'effectuer des opérations de sauvegarde ou de restauration dans la région défaillante jusqu'à ce que la région soit rétablie, le RTO reste indéfini.

  • Si vous utilisez CRR, le RTO pour lancer la restauration des sauvegardes déjà répliquées dans la région jumelée est égal à zéro. Si vous n'utilisez pas CRR, le RTO dépend du temps nécessaire pour Microsoft déclarer un sinistre dans la région ayant échoué.

• Redistribution: Aucun travail de sauvegarde ne peut s’exécuter pendant que la région primaire est hors connexion. Vous pouvez restaurer les données dans le coffre-fort, mais vous ne pouvez pas ajouter de nouvelles données.

  Vous êtes responsable de la restauration de votre sauvegarde dans l’infrastructure dans la région jumelée et de la reconfiguration des équilibreurs de charge, des clients et d’autres systèmes pour rediriger le trafic vers une infrastructure saine dans la région jumelée.

Récupération de région

Lorsque la région primaire récupère, la sauvegarde restaure automatiquement les opérations dans la région. Les travaux reprendnt et les données restent disponibles.

Tester les défaillances régionales

Vous pouvez utiliser CRR pour effectuer une opération de restauration dans la région jumelée. Vous pouvez utiliser cette approche pour vérifier la restauration et d’autres processus de récupération.

Résilience à la perte de données de sauvegarde

La sauvegarde fournit deux fonctionnalités de récupération clés pour empêcher la suppression accidentelle ou malveillante de vos données de sauvegarde :

• La suppression temporaire vous permet de récupérer des objets et des coffres supprimés pendant une période de rétention configurable. Par défaut, cette période est de 14 jours, mais vous pouvez la modifier. Considérez la suppression réversible comme la Corbeille de recyclage pour vos sauvegardes et coffres-forts. Pour plus d’informations, consultez Sécuriser par défaut avec la suppression réversible pour la sauvegarde.

• Les coffres immuables peuvent vous aider à protéger vos données de sauvegarde en bloquant les opérations susceptibles d’entraîner une perte de points de récupération. Vous pouvez verrouiller le paramètre de voûte immuable pour la rendre irréversible. Vous pouvez également utiliser le stockage WORM (écriture unique, lecture multiple) pour les sauvegardes, afin d'empêcher des acteurs malveillants de désactiver l’immuabilité et de supprimer les sauvegardes. Pour plus d’informations, consultez le coffre immuable pour la sauvegarde.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour Azure services décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez ALS pour les services en ligne.

Le contrat SLA de sauvegarde couvre la disponibilité du service pour les opérations de sauvegarde et de restauration. Pour être couvert par le contrat SLA, vous devez réessayer les travaux de sauvegarde ou de restauration ayant échoué au moins une fois toutes les 30 minutes.

Contenu connexe

• Reliability in Azure
• Reliability in Machines virtuelles Azure
• Reliability in Stockage sur disque Azure
• Reliability in Azure Site Recovery