Sauvegarde et PRA en 2026 : la règle 3-2-1-1-0 face aux ransomwares

90 % des organisations se disent confiantes dans leur capacité à récupérer après une cyberattaque. Dans les faits, seulement 28 % y parviennent totalement. Cet écart, révélé par le dernier rapport Veeam sur la résilience des données, résume à lui seul pourquoi « avoir des sauvegardes » et « avoir une vraie stratégie de sauvegarde et de PRA » sont deux choses très différentes. Voici ce que ces chiffres impliquent concrètement pour ton infrastructure.

Le fossé entre confiance et réalité

Le rapport 2026 de Veeam sur la résilience face aux ransomwares dresse un constat qui devrait faire réfléchir toute équipe infra :

• 90 % des organisations se disent confiantes dans leur capacité de reprise après incident, mais seulement 28 % récupèrent l’intégralité de leurs données après une attaque — la récupération moyenne plafonne à 72 % des données touchées.
• 42 % des organisations attaquées signalent une perturbation directe pour leurs clients ou utilisateurs, 41 % des pertes financières, et 38 % un arrêt de service prolongé.
• Les organisations ayant augmenté leur budget cybersécurité affichent un taux de récupération complète de 40 %, contre seulement 16 % pour les autres — la corrélation entre investissement et résilience réelle est nette.

Le rapport identifie quatre pratiques qui font la différence : une visibilité claire sur les données en production et en sauvegarde, des contrôles de sécurité réellement appliqués (pas seulement documentés), des tests de restauration réalistes, et un alignement de la direction sur les responsabilités et objectifs de reprise (rapport complet sur veeam.com).

La règle 3-2-1-1-0, colonne vertébrale d’une stratégie solide

La bonne nouvelle, c’est que le cadre pour combler cet écart existe depuis longtemps et reste valable en 2026. La règle 3-2-1 s’est enrichie de deux exigences supplémentaires face aux ransomwares modernes :

• 3 copies de tes données (la production + 2 sauvegardes)
• 2 supports de stockage différents (ex. disque local + stockage objet cloud)
• 1 copie hors site (offsite, dans une autre région/datacenter)
• 1 copie hors ligne, immuable ou air-gapée — inaccessible même si un attaquant obtient des droits d’administration sur ton infra
• 0 erreur après vérification — une sauvegarde qui n’a jamais été testée n’est qu’une hypothèse

Le dernier point est celui que la plupart des équipes négligent. Une sauvegarde immuable qui ne restaure pas correctement au moment critique n’apporte aucune protection réelle.

Rendre tes sauvegardes vraiment immuables (pas juste « protégées »)

Sur Azure, le point de départ est le soft delete renforcé des coffres Recovery Services, activé par défaut sur les nouveaux coffres depuis les dernières évolutions de sécurité d’Azure Backup, avec une rétention configurable et une protection contre la suppression accidentelle ou malveillante des points de restauration :

# Activer l'immuabilité sur un coffre Recovery Services existant (Azure CLI)
az backup vault backup-properties set \
  --name "rsv-prod-backup" \
  --resource-group "rg-backup" \
  --backup-storage-redundancy GeoRedundant \
  --immutability-state Locked

# Vérifier l'état de l'immuabilité du coffre
az backup vault backup-properties show \
  --name "rsv-prod-backup" \
  --resource-group "rg-backup" \
  --query immutabilitySettings

Le point de vigilance : une fois passé en état Locked, l’immuabilité ne peut plus être désactivée, ce qui est précisément le comportement recherché contre un attaquant disposant de droits élevés. Teste d’abord en environnement non critique avant de verrouiller un coffre de production. Le détail des options (soft delete, coffres verrouillés, sauvegardes « vaulted ») est couvert dans la documentation officielle sur le soft delete renforcé d’Azure Backup et la vue d’ensemble des fonctionnalités de sécurité d’Azure Backup.

Le PRA, ce n’est pas la sauvegarde (et c’est souvent là que ça coince)

Avoir des sauvegardes fiables ne garantit pas un plan de reprise d’activité (PRA) fonctionnel. Ce sont deux disciplines complémentaires mais distinctes :

• La sauvegarde répond à la question « puis-je restaurer mes données ? »
• Le PRA répond à la question « en combien de temps mon service est-il de nouveau opérationnel, et avec quelle perte de données acceptable ? »

Ça se traduit par deux indicateurs à définir service par service, pas globalement pour toute l’infra :

• RPO (Recovery Point Objective) : quantité de données que tu acceptes de perdre, mesurée en temps depuis la dernière sauvegarde valide.
• RTO (Recovery Time Objective) : délai maximal acceptable avant que le service soit de nouveau disponible.

Un serveur de fichiers interne et une base de données transactionnelle critique n’ont pas les mêmes exigences — les traiter avec la même politique de sauvegarde est une erreur fréquente. C’est aussi un sujet que la réglementation pousse de plus en plus : la directive NIS2 en cours de transposition en France impose justement aux entités concernées de formaliser des capacités de continuité et de reprise d’activité, pas seulement des sauvegardes techniques.

Tester vraiment, pas seulement sur le papier

Un PRA qui n’a jamais été exécuté en conditions réelles reste une théorie. Quelques pratiques concrètes pour sortir de la théorie :

• Planifie des exercices de restauration complets (pas juste un fichier isolé) au moins une à deux fois par an, en dehors des heures critiques.
• Restaure vers un environnement isolé du réseau de production pour valider qu’une sauvegarde compromise ne recontamine pas l’infra restaurée.
• Mesure le RTO réel obtenu lors du test et compare-le à ton objectif — l’écart, s’il existe, te dit exactement où prioriser tes efforts.
• Documente qui fait quoi pendant l’exercice : un PRA qui dépend d’une seule personne disponible est un PRA fragile.

Si ton infrastructure de sauvegarde et de reprise est déployée sur Azure, la définir en Infrastructure as Code facilite grandement la reproductibilité de ces tests — coffres, politiques de rétention et réseaux isolés redéployés à l’identique à chaque exercice. Notre article sur les Azure Landing Zones et les Azure Verified Modules couvre justement cette approche pour structurer ce type d’infrastructure de façon cohérente.

FAQ

Quelle différence entre RTO et RPO ?

Le RPO mesure la perte de données acceptable (combien de temps depuis la dernière sauvegarde valide), le RTO mesure le temps d’indisponibilité acceptable avant reprise du service. Les deux se définissent ensemble, service par service.

Une sauvegarde immuable, c’est quoi concrètement ?

C’est une copie de sauvegarde qui ne peut être ni modifiée ni supprimée pendant une période définie, même par un compte disposant de droits d’administration — la protection ultime contre un ransomware qui aurait compromis tes accès élevés.

À quelle fréquence tester son PRA ?

Au minimum une à deux fois par an pour un test complet, et idéalement après chaque changement structurant de l’infrastructure (migration, nouvelle application critique, changement de fournisseur cloud).

Ce qu’il faut retenir

L’écart entre « je pense pouvoir récupérer » et « je peux effectivement récupérer » se comble avec trois ingrédients : des sauvegardes réellement immuables suivant la règle 3-2-1-1-0, des objectifs RTO/RPO définis service par service, et des tests de restauration exécutés en conditions réelles plutôt que supposés fonctionner. C’est un chantier qui se construit progressivement — mais qui vaut clairement l’investissement le jour où tu en as besoin.