Backup documentation uses the terms "full" and "incremental" loosely, and implementations differ enough between vendors that shared assumptions break down. This article defines the classic vocabulary, explains how StateWarden actually executes backups, and shows how to interpret the size metrics in the Dashboard.
1. The Classic Vocabulary
Full Backup
A complete, self-contained copy of the source at a point in time. Every block is read and transferred. A full backup restores on its own with no dependency on any other backup, at the cost of the highest I/O load, transfer volume, and backup window duration.
Incremental Backup
A capture of only the data that changed since the last backup of any kind (full or incremental). Incrementals are fast and small, but in classic implementations they form a chain: a restore requires the last full backup plus every incremental taken after it. If any element of the chain is lost or corrupted, every later restore point is affected.
Differential Backup
A capture of all data that changed since the last full backup. Differentials grow with every run but keep the restore dependency short: the last full plus the latest differential. StateWarden does not use the differential strategy; it is listed here only for vocabulary completeness.
| Strategy | Reads per run | Classic restore dependency |
|---|---|---|
| Full | 100% of source | Self-contained |
| Incremental | Changes since last backup | Full chain (full + all incrementals) |
| Differential | Changes since last full | Last full + latest differential |
2. How StateWarden Actually Works: Forever-Incremental
StateWarden processes volumes at the block level (see Smart NTFS and Block-Level Backups). The Agent chunks the data stream, hashes and encrypts the chunks, and uploads only those chunks that are not already present in the Realm's deduplicated chunk store on the Data Plane (Driad). Chunk identity is content-based, so identical data is stored once regardless of which device or backup produced it (see Architecture Overview: Artemis, Driad, and the Agent).
After the initial baseline, every scheduled backup runs as an incremental: the Agent reads only the blocks that changed and transfers only the resulting unique chunks. There is no scheduled rotation of periodic full backups; under normal operation a source is read in full exactly once (exceptions in section 4).
The critical difference from the classic model is on the restore side. Although each run stores only changed chunks, every restore point is presented in the Dashboard and on the Restore Data page as a complete, independently usable snapshot of the source, synthesized from the chunk store. The consequences are operational, not cosmetic:
- There is no incremental chain to break. Any single restore point is sufficient on its own.
- Expiring or deleting an old restore point does not affect the integrity of newer ones; chunks still referenced by remaining restore points are retained.
- Retention management never requires re-seeding a full backup to keep a chain valid.
The backup history records the strategy each run used in the Type column: Full, Incremental, or Synthetic Full. A Synthetic Full is produced for whole-disk images: the Agent captures the disk layout and all partitions using incremental reads where change tracking is available, and the result is a complete, bootable disk image suitable for Bare Metal Recovery (see Bare Metal Recovery Walkthrough).
3. What CBT Is - and What It Is Not
Changed Block Tracking (CBT) is a change-detection accelerator, not a storage format and not a backup type. StateWarden's Smart CBT uses the operating system's native mechanisms:
- Windows: the NTFS Update Sequence Number (USN) Journal.
- Linux: era-based device-mapper tracking (
dm-era).
CBT answers exactly one question: which blocks must the Agent read for this run? Instead of scanning the volume to discover changes, the Agent asks the OS for the list of blocks modified since the last snapshot and reads only those. This reduces the detection phase from a full volume scan to a metadata query.
CBT does not change what gets stored. The storage path is identical for every run: chunk, hash, deduplicate, encrypt, upload unique chunks. A restore point created with CBT is not a partial backup; it is a complete point-in-time image of the source, assembled from the same chunk store as any other restore point.
Two practical implications:
- CBT is controlled per volume in the Dashboard, which also reports the per-volume tracking state. Where CBT cannot be enabled (for example on raw encrypted volumes such as BitLocker or LUKS, where block-level change detection is ineffective), the volume is backed up with full reads instead.
- Because CBT only accelerates detection, a fallback to a full read changes run duration and I/O load, never restore completeness.
For enabling, disabling, and troubleshooting CBT per volume, see Smart CBT: Incremental Backups.
4. When a Full Read Still Happens
In StateWarden, "full" describes the read side: the Agent reads the entire source sequentially instead of consulting change tracking. A full read occurs in these cases:
- First backup of a source. No tracking baseline exists yet, so the initial run always reads the whole volume and establishes the baseline.
- CBT unavailable or disabled. If tracking is not enabled for the volume, or the OS mechanism is not usable, the Agent falls back to reading the source in full on every run.
- After a forced full backup. A forced full re-reads the source and re-establishes the tracking baseline (see section 5).
- Invalidated tracking state. Disabling CBT discards the tracking metadata, and major system changes (for example a kernel upgrade or a bare-metal restore) can invalidate it; the next run re-baselines with a full read.
Even during a full read, the upload remains deduplicated: the Agent transfers only chunks the store does not already hold. Re-reading an unchanged volume in full therefore costs I/O and time, but little bandwidth and no additional storage.
5. Key Rotation and Forced Full Backups
Backups are encrypted with the Realm's encryption key, and every restore point is bound to the key it was written under. When the key is rotated at the Realm level on the Security & Compliance page (see Global Keys vs Device Keys: Enterprise Encryption Strategy):
- Restore points written under the previous key are marked with a STALE KEY badge in the Dashboard. They remain listed, but restoring them requires the previous Recovery Key.
- Incremental tracking state tied to the previous key is discarded on the next run. The next backup after a rotation executes as a full baseline automatically.
- The Backup Now action offers a Force full backup option for cases where a device should be re-baselined immediately rather than at the next scheduled run. Forcing a full backup reads the entire source and resets change tracking; the upload is still deduplicated.
Expect stored size to grow temporarily after a rotation: data written under the previous key is retained until the affected restore points expire or are removed, so the same logical data can occupy space under both keys until superseded data is garbage-collected.
6. Reading the Metrics
Three size figures appear around every backup. They measure different things, and confusing them leads to wrong conclusions about backup health and cost.
| Concept | Dashboard label | What it measures |
|---|---|---|
| Source size | Restore Size | The uncompressed size of the source data if restored to disk. Constant across runs regardless of backup type; use it to verify the backup covers the expected scope. |
| Transferred size | Deduplicated data size | The data actually sent to the storage node after deduplication and compression. This is why a run against a 100 GB source can complete in seconds: only the changed, not-yet-stored chunks cross the network. |
| Stored size | Quota / Backups + metadata | The physical space occupied on the storage side by your encrypted chunks and backup metadata, measured after deduplication and compression. This is the billing-relevant figure (see Understanding Quotas and Fair Use). |
Read together, the three figures describe the efficiency of the strategy at a glance: Restore Size stays flat, transferred size tracks the actual change rate of the workload, and stored size grows only with genuinely new, non-duplicate data. A sudden jump in transferred size on an incremental run means the workload changed significantly or a full read occurred; it does not mean the restore point contains more data.