"Backup" gets used as if it were one thing, but what actually gets copied, how long that takes, how much storage it consumes, and how long a restore takes afterward are all determined by which of three underlying strategies is running: full, incremental or differential. Most backup systems — including the ones built into typical hosting control panels — use some combination of the three rather than picking just one, so understanding how each behaves is what makes a backup schedule a deliberate choice instead of whatever the default happened to be.
What a backup actually copies
A website backup is typically two things bundled together: the files (the application code, themes, plugins, uploaded media) and the database (posts, products, orders, user accounts — anything stored as structured data rather than a file on disk). Both change over time, usually at different rates — a media library might grow steadily while the database changes constantly on an active site. A backup strategy has to account for both, and the full/incremental/differential distinction applies to each independently, though in practice most systems back up files and database on the same schedule for simplicity.
Full backups: a complete copy every time
A full backup copies everything, every time it runs, regardless of what changed since the last one. It's the simplest to understand and the simplest to restore from, because a single full backup is a complete, self-contained snapshot — restoring means replacing everything with that one copy, with no other backups involved. The cost is that it's also the most expensive to run repeatedly: a full backup of a 5GB site takes roughly the same time and storage whether 5MB or 2GB changed since yesterday, because it doesn't check what changed at all, it just copies all of it again.
Incremental backups: only what changed since the last backup
An incremental backup copies only the files and database changes made since the most recent backup of any kind — full or incremental. This makes each individual incremental backup fast and small, since on most days only a small fraction of a site's content actually changes. The tradeoff shows up at restore time: recovering a specific point requires the last full backup plus every incremental backup made since then, applied in order. If a full backup ran on Monday and incrementals ran Tuesday through Friday, restoring Friday's state means applying all five backups in sequence — and if one incremental in that chain is corrupted or missing, everything after it in the chain is generally unusable too.
Differential backups: everything since the last full backup
A differential backup copies everything changed since the last full backup, not since the last backup of any kind. Each differential backup grows larger than the last as the days since the full backup accumulate, but restoring only ever needs two backups: the last full one, plus the most recent differential. There's no chain of several files that all need to be intact — just those two — which makes differential a middle ground between full backups' simplicity and incremental backups' storage efficiency.
Comparing the three side by side
| Factor | Full | Incremental | Differential |
|---|---|---|---|
| What it copies | Everything, every run | Changes since the last backup of any kind | Changes since the last full backup |
| Backup size over time | Constant, largest | Smallest, stays small | Grows until the next full backup |
| Backup speed | Slowest | Fastest | Moderate, slows as it grows |
| Restore complexity | One file, simplest | Full backup + every incremental in the chain | Full backup + one differential |
| Risk if one backup is bad | Only that backup is lost | Everything after the bad link in the chain is affected | Only affects restores needing that specific differential |
A worked example: a 5GB site over one week
Say a 5GB WordPress site runs a full backup every Sunday, and something runs daily the rest of the week. With daily incrementals: Monday's backup might be 40MB (a few posts, some plugin updates), and each day after stays similarly small as long as daily change volume stays modest — by Saturday, total storage for the week is roughly 5GB (Sunday's full) plus six small incrementals, maybe 5.3GB combined. Restoring Saturday's state means applying Sunday's full backup, then all six incrementals in order. With daily differentials instead: Monday's is also around 40MB, but Tuesday's differential includes everything since Sunday — Monday's changes plus Tuesday's, so maybe 75MB — and it keeps growing each day, reaching perhaps 250MB by Saturday as a week's worth of changes accumulate into one file. Total storage for the week ends up higher than the incremental approach, but restoring Saturday's state only needs two files: Sunday's full backup and Saturday's differential.
Where backups are stored matters as much as how often
A backup stored on the same physical server it's protecting defeats much of its own purpose: if that server suffers a hardware failure, gets compromised, or its storage is wiped or encrypted by ransomware, a backup sitting on the same disk is lost along with everything else it was meant to protect. This is the reasoning behind the widely used "3-2-1" principle — keep at least 3 copies of data, on at least 2 different types of storage, with at least 1 copy stored off-site, away from the server itself. For a typical business website, this translates into a backup destination that's physically or at least logically separate from the hosting account it protects — a separate storage service, a different data center, or at minimum a different physical disk than the one the live site runs on. A nightly backup job that writes its output to the same disk as the site it's backing up still has real value against accidental deletion or a bad deployment, but it offers no protection at all against the disk itself failing or the whole account being compromised, which is exactly the scenario a backup is often most needed for.
What restoring actually involves
Restoring is where the practical difference between these strategies actually gets felt, usually during an incident, which is the worst time to discover a backup chain has a gap in it. A full-backup-only restore is a single operation. A differential restore is two operations applied in a fixed order. An incremental restore can be many operations applied in a fixed order, and every one of those operations has to succeed for the final state to be correct — which is exactly why systems using long incremental chains need the full backup and every incremental in between to be verified intact, not just present. This is also why "do we have a backup" is the wrong question to test; the right question is "have we actually restored from this backup successfully," since an untested backup chain is an assumption, not a safeguard.
Which type to use, and when
Most real backup schedules aren't a pure choice of one strategy — they're a full backup on some regular cadence (weekly is common) combined with either incremental or differential backups filling the gaps between full backups, and the choice between those two is mostly about how much storage is available versus how tolerable a multi-step restore is. A site with limited backup storage and infrequent, predictable restores benefits from incremental's smaller footprint. A site where restore speed and simplicity during an incident matters more than storage cost benefits from differential's two-file restore, especially once storage is cheap relative to the value of time during an outage. Neither choice matters much if backups aren't tested — see How Often Should You Back Up a Business Website? for how to reason about frequency and retention once the backup type itself is decided, and Common Website Security Mistakes for where "no tested backup strategy" sits among the more common, avoidable failures.
