Why Is an Incremental Backup Almost as Large as a Full Backup?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Why Is an Incremental Backup Almost as Large as a Full Backup? - Zima Store Online

An incremental backup can become almost as large as a full backup when the source genuinely rewrites many blocks, the backup engine loses its previous change baseline, the protected scope changes, or the number you are reading is repository growth rather than the current incremental payload. Diagnose those possibilities separately before deleting restore points, resetting the job, or starting a new full backup.

First Identify Which Number Looks Too Large

“The incremental is full-sized” can describe four different measurements. They are not interchangeable, and each points to a different cause.

Measurement	What It Means	What a Large Value Suggests
Source bytes scanned	Data read to detect changes	The engine may need to inspect whole files even if it uploads only changed chunks
Transferred bytes	New data sent to the destination	Many blocks changed, the baseline was lost, or deduplication did not match
Incremental file size	New restore-point data written by this run	The job captured a genuinely large delta or behaved like a new baseline
Total repository growth	Net storage added after merges, retention, metadata, and synthetic operations	The backup-chain design or cleanup schedule may be the real cause

Record all four numbers for one run. A job that scans 8 TB but transfers 12 GB is behaving very differently from one that transfers and writes 7 TB.

Confirm Whether the Workload Really Changed That Much

Volume-level backup software protects changed storage blocks, not the user-visible size of edited documents. A small edit can alter a larger block, and busy services continuously modify logs, indexes, databases, caches, and operating-system files. A recent administrator discussion explains why one changed byte can make the containing backup block part of the next increment.

Check whether the large run followed any of these events:

Database maintenance, compaction, reindexing, or transaction-log growth
Virtual-machine updates, swap activity, antivirus scans, or guest defragmentation
Media transcoding, photo-library reindexing, thumbnail regeneration, or metadata rewrites
Large archive, encrypted-container, mailbox, or disk-image files being rewritten in place
Filesystem balance, pool expansion, block relocation, or snapshot consolidation

Compare the backup window with application logs and storage-write graphs. If source writes rose at the same time, the backup may be reporting a real delta rather than a backup fault.

Check Whether Change Tracking Lost Its Baseline

Block-tracking systems compare the current state with a known previous change ID. A snapshot revert, tracking reset, invalid change map, host migration, failed prior session, or backup-job recreation can break that relationship. The next run may then read or protect the entire source to establish a safe baseline. A practical CBT recovery walkthrough notes that resetting change tracking can require a new active full before normal incrementals resume.

Look for log terms such as CBT reset, change ID invalid, journal wrapped, baseline missing, new chain, or full scan required. Do not reset tracking repeatedly without preserving the logs; repeated resets can hide the original trigger and produce repeated full-sized runs.

Verify That the Backup Scope and Source Identity Did Not Change

A job may still be labelled incremental while protecting a different source than before. A new mount under an included path, a filesystem resize, a changed device identifier, a different host name, a new share path, or an expanded include rule can make the engine build new internal structures. Community troubleshooting shows that additional volumes and mount points can be pulled into a job that appears unchanged.

Export the previous and current job definitions and compare:

Protected roots, mounts, shares, datasets, and virtual disks
Host, volume, and filesystem identifiers
Include and exclude patterns
Snapshot provider and consistency mode
Encryption, compression, and deduplication settings

If the source expanded intentionally, one full-sized increment may be expected. If every later run remains large, continue the diagnosis.

Determine Whether the Backup Granularity Fits the Files

File-level, block-level, and content-defined chunking engines react differently to edits, renames, and rewrites. A block-deduplicating system may record only metadata when a folder is moved; a simpler file-level engine may treat the moved path as a deleted file plus a new file. In one block-based example, renaming a directory changes path metadata without re-uploading all unchanged data blocks.

Large mutable files need special attention. A database, VM image, encrypted vault, or monolithic archive may be fully read to discover small internal changes, and the amount ultimately stored depends on chunk boundaries and deduplication. A large-database discussion describes how a multi-gigabyte database file may be read in full even when only changed chunks are transferred.

If the application provides a consistent export, transaction-log backup, or application-aware backup method, compare that workflow with backing up the live monolithic file.

Separate a Large Increment From Synthetic Full and Retention Activity

A synthetic full is assembled inside the repository from an earlier full plus later incrementals. It can create a full-sized recovery object without reading the entire source again. An overview of backup types explains that synthetic full backups are built from the existing full and incremental chain.

Repository growth can also stay high when old restore points remain locked, pruning has not run, deleted snapshots still reference chunks, or a merge temporarily needs working space. Check the job timeline instead of judging one directory listing:

Observed Pattern	Likely Interpretation	Next Check
Network transfer is small, repository write is large	Synthetic full, merge, or repack	Repository task log
Increment file is small, total usage keeps rising	Retention, immutability, snapshots, or delayed pruning	Oldest retained point and reclaim schedule
Transferred and written bytes both approach full size	Real churn, lost baseline, or changed scope	Source activity and tracking logs
Only the first run after a change is large	New baseline or source-layout transition	Next two incremental runs

Run a One-Variable Test Before Rebuilding the Backup Chain

Save the current job configuration, detailed logs, restore-point list, and repository capacity.
Choose a quiet test window and pause known high-write applications if doing so is safe.
Create one small test file, modify it once, and run the same incremental job without changing any settings.
Record scanned, transferred, written, deduplicated, and retained bytes.
Run a second incremental with no source changes.

If both controlled runs remain full-sized, focus on tracking, source identity, or job-chain configuration. If they become small, restore normal workloads one at a time until the change rate returns. This separates backup-engine behavior from application churn.

Match the Fix to the Cause

Confirmed Cause	Corrective Action	Expected Result
High real write rate	Reduce temporary-file scope, use app-aware exports, or schedule after maintenance	Increment size follows meaningful data changes
Tracking baseline lost	Repair tracking once, create the required baseline, then verify later increments	One large run followed by smaller deltas
Scope expanded	Confirm the new data is intended or split it into a separate job	Predictable growth tied to the added source
Large mutable files	Use application-consistent dumps or a chunk-aware backup method	Less unnecessary reprocessing and safer restores
Retention or synthetic operations	Adjust capacity planning, prune timing, or restore-point policy	Repository growth matches the intended history

When sizing the destination, remember that version history and retention can make a repository larger than the active source. The same distinction is covered in the ZimaSpace guide to planning NAS capacity for versions and backup history.

Stop and Escalate When Every Run Creates a New Baseline

Escalate before deleting the chain when the logs show repeated baseline invalidation, source identifiers change unexpectedly, restore points disappear, repository metadata reports corruption, or a no-change test still writes almost the entire source. Keep the current restore points until at least one representative restore has been tested. Recreating the job can hide the evidence and remove the only recoverable history.

Frequently Asked Questions

Can moving or renaming a large folder cause a full-sized incremental?

It depends on the backup engine. Content- or block-deduplicating tools may reuse the existing data and store mostly path metadata, while file-level tools may treat the moved files as new objects. Test the exact product with one representative folder before reorganizing a large dataset.

Does a synthetic full mean the NAS uploaded the whole source again?

Not necessarily. A synthetic full is commonly assembled from data already in the repository. Compare source-read and network-transfer counters with repository-write counters to see where the work occurred.

Why can a small database edit create a large incremental?

The application may rewrite many storage blocks, compact the database, rotate logs, or change chunk boundaries even when the visible record change is small. Use an application-consistent backup or export and compare its delta with the live database file.