La documentation de sauvegarde utilise les termes « complète » et « incrémentale » avec une certaine souplesse, et les implémentations diffèrent suffisamment d'un éditeur à l'autre pour que les suppositions partagées volent en éclat. Cet article définit le vocabulaire classique, explique comment StateWarden exécute réellement les sauvegardes et montre comment interpréter les indicateurs de taille du Dashboard.
1. Le vocabulaire classique
Sauvegarde complète
Une copie intégrale et autonome de la source à un instant donné. Chaque bloc est lu et transféré. Une sauvegarde complète se restaure seule, sans dépendre d'aucune autre sauvegarde, au prix de la charge d'E/S, du volume de transfert et de la durée de fenêtre de sauvegarde les plus élevés.
Sauvegarde incrémentale
Une capture des seules données modifiées depuis la dernière sauvegarde, quel qu'en soit le type (complète ou incrémentale). Les incrémentales sont rapides et légères, mais dans les implémentations classiques elles forment une chaîne : une restauration exige la dernière sauvegarde complète plus chaque incrémentale prise ensuite. Si un maillon de la chaîne est perdu ou corrompu, tous les points de restauration ultérieurs sont affectés.
Sauvegarde différentielle
Une capture de toutes les données modifiées depuis la dernière sauvegarde complète. Les différentielles grossissent à chaque exécution mais maintiennent une dépendance de restauration courte : la dernière complète plus la dernière différentielle. StateWarden n'utilise pas la stratégie différentielle ; elle n'est mentionnée ici que pour compléter le vocabulaire.
| Stratégie | Lectures par exécution | Dépendance de restauration classique |
|---|---|---|
| Complète | 100 % de la source | Autonome |
| Incrémentale | Modifications depuis la dernière sauvegarde | Chaîne complète (complète + toutes les incrémentales) |
| Différentielle | Modifications depuis la dernière complète | Dernière complète + dernière différentielle |
2. Comment StateWarden fonctionne réellement : l'incrémentale perpétuelle
StateWarden traite les volumes au niveau bloc (voir Smart NTFS et sauvegardes au niveau bloc). L'agent découpe le flux de données en chunks, calcule leur empreinte et les chiffre, puis ne téléverse que les chunks absents du magasin de chunks dédupliqué du Realm sur le plan de données (Driad). L'identité d'un chunk repose sur son contenu ; une donnée identique n'est donc stockée qu'une seule fois, quel que soit l'appareil ou la sauvegarde qui l'a produite (voir Vue d'ensemble de l'architecture : Artemis, Driad et l'agent).
Après la référence initiale, chaque sauvegarde planifiée s'exécute comme une incrémentale : l'agent ne lit que les blocs modifiés et ne transfère que les chunks uniques qui en résultent. Il n'y a pas de rotation planifiée de sauvegardes complètes périodiques ; en fonctionnement normal, une source n'est lue intégralement qu'une seule fois (exceptions en section 4).
La différence critique avec le modèle classique se situe côté restauration. Bien que chaque exécution ne stocke que les chunks modifiés, chaque point de restauration est présenté dans le Dashboard et sur la page Restaurer les données comme un snapshot complet et utilisable indépendamment de la source, synthétisé à partir du magasin de chunks. Les conséquences sont opérationnelles, pas cosmétiques :
- Il n'y a pas de chaîne incrémentale à briser. N'importe quel point de restauration suffit à lui seul.
- Faire expirer ou supprimer un ancien point de restauration n'affecte pas l'intégrité des plus récents ; les chunks encore référencés par les points restants sont conservés.
- La gestion de la conservation n'exige jamais de regénérer une sauvegarde complète pour maintenir une chaîne valide.
L'historique des sauvegardes consigne la stratégie de chaque exécution dans la colonne Type : Full, Incremental ou Synthetic Full. Une sauvegarde synthétique complète est produite pour les images disque entières : l'agent capture la topologie du disque et toutes les partitions avec des lectures incrémentales lorsque le suivi des modifications est disponible, et le résultat est une image disque complète et amorçable, exploitable pour une Bare Metal Recovery (voir le Guide Bare Metal Recovery).
3. Ce que le CBT est - et ce qu'il n'est pas
Le Changed Block Tracking (CBT) est un accélérateur de détection des modifications, pas un format de stockage ni un type de sauvegarde. Smart CBT de StateWarden s'appuie sur les mécanismes natifs du système d'exploitation :
- Windows : le journal USN (Update Sequence Number) de NTFS.
- Linux : le suivi device-mapper par ères (
dm-era).
Le CBT répond à une seule question : quels blocs l'agent doit-il lire pour cette exécution ? Au lieu d'analyser le volume pour découvrir les changements, l'agent demande à l'OS la liste des blocs modifiés depuis le dernier snapshot et ne lit que ceux-là. La phase de détection passe ainsi d'une analyse complète du volume à une simple requête de métadonnées.
Le CBT ne change pas ce qui est stocké. Le chemin de stockage est identique à chaque exécution : découpage en chunks, empreinte, déduplication, chiffrement, téléversement des chunks uniques. Un point de restauration créé avec le CBT n'est pas une sauvegarde partielle ; c'est une image complète de la source à un instant donné, assemblée à partir du même magasin de chunks que tout autre point de restauration.
Deux implications pratiques :
- Le CBT se contrôle par volume dans le Dashboard, qui indique aussi l'état de suivi de chaque volume. Là où le CBT ne peut pas être activé (par exemple sur les volumes chiffrés bruts comme BitLocker ou LUKS, où la détection des modifications au niveau bloc est inefficace), le volume est sauvegardé par des lectures complètes.
- Comme le CBT n'accélère que la détection, un repli sur une lecture complète modifie la durée d'exécution et la charge d'E/S, jamais la complétude de la restauration.
Pour activer, désactiver et dépanner le CBT par volume, voir Smart CBT : sauvegardes incrémentales.
4. Quand une lecture complète a tout de même lieu
Dans StateWarden, « complète » décrit le côté lecture : l'agent lit l'intégralité de la source séquentiellement au lieu de consulter le suivi des modifications. Une lecture complète se produit dans les cas suivants :
- Première sauvegarde d'une source. Aucune référence de suivi n'existe encore ; l'exécution initiale lit donc toujours le volume entier et établit la référence.
- CBT indisponible ou désactivé. Si le suivi n'est pas activé pour le volume, ou si le mécanisme de l'OS n'est pas utilisable, l'agent retombe sur une lecture intégrale de la source à chaque exécution.
- Après une sauvegarde complète forcée. Une complète forcée relit la source et rétablit la référence de suivi (voir section 5).
- État de suivi invalidé. Désactiver le CBT abandonne les métadonnées de suivi, et des changements système majeurs (par exemple une mise à niveau du noyau ou une restauration bare metal) peuvent les invalider ; l'exécution suivante rétablit la référence par une lecture complète.
Même pendant une lecture complète, le téléversement reste dédupliqué : l'agent ne transfère que les chunks que le magasin ne détient pas déjà. Relire intégralement un volume inchangé coûte donc des E/S et du temps, mais peu de bande passante et aucun stockage supplémentaire.
5. Rotation de clé et sauvegardes complètes forcées
Les sauvegardes sont chiffrées avec la clé de chiffrement du Realm, et chaque point de restauration est lié à la clé sous laquelle il a été écrit. Lorsque la clé fait l'objet d'une rotation au niveau du Realm sur la page Sécurité & Conformité (voir Clés globales et clés par appareil : stratégie de chiffrement en entreprise) :
- Les points de restauration écrits sous la clé précédente sont marqués d'un badge CLÉ OBSOLÈTE dans le Dashboard. Ils restent listés, mais leur restauration exige la clé de récupération précédente.
- L'état de suivi incrémental lié à la clé précédente est abandonné à l'exécution suivante. La première sauvegarde après une rotation s'exécute automatiquement comme une référence complète.
- L'action Sauvegarder maintenant propose une option Forcer une sauvegarde complète pour les cas où un appareil doit rétablir sa référence immédiatement plutôt qu'à la prochaine exécution planifiée. Forcer une sauvegarde complète lit l'intégralité de la source et réinitialise le suivi des modifications ; le téléversement reste dédupliqué.
Attendez-vous à ce que la taille stockée augmente temporairement après une rotation : les données écrites sous la clé précédente sont conservées jusqu'à ce que les points de restauration concernés expirent ou soient supprimés ; la même donnée logique peut donc occuper de l'espace sous les deux clés jusqu'à ce que les données remplacées soient récupérées par le garbage collection.
6. Lire les indicateurs
Trois chiffres de taille entourent chaque sauvegarde. Ils mesurent des choses différentes, et les confondre mène à de fausses conclusions sur la santé et le coût des sauvegardes.
| Concept | Libellé du Dashboard | Ce que ça mesure |
|---|---|---|
| Taille de la source | Taille de restauration | La taille non compressée des données sources si elles étaient restaurées sur disque. Constante d'une exécution à l'autre, quel que soit le type de sauvegarde ; utilisez-la pour vérifier que la sauvegarde couvre le périmètre attendu. |
| Taille transférée | Taille après déduplication | Les données réellement envoyées au nœud de stockage après déduplication et compression. C'est pourquoi une exécution sur une source de 100 Go peut se terminer en quelques secondes : seuls les chunks modifiés et pas encore stockés traversent le réseau. |
| Taille stockée | Quota / Sauvegardes + métadonnées | L'espace physique occupé côté stockage par vos chunks chiffrés et les métadonnées de sauvegarde, mesuré après déduplication et compression. C'est le chiffre qui compte pour la facturation (voir Comprendre les quotas et le Fair Use). |
Lus ensemble, les trois chiffres décrivent l'efficacité de la stratégie en un coup d'œil : la taille de restauration reste stable, la taille transférée suit le taux de changement réel de la charge, et la taille stockée ne croît qu'avec les données réellement nouvelles et non dupliquées. Une hausse soudaine de la taille transférée sur une exécution incrémentale signifie que la charge a beaucoup changé ou qu'une lecture complète a eu lieu ; cela ne signifie pas que le point de restauration contient davantage de données.