Infrastructure

Azure Backup : valider un point de restauration avant de déclarer le rollback prêt

Un runbook de production pour qualifier un point de restauration Azure Backup avec cohérence applicative, dépendances, identité, réseau, test de restauration, preuves, décision et rollback avant bascule.

17 juil. 2026 azureazure-backupbackuprestorerollbackdisaster-recoveryidentitynetworkingobservabilityrunbookproduction

Un point de restauration Azure Backup visible dans le portail ne suffit pas à déclarer un rollback prêt. Il prouve qu’une sauvegarde existe, pas que l’application peut redémarrer avec des données cohérentes, les bonnes identités, les dépendances réseau attendues et un chemin de retour contrôlé.

Le cas d’usage est une application de production touchée par une migration ratée, une corruption de données, un déploiement destructif ou une erreur d’exploitation. Une équipe veut restaurer une VM, un disque, une base ou un partage sauvegardé avec Azure Backup. Le but du runbook est de décider si le point de restauration est exploitable, s’il faut restaurer dans un environnement isolé, basculer partiellement, attendre des preuves supplémentaires ou rollbacker le changement sans aggraver l’incident.

Figer le périmètre de restauration

Commence par écrire ce qui doit revenir en arrière. Un rollback de production n’est pas toujours une restauration complète. Il peut viser un disque de données, une VM, une base, un fichier critique, une configuration ou un ensemble de ressources qui doivent rester cohérentes.

text restore-scope.txt

Incident
Service impacte: api-orders-prod
Changement suspect: migration schema + batch de reprise
Fenetre d'impact: 2026-07-17 06:20-07:10 UTC
Objectif: restaurer donnees coherentes sans perdre les transactions valides

Perimetre candidat
Workload: VM, disque, Azure Files, SQL dans VM ou donnees applicatives
Recovery Services vault: rsv-prod-core
Backup policy: prod-daily-hourly
Point de restauration cible: avant le changement suspect
Ressources dependantes: Key Vault, identity, DNS, firewall, storage, queue, API aval

Decision attendue
Restaurer en environnement isole
Restaurer partiellement
Basculer vers le restore
Rejouer ou reconstruire une partie des donnees
Abandonner le point et utiliser un autre rollback

Si le périmètre n’est pas explicite, l’équipe risque de restaurer une ressource techniquement valide mais fonctionnellement incohérente.

Vérifier le point de restauration réel

Le premier contrôle porte sur la fraîcheur, le type et l’état du point de restauration. Évite de choisir un point uniquement parce qu’il est le dernier disponible : il peut être postérieur à la corruption, crash-consistent seulement, incomplet ou lié à une policy qui ne couvre pas toutes les dépendances.

bash 01-list-restore-points.sh

SUBSCRIPTION="00000000-0000-0000-0000-000000000000"
VAULT_RG="rg-prod-backup"
VAULT="rsv-prod-core"
CONTAINER="iaasvmcontainer;iaasvmcontainerv2;rg-prod-app;vm-orders-01"
ITEM="vm;iaasvmcontainerv2;rg-prod-app;vm-orders-01"

az account set --subscription "$SUBSCRIPTION"

az backup recoverypoint list --resource-group "$VAULT_RG" --vault-name "$VAULT" --container-name "$CONTAINER" --item-name "$ITEM" --backup-management-type AzureIaasVM --query "[].{time:recoveryPointTime,type:recoveryPointType,tier:recoveryPointTier,consistency:recoveryPointConsistencyType}" --output table

Le point choisi doit être relié à la chronologie de l’incident. Une restauration trop récente peut réintroduire la panne. Une restauration trop ancienne peut perdre des transactions que l’équipe aurait pu préserver autrement.

Séparer sauvegarde disponible et restauration utilisable

Une sauvegarde disponible n’est pas encore un rollback utilisable. Il faut tester la restauration dans un périmètre qui ne modifie pas la production active : ressource temporaire, réseau isolé, abonnement de reprise, VM arrêtée ou disque restauré sans attachement immédiat.

text restore-readiness-checks.txt

Preuves avant bascule
Le point de restauration est anterieur au changement suspect
Le type de coherence est acceptable pour le workload
La restauration test se termine sans erreur
Les donnees restaurees passent un controle applicatif minimal
Les secrets et identites necessaires existent encore
Les routes, DNS et firewall permettent le test sans exposer la production
Les dependances aval ne consomment pas de donnees du restore par accident

Blocage
Restaurer directement sur la ressource active sans test
Attacher un disque restaure a une VM de production sans gel d'ecriture
Demarrer deux copies du meme workload avec les memes identites et consumers
Rejouer des jobs applicatifs avant controle d'idempotence

Cette séparation évite le rollback qui réussit techniquement mais déclenche une deuxième écriture, une double consommation de message ou une collision d’identité.

Restaurer dans une zone de preuve

La zone de preuve doit permettre d’inspecter sans produire d’effet métier. Pour une VM, restaure les disques ou crée une VM isolée. Pour des fichiers, restaure vers un chemin temporaire. Pour une base hébergée dans une VM, restaure hors ligne avant d’ouvrir aux applications.

bash 02-restore-disks-for-validation.sh

TARGET_RG="rg-restore-validation"
STORAGE_ACCOUNT="strestoreevidence"
RESTORE_POINT_NAME="AzureBackup_20260717_052000"

az backup restore restore-disks --resource-group "$VAULT_RG" --vault-name "$VAULT" --container-name "$CONTAINER" --item-name "$ITEM" --rp-name "$RESTORE_POINT_NAME" --storage-account "$STORAGE_ACCOUNT" --target-resource-group "$TARGET_RG" --restore-to-staging-storage-account true

La commande exacte dépend du type de workload et des options activées. Le principe reste stable : produire un artefact restauré inspectable, avec des droits limités, avant toute bascule.

Contrôler la cohérence applicative

Le test utile n’est pas seulement le démarrage de la VM ou la présence des fichiers. Il doit prouver que l’application peut lire ses données, retrouver ses dépendances et refuser les actions dangereuses tant que la bascule n’est pas décidée.

text application-consistency-probe.txt

Controles minimum
Monter le disque ou ouvrir la base restauree en lecture seule
Verifier version schema, migrations appliquees et horodatage des donnees
Comparer un echantillon de cles metier avec les logs avant incident
Lister les transactions manquantes entre restore point et gel d'ecriture
Verifier que les secrets references existent encore dans Key Vault
Verifier que l'identite runtime ne declenche pas de jobs ou webhooks
Tester une requete applicative representative sans ecriture aval

Signaux de rejet
Schema incompatible avec le code encore deploye
Donnees restaurees deja compensees par un autre traitement
Files, webhooks ou batchs capables de retraiter en double
Identite restauree possede des droits de production non bornes

Pour beaucoup d’incidents, la meilleure décision n’est pas de basculer tout le restore. C’est de restaurer un sous-ensemble, extraire une donnée, ou utiliser le restore comme source de comparaison.

Lire les signaux Backup et Activity Log

Garde les preuves de la sauvegarde et de la restauration. Elles servent à distinguer un point inexploitable, une restauration échouée, un problème de permission, une limite de quota ou une erreur réseau dans la zone de preuve.

kusto 03-backup-restore-evidence.kql

let StartTime = datetime(2026-07-17T05:00:00Z);
let EndTime = datetime(2026-07-17T08:00:00Z);
AzureActivity
| where TimeGenerated between (StartTime .. EndTime)
| where ResourceProviderValue has_any ("MICROSOFT.RECOVERYSERVICES", "MICROSOFT.COMPUTE", "MICROSOFT.STORAGE")
| where OperationNameValue has_any ("restore", "backup", "write", "delete", "disks")
| project TimeGenerated, ResourceGroup, ResourceProviderValue, OperationNameValue, ActivityStatusValue, Caller, CorrelationId, Properties
| order by TimeGenerated desc

Complète avec les jobs du vault, les logs applicatifs et les changements IaC. Un rollback sans horodatage fiable devient difficile à défendre si une perte de données est découverte ensuite.

Décider restauration, extraction ou abandon

La décision doit tenir compte de l’impact métier, de la cohérence des données, de la fenêtre de perte acceptable et du risque de double écriture. Elle doit aussi nommer le plan inverse : comment revenir si la restauration empire la situation.

yaml restore-decision.yml

decision:
restore_to_production:
  when:
    - restore_point_precedes_fault
    - application_consistency_validated
    - write_freeze_or_cutover_window_confirmed
    - dependencies_ready_for_restored_state
  validation:
    - health_probe_passes
    - business_sample_matches_expected_state
    - no_duplicate_consumers_running

partial_restore_or_extract:
  when:
    - only_some_records_or_files_are_needed
    - full_restore_would_lose_valid_work
    - restored_copy_is_safe_as_read_only_source
  validation:
    - extracted_items_reviewed
    - target_update_is_idempotent
    - audit_trace_keeps_source_restore_point

hold:
  when:
    - restore_point_consistency_is_unclear
    - downstream_side_effects_are_not_controlled
    - identity_or_network_path_is_not_isolated

abandon_restore_point:
  when:
    - point_is_after_corruption
    - schema_or_data_is_incompatible
    - safer_recovery_path_exists

Une restauration de production doit être une décision, pas la suite automatique d’une sauvegarde réussie.

Préparer la bascule et le rollback du rollback

Avant la bascule, définis le gel d’écriture, les identités actives, les consommateurs à arrêter, les probes attendues et le point de retour si le restore échoue. Le rollback du rollback est rarement confortable, mais il doit exister.

text cutover-and-backout.txt

Avant bascule
Geler les ecritures ou couper les consumers concernes
Sauvegarder l'etat courant avant remplacement
Nommer le point de restauration utilise
Desactiver les jobs qui rejoueraient en double
Verifier DNS, routes, NSG et firewall de la ressource restauree
Verifier identites, secrets et droits minimums
Annoncer la fenetre et les criteres d'arret

Validation apres bascule
Health check applicatif
Lecture echantillon metier
Logs sans erreurs identite, disque, base ou reseau
Aucune reprise de messages en double
Alertes Azure Monitor revenues au bruit attendu

Retour arriere
Stopper le workload restaure
Revenir a la ressource pre-bascule ou au snapshot pris juste avant
Retirer les droits temporaires
Conserver les artefacts de preuve et la raison d'echec

Si le plan ne sait pas arrêter les consommateurs ou revenir à l’état pré-bascule, la restauration n’est pas encore prête.

Conclusion

Azure Backup donne un point de départ, pas une décision de rollback. Le runbook doit relier le point de restauration à la chronologie de l’incident, tester la restauration hors production, prouver la cohérence applicative, contrôler les identités et dépendances, puis décider entre bascule complète, restauration partielle, attente ou abandon.

Le bon signal de fin n’est pas “le restore existe”. C’est “nous savons ce que ce point restaure, ce qu’il perd, ce qu’il peut casser, comment le valider et comment revenir si la bascule échoue”.