Objectif
Prouver qu’une sauvegarde est réellement restaurable en exécutant un scénario contrôlé dans un environnement isolé, en mesurant le temps nécessaire, en vérifiant la cohérence applicative et en transformant le résultat en actions correctives sur le plan de reprise.
Prérequis
- Politique RPO/RTO ou objectifs de reprise définis pour le workload testé.
- Restore point sélectionné et suffisamment récent pour le scénario.
- Zone de test isolée avec capacité CPU, RAM, stockage et réseau suffisante.
- Critères de succès écrits avant le test et personne métier capable de valider l’application si nécessaire.
- Procédure de destruction de l’environnement de test et conservation du rapport.
Procédure pas à pas
Choisir un scénario représentatif
Sélectionnez un workload critique et définissez le type de restauration : fichier, VM complète, base ou application. Le scénario doit correspondre à une vraie panne possible, par exemple perte d’une VM, corruption d’un fichier ou indisponibilité d’un site. Évitez de tester uniquement le cas le plus simple chaque trimestre.
- Le scénario, le périmètre et le niveau de criticité sont documentés.
Fixer RPO, RTO et critères de succès
Avant de lancer le test, notez le restore point utilisé et l’écart avec la production pour mesurer le RPO. Définissez le RTO cible et les critères fonctionnels : démarrage OS, services, ouverture de session, accès à la base, test applicatif, intégrité de fichiers ou transaction métier. Sans critères préalables, le test risque de conclure à tort à un succès.
- Les objectifs temporels et fonctionnels sont mesurables.
Préparer un environnement isolé
Créez un réseau ou virtual lab qui empêche la VM restaurée d’entrer en conflit avec la production. Évitez les doublons d’IP, DNS
- Le test ne peut pas écraser ou perturber la production.
Démarrer le chronomètre au moment réaliste
Mesurez le temps à partir de l’instant où l’équipe reçoit l’ordre de restaurer, pas seulement la durée affichée par le logiciel. Incluez la recherche du restore point, les validations, la préparation de la cible, le transfert et la remise en service. Cette mesure révèle les délais humains ou documentaires invisibles dans le temps de traitement du job.
- Le RTO mesuré reflète l’ensemble du processus opérationnel.
Exécuter la restauration
Restaurez vers la cible isolée avec la procédure documentée. Conservez les logs, le débit et les erreurs. Pour un test Veeam, vous pouvez utiliser une restauration classique ou une vérification automatisée via SureBackup lorsque le workload et l’infrastructure le permettent. Le mécanisme choisi doit correspondre au niveau de preuve recherché.
- Les données ou la VM sont restaurées sans modifier la production.
Valider l’intégrité technique
Démarrez la VM ou ouvrez les données restaurées. Contrôlez système de fichiers, services, journaux et absence d’erreurs critiques. Pour une VM, vérifiez les disques, le démarrage et les services. Pour un fichier, calculez si possible une empreinte ou ouvrez-le avec l’application réelle. Pour une base, exécutez les contrôles natifs prévus par le moteur.
- La restauration est techniquement cohérente et lisible.
Effectuer la validation fonctionnelle
Faites réaliser une action métier représentative : ouverture du logiciel, requête, consultation d’un dossier, génération d’un document ou autre test prévu. Une VM qui démarre mais dont l’application ne fonctionne pas ne doit pas être classée comme restaurée avec succès. Notez les dépendances absentes dans le laboratoire.
- Le propriétaire du service confirme le fonctionnement du scénario testé.
Comparer le temps réel au RTO et le point au RPO
Arrêtez le chronomètre lorsque les critères de disponibilité sont atteints. Comparez le RTO réel à l’objectif et mesurez l’âge du restore point. Si le RTO est dépassé, identifiez précisément la cause : transfert trop lent, restauration séquentielle, absence de documentation, manque de capacité ou validation métier trop tardive.
- Les écarts RTO/RPO sont chiffrés et expliqués.
Détruire proprement l’environnement de test
Après validation et conservation des preuves, supprimez uniquement les VM, réseaux temporaires et données de test. Vérifiez qu’aucune restauration isolée n’est restée connectée au réseau de production et qu’aucun secret ou compte temporaire n’est oublié. Ne supprimez évidemment pas le backup utilisé pour le test.
- Le laboratoire est nettoyé sans affecter les sauvegardes ou la production.
Produire un rapport et corriger le plan de reprise
Rédigez un rapport court mais exploitable : restore point, durée, débit, erreurs, critères réussis/échoués et actions. Transformez chaque écart en tâche : augmenter la bande passante, ajouter une copie hors site, automatiser SureBackup, corriger un compte de service ou améliorer la documentation. Planifiez le prochain test sur un autre scénario.
- Le test produit des actions mesurables et une prochaine date de vérification.
Validation
La procédure est validée lorsque :
- La restauration est exécutée dans un environnement isolé sans impact production.
- Les données et l’application sont réellement validées, pas seulement le job de restauration.
- RTO et RPO réels sont mesurés et comparés aux objectifs.
- Un rapport de test et des actions correctives sont conservés.
Retour arrière
- Arrêter le laboratoire si une restauration menace de communiquer avec la production.
- Supprimer la cible de test et recommencer avec un environnement isolé si les identités/IP sont en conflit.
- Ne jamais utiliser la restauration de test comme nouvelle production sans un processus de bascule explicitement validé.
- Conserver le backup source et les logs du test jusqu’à clôture du rapport.
Dépannage / erreurs fréquentes
- Restore lent : distinguer lecture repository, réseau, écriture cible et phase de démarrage applicatif.
- VM démarre mais application KO : vérifier DNS, dépendances externes, comptes de service et réseau isolé.
- Restore point absent : traiter immédiatement la politique de rétention ou l’échec du job source.
- Test SureBackup échoue mais restore manuel fonctionne : vérifier virtual lab, réseau isolé et scripts/tests applicatifs.
- RTO dépassé malgré restore rapide : analyser les étapes humaines et de validation qui allongent le processus.