Modèle image-level & CBT cbt
Sauvegarder une machine, c'est lire ses disques au niveau bloc, suivre les blocs modifiés (CBT) pour les incrémentaux, et faire passer le flux dans le même pipeline que les fichiers. C'est là que la dédup inter-clients paie le plus.
Agentless ou agent invité
Deux placements, complémentaires.
- Agentless (proxy) — un proxy Cairn parle à l'API de l'hyperviseur, snapshote la VM et lit ses disques. Idéal pour l'image-level : rien à installer dans les invités. Le proxy est un client Cairn — il détient le secret du tenant et chiffre côté client, donc la propriété zéro-connaissance tient.
- Agent invité — l'agent tourne dans la VM et fait du fichier (voir section A) ou, sur une machine physique, du bare metal. Nécessaire quand il n'y a pas d'hyperviseur à interroger.
Le flux image-level
# incrémental d'un disque de VM
snapshot = hyperviseur.snapshot(vm) # point cohérent
delta = CBT.changed_blocks(vm, depuis=dernier) # seulement les régions modifiées
chunks = FastCDC(delta) → dédup → chiffrement → adresse # pipeline habituel
snapshot = hyperviseur.snapshot(vm) # point cohérent
delta = CBT.changed_blocks(vm, depuis=dernier) # seulement les régions modifiées
chunks = FastCDC(delta) → dédup → chiffrement → adresse # pipeline habituel
Le disque virtuel est un gros blob. On le découpe en chunks, on déduplique, on chiffre — exactement comme un fichier. La différence tient au CBT (Changed Block Tracking) de l’hyperviseur : il nous dit quelles régions ont bougé depuis la dernière sauvegarde, donc on ne relit et ne re-découpe que le delta. Les chunks inchangés sont déjà présents → dédup gratuite.
Là où la dédup inter-clients brille
Cent VMs issues du même modèle d'OS partagent l'essentiel de leurs blocs. Adressés par le contenu, ces blocs identiques ne sont stockés qu'une seule fois pour tout le parc d'un tenant. L'image-level est le cas d'usage qui rentabilise le plus la déduplication — l'argument commercial le plus fort de l'architecture.
Par plateforme
| Plateforme | API | CBT | Transport disque |
|---|---|---|---|
| Proxmox VE | API Proxmox / QMP | dirty bitmaps QEMU | storage / NBD |
| XCP-ng | XAPI | CBT XAPI (list_changed_blocks) | NBD |
| Hyper-V | WMI / PowerShell | RCT | SMB / API |
| VMware vSphere | VADP (vCenter / ESXi) | CBT (QueryChangedDiskAreas) | VDDK : NBD / hotadd / SAN |
VMware — dépendance propriétaire
VADP passe par le VDDK, un SDK propriétaire de VMware, et les conditions d'accès aux API et de licence évoluent côté Broadcom. À traiter comme une dépendance à part entière, avec son propre risque, contrairement aux trois autres qui exposent des API ouvertes.
Bare metal
Sur une machine physique, pas d’hyperviseur à interroger : c’est l’agent qui fait tout.
- Cohérence — snapshot du volume avant lecture : VSS sous Windows, LVM / dm-snapshot (ou blk-snap) sous Linux.
- CBT côté agent — l'agent maintient lui-même un bitmap des blocs modifiés, faute d'hyperviseur pour le fournir.
- Restauration (BMR) — un média bootable (WinPE / live Linux) embarque l'agent Cairn, repartitionne et réécrit les blocs. Restauration vers matériel dissemblable : injection de pilotes (Windows), régénération de l'initramfs (Linux).
Modes de restauration
- VM / machine complète — réécriture de l'image entière.
- Fichier depuis une image — monter l'image sauvegardée et en extraire des fichiers, sans tout restaurer.
- Instant recovery — démarrer directement depuis la sauvegarde (booter la VM sur le stockage de backup le temps d'une vraie restauration). Avancé, à envisager plus tard.
À trancher
- Granularité du CBT (blocs de taille fixe) face au découpage FastCDC (taille variable) : re-découper les régions changées, et mesurer le surcoût.
- Où tourne le proxy agentless (par cluster ? par hôte ?) et comment il reçoit le secret du tenant sans jamais l'exposer.
- Cohérence applicative fine (bases de données à l'intérieur des VMs) : quiescing invité vs sauvegarde applicative dédiée.