Technical guide

Incremental backup for Mac: full vs incremental

Backup labels describe how data is captured and stored, but recovery depends on the repository contract. A small incremental upload can still produce a complete restore point—and a chain of incremental files can still be fragile.

Last technically reviewed: July 10, 2026.

Scope and disclosure. Azivault describes its engine as differential and content-addressed rather than as a traditional full-plus-incremental chain. This guide distinguishes those models and states where other tools use different terminology.

The short version

Full backup: reads and stores the protected dataset as a new complete copy, even when earlier copies exist.
Incremental backup: stores changes since a previous backup; restore may depend on a chain or repository index.
Differential backup: identifies state changes relative to a known baseline or catalog rather than blindly copying everything.
Content-addressed repository: stores payloads by content identity and lets multiple restore points reference unchanged objects.

Full backup

A traditional full backup creates a new complete stored copy of the selected data. Restore is conceptually simple because that copy stands alone, but repeated full backups can consume time, bandwidth, and storage proportional to the entire dataset.

Some products present every restore point as full even though unchanged data is shared internally. User-visible completeness and physical duplication are not the same thing.

Incremental and differential backup

A traditional incremental stores changes since the immediately preceding backup. A traditional differential stores changes since the last full backup. Incrementals minimize each backup but may create longer restore chains; differentials grow until another full backup but need fewer chain elements.

Modern repository tools often do not fit either textbook definition. They scan current state, compare it with indexed prior state, store new content objects, and commit a complete logical snapshot that references both old and new objects.

How Azivault stores changed and unchanged files

Azivault compares source metadata and keyed path identifiers against the catalog. Changed content is compressed, encrypted, and stored as content-addressed blobs. Valid existing blobs are reused instead of rewritten. Renames, deletions, empty directories, and current file state are represented in catalog events and checkpoints.

Each successful run becomes a complete logical restore point. Finder and the CLI enumerate only completed runs. Failed or cancelled runs may leave valid staged or content-addressed work that a later run can reuse, but they do not become restore points.

Deduplication is not retention

Deduplication reduces repeated storage. Retention decides which restore points remain promised. Deleting an old run must not remove a shared object still referenced by a newer run. A repository therefore needs reachability and cleanup rules, not just hashes.

Azivault has content-addressed reuse and immutable blob semantics, but it should not be described as having every mature retention and pruning feature available in longer-established products such as Arq or restic.

Snapshots, clones, sync, and backup

An APFS snapshot or clone can provide a stable local view and fast copy-on-write history. It does not automatically create an offsite copy. Synchronization makes two working locations converge and may propagate unwanted changes. Repository backup creates explicit recovery history with its own storage contract.

Azivault uses an APFS clone when available to reduce race exposure while reading the source. It is not a volume-wide atomic snapshot, and cloud-only placeholders must be materialized from the live path because a clone can preserve the placeholder without its bytes.

What makes incremental recovery safe

The backup must commit atomically enough that an interrupted run cannot replace the last known-good restore point. Stored objects need integrity checks. Metadata must identify which objects make up a completed run. Cleanup must understand shared references.

Test a restore from an older run, not only the latest one.
Verify the repository after interruption or storage migration.
Do not delete repository files manually because they look old or duplicated.
Keep recovery keys and storage credentials separate from repository contents.

Choose based on restore behavior

Ask whether a restore point is logically complete, how missing or corrupt objects are detected, whether recovery needs the original machine database, and what independent tools can read the format. These questions are more useful than choosing the product with the smallest advertised incremental upload.

FAQs

Is an incremental backup a complete restore point?

It can be. Modern repositories often present a complete logical snapshot while physically storing only new content. Traditional chains work differently.

Does Azivault make a new full copy every run?

No. It compares current state with the catalog and reuses valid content-addressed blobs for unchanged content.

Can I restore a failed Azivault run?

No. Only completed runs are exposed for restore. Failed or cancelled work must not replace the previous completed restore point.

Is a filesystem snapshot an offsite backup?

No. A local snapshot is useful history but remains vulnerable to loss of the device or storage system that contains it.