La sauvegarde des machines virtuelles n’est plus un simple sujet d’exploitation. En 2026, elle constitue une brique centrale du plan de continuité d’activité, de la réponse à incident et de la maîtrise du risque cyber. Un cluster de virtualisation peut concentrer plusieurs centaines de charges critiques sur quelques hôtes physiques : contrôleurs de domaine, bases de données, ERP, serveurs de fichiers, applications métier, services web, postes VDI et outils de supervision. Cette densité change radicalement les conséquences d’une erreur humaine, d’une panne de baie, d’une corruption logique ou d’un ransomware. Restaurer rapidement une VM ne suffit pas toujours ; il faut pouvoir restaurer des données cohérentes, vérifier l’intégrité des sauvegardes, reconstruire des dépendances applicatives et respecter des objectifs RPO et RTO réalistes.

Une stratégie efficace repose donc sur plusieurs couches. La première concerne la cohérence des données capturées. La seconde porte sur le stockage et la distribution géographique des copies. La troisième vise la protection de ces copies contre leur suppression ou leur chiffrement. Enfin, la dernière concerne les procédures de restauration, qui doivent être testées de façon répétable. Les outils évoluent, mais les principes restent stables : identifier les services prioritaires, définir les objectifs métier, sauvegarder selon une fréquence adaptée, isoler une copie et mesurer régulièrement la capacité réelle de restauration. Veeam Backup & Replication reste une référence fréquente dans les environnements VMware et Hyper-V, tandis que Proxmox Backup Server et Bacula répondent à des besoins différents, notamment dans les architectures open source ou fortement personnalisées.

Partir des objectifs RPO et RTO, pas de l’outil

Avant de choisir un produit ou une cible de stockage, il faut formaliser les exigences de reprise. Deux indicateurs structurent les décisions techniques :

Ces objectifs ne sont pas uniformes. Une base de données transactionnelle, un annuaire Active Directory, un serveur de fichiers et une archive documentaire n’ont ni le même niveau de criticité ni les mêmes contraintes de restauration.

Catégorie de charge Exemple RPO courant RTO courant Approche recommandée
Critique ERP, base SQL, annuaire 15 min à 4 h 1 à 4 h Sauvegarde applicative, réplication éventuelle, restauration testée
Importante Serveur de fichiers, applicatif métier 4 à 24 h 4 à 24 h Sauvegarde image régulière, copies hors site
Standard Outils internes, services secondaires 24 h 24 à 72 h Sauvegarde quotidienne, rétention adaptée
Archive Données historiques, VM retirées de production Plusieurs jours Plusieurs jours Stockage objet, archivage, rétention longue

Le piège habituel est de définir un RPO de 24 heures partout parce qu’une sauvegarde nocturne existe déjà. Cette valeur ne dit rien de la capacité à restaurer. Une chaîne de sauvegarde peut être complète, mais un débit insuffisant, un dépôt saturé ou une dépendance applicative non documentée peuvent rendre le RTO irréaliste.

Cartographier les dépendances applicatives

Une VM ne constitue pas toujours une unité de reprise. Une application peut dépendre d’un DNS, d’un contrôleur de domaine, d’une base de données, d’un partage SMB, d’un serveur de licences et d’un relais SMTP. Restaurer uniquement le serveur frontal dans un réseau isolé peut donner l’impression que le système démarre, sans que le service soit réellement utilisable.

La cartographie doit donc inclure :

Cette cartographie servira directement aux tests de restauration et à la construction de runbooks exploitables pendant un incident.

Les mêmes principes de fond s’appliquent, à une échelle différente, à la sauvegarde de documents et de données en entreprise hors virtualisation : cohérence des copies, redondance et vérification régulière de la restauration. Ce guide de sauvegarde de données en entreprise pour TPE/PME aborde ces fondamentaux pour les organisations qui n’ont pas encore basculé leur infrastructure sur des VM.

Snapshot, sauvegarde image et cohérence applicative

Un snapshot d’hyperviseur n’est pas une sauvegarde. Il s’agit d’un mécanisme temporaire qui enregistre les modifications apportées à un disque virtuel après un point donné. Il facilite un retour arrière court, par exemple avant une opération de maintenance, mais ne répond pas aux exigences de protection durable.

Un snapshot prolongé peut dégrader les performances, augmenter la fragmentation, compliquer les consolidations et consommer rapidement l’espace disponible. Il reste par ailleurs dépendant du même datastore, du même cluster et souvent de la même baie de stockage que la production. Une panne de ce périmètre peut donc emporter la VM et son snapshot.

Cohérence crash-consistent

Une sauvegarde crash-consistent capture l’état des disques comme si la VM avait subi une interruption brutale. Les systèmes de fichiers modernes disposent souvent de journaux permettant un redémarrage correct, mais cela ne garantit pas une cohérence métier. Une base de données peut nécessiter une phase de récupération longue ou présenter des transactions incomplètes.

Cette approche peut être acceptable pour des VM stateless, des serveurs web reconstruisibles ou certaines charges non critiques. Elle est moins adaptée aux serveurs transactionnels et aux applications avec de fortes exigences d’intégrité. Pour aller plus loin, consultez le comparatif Veeam contre Proxmox Backup Server.

Cohérence applicative et quiescence

Une sauvegarde applicative cohérente coordonne la capture avec le système invité et, idéalement, avec l’application. Dans les environnements Windows, cela passe généralement par VSS, Volume Shadow Copy Service. Les writers VSS des applications permettent de figer temporairement les écritures, de purger ou gérer les journaux selon la politique définie, puis de reprendre l’activité après le snapshot.

Sous Linux, l’approche dépend de la pile applicative : scripts pré-freeze et post-thaw, snapshots LVM, mécanismes natifs de base de données ou sauvegarde applicative complémentaire. Pour PostgreSQL, MariaDB, MySQL, Oracle ou d’autres moteurs, il faut vérifier que la méthode utilisée couvre réellement les journaux de transactions et permet une restauration compatible avec le RPO annoncé.

Une bonne pratique consiste à surveiller les erreurs de quiescence sans masquer systématiquement l’échec. Autoriser une sauvegarde à continuer après un échec VSS peut éviter une absence totale de point de restauration, mais il faut alors la qualifier explicitement comme crash-consistent et traiter la cause.

CBT et sauvegardes incrémentales dans un environnement virtualisé

Le Change Block Tracking, ou CBT, est un mécanisme qui identifie les blocs de disque modifiés entre deux points de sauvegarde. VMware propose son propre suivi des blocs modifiés, Hyper-V s’appuie notamment sur les fichiers RCT, Resilient Change Tracking, et d’autres plateformes disposent de mécanismes équivalents.

L’intérêt est majeur : au lieu de relire l’intégralité d’un disque virtuel de plusieurs téraoctets, le logiciel de sauvegarde ne transfère que les blocs modifiés depuis la dernière exécution. Cela réduit la fenêtre de sauvegarde, la charge sur les datastores et la consommation réseau.

Ce que le CBT apporte réellement

Le CBT accélère la lecture des données, mais il ne remplace ni la déduplication, ni la compression, ni une politique de rétention. Il ne garantit pas non plus, à lui seul, que l’incrément sera petit. Une opération de défragmentation, une réécriture massive, un chiffrement ransomware ou un traitement analytique peut modifier une proportion importante des blocs.

Il faut aussi prévoir les cas de réinitialisation du suivi des changements : consolidation de snapshots, déplacement de disques, opérations d’administration de l’hyperviseur, corruption détectée par l’outil ou changement de chaîne de sauvegarde. Dans ce cas, une lecture complète peut être nécessaire. Les capacités réseau et la fenêtre de traitement doivent absorber ce scénario exceptionnel.

Synthétique, reverse incremental et chaînes de restauration

Les produits modernes proposent différentes méthodes pour limiter les sauvegardes complètes actives :

Le choix dépend du stockage cible, de la bande passante, des capacités de déduplication et du profil de restauration. Sur un dépôt performant, une chaîne incrémentale correctement gérée réduit fortement les lectures sur la production. Sur un stockage objet distant, il faut aussi mesurer les coûts de requêtes, les délais de récupération et la politique de cycle de vie.

Un tableau de bord de sauvegarde rassure sur l'état de la protection des VM.
Un tableau de bord de sauvegarde rassure sur l'état de la protection des VM.

Veeam Backup & Replication : référence, mais pas réponse universelle

Veeam Backup & Replication reste très présent dans les infrastructures VMware vSphere et Microsoft Hyper-V. Sa position s’explique par une couverture fonctionnelle mature : sauvegarde image, traitement applicatif, intégration avec les hyperviseurs, dépôts Linux durcis, copies de sauvegarde, réplication, restauration granulaire et automatisation via API ou PowerShell.

Dans un environnement bien conçu, Veeam permet de séparer les rôles : serveur de gestion, proxys de transport, dépôts de sauvegarde et cibles hors site. Cette séparation aide à dimensionner les flux et à limiter les privilèges.

Fonctions utiles pour le PCA

Pour les administrateurs responsables de la reprise, les fonctions les plus intéressantes ne sont pas seulement la création de jobs :

La fonctionnalité doit cependant être confrontée à l’architecture. Une restauration instantanée peut démarrer vite, mais ses performances dépendront de la capacité du dépôt à servir les disques de la VM. Elle constitue souvent une étape de reprise, pas nécessairement un état durable de production.

Points de vigilance sur l’architecture Veeam

Le compte utilisé pour administrer la solution ne doit pas être un compte d’administration de domaine ordinaire. Le serveur de sauvegarde, les comptes de service, les identifiants d’hyperviseur et les accès aux dépôts doivent être segmentés. En cas de compromission Active Directory, cette séparation peut faire la différence entre une reprise possible et la destruction simultanée de la production et des sauvegardes.

Le dépôt Linux mérite une attention particulière. Il doit être dédié, limité en services exposés, protégé par des comptes distincts et administré avec une journalisation adaptée. L’immuabilité ne dispense pas de sécuriser l’accès : elle limite la suppression des données pendant une période donnée, mais ne corrige pas une mauvaise rétention, une saturation de capacité ou un vol de clés d’accès à un stockage objet.

Alternatives open source : Proxmox Backup Server et Bacula

Les alternatives open source ne sont pas des copies gratuites d’une suite propriétaire. Elles répondent à des modèles d’exploitation différents et demandent souvent davantage de compétences internes sur le stockage, l’automatisation et la supervision. Pour aller plus loin, consultez les fondamentaux du stockage virtualisé.

Proxmox Backup Server pour l’écosystème Proxmox VE

Proxmox Backup Server, ou PBS, est particulièrement cohérent avec Proxmox VE. Il fournit une sauvegarde incrémentale au niveau des blocs, de la déduplication, de la compression, du chiffrement côté client et une gestion de rétention intégrée. Son architecture en datastores simplifie les déploiements lorsqu’une organisation exploite déjà Proxmox VE. La documentation officielle sauvegarde et restauration de Proxmox VE détaille les modes snapshot, stop et suspend disponibles.

PBS est efficace pour sauvegarder des VM et conteneurs Proxmox, avec un bon niveau d’intégration. Il faut néanmoins traiter les besoins applicatifs avec la même rigueur que sur toute autre plateforme : une sauvegarde de VM ne remplace pas automatiquement une stratégie de sauvegarde transactionnelle pour une base critique.

Bacula pour les environnements hétérogènes

Bacula est une solution de sauvegarde historique et flexible, particulièrement pertinente lorsque le besoin dépasse la sauvegarde image d’hyperviseur : serveurs physiques, agents applicatifs, fichiers, bandes, politiques de rétention complexes et intégrations spécifiques. Sa puissance s’accompagne d’une courbe d’apprentissage plus élevée et d’une exploitation rigoureuse de son catalogue, de ses pools et de ses politiques de médias.

Solution Cas d’usage principal Points forts Contraintes
Veeam Backup & Replication VMware, Hyper-V, environnement mixte Fonctions de restauration, intégrations, exploitation mature Coût de licence, dépendance à une architecture dédiée
Proxmox Backup Server Proxmox VE Intégration native, déduplication, simplicité opérationnelle Couverture orientée écosystème Proxmox
Bacula Infrastructure hétérogène et personnalisée Flexibilité, agents, bande, scénarios complexes Conception et exploitation plus exigeantes

Le choix doit être guidé par le périmètre réel, les compétences internes et les exigences de restauration. Une solution gratuite mais non maîtrisée devient coûteuse lors du premier incident.

Appliquer concrètement la règle 3-2-1

La règle 3-2-1 reste un socle utile : conserver au moins trois copies des données, sur deux types de supports différents, dont une copie hors site. En virtualisation, il faut aller au-delà du slogan et définir ce que représente chaque copie.

Un exemple pragmatique :

  1. La production sur le stockage primaire.
  2. Une sauvegarde locale sur un dépôt indépendant, idéalement avec des disques et une administration séparés.
  3. Une copie hors site sur un second datacenter, un stockage objet ou une cible isolée.

La copie locale permet des restaurations rapides. La copie hors site protège contre l’incendie, le vol, une panne de site ou une compromission généralisée. Les deux ne doivent pas être confondues avec une réplication seule. Une réplication peut propager une corruption logique ou un chiffrement ; elle améliore le RTO, mais ne remplace pas la conservation de points historiques.

Ajouter l’immuabilité : vers 3-2-1-1-0

La variante 3-2-1-1-0 ajoute une copie hors ligne ou immuable et zéro erreur lors de la vérification de restauration. Dans la pratique, l’immuabilité peut être apportée par :

L’immuabilité doit être définie en fonction du délai de détection d’une compromission. Si une attaque reste invisible pendant 30 jours, une rétention immuable de 7 jours est insuffisante. Il faut disposer de points assez anciens pour revenir avant l’événement, sans pour autant conserver indéfiniment toutes les sauvegardes coûteuses.

Des unités de stockage externes illustrent la redondance d'une stratégie 3-2-1.
Des unités de stockage externes illustrent la redondance d'une stratégie 3-2-1.

Construire une stratégie hors site résiliente aux ransomwares

Le ransomware moderne cible les hyperviseurs, les consoles de sauvegarde, les comptes d’administration, les dépôts réseau et les stockages objet. La protection ne repose donc pas uniquement sur un coffre de sauvegarde, mais sur une réduction systématique des chemins d’attaque.

Segmenter les identités et les accès

Les comptes de sauvegarde doivent être séparés des comptes bureautiques et des comptes d’administration de production. Activez l’authentification multifacteur là où elle est disponible, limitez les droits au strict nécessaire et évitez les partages SMB accessibles en écriture par des comptes trop larges.

Les accès à la console de sauvegarde doivent être journalisés. Les opérations sensibles, comme une réduction de rétention, une suppression de dépôt, une modification de clé de chiffrement ou un changement de compte de stockage objet, doivent être surveillées. Une alerte sur l’échec d’un job est nécessaire, mais une alerte sur la diminution brutale du volume de points restaurables l’est tout autant.

Prévoir la reprise sans les services habituels

Lors d’une compromission majeure, l’annuaire, le DNS interne, le bastion, le serveur de sauvegarde ou le vCenter peuvent être indisponibles. Les runbooks doivent donc documenter :

Une sauvegarde chiffrée sans clé de chiffrement correctement conservée est une sauvegarde perdue. Cette clé doit être protégée mais récupérable hors du périmètre compromis.

Tester les restaurations, pas seulement les sauvegardes

Un job vert signifie seulement que le logiciel a terminé l’opération qu’il devait effectuer. Il ne prouve ni que les données sont exploitables, ni que le RTO sera respecté, ni que les équipes sauront exécuter la reprise.

Les tests doivent être planifiés, documentés et variés. Restaurer toujours la même petite VM de test ne valide pas la reprise d’une base critique de plusieurs téraoctets ni le démarrage coordonné d’une application distribuée. Pour aller plus loin, consultez la protection contre les ransomwares ciblés sur l’hyperviseur.

Niveaux de test recommandés

Un programme de validation peut combiner plusieurs niveaux :

Lors d’un test, mesurez le temps réellement nécessaire : préparation de l’infrastructure, transfert des données, démarrage, récupération applicative, contrôles fonctionnels et remise en production. Comparez ces mesures au RTO annoncé. Si l’écart est important, il faut corriger l’architecture, réduire le volume à restaurer, augmenter les performances du dépôt ou revoir l’objectif avec les métiers. Pour aller plus loin, consultez la sécurisation générale d’un cluster.

Évaluer le coût des licences face au budget global

Le coût d’une licence de sauvegarde est souvent examiné isolément, alors que le coût réel doit inclure le stockage, les serveurs de dépôt, le réseau, le stockage objet, les bandes éventuelles, l’administration, les tests et le temps passé à résoudre les échecs. Inversement, réduire excessivement ce budget peut transformer une économie annuelle modeste en interruption de service coûteuse.

L’analyse doit comparer le coût total de possession à l’impact d’une indisponibilité. Pour une application critique, quelques heures d’arrêt peuvent coûter bien davantage que plusieurs années de licences. Pour des charges secondaires, une approche open source ou une rétention moins ambitieuse peut être parfaitement justifiée.

Il est utile de séparer trois budgets :

La meilleure solution n’est pas nécessairement celle qui affiche le prix de licence le plus faible. C’est celle qui permet de restaurer les services prioritaires dans les délais convenus, avec une exploitation soutenable et une protection crédible contre les scénarios de compromission.

Checklist opérationnelle pour un plan de sauvegarde virtualisé

Pour transformer les principes en dispositif exploitable, vérifiez au minimum les points suivants :

La sauvegarde d’un environnement virtualisé est un système à part entière. Elle doit être conçue, sécurisée, supervisée et testée avec le même niveau d’exigence que la production. Une stratégie 3-2-1 enrichie par l’immuabilité, des restaurations validées et une segmentation des accès donne une base solide. Le véritable critère de réussite reste simple : être capable de restaurer le bon service, au bon état, dans le délai attendu, même lorsque l’infrastructure habituelle n’est plus digne de confiance.