Backup schemes: full, incremental, differential, synthetic, and where each fits

Why this matters

Backup is the last objective in this course and it is the one that decides the outcome of several of the earlier ones. Ransomware, a failed disk, a failed upgrade, a stolen laptop, a deleted folder — each of those is either an inconvenience or a disaster, and which one it is was decided before the incident by whether a usable backup existed.

The exam asks about the schemes, their storage and restore costs, and the 3-2-1 rule. What makes this worth learning properly is that the arithmetic is simple and the failures are not technical: the backups that let people down are almost always the ones nobody checked, or the ones on a disk that was attached to the machine when it was encrypted.

The lesson

What a backup is for, which decides everything else about it

Everything else follows from the answer to one question: what is this backup for?

Four different purposes, with four different right answers:

• Hardware failure. A disk dies and the data must come back. A copy on another device is sufficient; it can be recent, and it can be on site.
• Accidental deletion or corruption. Somebody overwrites a file or deletes a folder and notices next week. This needs versions over time, not a mirror. A synchronised copy propagates the deletion immediately and helps with nothing.
• Ransomware or compromise. This needs versions and copies the attacker cannot reach — offline, immutable, or under separate credentials. A backup on a mapped drive is encrypted along with everything else.
• Fire, flood, theft. This needs a copy somewhere else. Everything on site is lost together.

The consequences worth stating plainly:

• Synchronisation is not backup. Cloud file sync propagates every change, including deletions and encryption, to every device. Most services keep version history, which is what rescues people — and that is the backup part, not the sync part.
• RAID is not backup. It keeps a system running through a disk failure and reproduces every deletion instantly.
• A snapshot is not backup, for the reasons in the next section.

So the first question in any backup conversation is which of the four risks is being addressed, and the honest answer for most people is all of them — which is what the 3-2-1 rule exists to satisfy.

Full, incremental and differential, with the restore cost of each worked through

Three schemes, and the trade is always between how long the backup takes and how long the restore takes.

Full. Everything, every time. Longest to back up, largest storage, and the simplest restore: one set, one operation.

Incremental. Everything changed since the last backup of any kind. Fastest to back up and smallest storage. The restore needs the last full plus every incremental since, in order, and a single damaged member of that chain breaks it.

Differential. Everything changed since the last full backup. Each one is larger than the last, growing until the next full. The restore needs the last full plus the most recent differential — two sets, whatever day it is.

Worked through. A full backup on Sunday, then daily backups, and the disk fails on Friday afternoon.

• Incremental: restore Sunday's full, then Monday, Tuesday, Wednesday, Thursday and Friday's — six operations, and all six must be readable.
• Differential: restore Sunday's full, then Thursday's differential — two operations. Friday's has not run yet.

The trade in one line: incremental is cheap to make and expensive to restore; differential is the reverse. Full is expensive to make and cheapest to restore.

The other examinable detail: incremental backups typically clear the archive attribute and differentials do not, which is the mechanism behind the difference.

Which to choose: think about the restore, because that is the day that matters. An organisation that cannot tolerate a long restore should accept larger backups.

Synthetic full backups, snapshots, and why a snapshot is not a backup

Two more terms, and one important negative.

Synthetic full. Rather than reading everything from the source again, the backup system builds a new full backup by combining the previous full with the incrementals since. The source is read once; the full set is assembled on the backup storage. The benefit is a full backup's restore simplicity at an incremental's cost to the live system, and it is what most modern backup products do.

Snapshots. A point-in-time view of a volume or a virtual machine, taken almost instantly by recording changes rather than copying data. Extremely useful: it is what makes a consistent backup of a running system possible, and it is what lets you revert a virtual machine after an experiment — which is what the disposable machine lesson at the start of this course was built on.

Why a snapshot is not a backup, which is the examinable point:

• It lives on the same storage as the original. The disk that fails takes both.
• It depends on the original being intact; a snapshot is a set of differences from something, not an independent copy.
• Deleting the virtual machine deletes its snapshots.
• They are not designed to be retained, and performance degrades as they accumulate.

The rule: snapshots are for short-term reversibility — before an update, before a change, during a backup. A backup is an independent copy on separate storage. Anything that fails when the original storage fails is not a backup, and that single test also disposes of RAID, of sync, and of a second partition on the same disk.

Retention, versioning, and the ransomware case that changed the arithmetic

Retention decides how far back you can go, and ransomware changed what a sensible answer looks like.

Versioning keeps multiple copies of a file over time, so you can retrieve the state from before a change. Without it, a backup that runs nightly faithfully replaces the good copy with the corrupted one, and by the time anyone notices, every copy is bad.

Retention is how long each is kept. A common shape is daily backups for a month, weekly for a quarter, monthly for a year, yearly beyond — the grandfather-father-son pattern, which balances storage against reach.

The arithmetic ransomware changed: the assumption used to be that problems are noticed within a day or two, so a week of daily backups was enough. That assumption is wrong now. Attackers routinely spend weeks inside a network before encrypting anything, and they specifically look for and destroy backups first. So:

• Retention has to reach back further than the time it takes to notice, which may be a month or more.
• Backups must be unreachable from the machines being backed up — offline, or immutable so they cannot be deleted or overwritten even with valid credentials, or under separate credentials that the compromised estate does not hold.
• The backup system is a target and needs its own protection: separate authentication, multifactor, and alerting when backups are deleted.

Immutability is the modern answer and it is worth knowing the term: storage that accepts writes and refuses changes or deletions until a retention period expires. An attacker with full administrative rights cannot remove those copies, which is precisely the property that was missing before.

Backup media and destinations, including the one that is offline

Where the copies live decides which risks they cover.

• External disk attached to the machine. Cheap and easy. Covers hardware failure and nothing else: it is encrypted with everything else, and it burns with the building. Useful as one copy of three.
• Network attached storage or a file server. Better for multiple machines, and still on the same site and reachable by anything with credentials.
• Cloud backup. Covers off-site automatically, usually with versioning and often with immutability. The considerations are restore time for large volumes, ongoing cost, and the credentials protecting it.
• Tape. Still used at scale, because it is cheap per terabyte and it is inherently offline once ejected. Slow to restore, and needs its own media handling.
• Offline disk, rotated. The practical small-scale version of tape: two external disks, one always disconnected and ideally off site, swapped weekly. Unglamorous and effective.

The one that matters most is the offline copy, and it is the one most often missing. An always-connected backup is a backup that ransomware encrypts, that an accidental delete can reach, and that a power surge can take with the machine. Disconnecting it is a physical act with no software equivalent, which is exactly why it works.

And the practical note: whichever destination, know how long a restore takes. A cloud backup of two terabytes on a slow connection is a week, which may be an acceptable answer or a catastrophic one — and the time to find out is not the morning after.