A full backup copies everything, every time. An incremental backup copies only what changed since the previous backup. Full backups are simple to restore but slow and storage-hungry. Incrementals are fast and small but make recovery longer and more dependent on an unbroken chain of files. For most websites the best answer is both: a full backup on a regular cycle with incrementals in between.
The rest of this guide shows how the two behave in practice, where the third type (differential) fits, and how to pick a schedule you will not regret on the day something breaks.
TL;DR
- A full backup copies all source data. An incremental copies only data changed since the previous backup, whether that one was full or incremental.
- Incrementals use the least storage and finish fastest. Restoring them takes more steps, because you need the full backup plus every incremental in order.
- A differential copies everything changed since the last full backup. It restores faster than a chain of incrementals but grows larger each day until the next full.
- A common starting pattern is a weekly full with daily incrementals. Set the frequency by how much work you can afford to lose, then test restores regularly.
Table of Contents
- What each backup type actually copies
- Side-by-side comparison
- A worked example with a real-looking site
- Restoring: where incrementals cost you
- Incremental vs differential: which one for you?
- Choosing a schedule for a website
- Retention, monitoring and testing restores
- Perspective: what we see on real sites
- Hosting that takes the backup chore off your plate
- Common mistakes to avoid
- FAQ
- Sources
What each backup type actually copies
The names sound technical, but each type answers one question: what does this run compare itself against?
Full backup
A full backup copies all source data: every file, every database, every setting in scope. Each full backup stands alone. If you have last night's full, you have everything as of last night, and you need nothing else to restore it.
That independence is its main virtue. The cost is that you copy unchanged data again and again. A site where 98% of the files never change still gets re-copied in full each run.
Incremental backup
An incremental backup contains only the changes since the previous backup, and "previous" means the previous backup of any kind. If you run a full backup on Sunday, Monday's incremental holds Monday's changes. Tuesday's holds only what changed after Monday's run. Wednesday's holds only what changed after Tuesday's.
Because changes are usually a small slice of the whole, each run is quick and small. That is why incrementals can run often, even several times a day on a busy store or a membership site.
Differential backup
A differential is the in-between option. It holds all changes since the last full backup, not since the last run. Monday's differential holds Monday's changes. Tuesday's holds Monday's and Tuesday's. By Saturday it holds almost the whole week.
Many readers arrive at this topic from the "incremental vs differential" question, so a dedicated section on it follows below.
Side-by-side comparison
The general pattern, as described by TechTarget's overview of backup types, looks like this:
| Full | Incremental | Differential | |
|---|---|---|---|
| Copies | Everything | Changes since the previous backup of any kind | Changes since the last full backup |
| Storage used | Most | Least | Starts small, grows until the next full |
| Backup time | Longest | Shortest | Grows until the next full |
| Restore needs | That one full backup | Full backup plus every incremental, in order | Full backup plus the latest differential |
| Restore speed | Fastest and simplest | Slowest, most steps | In between |
| Main risk | Wasted storage and time | One missing or damaged link breaks the chain | Larger files late in the cycle |
No type wins on every row. You are trading backup cost against restore cost, and the right trade depends on your site.
A worked example with a real-looking site
Numbers make the difference concrete. Take an illustrative small business site: 100 GB of files and databases, with roughly 2 GB of new or changed data each day. These figures are an example, not a measurement of any particular site.
Strategy A: a full backup every night, kept for 7 days. You store 7 copies of 100 GB, which is 700 GB. Each nightly run copies the full 100 GB.
Strategy B: one full on Sunday, incrementals Monday to Saturday. You store 100 GB plus six increments of about 2 GB each, roughly 112 GB. Each weekday run copies about 2 GB.
Strategy C: one full on Sunday, differentials Monday to Saturday. Monday's holds about 2 GB, Tuesday's about 4 GB, and so on up to about 12 GB on Saturday. The week totals roughly 100 GB plus 42 GB, about 142 GB.
Strategy B uses about a sixth of Strategy A's storage and a fiftieth of the copy volume per run. That gap is why almost nobody who runs daily backups of a growing site does a full every night.
Now the restore side. Say your site is hit on Friday morning and you want Thursday night's state.
- A: restore Thursday's full. One step.
- B: restore Sunday's full, then Monday, Tuesday, Wednesday and Thursday incrementals in order. Five steps.
- C: restore Sunday's full, then Thursday's differential. Two steps.
The saving in B is real, and so is the extra restore work. Whether the extra steps matter depends on how often you restore and how long you can be down.
Restoring: where incrementals cost you
For a full backup followed by incrementals, the standard approach is to restore the full backup first, then apply every incremental through your target time in order. For differentials, you restore the full backup and then only the latest differential for that target time.
Two practical consequences follow.
Restores take longer and are more fiddly. Each extra increment is another step where something can go wrong, and another file to fetch if your backups are stored off the server.
The chain is only as strong as its weakest link. Incrementals depend on the full backup plus every intermediate increment. A missing or damaged set can prevent complete recovery. If Wednesday's increment is corrupt, Thursday's is useless on its own, because it only describes changes since Wednesday.
This is the strongest argument for running fulls on a regular cycle. Cloud Backup documentation from T-Systems notes that periodic full backups shorten the interval incremental backups rely on, which improves reliability. Their suggested example is a full backup about once every 30 days with daily incrementals between. A site that cannot tolerate a long chain would choose a shorter cycle, such as weekly.
Incremental vs differential: which one for you?
The two differ in what they compare against. Incrementals compare to the last backup of any kind. Differentials compare to the last full. That single difference creates the trade-off.
- Incrementals are smaller and quicker to create, but the restore chain is longer.
- Differentials get bigger each day, but restoring needs only two pieces: the full and the latest differential.
MySQL's backup documentation frames the choice simply: weigh your available storage against how quickly you need to restore. If storage is tight and you can tolerate a slower recovery, choose incrementals. If a fast, simple restore matters more and you have the space, choose differentials.
A rough rule for site owners: if your content changes slowly and your full cycle is short (weekly), the difference is small and either works. If you run a high-traffic store with constant database writes, differentials can balloon by midweek, and incrementals (plus a shorter full cycle) tend to be the more practical pattern.
Choosing a schedule for a website
Start with one question: how much work can you afford to lose? That is your recovery point objective. A brochure site that changes monthly can lose a day of edits without drama. An online store that takes orders every few minutes cannot lose even an hour.
TechTarget's backup scheduling guidance says to set frequency from that objective while accounting for data size and available resources. It gives daily incrementals with weekly fulls as a common starting pattern. Use it as a baseline, then adjust.
Here is how that might play out for different sites. These are our suggestions built on the pattern above, not fixed rules.
| Site type | Reasonable starting point |
|---|---|
| Brochure site or portfolio, rare edits | Weekly full, daily incremental or differential |
| Blog or content site, posts a few times a week | Weekly full, daily incrementals |
| Online store or membership site | Weekly full, incrementals several times a day for the database, plus a daily file backup |
| Agency or developer managing many client sites | Per-site schedule, with fulls before any major update or deployment |
Two habits matter more than the exact numbers.
Take a full backup before risky changes. Before a major plugin update, theme change or migration, make a fresh full backup so you have one clean, standalone restore point. A staging site lets you test the change first, which cuts the odds you will need that backup at all.
Keep backups off the machine they protect. A backup on the same server as the site disappears with the server. Store copies elsewhere, for example on a separate storage server built for backups and archives.
Retention, monitoring and testing restores
Retention is how long you keep each backup. TechTarget recommends setting retention for each backup type, automating and monitoring the jobs, and testing restores regularly. Because an incremental is useless without its full, retention for the two has to be linked: never delete a full backup while increments that depend on it are still needed.
A workable retention plan for a small site might keep daily backups for two weeks, weekly fulls for two months, and one monthly full for a year. Adjust for storage and for any legal or contractual obligations you have around customer data. If you hold records subject to specific rules, ask your accountant or attorney how long you must keep them.
For a wider checklist on keeping backups healthy, including maintenance and error monitoring, these data backup best practices are worth a read alongside this guide.
On testing: the guidance is to regularly test restores to confirm data can be recovered and to catch problems early. It does not prescribe one universal interval, so pick one you will actually keep. A sensible habit is a test restore to a staging copy after any change to your backup setup, and on a recurring calendar reminder otherwise. A backup you have never restored is a hope, not a plan.
When you test, check more than "the files came back." Open the site, log in, place a test order, and confirm the database matches what you expect. If you run WordPress, our guide to restoring WordPress from a backup walks through host, plugin and FTP routes.
Perspective: what we see on real sites
Most site owners do not need to become backup engineers. They need two things: a recent copy that is stored somewhere safe, and proof it restores.
We look after sites with a team of SRE and DevOps engineers in the EU and US, and the failures we see are rarely about picking the wrong backup type. They are about silence. A job that stopped running three weeks ago and nobody noticed. A backup stored on the same server as the site. A chain of increments with one broken link that nobody found until the day of the restore.
Our advice is to favor boring and verifiable. A regular full backup, increments or daily copies in between, off-server storage, and a restore test on a staging copy. If the choice is between a clever scheme you do not understand and a simple one you have tested, take the simple one.
We also think backup terms should be plain. If you are not sure what your host actually keeps, how long, and how to restore it yourself, ask before you need it. For a broader look at the categories, see our overview of types of website backups and the SMB website backup guide.
— Ihor
Hosting that takes the backup chore off your plate
If you would rather not build a backup routine from scratch, our plans include daily backups and free migration from your current host, run by engineers who handle restores for a living. WordPress sites can start on our WordPress hosting plans, and general sites on shared hosting. Larger or custom setups can move to a VPS. Every plan is covered by a 30-day money-back guarantee, so you can check how it works for your site.
Our pages list the current plans and terms, so check them before you choose.
Common mistakes to avoid
A few patterns cause most backup disappointments, whichever type you choose.
- Running incrementals forever without a new full. The chain grows, restores slow down, and one bad file threatens everything after it.
- Deleting old fulls to save space. The increments that depend on them become unusable.
- Backing up files but not the database. On a dynamic site the database holds the orders, posts and users. Files alone are rarely enough.
- Leaving backups on the same server. Hardware failure, a compromised account or an accidental deletion can take both site and backup.
- Never testing a restore. The first time you learn it does not work should not be during an outage.
- Ignoring failure alerts. Automation helps only if someone reads the notifications.
For the bigger picture on why this all matters to uptime, see our piece on why backups are essential for reliable hosting and the uptime best practices guide.
FAQ
Is incremental better than full backup?
Neither is better in every case. Incremental backups save time and storage and can run often, while full backups are the simplest and fastest to restore. Most sites do best combining them: a full backup on a regular cycle with incrementals between.
What is the difference between incremental and differential backups?
An incremental holds the changes since the previous backup of any kind. A differential holds all changes since the last full backup. Restoring a differential needs the full plus the latest differential, while incrementals need the full plus every increment in order.
How often should I run a full backup?
Weekly is a common choice, and the T-Systems documentation gives roughly every 30 days as an example for a lower-change environment. A shorter cycle makes the incremental chain shorter and restores more reliable. Choose by how much data you can afford to lose and how large your site is.
Can I delete old incremental backups?
Only with care. An incremental depends on the full backup and on every increment before it, so removing one can make later ones unusable. Retire a whole cycle (the full and all its increments) together, once a newer full backup is verified.
How often should I test a restore?
There is no single official interval, but testing regularly is a standard recommendation. Do a test restore to a staging copy after any change to your backup setup and on a recurring schedule you will keep, and confirm the site and database both work.
Sources
- Types of backup explained: Incremental vs. differential vs. full, TechTarget
- Backup scheduling best practices to ensure availability, TechTarget
- MySQL Enterprise Backup 8.4 User's Guide: incremental backups
- What Are Full Backup and Incremental Backup? Cloud Backup and Recovery documentation