Comment vérifier que votre sauvegarde se restaure réellement (sans tout effacer sur le PC)

La restaurabilité est le résultat, pas « avoir des sauvegardes »

Les sauvegardes sont un moyen. La restauration est le résultat. Si vous ne pouvez pas restaurer de manière fiable, vous n’avez pas des sauvegardes—vous avez du stockage.

Le piège est que « restaurer » n’est pas une seule chose. Une restauration peut signifier :

• Restauration de fichier : « Rends-moi taxes-2024.pdf. »
• Restauration d’application : « Remets la base de données à 09:14 avant la migration. »
• Restauration système : « Le PC doit démarrer et être utilisable. »
• Reprise après sinistre : « L’activité redémarre : identité, applications, données, réseau, identifiants. »

La vérification doit correspondre à ce que vous affirmez pouvoir faire. Si votre plan est « Je peux réinstaller l’OS et restaurer les fichiers », alors vérifiez les restaurations de fichiers. Si votre plan est « Je peux restaurer une image bare-metal », alors vérifiez la capacité de démarrage. Tout le reste est du théâtre.

Et oui, vous pouvez vérifier des restaurations sans effacer la machine. Les techniques principales sont :

• Montages en lecture seule d’images de sauvegarde ou de snapshots
• Restaurations tests dans un répertoire de quarantaine
• Tests de démarrage en VM en utilisant une image de disque restaurée
• Vérification de sommes de contrôle et intégrité des dépôts
• Exercices de restauration avec étapes documentées et mesures de temps

Une citation à garder sous les yeux :

« L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Blague #1 : Les sauvegardes sont comme des parachutes—si vous ne les testez qu’après avoir sauté, vous jouez en mode difficile.

Faits et histoire : pourquoi la vérification des sauvegardes est difficile

Un peu de contexte aide, car beaucoup de modes de défaillance des sauvegardes héritent de décennies de « ça marche généralement ». Voici des faits concrets qui expliquent le bazar actuel :

1. Les premiers workflows sur bande ont normalisé le « écrire une fois, espérer plus tard ».  Vérifier chaque bande était lent et usait le média ; beaucoup de sites vérifiaient seulement les en-têtes ou des échantillons aléatoires.
2. Le terme « fenêtre de sauvegarde » vient des jobs nocturnes sur bande.  Il a orienté la conception logicielle vers « finir avant le matin », pas « restaurer vite en cas de panique ».
3. RAID a réduit le temps d’indisponibilité mais créé une fausse confiance.  Les gens ont commencé à traiter la redondance comme une sauvegarde, puis ont découvert que la corruption, le ransomware et l’erreur humaine se moquent de la parité.
4. Les sommes de contrôle dans les systèmes de fichiers (ex. ZFS) ont changé les attentes.  Elles détectent la corruption, mais ne valident pas magiquement votre capacité à restaurer une application de manière cohérente.
5. Les chaînes incrémentales peuvent être fragiles.  Perdez un maillon ou un index de catalogue, et « sauvegarde réussie » devient « archéologie créative ».
6. « Air-gapped » était littéral autrefois.  Désormais c’est souvent logique (immutable/object-lock), car la séparation physique coûte cher et est pénible opérationnellement.
7. Le ransomware a déplacé le mode de défaillance de « disque mort » à « tout est chiffré, y compris les sauvegardes réseau ».  La vérification inclut maintenant : pouvez-vous restaurer des données propres, rapidement, hors ligne ?
8. La déduplication a rendu les restaurations non évidentes.  Les données peuvent n’exister qu’en chunks référencés par des métadonnées ; perdre les métadonnées peut être fatal même si les disques semblent pleins.
9. Le stockage cloud a rendu la durabilité bon marché mais les restaurations potentiellement lentes.  Les coûts d’egress, le throttling et les délais de « rehydration » deviennent du temps d’indisponibilité réel si on ne les teste pas.

Le motif : la technologie de sauvegarde évolue, mais l’habitude humaine persiste—les gens mesurent le succès par la fin du job, pas par la capacité à restaurer sous contrainte.

Décidez ce que vous vérifiez : fichiers, images système ou reprise complète

Avant de toucher une ligne de commande, décidez la promesse que vous voulez pouvoir tenir. Choisissez une « promesse de restauration » principale et une secondaire. Sinon vous ferez une série de vérifications qui auront l’air productives et ne prouveront rien.

1) Sauvegardes au niveau fichier (la plupart des gens devraient commencer ici)

Outils typiques : snapshots basés sur rsync, Borg, Restic, Time Machine, Windows File History. La vérification signifie :

• Les contrôles d’intégrité du dépôt réussissent
• Vous pouvez lister les snapshots/versions
• Vous pouvez restaurer un échantillon aléatoire de fichiers
• Les permissions, timestamps et symlinks semblent corrects
• Pour les données critiques : vous pouvez restaurer l’arbre complet vers un nouvel emplacement et comparer les hachages

2) Sauvegardes basées image (style bare-metal)

Outils typiques : agents Veeam, Macrium, Clonezilla, Windows System Image Backup (legacy), certains outils OEM. La vérification signifie :

• L’image est lisible et montable (lecture seule)
• Vous pouvez en extraire des fichiers
• Vous pouvez la démarrer dans une VM (meilleure preuve non destructive)
• Vous avez géré les pilotes/bootloader (UEFI vs BIOS)

3) Sauvegardes cohérentes applicatives

Si vous exécutez des bases de données, serveurs mail ou tout service avec état, les copies au niveau fichier sont souvent des « sauvegardes » de la même manière qu’une photo d’un moteur en marche est « un moteur de rechange ». Il vous faut quiescing, snapshots, WAL logs ou dumps natifs de l’app. La vérification signifie :

• Vous pouvez restaurer sur une instance de test
• Le service démarre
• Les contrôles de base passent (version de schéma, compteurs de lignes, replay des logs)

4) Modèle de menace : corruption, ransomware et « oups »

Votre plan de vérification doit couvrir explicitement :

• Corruption média : bit rot, disques instables, bizarreries de contrôleur
• Corruption logique : mauvaises écritures, applis boguées, troncature silencieuse
• Modifications malveillantes : ransomware, wipers, compromission d’identifiants
• Erreur humaine : suppression, écrasements, synchronisation de mauvais dossier

Si vous ne vérifiez que « quelques octets sont lisibles », vous restez exposé aux pires catastrophes : restaurer la mauvaise version, restaurer des données chiffrées, ou restaurer une sauvegarde qui n’a jamais capturé ce que vous pensiez.

Mode d’emploi de diagnostic rapide : trouver le goulot en minutes

Vous faites une restauration test et c’est lent, ça échoue ou c’est étrange. Ne vous égarez pas. Vérifiez dans cet ordre—premier/deuxième/troisième—parce que chaque étape élimine rapidement une grande classe de problèmes.

Premier : le catalogue/dépôt de sauvegarde est-il sain ?

• Exécutez la vérification d’intégrité de l’outil (Borg/Restic/etc.).
• Recherchez des packs manquants, des index endommagés, des échecs d’authentification ou des bizarreries de « prune ».
• Si le dépôt n’est pas sain, arrêtez-vous. Réparez cela avant d’optimiser les performances.

Deuxième : la cible de restauration et le système de fichiers se comportent-ils bien ?

• Confirmez l’espace libre, la disponibilité des inodes et les permissions en écriture.
• Testez le débit d’écriture brut avec un fichier temporaire (puis supprimez-le).
• Vérifiez la présence d’un antivirus/protection endpoint qui scanne en temps réel le répertoire de restauration.

Troisième : le transport est-il lent ou instable ?

• Pour les restaurations réseau : vérifiez la perte de paquets, les options de montage SMB/NFS, l’overhead VPN.
• Pour le cloud/objet : vérifiez le throttling, les identifiants, et si vous récupérez depuis un stockage froid.
• Mesurez avec la restauration d’un seul gros fichier, pas un répertoire avec 400k petits fichiers.

Quatrième : êtes-vous limité par les métadonnées ou les petits fichiers ?

• Des millions de fichiers puniront la latence et les filtres antivirus.
• Les restaurations dédupliquées peuvent être liées au CPU (décompression/déchiffrement) ou à l’I/O (lectures aléatoires).
• Essayez de restaurer un sous-ensemble pour voir si le temps évolue linéairement ou explose.

Cinquième : restaurez-vous la bonne chose ?

• Confirmez le timestamp, le nom du snapshot et la sélection de version.
• Cherchez des signes de ransomware : extensions de fichiers, entropie, « README_RESTORE_FILES ».
• Vérifiez que les fichiers canaris connus s’ouvrent correctement.

Tâches pratiques de vérification de restauration (commandes, sorties, décisions)

Ci‑dessous se trouvent des tâches pratiques que vous pouvez exécuter sur une station Linux ou un serveur. Même si vous êtes sous Windows ou macOS, les idées se transposent : lister les sauvegardes, vérifier le dépôt, monter en lecture seule, restaurer dans un bac à sable, comparer des sommes de contrôle et faire un test de démarrage en VM.

Chaque tâche inclut : une commande, ce que la sortie signifie et la décision suivante. Ce ne sont pas des « démos mignonnes ». Ce sont les mêmes mouvements que j’utilise quand quelqu’un jure que les sauvegardes vont bien et que j’ai besoin de preuves avant de parier le week-end là-dessus.

Task 1: Confirm you’re testing the right backup source

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
NAME   SIZE FSTYPE MOUNTPOINTS MODEL            SERIAL
sda    1.8T        /           Samsung_SSD_870   S6PUNX0T123456
sdb    3.6T ext4   /mnt/backup  WDC_WD40EFRX     WD-WCC4E7ABCDEF

Ce que cela signifie : Vous voyez quel disque est le disque de sauvegarde (/mnt/backup) et confirmez que vous n’allez pas tester par erreur le disque racine actif.

Décision : Si la cible de sauvegarde n’est pas clairement identifiable, étiquetez-la maintenant (label du système de fichiers, unité de montage, étiquette physique). L’ambiguïté est la manière dont les restaurations deviennent des incidents.

Task 2: Check free space and inode headroom on the restore target

cr0x@server:~$ df -h /restore-sandbox
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc1       500G  120G  355G  26% /restore-sandbox

cr0x@server:~$ df -i /restore-sandbox
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/sdc1      32768000 2100000 30668000    7% /restore-sandbox

Ce que cela signifie : L’espace est suffisant et vous avez beaucoup d’inodes. Manquer d’inodes ressemble à « No space left on device » même quand df -h est content.

Décision : Si l’utilisation des inodes est élevée, restaurez sur un système de fichiers formaté pour un grand nombre d’inodes, ou changez votre approche de vérification (restaurez moins de petits fichiers, ou archivez-les d’abord).

Task 3: Validate a Borg repository (integrity before performance)

cr0x@server:~$ export BORG_REPO=/mnt/backup/borg/laptop
cr0x@server:~$ borg check --verify-data
Starting full repository check
Verifying data integrity
Repository check complete, no problems found.

Ce que cela signifie : La structure du dépôt et les chunks de données correspondent aux hachages attendus. C’est le moyen le plus rapide de détecter « ça a l’air monté, mais c’est corrompu ».

Décision : Si cela échoue, arrêtez-vous. Clonez le dépôt avant de faire quoi que ce soit d’autre. Les réparations peuvent être destructrices. Votre travail est de préserver les preuves et les options.

Task 4: List snapshots/archives and confirm retention is real

cr0x@server:~$ borg list --short
laptop-2026-01-10T020001
laptop-2026-01-17T020001
laptop-2026-01-24T020001
laptop-2026-01-31T020001

Ce que cela signifie : Vous avez plusieurs points de restauration. Si la liste est plus courte que prévu, les politiques de rétention/prune peuvent grignoter l’historique.

Décision : Si vous n’avez qu’un seul snapshot, vous n’avez pas des « sauvegardes », vous avez un point de défaillance unique mieux marketé.

Task 5: Do a small, surgical test restore to a sandbox

cr0x@server:~$ mkdir -p /restore-sandbox/test1
cr0x@server:~$ borg extract --progress --destination /restore-sandbox/test1 ::laptop-2026-01-31T020001 home/alex/Documents/taxes-2025.pdf
0.01 GB O 0.05 GB C 1 files restored

Ce que cela signifie : L’outil peut concrétiser des données. Cela prouve plus que n’importe quel email vert « backup succeeded ».

Décision : Si cela échoue, capturez l’erreur et identifiez si c’est un problème de permissions, de chunks manquants ou de mauvais chemin. Ne concluez pas « la sauvegarde est mauvaise » tant que vous n’avez pas confirmé que vous restauriez le bon chemin et l’archive correcte.

Task 6: Verify the restored file is not obviously corrupted

cr0x@server:~$ file /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
/restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf: PDF document, version 1.7

cr0x@server:~$ sha256sum /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
5ef2bf9a9c3c6d1a0c7b1c0e8b0a5d2d3b2c1f1a9e0d6c5b4a3f2e1d0c9b  /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf

Ce que cela signifie : La signature de fichier est plausible. La somme de contrôle vous donne une identité stable pour des comparaisons ultérieures.

Décision : Si file dit « data » ou « ASCII text » pour quelque chose qui devrait être un PDF ou un JPEG, suspectez des sauvegardes chiffrées par ransomware ou des restaurations tronquées.

Task 7: Spot-check metadata (ownership, permissions, timestamps)

cr0x@server:~$ stat /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
  File: /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
  Size: 248112     Blocks: 488        IO Block: 4096   regular file
Device: 8,33   Inode: 131089      Links: 1
Access: (0640/-rw-r-----)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2026-01-31 02:14:03.000000000 +0000
Modify: 2026-01-29 18:51:22.000000000 +0000
Change: 2026-01-31 02:14:03.000000000 +0000

Ce que cela signifie : Les permissions et la propriété sont préservées. Pour certaines restaurations (partages Windows ou NAS), c’est là que ça casse silencieusement.

Décision : Si la propriété devient root ou les permissions deviennent 777, votre restauration peut « fonctionner » mais vos applications échoueront. Corrigez les options de l’outil de sauvegarde, les options de montage ou la gestion des ACL.

Task 8: Restic repository check + selective restore

cr0x@server:~$ export RESTIC_REPOSITORY=/mnt/backup/restic/workstation
cr0x@server:~$ restic check
using repository at /mnt/backup/restic/workstation
created new cache in /home/cr0x/.cache/restic
load indexes
check all packs
check snapshots, trees and blobs
no errors were found

cr0x@server:~$ mkdir -p /restore-sandbox/restic-test
cr0x@server:~$ restic restore latest --target /restore-sandbox/restic-test --include "/home/alex/.ssh/config"
restoring  to /restore-sandbox/restic-test
Summary: Restored 1 files/dirs (1 B) in 0:00

Ce que cela signifie : Le check d’intégrité passe et vous pouvez restaurer un fichier sensible connu. Le config SSH est un bon canari car les permissions comptent et on remarque quand c’est faux.

Décision : Si restic check est propre mais que la restauration échoue, suspectez les permissions du système de fichiers cible ou un décalage de chemin dû aux règles include/exclude.

Task 9: Verify rsync snapshot backups by comparing a random sample

cr0x@server:~$ ls -1 /mnt/backup/snapshots | tail -5
2026-01-10
2026-01-17
2026-01-24
2026-01-31

cr0x@server:~$ find /mnt/backup/snapshots/2026-01-31/home/alex -type f | shuf -n 5
/mnt/backup/snapshots/2026-01-31/home/alex/Documents/taxes-2025.pdf
/mnt/backup/snapshots/2026-01-31/home/alex/Pictures/IMG_1882.jpg
/mnt/backup/snapshots/2026-01-31/home/alex/.ssh/config
/mnt/backup/snapshots/2026-01-31/home/alex/Projects/app/README.md
/mnt/backup/snapshots/2026-01-31/home/alex/Notes/meetings.txt

cr0x@server:~$ rsync -nac --delete /mnt/backup/snapshots/2026-01-31/home/alex/ /home/alex/ | head -20
sending incremental file list
.d..t...... ./
>fc........ Documents/taxes-2025.pdf
>fc........ Pictures/IMG_1882.jpg

sent 5,024 bytes  received 412 bytes  10,872.00 bytes/sec
total size is 148,801,932  speedup is 27,374.58 (DRY RUN)

Ce que cela signifie : -n fait une simulation ; -c compare les sommes de contrôle ; les lignes commençant par > indiquent des différences de contenu. Cela peut vouloir dire que vos fichiers live ont changé après le snapshot (normal) ou que le snapshot n’est pas ce que vous croyez.

Décision : Si vous voyez des différences sur des fichiers qui devraient être stables (photos anciennes, PDF archivés), enquêtez. Vous pourriez avoir une corruption silencieuse, un outil de sync qui réécrit des fichiers, ou un mauvais chemin de snapshot.

Task 10: Mount a disk image read-only and browse it (no risky restore)

cr0x@server:~$ sudo mkdir -p /mnt/image
cr0x@server:~$ sudo losetup --find --partscan --read-only /mnt/backup/images/laptop-2026-01-31.img
/dev/loop7
cr0x@server:~$ lsblk /dev/loop7
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop7       7:7    0  238G  1 loop
├─loop7p1 259:0    0  512M  1 part
└─loop7p2 259:1    0  237G  1 part

cr0x@server:~$ sudo mount -o ro,noload /dev/loop7p2 /mnt/image
cr0x@server:~$ ls /mnt/image
bin  boot  etc  home  lib  opt  root  usr  var

Ce que cela signifie : Vous avez prouvé que l’image est lisible structurellement et contient un agencement de système de fichiers plausible. ro et noload réduisent le risque de modifier des systèmes de fichiers journalisés pendant un test.

Décision : Si l’analyse des partitions ne montre rien, suspectez une image corrompue, un mauvais type d’image, ou un chiffrement oublié. Si le montage échoue, vous pouvez peut‑être encore extraire via des outils forensiques, mais votre plan de « restauration simple » est déjà compromis.

Task 11: Confirm the restored system image has a bootloader configuration (quick sanity)

cr0x@server:~$ sudo test -e /mnt/image/boot/grub/grub.cfg && echo "grub.cfg present" || echo "grub.cfg missing"
grub.cfg present

cr0x@server:~$ sudo test -d /mnt/image/boot/efi && echo "EFI directory present" || echo "EFI directory missing"
EFI directory present

Ce que cela signifie : Vous cherchez des ingrédients de démarrage évidents. Pas définitif, mais cela attrape les erreurs du type « l’image n’a capturé que /home ».

Décision : Si ceux-ci manquent alors que vous attendiez une image bootable, revoyez ce que votre outil d’imagerie a réellement inclus. « Sauvegarde système » signifie parfois « certaines partitions », ce qui est une manière polie de dire « surprise ».

Task 12: Boot-test a restored image in a VM (best proof without wiping)

cr0x@server:~$ qemu-system-x86_64 -m 4096 -enable-kvm -drive file=/mnt/backup/images/laptop-2026-01-31.img,format=raw,if=virtio -boot c -net nic -net user
SeaBIOS (version 1.16.3)
Booting from Hard Disk...
[    0.000000] Linux version 6.5.0 ...
Reached target Graphical Interface.

Ce que cela signifie : C’est la preuve non destructive ultime pour les images : elle boot. Vous avez prouvé « je peux restaurer une machine » sans toucher au vrai PC.

Décision : Si ça ne démarre pas, capturez la sortie console. Coupables courants : mismatch UEFI vs BIOS, initramfs manquant de pilotes pour virtio, root chiffré sans gestion de clé, ou bootloader installé au mauvais endroit.

Task 13: ZFS snapshot verification with scrub + spot restore

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:18:22 with 0 errors on Sun Feb  2 03:20:41 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          sda       ONLINE       0     0     0
          sdb       ONLINE       0     0     0

errors: No known data errors

cr0x@server:~$ zfs list -t snapshot -o name,creation | tail -3
tank/home@2026-01-24  Sun Jan 24 02:00 2026
tank/home@2026-01-31  Sun Jan 31 02:00 2026
tank/home@2026-02-02  Sun Feb  2 02:00 2026

cr0x@server:~$ mkdir -p /restore-sandbox/zfs-test
cr0x@server:~$ zfs clone tank/home@2026-01-31 tank/home-restore-test
cr0x@server:~$ zfs set mountpoint=/restore-sandbox/zfs-test tank/home-restore-test
cr0x@server:~$ ls /restore-sandbox/zfs-test/alex/Documents | head
invoices
taxes-2025.pdf

Ce que cela signifie : Scrub vérifie les sommes de contrôle sur disque ; le clone prouve que vous pouvez matérialiser une vue point‑dans‑le‑temps et accéder aux fichiers sans copier tout le dataset.

Décision : Si scrub montre des erreurs de checksum, traitez le pool comme compromis jusqu’à comprendre si la redondance a corrigé ou non. Si clone/mount échoue, vous avez peut‑être des conflits de namespace ou de points de montage—corrigez avant une vraie restauration.

Task 14: Detect “encrypted backups” after a ransomware event (entropy sniff test)

cr0x@server:~$ python3 - <<'PY'
import os, math
p="/mnt/backup/snapshots/2026-01-31/home/alex/Documents"
files=[os.path.join(p,f) for f in os.listdir(p) if os.path.isfile(os.path.join(p,f))][:20]
def entropy(data):
    from collections import Counter
    c=Counter(data)
    n=len(data)
    return -sum((v/n)*math.log2(v/n) for v in c.values())
for f in files:
    with open(f,'rb') as fh:
        b=fh.read(65536)
    e=entropy(b) if b else 0
    print(f"{e:0.2f} {os.path.basename(f)}")
PY
7.98 Q1-report.docx
7.99 taxes-2025.pdf
7.97 notes.txt

Ce que cela signifie : Une entropie très élevée sur plusieurs types de fichier peut être un indicateur de chiffrement (ou de formats compressés). Ce n’est pas une condamnation, c’est une alarme.

Décision : Si l’entropie est suspecte, ouvrez quelques fichiers dans un environnement d’affichage sûr et inspectez les en‑têtes avec file. Si vos sauvegardes ont capturé la sortie déjà chiffrée par des ransomware, votre « restauration » n’est que revenir sur la scène du crime.

Task 15: Time the restore (because RTO is a number, not a feeling)

cr0x@server:~$ /usr/bin/time -v borg extract --destination /restore-sandbox/perf ::laptop-2026-01-31T020001 home/alex/Projects
	Command being timed: "borg extract --destination /restore-sandbox/perf ::laptop-2026-01-31T020001 home/alex/Projects"
	User time (seconds): 92.11
	System time (seconds): 18.44
	Percent of CPU this job got: 325%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:45.33
	Maximum resident set size (kbytes): 812344
	File system outputs: 702400

Ce que cela signifie : Vous avez des mesures réelles de temps, d’utilisation CPU et d’I/O. Si le CPU est saturé, le chiffrage/la compression peut être le facteur limitant. Si les sorties filesystem sont énormes et le temps long, le stockage est le goulot.

Décision : Servez‑vous de ces chiffres pour décider si votre plan de restauration correspond à la réalité. Si vous ne pouvez pas restaurer dans le délai acceptable, changez quelque chose : disque cible plus rapide, paramètres de l’outil de sauvegarde, ou plan de restauration en niveaux.

Task 16: Unmount/cleanup safely (because leaving loop devices is how “testing” becomes “mystery”)

cr0x@server:~$ sudo umount /mnt/image
cr0x@server:~$ sudo losetup -d /dev/loop7
cr0x@server:~$ losetup -a | grep loop7 || echo "loop7 detached"
loop7 detached

Ce que cela signifie : Votre test a laissé le système propre. Cela compte sur des hôtes partagés et des machines longévives où des montages et loop devices restants créent de la confusion plus tard.

Décision : Si le démontage échoue pour cause de « busy », trouvez le processus qui le retient (lsof +f -- /mnt/image) et arrêtez‑le. Ne détachez pas de force sauf si vous acceptez le risque.

Trois mini-récits d’entreprise depuis les tranchées de restauration

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait une jolie histoire de sauvegarde : incrémentiels nocturnes, fulls hebdomadaires, réplication offsite. Tout le monde se sentait bien. Les auditeurs ont reçu un PDF avec des graphiques de rétention et une capture d’écran d’un widget « last job succeeded ». Le problème était que le widget mesurait la fin du job, pas le succès de restauration.

Une défaillance du contrôleur de stockage a emporté le serveur de fichiers principal. Pas catastrophique—jusqu’à ce que la restauration commence. L’outil de sauvegarde a demandé le « volume 12 » d’une séquence qui n’existait plus, parce que le « full » hebdomadaire n’était pas vraiment full. C’était un full synthétique construit à partir d’incrémentiels plus des métadonnées dans une base de catalogue.

La base de catalogue était sauvegardée… sur le même stockage qui a échoué. Donc le « full backup » était conceptuellement présent, mais pratiquement irréparable. Les sauvegardes étaient des chunks intacts avec des instructions manquantes.

Ils ont fini par reconstruire assez pour restaurer des partages critiques, mais le calendrier ressemblait à : deux jours de triage, un jour de récupération partielle, puis une lente procession de demandes d’utilisateurs pendant des semaines.

La mauvaise hypothèse : « Un job de sauvegarde réussi implique la capacité à restaurer. » Ce n’est pas vrai. Vous devez vérifier les chemins de restauration, y compris les catalogues, les clés et les dépendances de métadonnées.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe était fière de leur ratio de déduplication. Ils ont optimisé leur logiciel de sauvegarde pour compression maximale et dédup agressive, puis ont déplacé les dépôts sur des disques bon marché et lents. Sur le papier : énormes économies. Dans les tableaux de bord : parfait.

Puis la première vraie restauration à grande échelle est arrivée : un dev a supprimé un répertoire de projet et avait besoin de le récupérer vite. Le temps de restauration était affreux. Le système devait réhydrater une forêt de petits chunks éparpillés sur les disques, déchiffrer, décompresser et reconstruire les métadonnées de fichier. Le CPU a grimpé. Les seeks disque sont partis en vrille. Le réseau allait bien ; le stockage du repo non.

Ils ont essayé de « corriger » avec plus de threads. Cela a augmenté la pression d’I/O aléatoire et a ralenti encore. Ça a aussi déclenché des limites de débit sur la passerelle d’object-storage utilisée pour les copies offsite. Les restaurations sont devenues à la fois lentes et bruyantes.

Ce qui a finalement marché était banal : conserver une couche de restauration récente sur un stockage rapide (NVMe ou au moins SSD correct), utiliser une compression raisonnable, et considérer la dédup comme une fonctionnalité de coût, pas de récupération. Ils ont conservé la dédup—juste pas au détriment des performances de restauration.

Le retour de bâton : Optimiser pour l’efficacité du stockage de sauvegarde peut saboter le temps de restauration (RTO). Les restaurations sont la voie d’urgence ; ne la remplissez pas de briques économiques.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la mise

Un petit groupe d’opérations avait un rituel mensuel : « restore drill Friday. » Ce n’était pas glamour. Ils choisissaient un hôte aléatoire, une date aléatoire, restaurent dans une VM bac à sable et exécutent une courte checklist : démarrer, se connecter, vérifier quelques endpoints d’app, et s’assurer que les jeux de données critiques étaient présents.

Les gens se plaignaient parce que ça prenait une demi-journée et ça n’ajoutait pas de nouvelles fonctionnalités. La direction le tolèrait parce que l’équipe écrivait des rapports propres : temps de restauration, points de défaillance et correctifs planifiés dans le flux de travail normal.

Puis un incident ransomware a frappé via un identifiant de poste compromis. Les attaquants ont chiffré les partages réseau et tenté de supprimer les sauvegardes. Les paramètres d’immuabilité ont tenu pour les copies offsite, mais ce n’était pas le geste héroïque.

Le geste héroïque était la mémoire musculaire du restore drill. Ils avaient déjà : procédures testées, méthode de sélection de snapshot connue‑bonne, et un réseau de restauration mis en quarantaine. Ils ont restauré des données propres, les ont validées et remis les services en route avec peu d’improvisation.

La pratique salvatrice : Les drills de restauration de routine transforment la reprise après sinistre de « mystère technique » en « opération répétée ». L’ennuyeux est une fonctionnalité.

Listes de contrôle / plan pas à pas

Checklist A: File-level backup verification (30–90 minutes)

1. Choisissez un point de restauration. Prenez un snapshot de la semaine dernière et un d’il y a un mois. Vous testez la rétention et le versioning, pas seulement le job d’hier.
2. Exécutez l’intégrité du dépôt. Pour votre outil : borg check, restic check, etc.
3. Restaurez dans un répertoire sandbox. Ne restaurez jamais sur le chemin d’origine pour des tests.
4. Restaurez un échantillon aléatoire + un échantillon critique. L’aléatoire attrape les inconnus inconnus ; le critique attrape la réalité métier.
5. Validez le contenu. Utilisez file, ouvrez les documents en sécurité, validez les archives, exécutez les contrôles d’app si pertinent.
6. Validez les métadonnées. Permissions, propriétaires, timestamps, symlinks, ACLs si nécessaire.
7. Mesurez le temps. La vitesse de restauration fait partie de « ça marche ».
8. Notez les commandes exactes que vous avez lancées. Si vous ne pouvez pas répéter, vous n’avez pas vérifié ; vous avez eu de la chance une fois.

Checklist B: Image backup verification without wiping (60–180 minutes)

1. Montez en lecture seule. Prouvez que vous pouvez lire partitions et fichiers.
2. Extraire un fichier. Sortez un fichier de l’image (ou copiez depuis le FS monté) et validez le contenu.
3. Test de démarrage en VM. QEMU/VirtualBox/Hyper‑V—à vous de choisir. Le démarrage est la preuve.
4. Confirmez que la connexion fonctionne. Si c’est chiffré, confirmez que vous pouvez fournir la clé. Si ça utilise le TPM, prévoyez une solution.
5. Documentez les détails du mode de démarrage. UEFI vs BIOS, état secure boot, pilotes du contrôleur disque.
6. Enregistrez les temps et pièges. Si cela a pris 2 heures pour démarrer et corriger des pilotes, c’est votre temps réel de récupération.

Checklist C: Ransomware-aware restore validation (add 30–120 minutes)

1. Vérifiez qu’une copie immuable/offline existe. Si l’attaquant peut la supprimer, ce n’est pas un plan de reprise.
2. Choisissez un point de restauration « propre connu ».  Utilisez la timeline d’incident. Ne restaurez pas hier juste parce que c’est le plus récent.
3. Scannez les données restaurées en quarantaine. Utilisez un scan offline, évitez d’exécuter des binaires restaurés.
4. Vérifiez les indicateurs de chiffrement. Extensions de fichiers, entropie, en‑têtes corrompus, fichiers README suspects.
5. Restaurez d’abord sur un réseau isolé. Ne réintroduisez pas le malware en restaurant directement en production.

Blague #2 : Si votre plan de restauration dépend de « la seule personne qui sait faire », félicitations—vous avez construit un RAID‑0 humain.

Erreurs courantes : symptômes → cause racine → correction

C’est la partie où on cesse d’être poli sur les « bonnes pratiques » et où on parle de ce qui casse réellement à 2h du matin.

1) Symptom: “Backup succeeded,” but restore says archive/snapshot not found

Cause racine : Vous restaurez depuis un dépôt/cible différent de celui qui était sauvegardé, ou la rétention/prune a supprimé le point de restauration.

Correction : Vérifiez le chemin/identifiants du dépôt ; listez les snapshots et confirmez les conventions de nommage. Ajoutez des alertes sur le nombre et l’âge des snapshots, pas seulement sur le succès du job.

2) Symptom: Restore works for some files, fails for others with checksum or “chunk missing”

Cause racine : Corruption du dépôt, stockage capricieux, uploads interrompus, ou pack de dédup endommagé.

Correction : Exécutez des checks d’intégrité régulièrement ; gardez plusieurs copies indépendantes ; ne stockez pas la seule copie du dépôt sur un disque grand public sans scrubs.

3) Symptom: Restored files exist but apps won’t start (permissions errors, config unreadable)

Cause racine : ACL/xattr non préservés, mauvais utilisateur de restauration, ou restauration sur un FS qui ne peut pas représenter les métadonnées (ex. FAT/exFAT).

Correction : Utilisez un FS qui supporte les métadonnées requises ; assurez‑vous que les flags de l’outil incluent xattrs/ACLs ; restaurez en root si nécessaire, puis corrigez la propriété intentionnellement.

4) Symptom: Restore is painfully slow, but CPU is high and disk looks idle

Cause racine : Surcharge de compression/déchiffrement, décompression mono‑thread, ou overhead métadonnées de petits fichiers combiné à l’antivirus.

Correction : Benchmarquez avec la restauration d’un gros fichier ; excluez le répertoire de restauration du scan temps réel pendant les tests ; ajustez le parallélisme prudemment ; stockez les sauvegardes récentes sur du média plus rapide.

5) Symptom: Mounting an image works, but VM boot fails instantly

Cause racine : Mismatch du mode de boot (UEFI vs BIOS), partition EFI manquante, contraintes secure boot, ou pilotes manquants pour virtio.

Correction : Démarrez la VM dans le même mode ; utilisez l’émulation SATA si les pilotes virtio ne sont pas présents ; confirmez l’existence de la partition EFI ; prévoyez la gestion des clés secure boot.

6) Symptom: Restore completes, but data is “gibberish” or cannot be opened

Cause racine : Vous avez sauvegardé la sortie chiffrée d’un ransomware, ou l’outil a sauvegardé des fichiers temporaires pendant que l’app écrivait (état incohérent).

Correction : Choisissez un snapshot connu‑propre ; implémentez des sauvegardes cohérentes applicatives (dumps DB, snapshots avec quiesce) ; ajoutez des fichiers canaris qui doivent s’ouvrir correctement.

7) Symptom: Offsite restore is possible but takes days

Cause racine : Offsite sur lien lent, throttling, stockage froid, ou vous n’avez jamais planifié l’egress et le temps de rehydratation.

Correction : Maintenez une couche locale rapide pour les restaurations récentes ; testez les restaurations offsite trimestriellement ; documentez un RTO réaliste pour le pire cas.

8) Symptom: After a restore, you discover missing folders that “should be there”

Cause racine : Règles exclude trop larges, changements de chemin, surprises de gestion de symlink, ou sauvegarde du mauvais root.

Correction : Auditez les patterns include/exclude ; conservez un manifeste des répertoires critiques ; testez des restaurations d’arbres entiers, pas seulement quelques fichiers.

FAQ

1) Can I verify backups without restoring everything?

Oui. Faites des checks d’intégrité plus des restaurations sélectives de fichiers aléatoires et critiques. Pour les images, montez en lecture seule et faites un test de démarrage en VM. Vous prouvez le chemin, pas la copie de téraoctets pour le sport.

2) What’s the single best non-destructive restore test for a system image?

Démarrer l’image dans une VM. Monter prouve la lisibilité ; démarrer prouve toute la pile : partitions, bootloader, kernel/initramfs et viabilité de base de l’OS.

3) How many files should I spot-check?

Assez pour couvrir la diversité : quelques gros fichiers, beaucoup de petits fichiers, différents répertoires et éléments « métadonnées‑lourdes » (symlinks, configs sensibles aux permissions). J’aime 20 fichiers aléatoires plus 10 critiques comme base.

4) Should I trust a tool’s “verify” or “check” command?

Faites‑l pour ce qu’il promet : intégrité structurelle et cryptographique. Ça ne prouve pas que vous pouvez restaurer vite, choisir le bon snapshot ou reconstruire correctement une app. Donc exécutez le check, puis faites un vrai test de restauration.

5) What about Windows? I’m not running Linux commands.

Le workflow est le même : validez le jeu de sauvegarde, montez l’image en lecture seule, extrayez des fichiers et testez le démarrage dans Hyper‑V ou VirtualBox. Les noms changent ; les modes de défaillance non.

6) If I have RAID/ZFS redundancy, do I still need restore verification?

Oui. La redondance aide en cas de panne matérielle, pas en cas de suppression, ransomware, mauvaise mise à jour ou « j’ai synchro partout le mauvais dossier ». Les sauvegardes sont du voyage dans le temps ; le RAID ne l’est pas.

7) How often should I run restore drills?

Mensuellement pour les systèmes qui vous font perdre le sommeil. Trimestriellement au minimum pour le reste. Après des changements majeurs (nouvel outil de sauvegarde, nouveau chiffrement, nouveau stockage), faites un drill immédiatement—le changement est l’endroit où se cachent les cadavres.

8) What’s the difference between “backup verification” and “disaster recovery testing”?

La vérification prouve que vous pouvez restaurer des données depuis les médias/dépôts. Le test DR prouve que vous pouvez restaurer le service : compute, réseau, identité, dépendances, monitoring et accès. La vérification est nécessaire ; le test DR est la version adulte.

9) How do I avoid restoring ransomware back into my environment?

Restaurez dans un bac à sable isolé, scannez offline et choisissez un point de restauration antérieur aux premiers signes de compromission. Supposez que le « plus récent » est contaminé jusqu’à preuve du contraire.

10) Do I need checksums if my backup tool already encrypts?

Le chiffrement ne garantit pas l’intégrité sauf s’il s’agit d’un chiffrement authentifié et bien implémenté. La plupart des outils modernes font de l’intégrité, mais vous voulez néanmoins des checks de dépôt plus des tests de restauration périodiques parce que les métadonnées et catalogues peuvent échouer.

Prochaines étapes réalisables aujourd’hui

Pratique, pas héroïque :

1. Choisissez un dossier critique (documents, photos, dépôts) et faites une restauration sandbox de 10 fichiers depuis un snapshot d’il y a une semaine.
2. Exécutez le check d’intégrité de votre outil et sauvegardez la sortie ailleurs qu’au disque de sauvegarde.
3. Mesurez le temps de restauration pour un répertoire moyen (quelques Go). Notez le chiffre. C’est votre RTO de départ.
4. Si vous utilisez des images, faites un test de démarrage en VM une fois. C’est le moyen le plus rapide de transformer la croyance en preuve.
5. Planifiez un drill de restauration récurrent (mensuel). Mettez‑le au calendrier comme toute autre maintenance. S’il n’est pas planifié, il n’arrivera pas.
6. Documentez les étapes de restauration en langage clair avec les commandes exactes, où sont les clés/mots de passe et comment trouver le snapshot correct.

La vérification n’est pas de la paranoïa. C’est le contrôle qualité pour votre futur vous—qui sera fatigué, stressé et profondément peu impressionné par la coche verte d’hier.