Mensonges des sauvegardes Windows : les 3 paramètres qui déterminent si vous pouvez restaurer

Les 3 paramètres qui décident du succès de la restauration

La plupart des outils de sauvegarde Windows — Windows Server Backup, wbadmin, agents tiers s’appuyant sur VSS — se résument aux mêmes trois décisions cruciales. Si vous vous trompez sur ces points, votre « stratégie de sauvegarde » n’est qu’un programme d’optimisme gourmand en stockage.

1) Portée VSS et état des writers

Capturez‑vous des données cohérentes applicativement, ou juste une copie crash‑consistent de ce qui se trouvait sur le disque ? Si vos writers VSS sont en mauvais état ou exclus, votre sauvegarde « réussie » peut être un tas parfaitement préservé d’état irréparable.

2) Rétention et versioning

Avez‑vous les bons points de restauration, suffisamment longtemps, et avec un catalogue que vous pouvez réellement lire ? La rétention n’est pas une case de conformité ; c’est une machine à remonter le temps. Configurez‑la comme telle.

3) Récupérabilité bare‑metal

Pouvez‑vous restaurer sur un matériel différent, UEFI vs BIOS, un nouveau contrôleur de stockage ou une VM ? Si votre environnement de récupération ne voit pas le disque, ou si le système restauré ne démarre pas, vous n’avez pas de PRA — vous avez de l’archivage.

Tout le reste — plannings, cibles, compression, déduplication — compte, mais ces trois paramètres déterminent si vous pouvez restaurer sous pression.

Faits intéressants et contexte (parce que Windows n’est pas arrivé hier)

• VSS n’a pas toujours été le plan. Avant Volume Shadow Copy Service (introduit à l’époque de Windows Server 2003), les « sauvegardes cohérentes » signifiaient souvent arrêter des services et espérer que personne ne s’en aperçoive.
• NTBackup est mort pour vos péchés. Les anciennes versions de Windows livraient NTBackup ; Windows Server Backup moderne l’a remplacé, mais certaines habitudes (et idées reçues) ont perduré.
• System State est une bête spéciale. Ce n’est pas « juste un peu de registre ». C’est l’ensemble minimal pour reconstruire les rôles OS centraux — crucial pour AD DS, Certificate Services, et plus.
• VSS est une négociation. Le Requestor (l’outil de sauvegarde), les writers (applications), les providers (stockage) doivent s’entendre. Un writer défaillant peut torpiller la cohérence applicative.
• ReFS a changé les règles, puis à nouveau. Le clonage de blocs et les fonctions de résilience ont aidé certaines charges, mais la compatibilité et les comportements de sauvegarde ont évolué selon les versions.
• UEFI a rendu la récupération de démarrage plus stricte. Les layouts GPT, la partition système EFI et Secure Boot ajoutent des modes de défaillance que les admins de l’ère BIOS n’avaient pas à connaître.
• BitLocker est un multiplicateur de contraintes. C’est utile — jusqu’à ce que vous restauriez une machine et réalisiez que vous n’avez pas les clés de récupération accessibles pendant une panne.
• La déduplication peut être votre amie‑ennemie. Elle économise du stockage, mais augmente la complexité de restauration et peut amplifier la douleur des performances lors de grandes réhydratations.
• « Sauvegarde terminée avec succès » est un statut d’interface, pas une garantie. Les logs d’événements contiennent la vérité, y compris les éléments sautés et les avertissements des writers.

Paramètre n°1 : portée VSS et état des writers (ce que vous avez réellement sauvegardé)

VSS est la façon dont Windows prend un instantané pendant que le système fonctionne. Cela peut être magnifique : des instantanés application‑aware qui se coordonnent avec SQL Server, Hyper‑V et autres.

Ça peut aussi être du théâtre : un instantané qui semble correct jusqu’à ce que vous essayiez d’attacher une base, démarrer un service ou redémarrer un contrôleur de domaine AD et découvriez que la « sauvegarde » a conservé un point de corruption comme une pièce de musée.

Ce que signifie « portée » en pratique

La portée est la combinaison de :

• Quelles volumes sont inclus (C: seulement vs C: + volumes de données)
• Si System State / Bare Metal Recovery est inclus
• Si les writers applicatifs participent (SQLWriter, Hyper‑V VSS Writer, etc.)
• Ce qui est exclu (exclusions explicites, ou sauts implicites dus à des erreurs)

L’état des writers n’est pas optionnel

Lorsqu’un writer VSS est bloqué, échoué ou en timeout, les sauvegardes peuvent toujours « réussir » mais vous perdez la cohérence applicative. Pour certains services, c’est survivable. Pour d’autres, c’est un incident en mode ralenti.

Règle opérationnelle : Si vous tenez à la restauration, alertez sur les échecs des writers VSS, pas seulement sur les échecs de job de sauvegarde.

Blague n°1 (courte, pertinente) : Les sauvegardes sont comme les parachutes : la seule fois où vous en avez besoin est un terrible moment pour découvrir que vous avez acheté le modèle « décoratif ».

Une citation pour rester honnête

« L’espoir n’est pas une stratégie. » — idée paraphrasée souvent entendue en ingénierie/exploitation (utilisée ici comme principe de fiabilité)

Que faire et quoi éviter

• Faites vérifier les writers VSS sur chaque serveur protégé selon un calendrier.
• Faites des tests de restauration au niveau applicatif, pas seulement des restaurations de fichiers.
• Évitez de supposer qu’un « job réussi » équivaut à « données cohérentes ».
• Évitez d’empiler plusieurs technologies d’instantané/sauvegarde sur le même volume sans comprendre la sélection du provider (software vs hardware).

Paramètre n°2 : rétention et versioning (ce que vous avez conservé)

La rétention est l’endroit où la plupart des programmes de sauvegarde Windows vous trahissent discrètement. Pas par malveillance — plutôt comme un collègue qui archive la seule copie du tableur dont vous avez besoin parce que « c’était ancien ».

Il y a trois questions distinctes :

1. Combien de versions existent‑il ? (Vous voulez plusieurs points de restauration, pas un seul.)
2. Combien de temps existent‑elles ? (Vous voulez une couverture qui correspond au temps de détection des pannes et des attaques.)
3. Pouvez‑vous les retrouver ? (Intégrité du catalogue/index, santé de la destination de sauvegarde et métadonnées des jobs.)

Le piège de la rétention : « On garde 30 jours » (sauf quand ce n’est pas le cas)

Windows Server Backup sur un disque dédié utilise un mécanisme de versioning qui peut élaguer les sauvegardes plus anciennes selon l’espace disponible. Les outils tiers font de même quand le dépôt se remplit. Si vous avez dimensionné la cible pour « 30 jours » sans modéliser la croissance, vous pourriez garder « 30 jours sauf quand quelque chose d’intéressant arrive ».

Le ransomware a changé la conversation sur la rétention

Si un attaquant obtient des droits admin sur un serveur Windows, il peut souvent supprimer les sauvegardes locales, les shadow copies, et parfois même les sauvegardes distantes si les identifiants le permettent. La rétention n’a pas de sens sans immutabilité ou séparation d’accès.

Le versioning concerne aussi ce que vous pouvez remonter

L’historique de fichiers n’est pas une restauration système. Un snapshot VM n’est pas une sauvegarde applicative cohérente. Une image système n’est pas une récupération de fichiers granulaire. Vous avez besoin de restaurations en couches :

• Restauration rapide : restauration au niveau VM ou image pour la vitesse.
• Restauration granulaire : fichiers, répertoires, objets (AD), bases individuelles.
• Fenêtre forensique : versions suffisamment anciennes pour dépasser la corruption lente et la détection retardée.

Paramètre n°3 : récupérabilité bare‑metal (pouvez‑vous démarrer la machine restaurée)

La récupération bare‑metal est le moment où l’abstrait devient douloureusement physique : mode firmware, layout disque, drivers, chargeur de démarrage, BitLocker, et « pourquoi WinRE ne voit‑t‑il pas mon contrôleur RAID ? »

Ce que « bare metal » signifie vraiment

Au minimum, vous devez restaurer :

• Volumes OS
• Partitions de démarrage (EFI System Partition sur UEFI ; System Reserved sur BIOS/MBR)
• System State pour les serveurs à rôles lourds (AD DS, CA, etc.)
• Drivers nécessaires pour accéder au stockage et au réseau pendant la récupération

Mismatch UEFI/BIOS : un tueur classique de restauration

Restaurer une image basée MBR sur une VM uniquement UEFI (ou l’inverse) produit souvent « aucun périphérique de démarrage » ou des boucles. Certains outils gèrent la conversion ; beaucoup ne le font pas. Votre plan de DR doit spécifier la plateforme cible et le mode firmware.

BitLocker : génial jusqu’à ce que vous deviez restaurer rapidement

Si le volume OS est chiffré, la restauration nécessite des clés et parfois une séquence précise : suspendre la protection avant l’imagerie, assurer l’escalade des clés, confirmer le comportement du TPM en restauration virtualisée et vérifier que votre environnement de récupération peut déverrouiller les volumes.

Blague n°2 (courte, pertinente) : La seule chose plus permanente que les fichiers « temporaires » est une configuration de sauvegarde « rapide » faite en pleine panne.

Mode opératoire pour diagnostic rapide

Quand une restauration échoue, vous n’avez pas le temps d’admirer le message d’erreur. Vous avez besoin d’un chemin rapide vers le goulet d’étranglement — données, catalogue, démarrabilité ou cohérence applicative.

Première étape : confirmez que vous avez un point de restauration exploitable

1. Listez les sauvegardes disponibles et identifiez la bonne version pour la fenêtre d’incident.
2. Confirmez que la sauvegarde contient réellement les volumes/composants dont vous avez besoin (System State, partition EFI, volumes de données).
3. Validez la santé du dépôt/destination : peut‑on le lire à la vitesse attendue sans erreurs I/O ?

Deuxième étape : vérifiez les preuves VSS et de cohérence applicative

1. Recherchez les erreurs des writers VSS autour du temps de sauvegarde.
2. Vérifiez les logs applicatifs (SQL, AD, Hyper‑V) pour des signaux « recovery needed » que vous pouvez anticiper.
3. Décidez de restaurer crash‑consistent puis lancer la récupération applicative, ou de basculer vers un point connu‑bon plus ancien.

Troisième étape : validez le chemin de démarrage et l’environnement de récupération

1. Confirmez les attentes UEFI vs BIOS, GPT vs MBR.
2. Confirmez que WinRE voit le stockage (drivers chargés) et le réseau (si vous tirez depuis un partage distant).
3. Prévoyez le déverrouillage BitLocker et la disponibilité des clés.

Quatrième étape : mesurez le véritable goulet d’étranglement

Si la restauration est « bloquée », c’est généralement l’un des suivants : dépôt source lent, disque cible lent, surcharge CPU pour décompression/dédoublonnage, ou throttling réseau. Mesurez avant de deviner.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici des vérifications pratiques que vous pouvez exécuter sur Windows Server et dans WinRE. Chaque tâche inclut : commande, sortie d’exemple, ce que ça signifie et la décision à prendre. Exécutez‑les avant d’en avoir besoin, puis conservez les sorties dans vos notes DR.

Task 1: List VSS writers (health check)

cr0x@server:~$ vssadmin list writers
Writer name: 'SqlServerWriter'
   Writer Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
   State: [1] Stable
   Last error: No error

Writer name: 'System Writer'
   State: [5] Waiting for completion
   Last error: Retryable error

Sens : « Stable / No error » est bon. « Waiting », « Failed » ou « Retryable error » est un signal d’alerte — la cohérence applicative est à risque.

Décision : Si un writer critique n’est pas Stable, corrigez d’abord les writers (redémarrer les services dépendants de VSS, résoudre les timeouts, consulter les journaux d’événements) et relancez une sauvegarde. Ne faites pas confiance au job de ce soir.

Task 2: List VSS providers (software vs hardware)

cr0x@server:~$ vssadmin list providers
Provider name: 'Microsoft Software Shadow Copy provider 1.0'
   Provider type: Software
   Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5}
   Version: 1.0.0.7

Sens : Si vous voyez des providers hardware tiers, le comportement des snapshots peut différer (et les bugs devenir… créatifs).

Décision : Standardisez les providers par plateforme si possible ; documentez tout provider hardware et testez les restaurations à partir de celui‑ci.

Task 3: Check existing shadow storage configuration

cr0x@server:~$ vssadmin list shadowstorage
Shadow Copy Storage association
   For volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Shadow Copy Storage volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Used Shadow Copy Storage space: 1.2 GB (1%)
   Allocated Shadow Copy Storage space: 2.0 GB (2%)
   Maximum Shadow Copy Storage space: 3.0 GB (3%)

Sens : Une taille max de shadow storage trop petite peut provoquer des échecs de création ou un churn.

Décision : Si vous comptez sur les snapshots VSS locaux (y compris certains workflows de sauvegarde), augmentez la taille max ou déplacez‑la sur un volume différent — puis surveillez la croissance.

Task 4: Verify Windows Server Backup policy (when using wbadmin)

cr0x@server:~$ wbadmin get status
WBADMIN 1.0 - Backup command-line tool
The last backup operation completed successfully.
Backup time: 2/4/2026 1:00 AM
Backup target: 192.168.10.20\\backupshare
Version identifier: 02/04/2026-01:00
Can recover: Volume(s), File(s), Application(s), Bare Metal Recovery

Sens : « Can recover: Bare Metal Recovery » est ce que vous voulez pour accélérer la reconstruction. S’il est absent, vous n’avez probablement pas inclus les bons composants.

Décision : Si BMR n’est pas inclus pour les serveurs où la reconstruction compte, changez la sélection de sauvegarde et relancez immédiatement.

Task 5: List backups available on a target

cr0x@server:~$ wbadmin get versions -backuptarget:\\\\192.168.10.20\\backupshare
WBADMIN 1.0 - Backup command-line tool
Backup time: 2/1/2026 1:00 AM
Version identifier: 02/01/2026-01:00
Can recover: Volume(s), File(s), Application(s)

Backup time: 2/4/2026 1:00 AM
Version identifier: 02/04/2026-01:00
Can recover: Volume(s), File(s), Application(s), Bare Metal Recovery

Sens : Vous avez plusieurs versions. Certaines incluent BMR, d’autres non. Ce décalage est fréquent après des « petits » changements de configuration.

Décision : Choisissez la version qui correspond à l’objectif de restauration. Si seules quelques versions incluent BMR, corrigez la dérive de politique.

Task 6: Inspect what’s inside a backup version

cr0x@server:~$ wbadmin get items -version:02/04/2026-01:00 -backuptarget:\\\\192.168.10.20\\backupshare
WBADMIN 1.0 - Backup command-line tool
Items in backup:
- Bare Metal Recovery
- System State
- Volume(C:)
- Volume(D:)

Sens : Vous capturez à la fois les volumes OS et data, plus le System State. C’est favorable à la restauration.

Décision : Si un volume requis (comme un volume de données contenant des bases) est absent, arrêtez et relancez une sauvegarde correcte. Restaurer des éléments partiels est la voie vers des systèmes « restaurés mais cassés ».

Task 7: Check backup-related events quickly

cr0x@server:~$ wevtutil qe Microsoft-Windows-Backup/Operational /c:5 /rd:true /f:text
Event[0]:
  Level: Error
  Date: 2026-02-04T01:02:12.0000000Z
  Message: The backup operation that started at '2026-02-04T01:00:00' has failed because the Volume Shadow Copy Service operation failed.
Event[1]:
  Level: Warning
  Date: 2026-02-04T01:01:49.0000000Z
  Message: The backup operation completed but some files were skipped.

Sens : Les erreurs et les « fichiers sautés » sont là où la vérité réside.

Décision : Si vous voyez des échecs VSS ou des sauts, traitez la sauvegarde comme suspecte. Enquêtez sur VSS et les exclusions de chemins. N’attendez pas une restauration pour l’apprendre.

Task 8: Confirm WinRE sees disks (bare-metal recovery sanity)

cr0x@server:~$ diskpart
DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          200 GB    200 GB        *

Sens : WinRE voit le disque et il est GPT‑capable (colonne Gpt affiche *). S’il ne montre rien, il vous manque un driver de stockage.

Décision : Si les disques ne sont pas visibles, chargez les drivers (USB/ISO) ou changez le média de récupération pour un qui contient la pile de stockage appropriée.

Task 9: Validate partition layout for UEFI boot

cr0x@server:~$ diskpart
DISKPART> select disk 0
DISKPART> list part

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             100 MB  1024 KB
  Partition 2    Reserved            16 MB   101 MB
  Partition 3    Primary            199 GB   117 MB

Sens : Pour UEFI/GPT, vous attendez une partition EFI System (« System »), une MSR (« Reserved »), puis l’OS (« Primary »). L’absence de la partition EFI est un scénario courant de « restauré mais ne bootera pas ».

Décision : Si les partitions EFI/MSR sont manquantes après restauration, vous pourriez avoir besoin d’une vraie restauration BMR ou d’une réparation manuelle du démarrage.

Task 10: Repair boot configuration (when you’re already in the ditch)

cr0x@server:~$ bcdboot C:\Windows /f UEFI
Boot files successfully created.

Sens : Recréé les fichiers de démarrage pour UEFI. Pour BIOS, on utiliserait une approche différente, mais c’est une correction commune sur les restaurations UEFI.

Décision : Si vous avez une bonne restauration OS mais pas de démarrage, tentez une réparation du boot. Si ça échoue, réévaluez un mismatch de mode firmware.

Task 11: Check BitLocker status before backup and during restore planning

cr0x@server:~$ manage-bde -status
Volume C: [OS]
    Size:                 199.00 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On
    Lock Status:          Unlocked

Sens : Chiffrement complet, protection activée. Les restaurations peuvent nécessiter des clés selon les changements hardware/TPM.

Décision : Confirmez l’escalade des clés (AD DS, Azure AD ou votre coffre) et testez le déverrouillage dans les workflows de récupération.

Task 12: Validate network access to a remote backup share (WinRE or server)

cr0x@server:~$ net use Z: \\192.168.10.20\backupshare /user:backupreader S3cretPass!
The command completed successfully.

Sens : Vous pouvez vous authentifier et accéder au partage. Si cela échoue dans WinRE, vous pourriez avoir besoin de drivers NIC ou d’ajustements SMB.

Décision : Si vous ne pouvez pas accéder au dépôt durant la récupération, vous n’avez pas de plan de récupération — vous avez un plan basé sur l’espoir. Corrigez le réseau et la séparation des identifiants.

Task 13: Measure repository speed (restore bottleneck finder)

cr0x@server:~$ winsat disk -seq -read -drive Z
> Disk  Sequential 64.0 Read                   220.15 MB/s          8.2

Sens : Débit brut de lecture depuis la cible de sauvegarde. S’il est à 20–40 MB/s sur un partage réseau chargé, votre RTO est fantaisiste.

Décision : Si la vitesse est faible, changez le chemin de restauration : staging local, dépôt plus rapide, réseau dédié ou autre niveau.

Task 14: Confirm installed roles/features that influence restore strategy

cr0x@server:~$ dism /online /get-features /format:table | findstr /i "Hyper-V AD-Domain-Services"
Hyper-V                                              | Enabled
AD-Domain-Services                                    | Disabled

Sens : Connaître les rôles vous indique ce que « cohérent » signifie. Les hôtes Hyper‑V nécessitent des soins particuliers ; les DC ont besoin d’un plan de restauration autoritaire/normal.

Décision : Alignez la méthode de sauvegarde et testez les restaurations par rôle. Ne traitez pas tous les serveurs Windows comme des serveurs de fichiers génériques.

Task 15: Validate time and timezone consistency (quiet killer for logs and trust)

cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 2/4/2026 12:55:10 AM
Source: time.corp.local

Sens : L’heure est synchronisée. Pendant les restaurations, une dérive temporelle peut casser les jointures de domaine, Kerberos, la validation de certificats et la chronologie d’investigation.

Décision : Si l’heure est incorrecte, corrigez NTP avant de déclarer la restauration « cassée ». Elle peut être simplement temporellement confuse.

Trois mini‑histoires d’entreprise depuis les tranchées de la restauration

Mini‑histoire n°1 : L’incident causé par une mauvaise hypothèse

Ils avaient une flotte de serveurs de fichiers Windows et un serveur « spécial » qui exécutait une application métier avec un backend SQL. Le tableau de bord de sauvegarde était vert pendant des mois. La direction adorait le tableau de bord. La direction adore toujours les tableaux de bord.

Puis un cycle de patch a coïncidé avec un incident de stockage et le volume SQL est parti en vrille. Le plan de récupération était simple : restaurer la sauvegarde de la veille, remettre le service en ligne, retourner discuter budgets.

La restauration s’est terminée. SQL ne démarrera pas proprement. Il se plaignait de fichiers journaux manquants ou incohérents. L’équipe a supposé que la base en production était corrompue et que la restauration avait fidèlement reproduit cette corruption. Hypothèse raisonnable. Faute.

Ils ont creusé l’historique des sauvegardes et trouvé des avertissements récurrents sur le writer SQLWriter. Le produit de sauvegarde continuait d’afficher les jobs « réussis » parce que la copie au niveau fichier avait réussi ; elle n’était simplement pas cohérente applicativement. Leur hypothèse était que « réussi » voulait dire « restaurable pour l’application ». Ce n’était pas le cas.

Le correctif n’était pas glamour : stabiliser VSS, augmenter le timeout, retirer un ancien agent ayant installé un provider VSS en conflit, puis tester les restaurations en attachant réellement la base dans un sandbox. Après cela, le tableau de bord est devenu moins vert. Il est aussi devenu honnête.

Mini‑histoire n°2 : L’optimisation qui s’est retournée contre eux

Une autre société voulait réduire les coûts de stockage de sauvegarde. Ils ont activé une déduplication et une compression agressives sur le dépôt, puis resserré la rétention parce que « nous n’avons besoin que de deux semaines ». Ils ont aussi déplacé les sauvegardes sur une baie NAS partagée déjà sollicitée par une douzaine d’autres jobs.

Les sauvegardes ont tourné. Les tests de restauration sur petits fichiers semblaient OK. Tout le monde s’est félicité. C’est souvent le signe que le danger approche.

Puis ils ont dû restaurer un gros serveur applicatif hébergé en VM pendant une clôture trimestrielle. Le débit de restauration s’est effondré. Le dépôt était CPU‑bound pour réhydrater les blocs dédupliqués, le NAS se battait avec d’autres charges, et le chemin réseau n’était pas isolé. La fenêtre de restauration est passée d’heures à « peut‑être demain ».

L’optimisation n’était pas mauvaise en soi. L’erreur a été de supposer que l’efficacité de sauvegarde et les performances de restauration sont la même métrique. Elles ne le sont pas. Les économies de stockage se sont transformées en explosion de coûts liés à l’indisponibilité.

La correction a été de tiercer : garder une fenêtre courte de sauvegardes « restauration rapide » sur un stockage performant (ou un objet immuable avec débit suffisant), puis déplacer les versions plus anciennes vers une capacité moins chère. Ils ont aussi commencé à mesurer le débit de restauration comme SLO de première classe.

Mini‑histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

La troisième organisation avait une politique que personne n’aimait : des drills trimestriels de restauration bare‑metal pour un serveur représentatif par rôle majeur. Pas un exercice de table. Une vraie restauration dans un VLAN isolé avec chronomètre et checklist.

Ça impliquait que quelqu’un maintienne un média WinRE avec drivers stockage et NIC. Que quelqu’un suive les réglages UEFI. Que quelqu’un stocke les clés de récupération BitLocker quelque part accessible même si AD était hors service. Tout cela est profondément peu sexy.

Puis un incident électrique plus une défaillance de contrôleur ont mis hors service un hôte de virtualisation primaire et corrompu quelques disques invités. Ils avaient des sauvegardes. Ce n’était pas la partie intéressante. L’important, c’est qu’ils avaient aussi un processus de restauration UEFI connu‑bon, y compris un chemin testé pour réparation de boot et injection de drivers si nécessaire.

Ils ont restauré d’abord les services d’identité, puis la couche applicative, puis le reste. L’impact business n’a pas été nul, mais est resté dans le domaine du « mauvaise journée » plutôt que « événement de carrière ». La pratique ennuyeuse n’a pas empêché la panne. Elle a empêché la panique.

Erreurs courantes : symptôme → cause → correction

1) « La sauvegarde a réussi » mais l’app ne démarre pas après restauration

Symptôme : La restauration se termine ; SQL/Exchange/autres services signalent des erreurs de récupération, journaux manquants ou état incohérent.

Cause racine : Échecs des writers VSS ou sauvegarde uniquement crash‑consistent ; la cohérence applicative n’a pas été atteinte.

Correction : Validez les writers VSS (vssadmin list writers), corrigez les writers en échec, relancez la sauvegarde ; effectuez un test de restauration au niveau applicatif (monter/attacher la base, démarrer les services en labo).

2) La restauration bare‑metal ne trouve aucun disque

Symptôme : WinRE n’affiche aucun disque ; l’assistant de restauration ne peut pas sélectionner de cible.

Cause racine : Drivers du contrôleur de stockage manquants dans l’environnement de récupération ; parfois drivers RAID/HBA, parfois drivers de stockage virtualisé.

Correction : Chargez les drivers dans WinRE ; maintenez un média de récupération à jour ; standardisez les contrôleurs si possible.

3) Machine restaurée ne démarre pas (« no boot device »)

Symptôme : La restauration se termine, puis le démarrage échoue immédiatement.

Cause racine : Partitions EFI/System non restaurées ; mismatch de mode firmware (UEFI vs BIOS) ; BCD mal configuré.

Correction : Confirmez le layout de partition avec diskpart ; corrigez le mode firmware ; exécutez bcdboot C:\Windows /f UEFI (ou équivalent BIOS) après avoir vérifié que la partition EFI existe.

4) Vous ne trouvez pas le bon point de restauration

Symptôme : Le dépôt contient des sauvegardes, mais l’outil liste moins de versions que prévu, ou le catalogue est manquant.

Cause racine : Rétention ayant élagué d’anciennes versions par manque d’espace ; corruption du catalogue ; chemin du dépôt changé ; permissions modifiées.

Correction : Augmentez la capacité du dépôt, appliquez une politique de rétention avec surveillance ; protégez les métadonnées du catalogue ; vérifiez périodiquement la sortie de wbadmin get versions et alertez sur toute chute inattendue.

5) Les restaurations sont douloureusement lentes

Symptôme : L’ETA de restauration augmente ; le débit est incohérent ; le réseau « a l’air OK ».

Cause racine : Conflit sur le dépôt, limites CPU pour la réhydratation déduplication, throttling SMB, antivirus scannant les flux de restauration, ou goulot disque cible.

Correction : Mesurez le débit (winsat, compteurs perf), excluez les chemins de restauration de l’AV pendant le DR, utilisez des réseaux dédiés, effectuez du staging local ou conservez des copies « restauration rapide ».

6) La restauration d’un contrôleur de domaine casse l’authentification

Symptôme : Après restauration, les clients ne peuvent pas s’authentifier ; erreurs de réplication ; risque d’objets persistants.

Cause racine : Mauvais type de restauration (authoritative vs non‑authoritative), restauration trop ancienne, ou gestion incohérente du System State.

Correction : Utilisez des sauvegardes System State appropriées ; définissez un runbook de restauration DC ; testez en isolation ; assurez la synchronisation temporelle et la planification FSMO.

7) BitLocker bloque l’accès après restauration

Symptôme : Le volume demande la clé de récupération ; l’OS ne démarre pas sans elle.

Cause racine : État TPM changé (nouveau matériel/VM), différences Secure Boot, ou escrow des clés manquant/incorrect.

Correction : Assurez‑vous que l’escalade des clés est accessible lors d’une panne ; documentez les étapes de déverrouillage ; testez la restauration sur une nouvelle VM avec BitLocker activé.

Listes de contrôle / plan étape par étape

Checklist A: Configurez les sauvegardes pour que les restaurations soient plausibles

1. Décidez des objectifs de restauration par rôle de serveur. Serveur de fichiers, serveur SQL, contrôleur de domaine, hôte Hyper‑V, etc. Différentes règles.
2. Activez et vérifiez les sauvegardes application‑consistantes. Les writers VSS doivent être Stable ; confirmez l’intégration spécifique aux applications quand c’est nécessaire.
3. Incluez les bons composants. Pour les serveurs critiques : Bare Metal Recovery + System State + tous les volumes pertinents.
4. Séparez les identifiants et l’accès. Les identifiants d’écriture du dépôt de sauvegarde ne doivent pas être les mêmes que les identifiants d’administration quotidienne.
5. Implémentez une rétention qui correspond au temps de détection. Si vous détectez typiquement des problèmes en 10–20 jours, deux semaines de rétention vous pénalisent.
6. Concevez un niveau de restauration rapide. Gardez au moins quelques points de restauration sur un stockage capable d’un débit soutenu.
7. Préparez pour l’immutabilité ou la résistance à la suppression. Au minimum : séparation d’accès ; idéalement : fonctionnalités de stockage immuable.
8. Documentez les attentes firmware et layout disque. UEFI vs BIOS, GPT vs MBR, réglages Secure Boot.
9. Gérez BitLocker délibérément. Escalade des clés, processus de récupération et comportement testé lors d’une restauration sur nouveau matériel/VM.
10. Planifiez des drills de restauration. Trimestriels est un bon départ ; après des changements majeurs, faites-en un supplémentaire.

Checklist B: Le runbook de restauration à suivre en incident

1. Identifiez la fenêtre d’incident. Quand la corruption/attaque a‑t‑elle commencé ? Choisissez le point de restauration en conséquence.
2. Listez les versions disponibles. Confirmez avec wbadmin get versions (ou l’équivalent de votre outil).
3. Confirmez le contenu de la version sélectionnée. Volumes, System State, BMR.
4. Vérifiez l’accès au dépôt. Les identifiants fonctionnent, le partage est atteignable, les performances sont acceptables.
5. Restaurez dans le bon ordre. Services d’identité d’abord (AD DS, DNS), puis stockage/BD, puis couche applicative.
6. Validez la démarrabilité. UEFI/BIOS, visibilité des disques, layout des partitions.
7. Validez la santé applicative. Pas « service démarré », mais vérifications fonctionnelles réelles (requêtes, connexions, workflows).
8. Collectez des preuves. Logs, horodatages, versions utilisées — pour améliorer le processus, pas le répéter.

Checklist C: Vérification continue (la partie que personne ne planifie)

1. Hebdomadaire : vérifications échantillons des writers VSS sur serveurs critiques ; alerte sur états non‑Stable.
2. Hebdomadaire : vérifiez que le nombre de versions de sauvegarde n’a pas chuté de façon inattendue (problème de rétention/capacité).
3. Mensuel : mesure du débit de restauration depuis le dépôt vers une cible de test.
4. Trimestriel : drill de restauration bare‑metal pour rôles représentatifs.
5. Après changements majeurs : nouveaux drivers stockage, mises à jour firmware, upgrades hyperviseur — relancez le drill de restauration.

FAQ

1) Windows Server Backup est‑il suffisant en production ?

Parfois. Il est fiable pour des charges plus simples si vous configurez correctement BMR/System State et testez réellement les restaurations. Pour des applications complexes et des parcs plus étendus, des outils centralisés avec meilleur reporting et immutabilité gagnent souvent.

2) Quelle est la différence entre crash‑consistent et application‑consistent ?

Crash‑consistent, c’est comme débrancher un cordon d’alimentation et imager le disque. Application‑consistent se coordonne avec l’application (via les writers VSS) pour que les bases flushent et que les journaux s’alignent. Crash‑consistent peut restaurer ; il peut juste nécessiter des étapes de récupération applicative ou échouer selon la charge.

3) Pourquoi les writers VSS échouent‑ils si souvent ?

Parce qu’ils dépendent de la santé de l’app, du timing et parfois d’enregistrements COM obsolètes. Déclencheurs fréquents : timeouts, systèmes surchargés, mises à jour cassées, agents tiers défaillants et conflits de providers.

4) Dois‑je sauvegarder System State sur chaque serveur ?

Pas nécessairement. Mais sur les serveurs à rôles lourds (contrôleurs de domaine, CAs, certains rôles en cluster), System State est central pour une récupération propre. Sur des serveurs applicatifs génériques sans état, c’est moins critique si vous pouvez reconstruire via l’automatisation.

5) Combien de points de restauration dois‑je conserver ?

Assez pour dépasser votre temps de détection. Si vous remarquez typiquement des problèmes après 3–4 semaines, garder 14 jours revient à se saborder. Conservez aussi au moins un point mensuel « golden » pour les corruptions lentes.

6) Puis‑je me fier aux shadow copies (Versions précédentes) comme sauvegarde ?

Non. Les shadow copies sont une fonctionnalité de commodité et peuvent être supprimées par des admins, des ransomwares ou la pression d’espace. Elles sont utiles en couche, pas comme seul mécanisme de récupération.

7) Qu’est‑ce qui casse le plus la restauration bare‑metal ?

Les drivers manquants dans WinRE, le mismatch de mode firmware et les partitions EFI/System manquantes. Ensuite : disponibilité des clés BitLocker et accès réseau au dépôt.

8) Quel est le test de restauration minimal qui prouve réellement quelque chose ?

Restaurer dans un environnement isolé, démarrer et effectuer une validation applicative (connexion, exécution d’une requête, ouverture de l’application, vérification des workflows critiques). Les seuls tests de restauration de fichiers prouvent très peu.

9) Ai‑je besoin de paramètres de sauvegarde différents pour les hôtes Hyper‑V ?

Oui. Hyper‑V a son propre comportement de writer VSS et coordination des invités. Vous devez décider si vous protégez au niveau hôte, invité, ou les deux — et tester les restaurations en conséquence pour éviter des états VM incohérents.

10) Comment empêcher les ransomwares de supprimer les sauvegardes ?

Commencez par la séparation d’accès : identifiants d’écriture de dépôt non utilisables pour l’administration interactive, permissions du dépôt verrouillées. Ajoutez l’immutabilité quand c’est possible, et surveillez les événements de suppression et les anomalies de rétention.

Conclusion : prochaines étapes réalistes

Si vous ne retenez rien d’autre : arrêtez de faire confiance au mot « réussi » à moins de pouvoir démontrer une restauration. Les échecs de sauvegarde Windows sont rarement mystérieux. Ils résultent généralement de trois paramètres qui dérivent discrètement : cohérence VSS, réalité de la rétention/versioning et démarrabilité bare‑metal.

Faites ceci dans les 72 heures

1. Choisissez vos 5 serveurs Windows critiques et exécutez vssadmin list writers. Corrigez tout ce qui n’est pas Stable.
2. Exécutez wbadmin get versions (ou l’équivalent de votre outil) et confirmez que vous avez plusieurs points de restauration utilisables, incluant au moins un point plus ancien que votre temps de détection typique.
3. Effectuez un drill de restauration réel dans un réseau isolé : restaurez, démarrez, validez l’application. Chronométrez‑le.

Faites ceci au cours du trimestre

1. Standardisez le mode firmware (UEFI préféré) et documentez‑le dans vos notes DR.
2. Créez et maintenez un média de récupération avec drivers NIC et stockage validés.
3. Créez un plan de rétention à deux niveaux : copies restauration rapide + fenêtre forensique plus longue, avec séparation d’accès.
4. Faites du test de restauration une routine, pas une histoire de héros.

Les systèmes de production ne récompensent pas l’optimisme. Ils récompensent des chemins de récupération répétés et mesurables. Configurez ces trois paramètres comme si vous prévoyiez de perdre le serveur — parce qu’un jour, vous le perdrez.