Home  ›  Glossary  ›  Differential Backup

What is differential backup?

Differential backup is a backup that copies everything changed since the last full backup. Each run is cumulative, so restoring any given day takes two pieces: the full and that day's differential.

Two files per restore instead of a chain

With incremental backups, restoring Friday from a Sunday full means applying the full and five incrementals in order, and one damaged file in the middle breaks every later restore point. A differential schedule restores the same Friday from the full plus Friday's file, and a damaged Wednesday differential affects Wednesday alone.

The mechanism explains both the benefit and the cost. The backup software keeps a reference to the last full and copies whatever differs from it. A differential run never moves that reference forward, so a block changed on Monday is copied again on Tuesday, Wednesday and each day after until the next full resets the count.

Change detection sets the granularity. File-level detection copies an entire file when any part of it changes, so a large database file with one modified page goes across in full. Block-level change tracking, standard for virtual machine backups, copies only the disk regions that were written. SQL Server applies the same idea inside the engine, tracking the database extents changed since the last full so a database differential copies only those.

Growth from day one to day six after a full

Take a 10 TB source with a weekly full and 200 GB of new changes each day:

Day after fullDifferentialIncremental
1200 GB200 GB
3600 GB200 GB
61.2 TB200 GB
Week total4.2 TB1.2 TB

Over the week the differentials take three and a half times the space of the equivalent incrementals. Growth is slower when the same blocks change every day, since a block rewritten daily appears only once in each differential.

The amount read during a restore is close for both methods. Restoring day five from differentials reads the 10 TB full plus a 1 TB differential; from incrementals it reads the full plus five 200 GB files, also about 11 TB. The difference lies in how many separate files all have to be intact and read in sequence.

Database jobs, file servers and lock dates

Late in the cycle, a differential of a busy file server can approach the size of a full, and the nightly job runs a little longer each day. On a repository of fixed size that growth repeats for every cycle retention keeps. In return, restores are quicker to start and easier to reason about when dozens of systems have to come back during an incident, and only the full remains a single point of failure.

Over four weekly cycles, the table above adds up to about 57 TB before reduction (four fulls plus four weeks of differentials), against roughly 45 TB for incrementals. On a deduplicating repository much of that gap closes, because blocks repeated across a week's differentials are stored once, and the extra cost shows up mainly as network traffic and job time.

Differentials show up most often in database protection, such as SQL Server differential backups, and in file-level jobs. Many virtual machine backup products default instead to incremental chains with periodic or synthetic fulls.

Retention locks inherit the same dependency. A differential restores only while its full exists, so a differential locked for 30 days on top of a full locked for 14 is protected in name only from day 15 onward, once the full has been allowed to expire.

ARTESCA and differential backup

Full and differential backups reach ARTESCA as separate S3 objects, each with its own Object Lock retain-until date, chosen by the backup software or by a default retention rule on the bucket. Compliance mode stops every user, root included, from removing either object early, while governance mode leaves a bypass open to identities granted it.

ARTESCA keeps no record of which differential depends on which full. That relationship lives in the backup catalog, so the storage does not check a differential's lock against its full's. The cumulative growth through each cycle shows up directly in bucket capacity, visible in the management interface and in Grafana and Prometheus metrics.