Reprise après sinistre avec NAKIVO : planification, mise en œuvre et tests

La sauvegarde et la reprise après sinistre constituent les fondements des stratégies de protection des données au sein des organisations et dans tous les secteurs d’activité. Reprise après sinistre désigne le processus de récupération des machines virtuelles et des services qui y sont exécutés sur un site secondaire (appelé « site de reprise après sinistre ») lorsque le site de production devient indisponible. Ces sites, qui hébergent des serveurs, des ordinateurs et des équipements réseau redondants dotés des logiciels nécessaires, Les sites DR secondaires peuvent être de différents types. en fonction du niveau de redondance.

NAKIVO Backup & Replication intègre la fonctionnalité Reprise après sinistre qui vous permet de créer des séquences de reprise avancées (avec basculement complet du site) pouvant être lancées d’un simple clic en cas de panne de votre site principal. Lisez cet article de blog pour en savoir plus sur les éléments clés d’une stratégie de reprise après sinistre, tels que la planification informatique de la reprise après sinistre, les tests et la mise en œuvre de la reprise après sinistre grâce à la solution intégrée de NAKIVO.

Garantir la disponibilité avec NAKIVO

Respectez les conditions strictes en matière de disponibilité des services dans les infrastructures virtuelles. Atteignez vos objectifs de disponibilité grâce à des fonctionnalités robustes d'orchestration et d'automatisation de la reprise après sinistre.

DÉCOUVREZ LA SOLUTION

Étape 1. Planification de la reprise après sinistre

Étape essentielle à une reprise après sinistre efficace, la planification doit inclure une évaluation des besoins de l’organisation en matière de reprise, ainsi qu’une compréhension globale des composants, étapes et procédures à intégrer dans un processus de reprise après sinistre.

Planification de la reprise après sinistre : bonnes pratiques

1. Réaliser une analyse d’impact sur l’activité

Une analyse d’impact sur l’activité (ou BIA) permet de déterminer l’impact négatif potentiel d’incidents majeurs ou de catastrophes naturelles sur les opérations de l’entreprise. Cette analyse consiste à établir un ordre de priorité pour les différentes VMs, à définir l’ordre de récupération et à évaluer le délai disponible avant qu’une interruption n’affecte de manière significative les opérations de l’entreprise. Par exemple, la défaillance d’une VM peut entraîner des retards et des désagréments, tandis que celle d’une autre peut conduire à une interruption totale des opérations critiques pour l’entreprise.

2. Évaluer les risques encourus

Avant de planifier la reprise après sinistre, rassemblez les données pertinentes concernant les risques pesant sur les opérations et la continuité d’activité de votre organisation. Dans certaines régions, une coupure d’électricité prolongée ou une attaque virale sont plus probables qu’une tornade, tandis que les catastrophes naturelles sont fréquentes dans d’autres. Une évaluation des risques vous aide à déterminer le niveau de protection approprié contre certaines menaces et à mettre en place des mesures visant à minimiser les risques et à en atténuer les conséquences. Même si les risques ne peuvent être totalement éliminés, vous serez mieux préparé aux scénarios de catastrophe auxquels vous êtes susceptible d’être confronté.

3. Élaborer la documentation relative à la reprise après sinistre

Une fois les risques et leur impact potentiel sur votre activité identifiés, vous comprenez mieux sur quoi concentrer vos efforts pour planifier les processus de reprise après sinistre. Procédures de récupération des documents, en décrivant en détail toutes les étapes essentielles et les mesures de reprise après sinistre, et mettez régulièrement à jour les documents afin de refléter les changements intervenus dans l’environnement. La documentation doit inclure :

• Disaster recovery scope. Évaluez l’importance de chaque composant matériel et logiciel de votre infrastructure et intégrez ceux qui sont essentiels aux opérations critiques dans votre plan de reprise après sinistre. Les VMs hébergeant des informations critiques, des systèmes informatiques et des applications dont le fonctionnement est indispensable pour assurer la continuité des services doivent constituer votre priorité absolue en matière de récupération.
• VM recovery order. Certaines VMs peuvent dépendre des logiciels ou des informations hébergés dans une autre VMs, ce qui signifie qu’elles ne peuvent pas fonctionner séparément ni être démarrées de manière aléatoire. Vous devez définir l’ordre de restauration afin d’optimiser le processus et d’éliminer tout risque de conflit logiciel sur le site de reprise après sinistre. Par exemple, la machine virtuelle hébergeant le contrôleur de domaine Active Directory doit être opérationnelle avant que vous puissiez démarrer une machine virtuelle hébergeant un serveur de fichiers utilisant l’authentification Active Directory.

Un autre exemple concerne les services Web, qui s’appuient souvent sur des logiciels installés sur plusieurs VMs différentes. La séquence suivante peut s’avérer nécessaire :

1. La machine virtuelle hébergeant le serveur de base de données doit être démarrée en premier.
2. La machine virtuelle hébergeant le serveur d’applications peut ensuite être démarrée.
3. Ce n’est qu’alors que la machine virtuelle hébergeant le serveur web peut être démarrée.

• RTO and RPO in disaster recovery. Définissez le objectifs de temps de récupération (RTO) et le objectifs de point de récupération (RPO) pour les machines virtuelles de différentes priorités dans le plan de reprise après sinistre. Par exemple, les machines virtuelles hébergeant des systèmes financiers peuvent avoir des objectifs de reprise plus courts que celles utilisées pour le stockage de documents archivés.
• Dependencies. Lors de la détermination de la chaîne de dépendances entre le personnel et les composants informatiques, collaborez avec vos collaborateurs et tenez compte de leurs besoins afin d’éviter les maillons faibles susceptibles d’entraîner l’échec de la récupération. Par exemple, une machine virtuelle utilisée par le service comptable devra peut-être être récupérée en priorité si les employés d’autres services dépendent de ces opérations financières pour effectuer leur travail.
• Staff. Attribuez des rôles et des responsabilités aux membres de l’équipe impliqués dans les processus de récupération après sinistre. S’ils doivent travailler sur le site de reprise après sinistre, assurez-vous que des postes de travail y soient installés, équipés de tout le matériel nécessaire, du mobilier de bureau et des équipements informatiques, afin qu’ils puissent poursuivre leur travail avec un minimum d’interruptions. Si les employés peuvent travailler à distance en cas de sinistre, configurez l’accès VPN et fournissez-leur des comptes VPN à l’avance.
• Hardware requirements. La réussite d’un plan de reprise après sinistre dépend fortement des performances et des capacités du matériel situé sur le site de reprise après sinistre. Plusieurs facteurs doivent être pris en compte :
• Les serveurs doivent disposer d’une puissance de processeur, d’une mémoire et d’une capacité de stockage suffisantes pour prendre en charge les Workloads transférés. Des performances de processeur faibles et une mémoire insuffisante peuvent affecter la vitesse de vos VMs, tandis qu’une vitesse de disque insuffisante entraîne de mauvaises performances des VMs.
• Les réseaux doivent fournir une bande passante suffisante pour que les VMs restaurées puissent interagir entre elles, avec stockage partagé, et avec les utilisateurs si nécessaire.

Étape 2. Préparation à la reprise après sinistre

Une fois votre documentation en main, vous pouvez passer à la préparation de la reprise après sinistre en mettant en place le site de reprise et en configurant la réplication des charges de travail critiques vers ce site. La réplication est nécessaire pour Basculement de machine virtuelle afin de disposer de machines virtuelles répliquées en cas de panne de l’infrastructure principale.

Qu’est-ce que la réplication de machines virtuelles ?

La réplication de machines virtuelles consiste à créer une copie identique d’une machine virtuelle source (appelée « réplique de machine virtuelle ») sur un autre hôte (l’hôte cible). La réplique de machine virtuelle est une machine virtuelle classique qui reste à l’arrêt jusqu’à ce qu’on en ait besoin (moment auquel elle peut être mise en service et fonctionner sur son hôte presque instantanément).

Découvrez comment créer et configurer une tâche de réplication VMware dans NAKIVO Backup & Replication pour plus de détails.

Le processus consistant à basculer des Workloads d’une machine virtuelle source (de production) vers une réplique de machine virtuelle sur le site de reprise après sinistre (DR) dans le but d’assurer la continuité des activités et la haute disponibilité est appelé « basculement ».

Bonnes pratiques en matière de réplication de machines virtuelles

Il existe tout un éventail de bonnes pratiques en matière de réplication pour garantir une meilleure fiabilité et efficacité du processus. Nous nous concentrerons ici sur deux points clés :

• Perform VM replication at the {10}. La couche de virtualisation est la couche intermédiaire entre le matériel physique et le système d’exploitation invité s’exécutant sur une machine virtuelle. La réplication effectuée au niveau de la virtualisation est appelée « réplication au niveau de l’hôte » et s’avère plus efficace que la réplication au niveau de l’invité.
• Use application-aware replication to avoid data loss. Si un instantané de machine virtuelle nécessaire à la réplication est pris alors que ces applications sont en cours d’exécution, sans aucune action supplémentaire, l’effet serait similaire à une coupure de courant et un arrêt inattendus, et les données pourraient être perdues.

Avec les méthodes cohérentes avec les applications, les applications sont gelées (mises en état de quiescence) et la mémoire est vidée ; aucune donnée ne peut être écrite sur le disque avant la prise de l’instantané. Une fois l’instantané cohérent pris, une réplique de la machine virtuelle peut être créée. Ces répliques de machines virtuelles peuvent être restaurées avec succès, les applications qu’elles contiennent fonctionnant correctement.
NAKIVO Backup & Replication prend en charge la réplication au niveau de l’hôte cohérente avec les applications pour les machines virtuelles VMware, Hyper-V et les instances EC2, avec des fonctionnalités spécifiques pour Microsoft SQL Server, Exchange Server et le contrôleur de domaine Active Directory.

Étape 3. Création d’un workflow de reprise après sinistre

Pour créer un workflow de reprise après sinistre, vous avez besoin d’une solution spécialisée telle que NAKIVO Backup & Replication, qui fournit une fonctionnalité intégrée de reprise après sinistre permettant d’orchestrer et d’automatiser les séquences de reprise après sinistre.

• Qu’est-ce qu’un processus de reprise après sinistre ?
• Actions disponibles pour un workflow de reprise après sinistre
• Comment créer un processus de reprise après sinistre
• Guide de configuration de la reprise après sinistre de NAKIVO

1. actions
2. Réseaux
3. Réassignation d’adresses IP
4. Calendrier des tests
5. Options

Qu’est-ce qu’un workflow de reprise après sinistre ?

Un workflow de reprise après sinistre est une séquence d’actions exécutées dans le cadre du processus de reprise après sinistre, afin d’assurer un basculement sûr et rapide des Workloads vers leurs réplicas. Le workflow organise le processus de basculement à l’aide d’actions liées aux VMs sources, aux VMs cibles, aux conditions à remplir, etc. Vous devez définir l’ordre dans lequel les actions doivent être exécutées, car certaines procédures de reprise après sinistre peuvent dépendre du résultat de l’exécution d’autres actions.

Actions Reprise après sinistre disponibles

La fonctionnalité Reprise après sinistre vous permet de créer des séquences de reprise après sinistre complexes en combinant des actions et des conditions au sein d’un même workflow. Chaque action peut être exécutée uniquement en mode test, uniquement en mode production, ou dans les deux modes (c’est le comportement par défaut) dans NAKIVO Backup & Replication.

Vous pouvez inclure tout ou partie des actions suivantes dans une séquence :

• Failover – lance le basculement vers des VMs VMware, Hyper-V ou des instances EC2 répliquées.
• Failback – transfère les workloads de la réplique de la machine virtuelle vers la machine virtuelle source. Les modifications apportées à la réplique de la machine virtuelle depuis le moment du basculement sont répercutées sur la machine virtuelle source lors de la restauration automatique. Les VMs sont synchronisées et la machine virtuelle source retrouve son état de production réel.
• Start – démarre des machines virtuelles VMware, des machines virtuelles Hyper-V ou des instances EC2.
• Stop – arrête les machines virtuelles VMware, les machines virtuelles Hyper-V et les instances EC2 en cours d’exécution.
• Run job – exécute une tâche de sauvegarde, de réplication, de reprise après sinistre, de copie de sauvegarde ou de démarrage instantané de machines virtuelles Flash.
• Stop jobs – arrête une tâche (l’une des tâches répertoriées au point précédent).
• Run script – exécute un script sur l’une des cibles suivantes : le serveur hébergeant Director, un Serveur Windows distant, un Serveur Linux distant, une machine virtuelle VMware, une machine virtuelle Hyper-V ou une instance EC2.
• Attach repository – associe un référentiel de sauvegarde utilisé par NAKIVO Backup & Replication pour stocker les sauvegardes.
• Detach repository – détache un référentiel de sauvegarde.
• Send email – envoie un e-mail contenant le message que vous rédigez à un ou plusieurs destinataires définis.
• Wait – attend le temps spécifié avant de passer à l’action suivante.
• Check condition – en fonction de votre saisie (tout ou partie d’un nom de ressource), vérifie l’une des conditions suivantes :
• La ressource existe
• La ressource est Exécution de
• L’adresse IP/le nom d’hôte est accessible

Comment créer un workflow Site Recovery

Voyons un exemple de création d’une tâche Site Recovery dans NAKIVO Backup & Replication.

Notre configuration

Voici la configuration que nous allons examiner : un site principal (de production) avec des machines virtuelles VMware vSphere et un site de reprise après sinistre (DR) situé à distance :

• DC-VM est une machine virtuelle Windows exécutant un contrôleur de domaine Active Directory.
• FS-VM est une machine virtuelle Windows hébergeant un serveur de fichiers (le protocole SMB est utilisé pour le partage de fichiers). Active Directory est utilisé pour l’authentification des utilisateurs. Les sauvegardes de la base de données Oracle sont stockées sur le serveur de fichiers.
• Ora-DB est la machine virtuelle sur laquelle s’exécute la base de données Oracle.

Le site de reprise après sinistre contient les machines virtuelles suivantes :

• DC-VM-replica et FS-VM-replica sont des réplicas des machines virtuelles de production. Elles peuvent servir de cibles pour le basculement.
• DB-VM est une machine virtuelle sous Linux avec Logiciel de base de données Oracle installé mais ne contient aucune base de données.

La base de données est sauvergardée avec NAKIVO Backup & Replication au niveau de la base de données vers FS-VM sur le site de production (cette sauvegarde Sauvegarde de la base de données Oracle est cohérente au niveau de l’application). FS-VM et DC-VM sont répliqués au niveau de l’hôte vers le site de reprise après sinistre à l’aide de la solution NAKIVO.

Ordre de restauration des machines virtuelles

Lors d’un incident entraînant la mise hors service du site de production, les composants doivent être restaurés sur le site de reprise après sinistre comme suit :

1. Basculement de DC-VM vers réplique de DC-VM.

2. Une fois que la réplique de la machine virtuelle DC ( ) est opérationnelle, effectuez le basculement de la machine virtuelle FS ( ) vers la réplique de la machine virtuelle FS ( ) . Vous devez respecter cet ordre car la machine virtuelle FS ( ) s’appuie sur la machine virtuelle DC ( ) pour l’authentification des utilisateurs sur le serveur de fichiers.
3. Une fois ces deux machines virtuelles en cours d’exécution, la machine virtuelle de base de données ( ) peut accéder au répertoire partagé sur le serveur de fichiers où est stocké le dump. La machine virtuelle de base de données ( ) peut alors être démarrée.

4. Une fois que DB-VM est en cours d’exécution, exécutez un script permettant de restaurer la base de données à partir de la sauvegarde située sur le serveur de fichiers. Les flèches bleues dans les schémas ci-dessus indiquent les dépendances.

Notez qu’un certain temps peut être nécessaire pour que les services démarrent sur une réplique de machine virtuelle mise sous tension après l’action de basculement et avant le basculement vers la réplique suivante ou la récupération d’une application ou d’une base de données. Ce délai d’attente doit faire partie de la séquence de reprise après sinistre (DR).

Pour cette procédure de basculement de machine virtuelle, vous devez créer une tâche de reprise après sinistre dans NAKIVO Backup & Replication en suivant la logique suivante :

• Action 1: Basculement de la machine virtuelle DC . Attendez que cette action soit terminée avant de passer à l’étape suivante. Arrêtez la tâche si cette action échoue.
• Action 2. Attendez pendant 3 minutes.
• Action 3. Vérifiez la condition de DC-VM-replica . Vérifiez si la ressource est en cours d’exécution. Si la ressource est en cours d’exécution, passez à l’action suivante de la tâche Site Recovery. Sinon, arrêtez la tâche et déclarez-la en échec.
• Action 4. Basculez la machine virtuelle FS . Attendez que cette action soit terminée avant de passer à l’action suivante. Arrêtez la tâche si cette action échoue.
• Action 5. Attendez pendant 3 minutes.
• Action 6. Vérifiez l’état de FS-VM-replica . Si la ressource est en cours d’exécution, passez à l’action suivante de la tâche Site Recovery. Sinon, arrêtez la tâche et déclarez-la en échec.
• Action 7. Démarrez DB-VM . Attendez que cette action soit terminée avant de passer à l’action suivante. Arrêtez la tâche si cette action échoue.
• Action 8. Attendez pendant 5 minutes.
• Action 9. Exécutez le script . Type de cible : machine virtuelle VMware. VM cible : DB-VM. Chemin d’accès au script : /home/oracle/restore_db.sh (lors de l’ajout de cette étape, vous devez saisir le nom d’utilisateur et le mot de passe d’un compte disposant des autorisations suffisantes pour exécuter le script).

Guide pratique de Reprise après sinistre de NAKIVO

Créons une nouvelle tâche de reprise après sinistre en suivant le plan décrit ci-dessus. Sur la page Jobs de votre instance NAKIVO Backup & Replication, cliquez sur Create > Site recovery job.

1. Actions

L’assistant de nouvelle tâche de reprise après sinistre s’ouvre. Dans le volet de gauche, vous trouverez les actions pouvant être ajoutées à la tâche. Il suffit de cliquer sur une action pour l’ajouter à la séquence. Notez que vous ne pouvez pas mélanger des actions destinées à différentes plateformes au sein d’une même séquence (nous créons ici une tâche pour des machines virtuelles VMware).

Action 1. Basculement vers la machine virtuelle DC-VM

1. Dans le volet de gauche, cliquez sur Failover VMware VMs.

2. Dans le volet de gauche, sélectionnez la réplique de la machine virtuelle à partir d’une tâche de réplication existante. Dans notre workflow, le basculement vers DC-VM-replica constitue la première action. Dans le volet de droite, vous pouvez sélectionner un point de restauration. Le point de restauration le plus récent est utilisé par défaut.

Cliquez sur Next pour continuer.

3. Pour les options de reprise après sinistre et de basculement , vous pouvez désélectionner Power off source VMs – cette option permet d’éviter un conflit d’adresses IP si les machines virtuelles sources et les répliques utilisent les mêmes réseaux.

Conformément à la logique décrite ci-dessus, nous sélectionnons les options suivantes :

• Exécuter cette action dans : Run this action in both testing and production mode
• Comportement d’attente : Wait for this action to complete
• Gestion des erreurs : Stop and fail the job if this action fails

Cliquez sur Save pour enregistrer l’action créée.

Action 2. Attendre 3 minutes

Une action d’attente est utile dans ce cas, car l’action de basculement suivante dans le flux de travail (basculement vers FS-VM-replica ) nécessiterait que la DC-VM-replica soit opérationnelle et exécute déjà les services de domaine Active Directory.

1. Dans le volet gauche de l’écran Actions , cliquez sur Wait.

2. Sélectionnez le Temps d’attente (nous utilisons 3 minutes ).

Sélectionnez les Options d’action comme vous l’avez fait pour la première action, puis cliquez sur Save.

La nouvelle action est ajoutée après l’action précédente, en bas de la liste. Vous pouvez réorganiser, modifier ou enlever des actions. Il suffit de passer la souris sur une action pour afficher les options.

Action 3. Vérifier l’état de DC-VM-replica

1. Dans le volet gauche de l’écran Actions , cliquez sur Check condition pour vérifier si la machine virtuelle qui a fait l’objet d’un basculement lors de la première action est en cours d’exécution.

2. Configurez cette action comme suit :

• Sélectionnez le type de condition : Resource is running. Les autres options sont la ressource existe ou l’adresse IP/le nom d’hôte est accessible.
• Sélectionnez le type de ressource : VMware VM.
• Sélectionnez la méthode d’identification : Name (l’autre option est ID ) pour identifier la VM en question. Vous pouvez utiliser n’importe quelle partie de la chaîne de caractères de la VM. Ici, nous connaissons le nom exact, nous utilisons donc la fonction Equals .
• Définissez la chaîne de recherche : DC-VM-replica.

Nous disposons désormais d’une action qui vérifie si la VM VMware nommée DC-VM-replica est en cours d’exécution. Cliquez sur Save pour continuer.

Action 4. Basculement de la VM FS

1. Comme pour l’action 1 de , cliquez sur Failover VMware VMs.

2. Nous sélectionnons ici FS-VM-replica . Cliquez sur Next, puis sélectionnez les mêmes options pour l’action de basculement que celles choisies dans l’action 1 de et cliquez sur Save.

Action 5.

Wait

Check condition

Attendez 3 minutes

Cliquez sur et configurez cette action comme vous l’avez fait pour l’action 2 de

. La durée spécifiée est à nouveau

3 minutes
1. dans notre cas.
   Start VMware VMs Action 6. Vérifiez l’état de FS-VM-replica

Cliquez sur

afin de vérifier si la machine virtuelle VMware FS-VM-replica

est en cours d’exécution. Reportez-vous à l’action 2 de
2. et sélectionnez les mêmes options – à l’exception, bien sûr, du nom de la machine virtuelle.
   Action 7. Démarrez la machine virtuelle de base de données Save

Cliquez sur dans le volet gauche de l’écran

Actions

.Wait



Sélectionnez la machine virtuelle de base de données

. Cette machine virtuelle peut être démarrée une fois que vous êtes certain que la réplique de la machine virtuelle FS

1. est en cours d’exécution. Au bas de la page, sélectionnez les mêmes options d’action que celles indiquées dans les actions précédentes. Cliquez ensuite sur .
   Run script
   
   Action 8. Attendez 5 minutes

Attendez 5 minutes. Cliquez sur

et configurez cette action de la même manière que pour l’action 2 de

. Ce délai devrait être suffisant pour démarrer le service Oracle sur la
2. DB-VM

.

Action 9. Exécutez le script

• Sur l’écran Actions

, cliquez sur

• . Rappelons que ce script est destiné à restaurer la base de données Oracle au niveau de la base à partir d’un dump stocké sur la FS-VM-replica .
• 
  

Définissez les options du script. Chemin d’accès au script :

• /home/oracle/restore.db.sh Nom d’utilisateur : oracle
• Mot de passe : (mot de passe)

Le chemin d’accès à votre script, votre Nom d’utilisateur et votre mot de passe seront différents. N’oubliez pas de vous assurer que le fichier de script est exécutable et que l’utilisateur dispose des autorisations suffisantes pour l’exécuter. Dans cet exemple, les options d’action sont configurées comme d’habitude.

Cliquez sur Save lorsque vous êtes prêt à continuer.

3. Vous pouvez désormais voir toutes les actions configurées. Cliquez sur le bouton Next pour poursuivre la configuration de la tâche Site Recovery en fonction de votre plan de reprise après sinistre.

2. Réseaux

Si les machines virtuelles du site de production et du site de reprise après sinistre sont connectés à différents réseaux, sélectionnez Enable network mapping. Cliquez sur Create new mapping, puis, dans les fenêtres contextuelles, sélectionnez un réseau source, un réseau de destination et un réseau à utiliser pour tester la tâche Site Recovery.
Cliquez sur Save pour enregistrer la règle de mappage réseau, puis cliquez sur Next.

Remarque : Vous pouvez également utiliser des règles de mappage existantes si vous les avez configurées dans d’autres tâches de réplication, de basculement ou de Reprise après sinistre.

3. Réassignation d’adresses IP

Si les réseaux utilisés pour la connexion des machines virtuelles sur le site source et le site cible ont des adresses différentes, vous devez activer la réassignation d’adresses IP en sélectionnant Enable Re-IP.

1. Créez une nouvelle règle de réassignation d’adresses IP en cliquant sur Create new rule. Définissez les paramètres de la source et les paramètres de la cible, puis cliquez sur Save.

2. Cliquez sur Select VMs et sélectionnez les VM pour lesquelles la Réassignation d’adresses IP doit être utilisée. Vous devez fournir les identifiants d’un utilisateur disposant des autorisations suffisantes pour modifier les paramètres réseau dans le système d’exploitation invité de la machine virtuelle.

4. Calendrier des tests

Vous pouvez créer un calendrier spécifiquement destiné à l’exécution de tâches de Reprise après sinistre en mode test et à la réalisation de tests de reprise après sinistre. Cela vous permet de vérifier si la tâche peut être exécutée avec succès dans les délais requis. Une fois terminé, cliquez sur Suivant.
Nous aborderons plus en détail les tests des tâches de reprise après sinistre à l’étape 6.

5. Options

Saisissez le nom de la tâche et les objectifs de temps de récupération. Cliquez sur Finish une fois la configuration terminée.

Étape 4. Réactivation de la protection de l’environnement

Une fois que les VMs ont été basculées et que les Workloads ont été migrés vers le site de reprise après sinistre, les VMs de production d’origine sont désormais hors ligne, et les réplicas sur le site de reprise après sinistre sont désormais les seules copies fonctionnelles. Si une réplique de machine virtuelle allumée venait à tomber en panne, vous ne seriez pas en mesure de restaurer rapidement les données et les Workloads.

Afin de protéger les VMs en cours d’exécution sur le site de reprise après sinistre, vous devez répliquer ces VMs vers un autre emplacement sûr. Ainsi, si la machine virtuelle en cours d’exécution sur le site de reprise après sinistre tombe en panne, vous pouvez effectuer rapidement un basculement vers la nouvelle réplique de machine virtuelle.

La fonctionnalité Reprise après sinistre vous permet de configurer une réplication automatisée dès que le basculement de la machine virtuelle est terminé. Voici un exemple détaillé illustrant comment réactiver la protection des VMs à l’aide d’une tâche de reprise après sinistre après un basculement.

1. Sur la page Jobs , cliquez avec le bouton droit sur le nom de la tâche de reprise après sinistre que vous venez de créer. Cliquez sur Edit dans le menu contextuel.

2. Vous pouvez voir que vos actions de basculement ont été ajoutées à la tâche de reprise après sinistre précédemment. Recherchez et cliquez sur Run jobs dans la liste des actions située dans le volet gauche de l’écran de reprise après sinistre Actions .

3. Sélectionnez la tâche de réplication dans la liste des tâches. Sélectionnez les options d’action comme d’habitude, puis cliquez sur Save.

4. Ajoutez une action Warten entre l’action de basculement et la tâche de réplication. Cela laisse à la réplique de la machine virtuelle le temps de démarrer et de charger le système d’exploitation (vous ne pouvez pas répliquer une machine virtuelle éteinte). Dans la liste Actions du volet de gauche, cliquez sur Wait.

5. Sélectionnez un temps d’attente – 5 minutes devraient suffire. Sélectionnez les options de l’action, puis cliquez sur Save.

6. Lorsque vous ajoutez l’action, celle-ci est ajoutée à la fin de la liste des actions. Cliquez sur Move up et déplacez l’action Wait de la quatrième à la troisième position : elle doit s’exécuter avant la réplication.

Les actions sont désormais classées dans l’ordre requis.

7. Enfin, la tâche Site Recovery est prête à être utilisée pour effectuer le basculement de la machine virtuelle et la re-protection automatique des répliques de machine virtuelle utilisées pour le basculement. Cliquez avec le bouton droit sur le nom de votre tâche de reprise après sinistre sur la page d’accueil, puis cliquez sur « Run job » dans le menu contextuel.

Étape 5. Restauration automatique

La restauration automatique est le processus consistant à restaurer les machines virtuelles dans leur état le plus récent depuis le site de reprise après sinistre vers le site de production d’origine ou vers un nouveau site de production. Pour comprendre pourquoi vous avez besoin de la restauration automatique, récapitulons le fonctionnement du basculement :

1. Lorsqu’un sinistre survient (ou est prévu), un basculement vers une réplica de machine virtuelle est effectué.

2. Toute modification apportée à la machine virtuelle (par exemple, les transactions ajoutées à une base de données lorsque des clients effectuent des achats en ligne) est enregistrée sur un disque virtuel de la réplique de la machine virtuelle. Certains blocs sont écrits, tandis que d’autres sont effacés. Le disque virtuel de la machine virtuelle source ne contient pas ces transactions.

3. Une fois l’incident résolu et le site de production à nouveau opérationnel, les Workloads doivent être ramenés sur le site de production. Les données mises à jour de la réplique de la machine virtuelle doivent être transférées vers la machine virtuelle source. Les VMs doivent être resynchronisées à l’aide d’une réplication inverse via la fonction de restauration automatique (failback).

Configuration de la restauration automatique (failback) dans NAKIVO Backup & Replication

La restauration automatique (failback) peut être effectuée soit en mode production, soit en mode test (lorsque toutes les modifications apportées à votre environnement virtuel par l’action de restauration automatique sont annulées et l’état antérieur à la restauration automatique est rétabli après le test).

Voyons en détail comment chaque cas fonctionne.

Préparation de la restauration automatique Vous devez tout d’abord créer une tâche de reprise après sinistre incluant des actions de basculement. Ce processus a été décrit en détail précédemment. Une tâche de réplication et une réplique de machine virtuelle sont nécessaires pour effectuer une action de basculement. Une tâche de reprise après sinistre doit inclure une action de basculement pour pouvoir effectuer la restauration automatique. Les réplicas de machine virtuelle doivent être en état de basculement ; par conséquent, vous ne pouvez effectuer la restauration automatique qu’après avoir effectué le basculement. Exécution de la restauration automatique Prenons un exemple pour illustrer comment exécuter la restauration automatique avec NAKIVO Backup & Replication. Assurez-vous que le basculement a bien été exécuté dans le cadre d’une tâche de reprise après sinistre (celle-ci devrait déjà avoir été créée). Créez une nouvelle tâche de reprise après sinistre : les actions de restauration automatique peuvent être intégrées à cette tâche. Sur la page , cliquez sur . L’assistant de création d’une nouvelle tâche Site Recovery s’ouvre. . Dans le volet de gauche, cliquez sur (pour d’autres environnements, utilisez ou ). Sélectionnez les répliques de machines virtuelles auxquelles l’opération de basculement doit s’appliquer. Cliquez sur . Sélectionnez un emplacement de retour en production : il peut s’agir du site de production d’origine ou d’un nouvel emplacement. Cliquez sur . Sélectionnez les options de la tâche. Sélectionnez si nécessaire. Cliquez sur lorsque vous êtes prêt à continuer. Une fois l’action de restauration automatique ajoutée, la tâche Reprise après sinistre se présente comme sur la capture d’écran ci-dessous. Cliquez sur . . Sélectionnez cette option si vous devez activer le mappage réseau pour cette tâche. Cliquez sur . . Sélectionnez cette option si vous devez activer la Ré-assignation d’adresses IP pour cette tâche. Cliquez sur . . Configurez vos options de planification, puis cliquez sur . . Définissez les options de la tâche Reprise après sinistre et saisissez le nom de la tâche.

2. Jobs Create > Site recovery job

1. Actions

1. Failback VMware VMs Failback Hyper-V VMs Failback EC2 Instances

2. Next

3. Next

4. Power off replica VMs Save

5. Next

2. Networks Next

3. Re-IP Next

4. Test Schedule Next

5. Options Vous pouvez définir le RTO requis pour la machine virtuelle et indiquer l’adresse e-mail pour le rapport de restauration automatique. Cliquez sur Finish pour finaliser la création de cette nouvelle tâche Reprise après sinistre avec restauration automatique.

Vous pouvez désormais exécuter cette tâche Reprise après sinistre pour effectuer la restauration automatique de la machine virtuelle : il suffit de cliquer avec le bouton droit sur le nom de la tâche Reprise après sinistre, de sélectionner Run job, puis de choisir Test site recovery job ou Run site recovery job.

Étape 6. Réalisation de tests de reprise après sinistre

Les tests de reprise après sinistre vous aident à vous assurer que vous êtes prêt à effectuer la reprise en cas de sinistre et que tous les composants sélectionnés peuvent être restaurés avec succès dans les délais impartis.

Il existe deux raisons principales Pourquoi il est nécessaire de tester la reprise après sinistre:

• To make sure that everything can be recovered successfully. Lorsque vous testez votre plan de reprise après sinistre et que vous découvrez des problèmes, vous pouvez corriger ces problèmes avant qu’ils n’entraînent de graves conséquences dans un scénario de crise réel.
• To make sure that RTO values can be met. Les tests de reprise après sinistre vous permettent de vérifier si vos Workloads peuvent être restaurés dans les délais de reprise (RTO) requis. Un test de reprise après sinistre peut être exécuté manuellement sur demande ou automatiquement selon un calendrier planifié, ce qui simplifie le processus et vous fait gagner du temps.

Différences entre le basculement en mode test et en mode production

Le mécanisme d’exécution du basculement diffère selon que la tâche de reprise après sinistre est exécutée en mode test ou en mode production. Le tableau ci-dessous présente le détail des étapes pour chaque mode.

Comme vous pouvez le constater, les deuxième et troisième points diffèrent entre les workflows de production et de test. Vous pouvez lancer la réplication à partir d’une machine virtuelle source en mode test alors que celle-ci est en cours d’exécution. Dans la plupart des cas, en cas de sinistre, la machine virtuelle source cesse de fonctionner et la réplication ne peut donc pas être effectuée. Les réseaux utilisés pour la connexion des machines virtuelles peuvent être définis séparément dans les options de mappage réseau pour le mode production et le mode test lors de la configuration d’une tâche de reprise après sinistre.

Le nettoyage après un test de basculement est effectué après l’exécution d’une tâche de reprise après sinistre en mode test. La réplique de la machine virtuelle est mise hors tension et ramenée à son état antérieur au basculement via un instantané (un instantané de la réplique de la machine virtuelle est créé avant d’effectuer une action de basculement). La réplique passe ensuite de l’état de basculement à son état normal, et la réplication depuis l’objet source vers la réplique est activée.

Fonctionnalités de test de reprise après sinistre dans Site Recovery de NAKIVO

Passons rapidement en revue les principaux points des fonctionnalités de test de Site Recovery de NAKIVO.
1. Checking the actions included in testing
Vérifiez la logique des actions dans la tâche de reprise après sinistre. Vérifiez si les actions sont classées dans le bon ordre et assurez-vous qu’elles ne forment pas une boucle infinie. Vous pouvez modifier les options d’une tâche de reprise après sinistre lorsque celle-ci n’est pas en cours d’exécution : changez l’ordre des actions, ajoutez-en, enlevez-en ou modifiez les options d’action si nécessaire.
2. Checking networking
Vérifiez que votre réseau fonctionne correctement. Une connexion VPN peut être utilisée entre un site de production et un site de reprise après sinistre (DR), mais cette connexion ne doit pas être périodiquement interrompue en conditions normales. Le réseau du site de reprise après sinistre doit également fonctionner sans interruption. Vérifiez les paramètres de mappage réseau et de réassignation d’adresses IP que vous avez utilisés pour configurer le basculement et le retour sur site. Si une machine virtuelle est configurée pour un réseau incorrect, la connexion réseau risque de ne pas s’établir. Il en va de même pour les paramètres IP.
3. Setting the test schedule
Le test d’une tâche de Reprise après sinistre peut être planifié dans les options de planification des tâches de Reprise après sinistre. Ouvrez l’interface Web de votre instance de NAKIVO Backup & Replication. Dans le volet de gauche, cliquez avec le bouton droit sur le nom de votre tâche, puis sélectionnez « Edit » dans le menu contextuel.

Les avantages de la reprise après sinistre de NAKIVO

• Comprehensive DR orchestration and automation. La reprise après sinistre vous permet de mettre en œuvre des plans de reprise après sinistre avec un haut niveau d’automatisation. Vous pouvez définir l’ordre de reprise des machines virtuelles en tenant compte de leurs dépendances afin que, en cas de sinistre, la reprise soit aussi efficace que possible.
• Flexibility to accommodate the needs of various businesses. Vous pouvez créer plusieurs tâches de reprise après sinistre en fonction de vos besoins. L’ensemble des actions pouvant être intégrées aux tâches de reprise après sinistre permet de créer différents workflows de reprise adaptés sur mesure à diverses situations.
• Built into the data protection solution. Reprise après sinistre est une fonctionnalité incluse dans NAKIVO Backup & Replication et disponible avec l’ensemble complet des fonctionnalités du produit ; il n’est pas nécessaire d’acheter une licence distincte pour Reprise après sinistre. Grâce à cette solution, toutes les activités de protection des données et de reprise après sinistre sont gérées à partir d’un tableau de bord unique.
• Significant savings compared to other DR solutions. NAKIVO Backup & Replication, avec son outil de reprise après sinistre intégré, constitue une solution économique. Le produit continue de satisfaire les utilisateurs grâce à de nouvelles fonctionnalités utiles, tout en conservant des prix abordables – en particulier par rapport à la concurrence sur le marché de la reprise après sinistre.

Essayez NAKIVO Backup & Replication

Profitez d'un essai gratuit pour découvrir toutes les fonctionnalités de protection des données de la solution. 15 jours gratuits. Aucune restriction en termes de fonctionnalités ou de capacité. Aucune carte bancaire requise.

Essayez gratuitement