Bonnes pratiques de sauvegarde VMware : snapshots, CBT, réplication et pièges typiques de RESTauration

Les exploitants d’environnements vSphere connaissent ce schéma : les sauvegardes passent « en vert », mais en cas d’incident il manque des minutes, des applications démarrent de façon incohérente ou la RESTauration prend nettement plus de temps que prévu. Bonnes pratiques de sauvegarde VMware relèvent donc moins d’une question d’outil que d’une discipline opérationnelle : utiliser correctement les snapshots, comprendre le Changed Block Tracking (CBT), positionner proprement la réplication et exclure systématiquement les pièges de RESTauration.

Cet article s’adresse aux administrateurs, System Engineers, opérateurs et pRESTataires IT techniques. L’objectif n’est pas « comment cliquer dans le produit X », mais : quels mécanismes techniques agissent en arrière-plan, quelles conditions doivent être remplies, quels risques sont typiques — et comment concevoir des stratégies de vérification et de repli qui tiennent dans la pratique.

Bonnes pratiques de sauvegarde VMware en pratique

La plupart des sauvegardes vSphere sans agent utilisent les vSphere APIs for Data Protection (VADP). Simplifié, la chaîne est la suivante : création d’un snapshot, lecture des données (plein ou incrémental), suppression du snapshot (Commit/Merge). Le snapshot n’est pas une « sauvegarde », mais un état temporaire qui permet une lecture cohérente. Selon la configuration, une mise en quiescence est déclenchée au niveau du système invité (les tampons d’application ou du système de fichiers sont gelés), typiquement via VMware Tools et, pour Windows, via VSS (Volume Shadow Copy Service).

Important pour l’exploitation : une sauvegarde n’affecte pas seulement le réseau et le repository. Elle sollicite surtout Datastore, Storage-Controller und die VM selbst, car les fichiers delta de snapshot génèrent des I/O supplémentaires et le fusionnement ultérieur (Snapshot-Commit) est lui aussi intensif en I/O. Si les sauvegardes s’exécutent « à un moment donné la nuit », mais que la charge de stockage est déjà élevée (jobs batch, ETL, rebuilds d’index, rotation des logs), les risques de durées de snapshot prolongées et de timeouts augmentent.

2) Snapshots en pratique : utilité, limites et erreurs typiques

Un snapshot VMware n’enregistre pas l’état complet de la VM comme une copie indépendante, mais crée des structures delta (les blocs modifiés sont consignés dans des fichiers séparés). Tant que le snapshot est actif, cette structure delta croît – en fonction du taux de modification, du profil d’I/O et de la taille du disque de la VM. C’est le cœur du risque opérationnel lié au « fait de laisser un snapshot en place ».

2.1 Pourquoi les snapshots prolongés sont dangereux

Les durées prolongées de snapshot entraînent souvent :

• Baisse de performance de la VM (chemins d’écriture supplémentaires, latence accrue).
• Croissance du datastore (les fichiers delta se remplissent ; avec le Thin Provisioning cela peut s’aggraver plus vite que prévu).
• Pics de commit (le merge prend du temps, concurrence l’I/O de production).
• Cascade des fenêtres de sauvegarde : un commit retardé décale d’autres jobs, entraînant finalement un embouteillage.

Un écueil fréquent : les sauvegardes sont interrompues, mais le Snapshot persiste (selon l’outil/le scénario d’erreur) ou le commit est retardé. On ne le voit pas toujours immédiatement dans la console de sauvegarde, mais dans le vSphere-Client ou via des alertes sur l’âge des Snapshots et leur nombre.

2.2 Quiesce, VSS et « application-aware » : quand cohérent est vraiment cohérent

« application-aware » signifie que non seulement le système de fichiers est cohérent, mais aussi que les applications (p. ex. bases de données) placent leurs tampons d’écriture dans un état défini. Bei Windows geschieht das typischerweise über VSS-Writer. Bei Linux dépend cela fortement de l’application et du mécanisme utilisé (p. ex. scripts, Pre-/Post-Freeze-Hooks, modes de sauvegarde propres à la base de données). C’est crucial : une image « crash-consistent » peut démarrer, mais les transactions de la base de données ou les index peuvent, dans le pire des cas, imposer une récupération plus longue ou échouer.

Pour les responsables opérationnels, cela signifie : définissez par classe de charge de travail (Domain Controller, SQL/Exchange, PostgreSQL, serveur de fichiers, serveur d’applications) explicitement quel degré de cohérence est nécessaire — et documentez les prérequis nécessaires (VMware Tools-Version, VSS-Writer-Status, services, scripts, credentials, règles de pare-feu).

2.3 Liste de contrôle : Snapshot-Hygiene in vSphere

• Alertes/rapports pour Snapshots âgés de plus de X Stunden et mehr als Y Snapshots pro VM.
• Planifier les jobs de sauvegarde de façon à ce que les Snapshots existent aussi brièvement que possible (prise en compte de la charge du Storage).
• Règle : les Snapshots sont temporaires. Pour une conservation prolongée, ils ne remplacent pas Backup/Archiv.
• Avant des changements importants (Patchday, modifications de schéma) : plan clair indiquant quand les Snapshots sont autorisés — et quand non (p. ex. en cas d’un fort taux d’écritures DB).

3) CBT (Changed Block Tracking) : un atout pour les incrémentiels, un risque en cas d’incohérence

CBT, Changed Block Tracking, est une fonctionnalité de vSphere qui suit, pour chaque disque virtuel, quels blocs ont été modifiés depuis un point dans le temps défini. Le logiciel de sauvegarde peut ainsi créer des sauvegardes incrémentielles sans relire l’intégralité du disque à chaque fois. Cela économise du temps et réduit les I/O – tant que CBT est correct.

3.1 Comment le CBT peut échouer (et pourquoi cela passe souvent inaperçu)

Le CBT peut « se tromper » lorsque l’historique des modifications ne correspond pas aux données réelles. Cela peut se produire à cause de certains scénarios Storage-/Snapshot-/Clone, de bugs dans d’anciennes versions de vSphere ou de séquences malheureuses d’opérations de Snapshot et de redimensionnement. Le problème : la sauvegarde peut continuer à réussir, mais lors de la RESTauration des blocs peuvent manquer ou l’état des données être incohérent.

Opérationnellement, cela signifie : en cas de problèmes de RESTauration inexpliqués ou de sauvegardes incrémentielles anormales (étonnamment petites ou étonnamment rapides), CBT est un suspect. Une stratégie de repli éprouvée est un reset actif des informations CBT (typiquement par une sauvegarde complète forcée ou via des mécanismes vSphere qui reconstruisent les données de suivi des modifications). La façon dont cela est implémenté dans l’outil concret dépend du produit – l’essentiel est le principe : « En cas de doute : rétablir une baseline cohérente une fois. »

3.2 Points de contrôle pour un fonctionnement compatible avec CBT

• Exploiter vSphere/ESXi dans une version stable et supportée (les bugs CBT sont historiquement bien documentés ; les versions anciennes sont risquées).
• Connaître les cas limites liés au stockage/snapshots (p. ex. chaînes de snapshots agressives, redimensionnements fréquents de disques).
• Effectuer régulièrement des tests de RESTauration sur des chaînes incrémentielles (pas seulement des sauvegardes complètes).
• Surveiller les motifs inhabituels : incrémentales systématiquement « trop petites », malgré un taux de changement élevé.

4) Réplication vs. Sauvegarde : même résultat, objectifs différents

La réplication (p. ex. via réplication au niveau de l’hyperviseur ou du stockage) copie les états de VM ou les blocs de stockage vers un second site de manière rapprochée dans le temps. L’objectif est typiquement d’obtenir un bon RPO (Recovery Point Objective : perte maximale de données en temps) et un RTO rapide (Recovery Time Objective : temps jusqu’à la remise en service). La sauvegarde vise en revanche davantage la gestion des versions, la conservation à long terme, l’inaltérabilité et la capacité à annuler des « erreurs logiques » (chiffrement par ransomware, suppression accidentelle, mises à jour défaillantes).

4.1 Hypothèses erronées typiques

• « Nous répliquons, donc nous n’avons pas besoin de sauvegarde. » Faux, car la réplication réplique souvent aussi les erreurs (p. ex. chiffrement, corruption des données, configuration erronée).
• « La sauvegarde est trop lente, donc la réplication suffit. » La réplication ne remplace pas les états historiques ni les exigences d’audit.
• « Les snapshots = points de RESTauration. » Les snapshots sont temporaires, critiques pour les performances et pas conçus pour la conservation.

4.2 Bonnes pratiques : combiner, mais séparer proprement

Dans des architectures robustes, on combine les deux : réplication pour la continuité d’exploitation (DR-Failover) et sauvegarde pour la protection des données et des versions. L’essentiel est la séparation des domaines d’erreur :

• Segmenter séparément le repository de sauvegarde (réseau, identifiants, MFA/RBAC).
• Prévoir des cibles de stockage inaltérables (Immutability) si le risque de ransomware est réaliste.
• Maintenir le runbook de réplication séparé du runbook de RESTauration : objectif différent, étapes différentes, tests différents.

5) Pièges de la RESTauration : pourquoi « RESTauration réussie » n’équivaut pas à « système rétabli »

Beaucoup d’équipes testent les RESTaurations trop rarement ou de manière trop superficielle. Une RESTauration de VM peut réussir techniquement, alors que l’application ne démarre pas, la récupération de la base de données bloque ou le réseau/l’identité ne correspondent pas. Pour des solutions logicielles proches des processus, le point critique n’est pas le démarrage, mais la remise en service fonctionnelle (dépendances, certificats, DNS, licences, intégrations).

5.1 Pièges fréquents de RESTauration en exploitation

• Données applicatives inconsistantes (crash-consistent au lieu d’application-aware ; VSS-Writer défectueux ; Linux-DB sans freeze/hook).
• Conception du repository trop RESTrictive : la RESTauration échoue parce que les données existent, mais le « cold tier »/stockage objet est trop lent pour le RTO.
• Dépendances réseau et d’identité : contrôleur de domaine/LDAP/DNS remis en ligne dans un ordre incorrect.
• Pilotes/contrôleurs/mode de démarrage : incompatibilité UEFI/BIOS, Secure Boot, contrôleurs virtuels modifiés.
• Chiffrement/clefs : BitLocker/LUKS/clefs d’application non disponibles ; la RESTauration démarre, mais les données RESTent illisibles.
• Autorisations et secrets : comptes de service modifiés, rotation des mots de passe, la sauvegarde contient d’anciens secrets.

5.2 Un test de RESTauration pragmatique : ce que vous devriez vérifier au minimum

Un test de RESTauration n’a pas besoin d’être à chaque fois un DR complet. Mais il doit être reproductible et mesurable. Pour de nombreux environnements, un cycle mensuel avec des charges de travail rotatives fonctionne :

• RESTaurer la VM dans un réseau isolé (pas de conflit IP/DNS).
• Vérifier le démarrage et les services de base (logs système, vérification des disques, journaux d’événements).
• Contrôler la santé de l’application (par ex. connexion, endpoint API, planificateur de tâches).
• Si une BD est impliquée : la base démarre, mesurer le temps de recovery, exécuter des contrôles d’intégrité.
• Documenter RTO/RPO et motiver les écarts (capacité, parallélisme, performance du repository).

Important : ne testez pas seulement la dernière sauvegarde complète. Testez également les chaînes incrémentales, car c’est là que CBT, l’intégrité des chaînes et les chemins de fusion sont particulièrement critiques.

6) Dépannage : quand les sauvegardes sont marquées OK mais que des snapshots persistent ou que des jobs RESTent « bloqués »

Symptômes typiques en exploitation : un snapshot RESTe présent, un job de sauvegarde dure anormalement longtemps, le commit prend une éternité, la latence du datastore augmente. La cause n’est souvent pas une « sauvegarde cassée », mais un goulot d’étranglement sur le chemin de stockage ou un quiescing invité qui ne revient pas proprement.

6.1 Séquence de vérification systématique (sans dépendance à un outil)

1. vCenter Events : événements de création/suppression de snapshot, timeouts, message de consolidation nécessaire.
2. Datastore/Storage : pics de latence, profondeur de file (queue depth), charge du contrôleur, rebuilds, congestion.
3. VM invité : état de VMware Tools, VSS-Writer (Windows), logs applicatifs, durée du freeze.
4. Backup-Proxy/Transport : HotAdd/NBD/SAN-Transport (selon l’architecture), chemins réseau, MTU, perte de paquets.
5. Repository : débits d’écriture/lecture, surcharge dedupe/compression, temps de récupération depuis le stockage objet.

6.2 PowerCLI : trouver les snapshots et analyser leur âge

Pour un aperçu rapide dans des environnements hétérogènes, PowerCLI est souvent pragmatique en pratique. L’exemple suivant liste les snapshots et leur âge (en jours). Adaptez les filtres et la sortie à vos standards.

# Voraussetzung: VMware PowerCLI installiert, Verbindung zu vCenter
# Connect-VIServer -Server vcenter.example.local

Get-VM | Get-Snapshot | Select-Object 
  @{N='VM';E={$_.VM.Name}}, Name, Created, Description, SizeMB, 
  @{N='AgeDays';E={[math]::Round(((Get-Date) - $_.Created).TotalDays,2)}} | 
  Sort-Object AgeDays -Descending

Remarque opérationnelle : « SizeMB » n’est pas toujours une représentation parfaite de l’impact réel sur le stockage (backend de stockage, Thin/Thick, motifs de données), mais utile comme indicateur en conjonction avec l’ancienneté et le nombre.

6.3 PowerCLI : Identifier les VMs avec « Consolidation needed »

Si des snapshots ont été supprimés mais que les structures delta n’ont pas été correctement fusionnées, vSphere peut signaler « Consolidation needed ». C’est un signal d’alerte, car la VM peut continuer à fonctionner avec des fichiers delta supplémentaires.

Get-VM | Where-Object {$_.ExtensionData.Runtime.ConsolidationNeeded -eq $true} | 
  Select-Object Name, PowerState

Si vous obtenez des résultats ici, vérifiez d’abord la latence du stockage et les tâches I/O intensives en cours. Une consolidation forcée en période de forte charge peut faire plus de mal que de bien. Prévoyez plutôt une fenêtre de maintenance contrôlée et ayez un plan de repli prêt (p. ex. capacité de stockage, migration d’urgence, ordre défini d’arrêt/démarrage).

7) Mise en œuvre en exploitation : fenêtres de sauvegarde, parallélisme, ressources et stratégie de repli

De nombreux problèmes de sauvegarde ne proviennent pas d’un manque de fonctionnalité, mais de la sursouscription : trop de jobs parallèles, proxies trop petits, I/O du Repository insuffisant, Datastores sous-dimensionnés. Les bonnes pratiques concernent ici principalement les règles de capacité et de déroulement.

7.1 Limiter délibérément le parallélisme

Plus de jobs parallèles ne réduisent pas automatiquement la fenêtre. À un certain point, les jobs se font concurrence pour les mêmes ressources : file d’attente du stockage, réseau, CPU (compression/dedupe), I/O du proxy. Il est judicieux d’appliquer un parallélisme contrôlé par Datastore/Cluster et par classe de workload. Les systèmes particulièrement intensifs en écriture (bases de données, logging, message broker) devraient idéalement être programmés dans des fenêtres à faible taux de changements.

7.2 Full vs. Inkremental : définir la stratégie de baseline

Les chaînes incrémentales sont efficaces, mais elles augmentent la dépendance aux métadonnées, au CBT et à l’intégrité de la chaîne. Définissez :

• À quelle fréquence un full synthétique ou un full réel est généré.
• Quelle doit être la longueur maximale des chaînes (risque opérationnel vs. économie de stockage).
• Comment basculer en cas de suspicion de problèmes CBT/chaînes (p. ex. full forcé, nouveau job de sauvegarde, nouvelle chaîne).

7.3 Stratégie de repli (Runbook) pour le Backup-Betrieb

Un runbook n’est pas un exercice de conformité, mais fait gagner du temps la nuit. Il devrait contenir au minimum :

• Les chemins de contact et d’escalade (stockage, réseau, plateforme, application).
• Règles décisionnelles : annuler le job oui/non, suppression des snapshots immédiate/retardée.
• Étapes de vérification avec sources : vCenter Events, métriques de stockage, Backup-Logs, Guest-Logs.
• Mesures d’urgence : réduire le parallélisme, replanifier les jobs, full ciblé, test de RESTauration isolé.

8) Sécurité et réalité du ransomware : pourquoi les zones de sauvegarde et les droits deviennent plus importants

Dans de nombreux incidents, le problème n’est pas le format de sauvegarde mais la chaîne d’accès : si des attaquants deviennent Domain-Admin, les serveurs de sauvegarde et les repositories sont souvent la cible suivante. Les bonnes pratiques dans le contexte VMware incluent donc des séparations strictes :

• Identités séparées pour les opérations de sauvegarde (Least Privilege, RBAC).
• Segmentation réseau : trafic de sauvegarde et gestion pas sur le même réseau plat.
• Immutabilité (mécanismes de type WORM) pour les périodes de rétention critiques.
• Copie hors ligne ou Air-Gap pour le scénario du pire cas (selon taille/RTO).

L’aspect praticable est essentiel : des barrières trop strictes, contournées dans la pratique, sont pires qu’un modèle solide et contrôlé. Vérifiez donc régulièrement que vos processus sont effectivement appliqués (p. ex. droits de RESTauration uniquement pour des rôles définis ; comptes Break‑Glass avec audit).

9) Listes de contrôle pratiques : avant le prochain audit ou test DR

9.1 Vérification opérationnelle : « Ma sauvegarde VMware fonctionne‑t‑elle vraiment ? »

• Existe‑t‑il des RPO/RTO documentés par classe de système et sont‑ils mesurés ?
• Les snapshots/la consolidation sont‑ils intégrés au monitoring et les écarts sont‑ils tracés ?
• Les chaînes incrémentales sont‑elles testées activement (pas seulement les sauvegardes complètes) ?
• Est‑il clair quels systèmes doivent être sauvegardés de manière application‑aware ?
• Le dépôt est‑il protégé contre la manipulation (droits, réseau, immutabilité, administrateurs séparés) ?
• Existe‑t‑il un environnement de test de RESTauration (réseau isolé, stratégie DNS/AD définie) ?

9.2 Préflight technique avant des changements majeurs

• Santé du stockage OK (latence, capacité, pas de rebuilds pendant la fenêtre critique) ?
• VMware Tools suffisamment à jour pour les exigences de quiescence ?
• Fenêtre de sauvegarde pas surbookée (parallélisme/proxies/E/S du dépôt) ?
• Plan d’urgence : si le commit du snapshot bloque, qui décide quoi et quand ?

Conclusion : les sauvegardes VMware ne valent que par la qualité de votre gestion des RESTaurations et des snapshots

Les bonnes pratiques solides pour les sauvegardes VMware reposent sur trois éléments : maintenir les snapshots courts et contrôlés, prendre au sérieux le CBT et les chaînes incrémentales comme sources potentielles d’erreurs, et séparer clairement la réplication de la sauvegarde. La preuve qualité déterminante n’est pas le statut « job » vert, mais une RESTauration régulièrement pratiquée incluant la vérification applicative, un RTO/RPO documenté et un runbook pour les incidents typiques.

Si vous souhaitez vérifier systématiquement votre capacité de RESTauration, l’étape suivante consiste en un plan de test propre avec points de mesure et cas de test reproductibles : Plan de test de RESTauration : vérifier la RESTaurabilité de vos sauvegardes étape par étape.

Pour ce sujet, les sauvegardes incrémentales et les sauvegardes application‑aware sont également importantes. L’article replace ces aspects de façon claire et montre ce qui compte au quotidien.