1. INTERVENANTS

DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨

2. PROBLÉMATIQUE

Tu veux bien faire
Tu crées un Recovery Services Vault (RSV) pour ton projet. Ton collègue en Data fait pareil. Puis l’équipe Infra. Puis une version pour DEV, une autre pour PROD… Et sans t’en rendre compte, tu te retrouves avec 10 RSV dispatchés un peu partout.

C’est le début du chaos 👇

• Multiplication des coffres = complexité de gestion exponentielle
• Chacun sa config, chacun ses politiques, chacun ses pratiques
• Difficile de faire un reporting global, d’auditer ce qui est vraiment sauvegardé, ou d’industrialiser
• Gouvernance impossible : tu veux durcir la sécurité ou faire évoluer une politique ? Tu dois le faire à la main sur chaque coffre
• RBAC ? On oublie. Soit les équipes ont tous les droits sur leur RSV (risqué), soit elles ne peuvent rien faire (bloquant). Il n’y a pas d’entre-deux simple.

Alors pose-toi les bonnes questions :

• Comment garder une vision claire quand chaque équipe fait ses propres choix ?
• Jusqu’où on peut déléguer sans risquer des erreurs critiques ?
• Est-ce qu’on protège bien les bonnes machines, avec le bon niveau de service ?
• Et surtout : comment faire évoluer tout ça intelligemment dans le temps, sans tout casser ?

3. MODÈLE RECOMMANDÉ

Si tu veux garder le contrôle tout en laissant de l’autonomie aux équipes, il te faut un socle commun.
Et ce socle, c’est une stratégie centralisée des RSV… mais pensée intelligemment.

Le principe :

Tu ne crées pas un coffre par projet, par environnement ou par équipe.
Tu crées un RSV par type de criticité, basé sur la technologie de réplication utilisée :

• LRS (Locally Redundant Storage) : Réplication dans une seule zone, pour les workloads non critiques.
• ZRS (Zone-Redundant Storage) : Réplication dans plusieurs zones d’une même région, pour une résilience accrue.
• GRS (Geo-Redundant Storage) : Réplication dans une région secondaire, pour les workloads critiques.

Et pour faire fonctionner ça à grande échelle, on impose une politique de tags cohérente :

• CriticiteSauvegarde = minor | standard | critique
• BackupPolicy = daily | weekly | monthly
• BackupHeure = 02h | 23h, etc.
• BackupRetention = 7j | 30j | 90j, etc.

Résultat ?

Grâce à l’automatisation (via script ou Azure Automation), chaque VM peut être :

• rattachée automatiquement au bon RSV
• assignée à la bonne policy en fonction des tags
• restaurée uniquement par les équipes autorisées
• protégée des suppressions accidentelles, grâce à un RBAC restrictif (Restore Only)

💡 Tu gagnes une architecture de sauvegarde :

• homogène
• lisible
• facilement gouvernable

Et surtout : tu poses les bases d’une stratégie d’entreprise claire et durable, pas un patchwork bricolé par projet

4. AUTOMATISER

Tu veux être sûr que chaque VM soit bien protégée ?
Alors n’attends pas que les équipes s’en souviennent.

On va automatiser le rattachement au RSV et l’application de la bonne stratégie de sauvegarde, à partir de simples tags.
Voici comment ça s’organise :

Lecture des tags

Pour chaque VM, on lit les tags suivants :

Mapping Criticité → RSV

C’est ce mapping qui permet de choisir dynamiquement le bon coffre

Script ou Runbook Automation

Un script PowerShell ou un runbook Azure Automation (avec System Assigned Identity) pourra :

1. Lister toutes les VMs éligibles (ou filtrer via Azure Resource Graph)
2. Lire leurs tags
3. Vérifier si elles sont déjà protégées
4. Les rattacher au RSV cible s’il manque la protection
5. Appliquer la bonne Backup Policy selon les tags

Et si besoin, notifier l’équipe (via Teams, email, webhook…) en cas de VM non conforme (tag manquant, erreur de policy, etc.)

Sécurisation RBAC

Dernier point souvent négligé : les droits d’accès.

• Les équipes ont le droit de restaurer leurs VMs
• Elles peuvent modifier leurs propres tags si besoin
• Mais elles n’ont pas le droit de supprimer un backup ou de toucher aux paramètres critiques du RSV

🎯 On limite donc la casse tout en laissant un vrai degré d’autonomie.

5. AJOUTER UNE POLITIQUE

Automatiser c’est bien.
Mais il faut aussi s’assurer que personne n’oublie de taguer ses VMs.

👉 C’est là qu’Azure Policy entre en jeu

Exiger les bons tags sur chaque VM

On crée une politique de conformité qui impose la présence de :

• CriticiteSauvegarde
• BackupPolicy

Deux approches sont possibles :

🟥 Option stricte : Deny

Avec cette stratégie, aucune VM ne peut être créée sans ces deux tags.
C’est net, carré, efficace.

Mais… ❗ ça peut aussi bloquer certaines équipes lors d’un déploiement

{
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Compute/virtualMachines"
        },
        {
          "field": "tags['CriticiteSauvegarde']",
          "exists": "false"
        },
        {
          "field": "tags['BackupPolicy']",
          "exists": "false"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}

🟨 Option souple : DeployIfNotExists

Cette option rajoute les tags manquants automatiquement, avec des valeurs par défaut :

• CriticiteSauvegarde = standard
• BackupPolicy = daily-7d

Cela permet de ne bloquer personne, tout en garantissant un minimum de protection.

6. ARCHITECTURE DE L’AUTOMATISATION

Tu veux une automatisation fiable, traçable, et facile à maintenir. Voici un schéma type basé sur une solution éprouvée :

Fonctionnement détaillé

1. Déclenchement

• Manuellement ou toutes les 12h via un schedule
• Option : déclenchement par événement (ex. création VM)

2. Lecture des VMs

• Liste toutes les VMs dans les scopes définis
• Ignore celles avec un tag IgnoreBackup=true si besoin

3. Analyse des tags

• Extrait les tags CriticiteSauvegarde et BackupPolicy
• Détermine le RSV cible (ex : rsv-e2-pr-haut)
• Vérifie si la VM est déjà protégée avec la bonne policy

4. Affectation

• Si ce n’est pas le cas :
  → Ajoute la VM dans le bon RSV
  → Applique la policy correspondante

5. Journalisation

• Chaque action est logguée dans Log Analytics
• En cas d’erreur ou incohérence : alerte via Action Group

Exemple de début de script PowerShell

# Connexion avec Managed Identity
Connect-AzAccount -Identity

# Liste des VMs
$vmList = Get-AzVM -Status

foreach ($vm in $vmList) {
    $tags = $vm.Tags
    $criticite = $tags["CriticiteSauvegarde"]
    $policy = $tags["BackupPolicy"]

    if (-not $criticite -or -not $policy) {
        Write-Output "❌ Tags manquants sur $($vm.Name)"
        # Envoi d'une notification via Action Group (ex. : Teams, email)
        continue
    }

    # Mapping Criticité → RSV
    $rsvName = switch ($criticite) {
        "minor" { "rsv-backup-lrs" }
        "standard" { "rsv-backup-zrs" }
        "critique" { "rsv-backup-grs" }
        default { Write-Output "❌ Criticité inconnue pour $($vm.Name)"; continue }
    }

    # Vérifier si la VM est protégée
    $backupItem = Get-AzRecoveryServicesBackupItem -BackupManagementType AzureVM -WorkloadType AzureVM -VaultId (Get-AzRecoveryServicesVault -Name $rsvName).ID | Where-Object { $_.Name -eq $vm.Name }

    if (-not $backupItem) {
        # Activer la sauvegarde
        $policyObject = Get-AzRecoveryServicesBackupProtectionPolicy -Name $policy -VaultId (Get-AzRecoveryServicesVault -Name $rsvName).ID
        Enable-AzRecoveryServicesBackupProtection -ResourceGroupName $vm.ResourceGroupName -Name $vm.Name -Policy $policyObject -VaultId (Get-AzRecoveryServicesVault -Name $rsvName).ID
        Write-Output "✅ VM $($vm.Name) ajoutée à $rsvName avec policy $policy"
    }
}

8. LIMITATION DE LA SOLUTION

Voici les principales limites de l’approche centralisée et automatisée pour la gestion des Recovery Services Vaults (RSV) :

• 🔴 Coût des RSV GRS : La réplication géo-redondante (GRS) est plus coûteuse que LRS ou ZRS. Pour les workloads non critiques, privilégiez LRS ou ZRS pour optimiser les coûts
• 🔴 Terraform/Bicep et Azure Policy : Les tags ajoutés par une policy DeployIfNotExists peuvent créer des incohérences avec le code d’infrastructure si celui-ci n’est pas mis à jour
• 🔴 Limite de 500 RSV par souscription par région : Azure autorise un maximum de 500 Recovery Services Vaults par souscription dans une région donnée
• 🔴 Contraintes régionales : Les RSV sont liés à une région Azure spécifique. Les données sauvegardées ne peuvent pas être déplacées directement vers un autre RSV dans une région différente, ce qui peut compliquer les migrations ou les stratégies multi-régions. De plus, la réplication GRS nécessite une région secondaire prédéfinie par Azure, limitant la flexibilité du choix

PROCHAIN ARTICLE

On vient de passer ensemble toute la mécanique du PCA/PRA côté machines virtuelles.
Mais dans Azure, ce n’est qu’une partie du puzzle.

Dans le prochain article, on s’attaquera à la continuité d’activité côté PaaS :
📦 Azure SQL, App Service, Key Vault, Service Bus…
Tous ces services qu’on utilise au quotidien, mais qu’on oublie souvent de protéger correctement.

Comment les rendre résilients ?
Comment prévoir un plan de reprise sans galérer à tout reconstruire à la main ?
Et surtout, comment éviter les pièges les plus fréquents ?

On verra tout ça très bientôt 😉

📎 Pour aller plus loin (docs Microsoft) :

• Vue d’ensemble des coffres de services de récupération (RSV)
• Concepts clés de sauvegarde Azure

Younes Djebbouri

Architecte Cloud Azure & DevOps. Passionné par la sécurité, la résilience et les bonnes pratiques d'architecture.

Suivre sur LinkedIn →