Il existe un dicton tiré du "Tao of Backup", écrit à l'époque de NT4 :
Croire en ses sauvegardes est une chose. Devoir les utiliser en est une autre.
Cette phrase est souvent abrégée en "Testez vos récupérations" ou "Testez vos récupérations" :
Si vous n'avez pas testé vos récupérations, vous n'avez pas de sauvegardes.
C'est bien beau, mais dans les environnements informatiques hétérogènes, les choses peuvent se compliquer. Vous pouvez utiliser SureBackup pour tester vos machines virtuelles Windows, mais qu'en est-il de votre boîtier Windows XP qui contrôle votre CNC ? De même, qu'en est-il de la machine Solaris 9 qui fait fonctionner votre oscilloscope ?
Les choses peuvent devenir encore plus délicates... que se passe-t-il si votre boîtier Solaris 9 utilise l'authentification Kerberos et exige que le contrôleur soit d'abord restauré ?
De nombreux outils modernes promettent un bouton-poussoir pour tester mes sauvegardes... ce qui est très bien, mais ils ne fonctionneront que si tous vos systèmes répondent à leurs critères. Si vous ajoutez un système physique hérité, vous vous retrouvez soudain sans protection - et c'est ce système qui est le plus susceptible de tomber en panne !
La stratégie
La première chose à faire est de déterminer comment restaurer manuellement les systèmes et les données et de documenter ce processus.
Un exemple de plan de récupération pour Solaris 9 pourrait être le suivant :
- Récupérer une image flar à partir d'un disque à l'aide du programme d'installation
- Récupérer des données à l'aide de tar à partir d'une bande
- Botte
- Exécuter des commandes de test
En revanche, un exemple de récupération de VM pourrait simplement être le suivant :
- Sélectionnez le plan de récupération de VM à partir de ${insérer le produit de sauvegarde ici}
Malheureusement, si la machine Solaris 9 en dépend (par exemple, elle fournit l'authentification Kerberos), vous devez les combiner. Ils doivent se trouver sur le même VLAN, démarrer dans un ordre spécifique et être testés dans l'ordre.
Un exemple de plan
Un exemple de plan pour une machine Solaris 9 connectée à un A/D sur Kerberos pourrait être le suivant :
| Machine Solaris | Contrôleur A/D |
|---|---|
| Récupérer une image flar à partir d'un disque | Image de la VM de récupération |
| Récupérer des données à l'aide de tar à partir d'une bande | Image de démarrage de la VM |
| ATTENDEZ → | Test du contrôleur A/N |
| Démarrage de la machine Solaris | |
| Test de la machine Solaris |
Même dans un cas simple, nous avons une dépendance à l'égard d'un test avant le démarrage. Dans un scénario plus compliqué, nous pouvons avoir plusieurs dépendances. Par exemple, supposons que nous ayons une interface web pour l'ancienne application Solaris exécutée sur une pile LAMP :
| Pile LAMP | Machine Solaris | Contrôleur A/D |
|---|---|---|
| Récupérer l'image de la VM | Récupérer une image flar à partir d'un disque | Récupérer l'image de la VM |
| Récupérer des données à l'aide de tar à partir d'une bande | Image de démarrage de la VM | |
| ATTENDEZ → | Test du contrôleur A/N | |
| Démarrage de la machine Solaris | ||
| ATTENDEZ → | Test de l'application Solaris | |
| Démarrage de la machine Linux | ||
| Tester l'interface web |
Cela fonctionnera, mais il y a d'autres problèmes :
- Que se passe-t-il si le démarrage de la machine Solaris prend beaucoup de temps ? Ne serait-il pas préférable de le démarrer plus tôt ?
- Si la récupération Linux échoue au niveau du système d'exploitation, nous pourrions le découvrir sans les autres machines. Il en va de même pour la machine Solaris - et cette récupération pourrait prendre beaucoup de temps si les données proviennent d'une bande...
| Pile LAMP | Machine Solaris | Contrôleur A/D |
|---|---|---|
| Récupérer l'image de la VM | Récupérer une image flar à partir d'un disque | Récupérer l'image de la VM |
| Désactiver le service web | Désactiver l'application | Image de démarrage de la VM |
| Botte | Botte | |
| Le système d'exploitation testé est opérationnel | Le système d'exploitation testé est opérationnel | |
| Récupérer des données à l'aide de tar à partir d'une bande | ||
| ATTENDEZ → | Test du contrôleur A/N | |
| ATTENDEZ → | Test de l'application Solaris | |
| Activer le service web | ||
| Tester l'interface web |
Nous disposons donc désormais d'un plan qui échouera le plus tôt possible en cas d'erreur du système d'exploitation. Ce plan peut probablement être encore amélioré ; il pourrait être possible de restaurer un sous-ensemble de données pour effectuer un test d'application rapide avant le test lent, il pourrait être possible de tester (partiellement) l'interface Web de manière isolée, etc...
Exigences en matière d'automatisation
Un tel plan nécessite :
- Une plateforme d'orchestration avec un contrôle libre de l'approvisionnement
- Scripting post-récupération avant le redémarrage pour contrôler le système d'exploitation qui démarre.
- API pour démarrer des machines récupérées pour une variété de plates-formes
- Une plateforme de test avec une API
Des outils pour le travail
Une plateforme d'orchestration
Nous utilisons Jenkins pour gérer cette opération particulière car, dans notre cas, Jenkins gère également la construction du logiciel de récupération. Jenkins peut être facilement scénarisé et dispose de plugins pour les principaux fournisseurs de VM, ce qui en fait une bonne base pour de nombreuses organisations.
Script de récupération et de post-récupération
Bien entendu, nous recommandons Cristie BMR qui supporte Solaris, Linux et Windows (et AIX) et qui offre la possibilité d'écrire des scripts après la récupération. Il est toutefois possible de procéder de manière fragmentaire avec différents outils : JumpStart peut être utilisé avec Solaris et FLAR de manière très efficace, bien que cela demande un certain effort. L'écriture de scripts post-récupération d'une VM peut s'avérer délicate, mais le démarrage dans un environnement Linux en direct après la récupération de la VM fonctionnerait bien.
API pour contrôler le démarrage
Tous les hyperviseurs ont des API pour démarrer les VMs... mais qu'en est-il du kit physique ? Une solution que nous utilisons est de se connecter via un port série et d'utiliser pyserial pour orchestrer la machine.
Une plate-forme d'essai
Nous utilisons à nouveau Jenkins pour cela, mais nous exécutons des scripts à l'aide de bats. C'est un bon moyen d'écrire très rapidement quelques contrôles simples qui peuvent être affichés dans Jenkins. Cependant, une solution plus complète serait d'utiliser serverspec ou autre.
Exemple
Le plugin Jenkins "blue-ocean" offre une vue très claire de la progression d'un test : A ce stade, nous avons commencé à utiliser Cristie CBMR pour restaurer un système Solaris 9 sur du matériel physique. Une fois terminé, un court script désactivera l'application requise au démarrage et définira les paramètres réseau à utiliser au démarrage.
Le script python qui effectue cette opération :
- Démarrer la machine en utilisant le démarrage réseau à partir d'un serveur PXE contenant l'image CBMR.
- Commencer la restauration à partir de la sauvegarde du système d'exploitation
Une fois l'opération terminée, il est possible d'accéder à la machine via le réseau au lieu de la console série et d'utiliser les scripts standard de Jenkins.
Achèvement
Le pipeline n'exécute chaque étape que dans l'ordre, c'est pourquoi les étapes sont utilisées pour séparer les actions simultanées.
Il ressort clairement du plan ci-dessus que l'A/D doit être testé avant que l'application ne puisse être lancée, que l'application doit être lancée avant que le service web ne soit lancé et que le service web ne peut être testé qu'après avoir été lancé. Il est possible d'utiliser le "plugin de ressources verrouillables" pour créer un contrôle plus fin, mais cela est plus difficile et comporte plus de risques.
À la fin du test de récupération, nous obtenons la sortie suivante (considérablement raccourcie) et un fichier journal :
Résumé
Il est possible d'utiliser des outils modernes d'IC pour tester la reprise après sinistre d'anciens systèmes d'exploitation, à condition que ces outils soient compatibles :
- Une API pour contrôler l'environnement qui sera démarré
- Une API pour contrôler quand l'environnement sera démarré
- Crochets d'orchestration pour provisionner les environnements en vue de la récupération
De nombreux systèmes de sauvegarde n'offrent pas ces possibilités. En particulier, peu d'outils fournissent des crochets qui vous permettent de provisionner un environnement de récupération.
TBMR
TBMR a été utilisé pour la restauration des systèmes d'exploitation. Il a été conçu pour fonctionner avec Windows, Linux, Solaris et AIX :
