Azure Backup : valider une restauration de VM avant de déclarer la reprise opérationnelle

Un job Azure Backup Completed prouve qu’un point de récupération a été produit. Il ne prouve pas que l’équipe saura sélectionner le bon point, restaurer les disques, démarrer la VM sans reconnecter un doublon à la production, puis valider l’application dans le temps attendu.

Le cas d’usage est une API interne hébergée sur une VM Azure avec un disque OS et un disque de données. L’équipe prépare un exercice de reprise après une évolution de l’image, du réseau ou de la politique de sauvegarde. Le runbook doit aboutir à une décision explicite : chemin de reprise prêt, prêt sous conditions, ou non prêt avec retour à la configuration précédente.

Écrire le contrat de restauration avant de choisir un point

Un exercice ne commence pas dans le portail. Il commence par la charge à reprendre, la perte de données acceptable, les contrôles métier et les effets que la VM restaurée ne doit jamais produire.

workload: api-orders-prod
source_vm: vm-orders-01
vault: rsv-platform-prod
protected_item: vm-orders-01
restore_mode: alternate_location
target_resource_group: rg-restore-drill-202609
target_network: vnet-restore-isolated
recovery_point_rule: newest_point_before_change_window
required_consistency: application_or_documented_recovery_procedure
business_checks:
- database-opens-read-only
- last-approved-order-present
- api-health-contract-valid
forbidden_effects:
- production-dns-registration
- outbound-email-or-webhook
- queue-consumption
- write-to-production-dependency
cleanup_owner: platform-operations
rollback: delete-drill-resources-and-keep-evidence

Le RPO et le RTO doivent être des critères de décision, pas des chiffres repris d’une politique. Le RPO se vérifie dans les données réellement restaurées. Le RTO se mesure depuis l’ouverture de l’exercice jusqu’à la validation métier, en incluant recherche du point, restauration, boot et contrôles.

Inventorier le coffre, l’item protégé et les points disponibles

Figer les identifiants évite de tester une VM homonyme, un autre coffre ou un point postérieur à l’incident simulé. Les commandes suivantes donnent un inventaire reproductible ; adaptez les noms natifs si plusieurs items portent le même nom convivial.

VAULT_RG="rg-backup-prod"
VAULT="rsv-platform-prod"
VM="vm-orders-01"

az backup item list --resource-group "$VAULT_RG" --vault-name "$VAULT" --backup-management-type AzureIaasVM --query "[?properties.friendlyName=='$VM'].{name:name,health:properties.healthStatus,last:properties.lastBackupTime,policy:properties.policyId}" --output json

az backup recoverypoint list --resource-group "$VAULT_RG" --vault-name "$VAULT" --backup-management-type AzureIaasVM --container-name "$VM" --item-name "$VM" --query "[].{name:name,time:properties.recoveryPointTime,type:properties.recoveryPointType}" --output table

Conservez l’heure UTC de l’incident simulé et celle du point retenu. « Le plus récent » n’est pas toujours le bon choix : un point créé après une corruption logique peut déjà contenir l’état défectueux.

Qualifier la cohérence au lieu de la supposer

Azure VM Backup peut produire des points de cohérence différente selon l’OS, la configuration et le résultat du traitement applicatif. La présence d’un point ne remplace donc pas la lecture de son type ni le test de la procédure de récupération de l’application.

Pour chaque point candidat, relevez :

• l’heure UTC et le type de cohérence observé ;
• les disques inclus et leur rôle ;
• le résultat du dernier job associé ;
• les scripts ou mécanismes applicatifs nécessaires après un démarrage crash-consistent ;
• la raison du choix par rapport à la fenêtre de changement.

Si l’application exige une cohérence transactionnelle, un boot réussi n’est pas une validation. La base doit terminer sa récupération, ouvrir les structures attendues et rendre un échantillon métier cohérent. Si ce contrôle n’est pas disponible, le chemin reste « prêt sous conditions » au mieux.

Isoler la cible avant toute restauration

La restauration alternative évite d’écraser la source, mais elle peut créer un deuxième système portant les mêmes hostnames, tâches planifiées, identités et configurations de dépendances. L’isolation doit être effective avant le premier boot.

Surface                 Contrôle avant boot
Réseau                  VNet et subnet dédiés, sans peering ni route vers production
Sortie                   Egress refusé par défaut, ouvert seulement vers les cibles de test
DNS                      Résolution de test explicite, aucune inscription automatique en production
Identité                 Aucun droit d'écriture implicite vers les ressources de production
Messagerie               Consumers, webhooks, SMTP et notifications désactivés ou redirigés
Planification            Cron, timers et agents de déploiement neutralisés avant validation
Adresse                  Aucun nom ni IP de production réutilisé
Observabilité            Logs du drill séparés et corrélés par un identifiant d'exercice

Un Private Endpoint peut faire partie du chemin de restauration pour certains services, mais il n’est pas le sujet central. La question est plus large : la cible isolée peut-elle récupérer ce dont elle a besoin sans obtenir un chemin d’écriture vers la production ?

Restaurer les disques dans un emplacement alternatif

Commencez par restaurer les disques dans un groupe de ressources dédié. Cela laisse une étape de contrôle avant de créer et démarrer une VM. La syntaxe exacte dépend de la configuration du coffre et de l’item ; utilisez les identifiants observés dans l’inventaire.

VAULT_RG="rg-backup-prod"
VAULT="rsv-platform-prod"
CONTAINER="vm-orders-01"
ITEM="vm-orders-01"
RECOVERY_POINT="<recovery-point-name>"
STAGING_ACCOUNT="strestore202609"
TARGET_RG="rg-restore-drill-202609"

az backup restore restore-disks --resource-group "$VAULT_RG" --vault-name "$VAULT" --container-name "$CONTAINER" --item-name "$ITEM" --rp-name "$RECOVERY_POINT" --storage-account "$STAGING_ACCOUNT" --target-resource-group "$TARGET_RG" --restore-mode AlternateLocation

Capturez le nom du job retourné, puis suivez-le avec az backup job show ou az backup job wait. Ne passez pas à la création de VM tant que le job n’est pas terminé et que les artefacts restaurés ne correspondent pas aux disques attendus.

Le stockage de staging, les droits, le chiffrement, les zones et les configurations particulières peuvent modifier la procédure. Le runbook local doit documenter ces prérequis au lieu de les découvrir pendant l’incident.

Construire la VM sans réimporter les effets de production

Inspectez le template et les disques restaurés avant déploiement. Créez la VM dans le groupe et le subnet d’exercice, sans IP publique, avec les contrôles de sortie déjà appliqués. Remplacez ou désactivez les éléments qui pourraient produire un effet : extensions de déploiement, scripts de démarrage, agents de monitoring utilisant des identifiants de production et tâches programmées.

Le succès attendu n’est pas seulement PowerState/running. Il faut prouver trois couches :

1. le système démarre et les volumes sont montés au bon endroit ;
2. l’application atteint un état stable sans dépendance de production ;
3. les données restaurées respectent le contrat métier et la fenêtre du point choisi.

Exécuter une validation technique et métier

Utilisez un manifeste de preuves identique à chaque exercice. Il évite qu’un opérateur conclue sur un ping tandis qu’un autre attend une transaction complète.

drill_id: restore-20260911-orders
recovery_point_utc: "<timestamp>"
restore_job_status: completed
checks:
os_boot: pass
expected_disks_mounted: pass
filesystem_check: pass
application_started: pass
health_endpoint_contract: pass
database_recovery: pass
business_sample: pass
production_write_refusal: pass
outbound_side_effect_refusal: pass
timing:
exercise_started_utc: "<timestamp>"
restore_completed_utc: "<timestamp>"
business_validation_completed_utc: "<timestamp>"
decision: pending

Le test de refus est essentiel. Une VM qui lit les bonnes données mais peut aussi consommer la queue de production n’est pas une cible de drill sûre. Vérifiez les routes, les règles réseau, les permissions effectives et les logs de refus avec la même attention que le test positif.

Mesurer le chemin complet et traiter les écarts

Séparez le temps du service Azure, le temps d’attente opérateur et le temps de validation applicative. Cette ventilation rend l’amélioration actionnable : automatiser la sélection d’un item n’a aucun effet si la reconstruction manuelle de la VM consomme l’essentiel du délai.

Documentez aussi chaque dérive par rapport à la source : taille de VM indisponible, extension absente, secret expiré, dépendance DNS introuvable, procédure de récupération non automatisée ou contrôle métier incomplet. Une restauration réussie avec trois corrections improvisées ne prouve pas un runbook prêt ; elle fournit la liste des corrections à intégrer.

Décider readiness, correction ou rollback

READY
Recovery point selected against the simulated incident window
Restore completed from documented identities and commands
Isolated VM booted with every expected disk
Technical and business checks passed
Forbidden production effects were refused
Measured recovery fits the approved objective
Cleanup and next-test owner are recorded

READY WITH CONDITIONS
Data is valid but one manual step remains documented
Recovery objective is missed with an accepted remediation plan
One non-critical dependency requires a controlled workaround

NOT READY
No suitable recovery point exists
Point consistency does not satisfy the application contract
Restored target can write to production
Data or business validation fails
Restore cannot be reproduced from the runbook

ROLLBACK THE RECENT CHANGE
Readiness regressed after a policy, vault, identity or network change
Restore the previous known configuration
Repeat the drill before closing the change

Le rollback de l’exercice consiste à supprimer les ressources temporaires après conservation des preuves, pas à toucher à la VM source ni à désactiver sa protection. Si le test révèle une régression causée par un changement récent, rétablissez la configuration connue, puis rejouez le chemin complet. Une configuration restaurée sans nouvel exercice reste une hypothèse.

Conclusion

Une sauvegarde exploitable se juge au moment où une équipe restaure, isole, démarre et valide la charge, pas au nombre de jobs verts dans le coffre. Le runbook utile relie le point choisi à un incident simulé, contrôle la cohérence, empêche les effets de bord et mesure le délai jusqu’à la preuve métier.

La décision devient alors nette : déclarer le chemin prêt quand restauration, refus et validation sont reproductibles ; accepter temporairement une condition documentée ; ou rollbacker la configuration récente et retester. Azure Backup fournit le point de récupération. L’exercice transforme ce point en capacité de reprise démontrée.