Restaurez-vous dans une seconde région grâce au Cross Region Restore

Qui a dit que le Cloud était sans aucun danger ? Qui a dit que tout était sauvegardé nativement dans le Cloud ? De plus, on n’imagine pas non plus perdre une région entière d’Azure. Malgré tout, des contre-mesures doivent être mises en place pour prévenir le risque. Plusieurs méthodes existent déjà pour augmenter la résilience d’une infrastructure IT. Dans cet article, nous allons prendre le temps de nous intéresser à une fonctionnalité spécifique du backup d’Azure, appelée Cross Region Restore.

Comme l’indique Microsoft dans sa documentation, l’option de Restauration inter-région (Cross Region Restore) permet de restaurer des données dans la région jumelée Azure à votre site de production. Ce service est donc disponible via Azure Backup. Une coffre de sauvegarde est donc déployé dans la région de production pour gérer la passerelle des données. A l’heure où ces lignes sont écrites, cette fonctionnalité supporte les sources de données suivantes :

  • Machines virtuelles Azure (disponibilité générale)
  • Bases de données SQL, hébergées sur des machines virtuelles Azure (préversion)
  • Bases de données SAP HANA, hébergées sur des machines virtuelles Azure (préversion)
Célèbre Viaduc de Millau en France, au-dessus des nuages.

Régions paires d’Azure

Comme indiqué par Microsoft, une région Azure comporte un ensemble d’un ou plusieurs datacenters connectés via un réseau dédié à faible latence :

Le nombre de datacenters au sein d’une région Azure est variable.

Liste des régions Azure :

GéographiePaire régionale APaire régionale B
Asie-PacifiqueAsie Est (Hong Kong, R.A.S.)Asie Sud-Est (Singapour)
AustralieAustralie EstSud-Australie Est
AustralieCentre de l’AustralieAustralie Centre 2*
BrésilBrésil SudÉtats-Unis – partie centrale méridionale
BrésilBrésil Sud-Est*Brésil Sud
CanadaCentre du CanadaEst du Canada
ChineChine du NordChine orientale
ChineChine Nord 2Chine orientale 2
EuropeEurope Nord (Irlande)Europe Ouest (Pays-Bas)
FranceFrance CentreFrance Sud*
AllemagneAllemagne Centre-OuestAllemagne Nord*
IndeInde centraleInde Sud
IndeInde OuestInde Sud
JaponJapon EstJapon Ouest
Corée du SudCentre de la CoréeCorée du Sud
Amérique du NordUSA EstUSA Ouest
Amérique du NordUSA Est 2USA Centre
Amérique du NordCentre-Nord des États-UnisÉtats-Unis – partie centrale méridionale
Amérique du NordUSA Ouest 2Centre-USA Ouest
NorvègeNorvège EstNorvège Ouest*
Afrique du SudAfrique du Sud NordAfrique du Sud-Ouest*
SuisseSuisse NordSuisse Ouest*
Royaume-UniOuest du Royaume-UniSud du Royaume-Uni
Émirats Arabes UnisÉmirats arabes unis NordÉmirats arabes unis Centre*
Ministère de la défense des États-UnisUS DoD Est*US DoD Centre*
Gouvernement américainUS Gov Arizona*US Gov Texas*
Gouvernement américainUS Gov Iowa*US Gov Virginie*
Gouvernement américainUS Gov Virginie*US Gov Texas*

Note : Comme indiqué dans un précédent billet sur la région Azure Suisse Ouest, certaines régions offrent un accès restreint pour la prise en charge de scénarios client spécifiques : par exemple la récupération d’urgence. Ces régions ne sont disponibles que sur demande en créant une demande de support dans le portail Azure.

Tarification de la sauvegarde Azure et de la fonctionnalité CRR

Dans le cadre de sauvegarde de machines virtuelles Azure, Microsoft indique clairement dans sa brochure tarifaire que l’activation de la fonctionnalité CRR entraine une évolution du SKU du compte de stockage, pour permettre la sauvegarde et la lecture de vos données dans les deux régions. Pour vous aider à y voir plus clair, voici la décomposition tarifaire de la sauvegarde faite via le service Azure Backup.

Azure facture en premier lieu l’instance sauvegardée, en fonction de sa taille :

Taille de chaque instanceTarif Sauvegarde Azure par mois
Instance inférieure ou égale à 50 GoCHF 7,3808 + stockage utilisé
Instance supérieure à 50 Go mais inférieure ou égale à 500 GoCHF 14,7615 + stockage utilisé
Instance supérieure à > 500 GoCHF 14,7615 pour chaque incrément de 500 Go + stockage utilisé

L’exemple de calcul donné par Microsoft est assez clair :

Exemple : si vous avez 1,2 To de données dans une instance spécifique, le coût correspond à CHF 44,29 (+ le stockage consommé, voir plus bas). Vous êtes alors facturé CHF 14,77 pour chacun des 2 incréments de 500 Go et CHF 14,77 pour les 200 Go de données restants.

44.29 CHF = 14.76 x 3 (3 incréments de 500 Go)

Est donc également facturé le volume de données sauvegardées. On ne parle plus ici de la taille de l’instance sauvegardée, mais bien de la taille totale prise par l’ensemble des sauvegardes journalières, hebdomadaires, mensuelles et annuelles. Le volume total va alors dépendre de différents facteurs comme :

  • La fréquence des sauvegardes
  • La durée de rétention des sauvegardes
  • Le facteur de compression des données brutes

Selon le niveau de protection désiré, le coût du stockage au Go peut lui aussi varier :

Niveau StandardNiveau Archive
LRSCHF 0,0331 par GoCHF 0,0043 par Go
ZRSPréversionCHF 0,0414 par GoS.O.
GRSCHF 0,0662 par GoCHF 0,0085 par Go
RA-GRSCHF 0,0840 par GoCHF 0,0085 par Go
Si vous activez l’option CRR sur votre coffre de sauvegarde, le coût au Go sera obligatoirement en RA-GRS.

Activation de la fonctionnalité Cross Region Restore

Vous êtes maintenant décidé à activer cette fonctionnalité ? Nous allons donc voir le processus d’activation de cette dernière, étape par étape, puis nous finirons par un test.

Etape I : Création d’une machine virtuelle de départ

Notre point de départ une machine virtuelle sur la région North Europe. Si vous n’avez jamais déployé de machine virtuelle dans Azure, je vous conseille de suivre le Quickstart, mis à disposition par Microsoft.

Comme indiqué dans cette copie d’écran, j’ai déployé une VM dans la région Azure “North Europe”.

Etape II : Création et configuration d’un coffre de sauvegarde Recovery Services Vault

Ce coffre de sauvegarde va nous servir pour piloter la sauvegarde de la machine virtuelle initiale. Ce coffre de sauvegarde doit être créé dans la même région Azure que la machine virtuelle, à l’inverse d’un coffre dédié à une solution de Disaster Recovery. Voici le processus de création de celui-ci étape par étape :

Utilisez la barre de recherche pour créer cette nouvelle ressource.

Renseignez les champs ci-dessous pour terminer la création de votre coffre de sauvegarde :

Pensez donc à positionner votre coffre dans la même région Azure que votre machine virtuelle.

Une fois que votre coffre de sauvegarde est créé, vous allez pouvoir activer la fonctionnalité de Cross Region Restore via le propriété de configuration de ce dernier :

Cette opération est à faire avant la mise en place de sauvegarde.

Deux options sont ici présentes dans la configuration du coffre de sauvegarde :

  • Type de réplication (LRS / ZRS / GRS) : nous parlons ici du nombre total de copies des sauvegardes et de leur localisation géographique sur l’infrastructure Azure
  • Cross Region Restore : Oui / Non
Important : ces options sont uniquement modifiables avant le démarrage de la première sauvegarde. Cela n’est plus possible de les changer après.

Etape III : Activation et démarrage de la sauvegarde

Une fois les options paramétrées, nous allons activer la sauvegarde de la machine virtuelle initiale. L’opération peut se faire depuis le coffre de sauvegarde ou directement sur la machine virtuelle :

L’écran suivant commence par détailler la police de sauvegarde à appliquer pour cette machine virtuelle. Il est question ici de définir le nombre de sauvegardes à faire et de leur rétention. Aucune police n’est créée à l’origine, vous pouvez donc la configurer directement via ce processus :

Par défaut, seule une sauvegarde journalière est définie. Elle sera conservée pendant 30 jours.
L’ajout de sauvegardes aura un impact sur le coût total de la sauvegarde. Une rétention plus longue augmente le coût.

Une fois la police créée, il est maintenant temps de sélectionner la machine virtuelle initiale pour continuer pour votre test :

Seules les machines virtuelles créées dans la région North Europe seront présentées dans cette liste de choix.

L’activation de la sauvegarde provoque la création automatique de ressources Azure :

Ce processus est rapide 🙂

Un retour dans le coffre de sauvegarde indique les objets sauvegardés et donc la bonne prise en compte de notre machine virtuelle initiale.

Note : Vous pouvez déjà apercevoir ici un filtre sur l’affichage de la première ou de la seconde région Azure.

Un clique sur la ligne “Azure Virtual Machine” affiche la machine virtuelle sauvegardée et le statut actuel de l’état de sauvegarde de cette dernière :

Un avertissement est présent car la première sauvegarde journalière n’a pas encore été faite. Cette sauvegarde sera déclenchée selon la police de sauvegarde.

Afin d’aller plus loin dans notre démonstration de la fonctionnalité CRR, nous allons devoir déclencher la première sauvegarde manuellement :

Cette sauvegarde est déclenchée manuellement, la durée de rétention est modifiable.
Le schéma ci-dessous nous montre l’étape de création du snapshot, faite au moment de la sauvegarde. Celui-ci reste à “proximité” des disques de la machine virtuelle. Les données seront transférées au coffre de sauvegarde ultérieurement.

Vous pouvez suivre l’avancement de la sauvegarde en consultant les jobs de sauvegarde. Le processus de sauvegarde initial est rapide, mais le transfert de données vers le coffre prend un peu de temps :

Le processus de sauvegarde commence par un snapshot local, puis un transfert vers le coffre de sauvegarde.

Une heure plus tard, la première sauvegarde de ma machine virtuelle est entièrement terminée et transférée vers le coffre de sauvegarde :

Le snapshot est fait et les données de sauvegarde ont bien été transférées au coffre de sauvegarde.

L’écran ci-dessous indique que l’avertissement précédent a disparu et que la sauvegarde faite manuellement est de type “Application consistent”.

Au passage, voici un rappel des différents types de cohérence de sauvegarde :

InstantanéDétails
Cohérence des applicationsLes sauvegardes cohérentes dans les applications capturent le contenu et les opérations d’E/S en attente de la mémoire. Les instantanés de cohérence d’application utilisent l’enregistreur VSS (ou un pré/post-script pour Linux) pour vérifier la cohérence des données d’application avant une sauvegarde.
Cohérence du système de fichiersLes sauvegardes cohérentes de système de fichiers assurent la cohérence en prenant une capture instantanée de tous les fichiers au même moment.
Cohérence en cas d’incidentDes instantanés de cohérence des incidents sont pris généralement si une machine virtuelle Azure s’arrête au moment de la sauvegarde. Seules les données déjà présentes sur le disque au moment de la sauvegarde sont capturées et sauvegardées.

Un retour dans le coffre de sauvegarde nous montre un premier travail effectué dans la seconde région Azure :

Un clique sur l’objet donne toutes les informations relatives aux sauvegardes :

La sauvegarde étant faite ce matin, le point de sauvegarde n’est pas encore transposé sur la seconde région Azure. Il va falloir faire preuve de patience pour finir la restauration de la machine virtuelle sur la seconde région Azure :

L’écran ci-dessus montre aucun point de restauration dans la seconde région Azure. Le transfert de sauvegardes entre régions n’est pas prioritaire.

Etape IV : Préparation à la restauration de la machine virtuelle

L’objectif de ce Cross Region Restore est bien de créer une nouvelle machine virtuelle dans la seconde région Azure. Vous trouverez toutes les informations relatives à restauration ici. En attendant de pouvoir avancer sur la restauration, j’en profite pour créer un compte de stockage, nécessaire à la future restauration.

Afin de faciliter la lecture ultérieure au travers du portail Azure, je vous conseille de créer les prochaines ressources dans un nouveau groupe de ressources, lui-même placé dans la seconde région Azure. Ce compte de stockage doit donc être créé de la façon suivante :

Le compte stockage doit être sur la seconde région Azure, de performance Standard et en redondance LRS.

Etape V : Restauration de la machine virtuelle sur la seconde région Azure

Quelques heures plus tard, je suis enfin en mesure de continuer l’opération de restauration. Je retourne donc sur le coffre de sauvegarde pour constater que la seconde région comporte bien le premier point de restauration :

Un nouveau clique sur l’item “Azure Virtual Machine” montre le premier point de restauration transféré entre les deux régions.
L’opération de transfert entre les régions aura donc pris plusieurs heures, mais s’est fait de manière transparente.

Note : La restauration ne peut se faire que si certaines ressources sont déjà en place dans la région de destination. Nous avions déjà vu dans l’étape précédente la création d’un compte stockage, utilisé en tampon. A celui-ci, il faudra également créer un réseau virtuel, pour relier la nouvelle machine virtuelle :

Pensez donc à créer le VNet au préalable pour terminer cette restauration.

Afin de suivre l’avancement de la restauration, un tour dans les travaux du coffre de sauvegarde permet d’obtenir plus d’informations :

Les jobs de CRR ne se trouvent pas dans la page principale, mais dans la liste de travaux de la région secondaire.
Cette opération prend quelques dizaines de minutes.
Ce processus n’est pas aussi rapide qu’un failover déclenché par Azure Site Recovery. Son objectif est lui aussi différent.
Le processus de restauration aura donc pris une peu moins de 30 minutes.

Afin de constater la création des nouvelles ressources Azure, je retourne sur le nouveau groupe de ressources créé sur “West Europe”. J’y constate la présence d’une nouvelle machine virtuelle et de toutes ses ressources associées :

Toutes les ressources présentes ici sont bien positionnées sur la seconde région Azure.
La nouvelle machine virtuelle est bien opérationnelle.

Un essai de connection RDP est possible :

Les codes d’administration sont les mêmes que ceux renseignés sur la machine virtuelle initiale.
Je retrouve bien la session d’administration 😎

Conclusion

Au final, la fonctionnalité Cross Region Restore d’Azure Backup fonctionne très bien entre région Azure. C’est une solution pour repartir en cas de désastre. A ne pas confondre avec une véritable solution de Disaster Recovery, elle permet par contre de conserver une meilleur contrôle des sauvegardes faites par Azure Backup.

Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Backup 😋