A file server fails on Saturday afternoon. The recovery plan assumes a few hours, but the last full backup dates from Sunday and six incremental backups followed it. The administrator restores them one after another and hits a read error on the Wednesday one. The data can only be brought back to Tuesday, and the department’s remaining days of work have to be rebuilt from email and memory.
Incremental vs differential backup is usually compared in terms of disk space and the time it takes to run a backup. In cybersecurity and business continuity, something else matters more: how many sets you have to restore on the worst day of the cycle, how many copies each restore point depends on, and whether anyone has ever tested that worst day.
What types of backup are there and how do they differ?
The basic types of backup are full, incremental and differential, and they differ in the point from which they count changes. NIST SP 800-34 Rev. 1, the contingency planning guide of May 2010 (updated in November 2010), describes them as three common methods for performing system backups.
A full backup captures all files on the disk or in the selected folder. An incremental backup captures files created or changed since the last backup, regardless of its type. A differential backup captures files created or changed since the last full backup, so a file changed after it goes into every subsequent differential backup until the next full one.
The concept of a backup copy is explained in the glossary, and the basic comparison of backup types, the 3-2-1-1-0 strategy and the place of backups in a recovery plan are covered in the guide what is backup. When choosing a scheme, however, the consequences that a table of features does not show are what count.
What determines restore time from incremental and differential backups?
Restore time depends above all on the number of sets that have to be restored in sequence, and that number grows with every day of the cycle. NIST SP 800-34 Rev. 1 notes that restoring from incremental backups may require media from many different backup operations, while with a differential backup the full backup and the latest differential are enough.
The difference is easiest to see in a weekly cycle with a full backup on Sunday:
| Day of failure | Incremental backup: sets to restore | Differential backup: sets to restore | What grows during the week |
|---|---|---|---|
| Monday | full and Monday’s | full and Monday’s | nothing, both schemes are equal |
| Wednesday | full and three incrementals | full and Wednesday’s differential | length of the incremental chain |
| Friday | full and five incrementals | full and Friday’s differential | size of the differential backup |
| Saturday | full and six incrementals | full and Saturday’s differential | both: chain and size |
The worst day for an incremental backup is the last day before the next full backup. For a differential backup the number of sets is constant, but the latest differential is then the largest, because it contains all the changes of the week.
That time has to be compared with the system’s RTO. NIST defines RTO as the maximum amount of time a resource can remain unavailable before there is an unacceptable impact on other resources and processes. On top of the time to copy the data you have to add preparing the environment, verification and starting the application, and each of these steps takes longer when there are more sets.
How does the type of backup affect RPO and data loss?
The type of backup does not set RPO directly, because RPO depends on how often a backup is made, not on whether it is full, incremental or differential. NIST SP 800-34 Rev. 1 describes RPO as the point in time before a disruption to which process data can be recovered from the most recent backup, that is, a measure of tolerable data loss.
The type of backup does, however, affect the cost of frequent backups. An incremental backup runs quickly and takes little space, so it can be run more often, for example several times a day. A full backup every hour would be too costly for a large data set, even though it would make restores the simplest.
NIST SP 800-209 of October 2020 illustrates the same relationship with snapshots: if requirements allow at most five minutes of committed data to be lost, snapshots have to be taken every five minutes or more often. Frequency is set from RPO, and the type of backup is chosen so that this frequency is achievable.
Why can one damaged incremental backup block a restore?
One damaged incremental backup blocks the restore of every later point, because each subsequent incremental backup contains only the changes relative to the previous one. When the Wednesday link is missing, the Thursday, Friday and Saturday backups have nothing to refer to.
NIST SP 800-209 states the principle more generally: backup systems often use incremental backups that capture changes relative to a baseline copy, and such copies cannot be used for recovery without the baseline. The document recommends that copies intended for recovery from a cyberattack have an independent, full baseline copy.
A differential backup has a shorter chain: each point depends only on the last full backup. A damaged Wednesday differential does not prevent a restore from Thursday’s. Both schemes, however, share one weak point: if the full backup fails, no point in the entire cycle works. That is why integrity checks of the full backup matter most, and in an incremental scheme every link in the chain has to be checked as well.
Key takeaways:
- On its worst day an incremental backup requires the full backup and every increment of the cycle.
- A damaged increment cuts off every later restore point, and a damaged full backup the whole cycle.
- RPO sets the backup frequency, and the type of backup decides whether that frequency is achievable.
How much space and how long a backup window does each scheme need?
A full backup needs the most space and the longest window, an incremental backup the least, and a differential backup grows with every day of the cycle. NIST SP 800-34 Rev. 1 describes the same relationships: a full backup takes a long time, and repeating it for rarely changed files, such as system files, leads to excessive media requirements.
According to the same document, incremental backups use storage media more efficiently and shorten backup times. A differential backup takes less time than a full one but longer than an incremental one, because the amount of data changed since the last full backup grows every day until the next full backup.
In practice the backup window matters for systems that run around the clock and for links to remote storage. If the end-of-week differential no longer fits in the night window, the scheme has to change before backups start being interrupted or postponed.
How does retention interact with the type of backup?
Retention has to take dependencies between copies into account: a full backup cannot be deleted while even one incremental or differential backup that depends on it is still kept. A policy that requires 30 days of backups but deletes the full backup after 7 days in practice keeps copies that cannot be restored.
NIST SP 800-209 recommends that a data protection plan be established before deployment and specify, for each data tier, the frequency, retention and type of copies, for example 48 hourly snapshots and 30 daily backups. NIST SP 800-34 Rev. 1 adds that the policy should specify the minimum frequency and scope of backups based on data criticality and the rate at which new information is introduced.
This leads to a simple check: for every restore point the policy promises, the repository must hold the complete set of copies needed to restore it. You check it on the oldest promised point, because that is where a deleted baseline copy is most likely.
Does a snapshot replace a full backup?
A snapshot does not replace a full backup, because it usually depends on the very source data it is meant to protect. NIST SP 800-209 describes a snapshot as a storage-efficient form of point-in-time copy that stores only the portions of data changed relative to the source, so when the source is unavailable, the snapshots are often unusable as well.
The same document notes that in some schemes, such as snapshots, only incremental copies are used and the baseline copy is the production data itself. It also recommends that copies intended for recovery from a cyberattack have no dependency on production baseline data. Ransomware that encrypts the source volume can therefore take the snapshots of that volume away from the company too.
Snapshots have their place: they give a quick return to the state of an hour ago after a user error or a failed update. Beneath them, however, there has to be an independent full backup, ideally isolated and immutable. Why immutability is a property of the whole setup rather than of the storage medium alone is explained in the article on immutable backup.
How do you match a backup scheme to a system’s requirements?
You match a backup scheme starting from the system’s requirements: first RTO and RPO, then the backup window and retention, and only at the end the type of backup that meets those requirements at a reasonable cost. NIST SP 800-34 Rev. 1 gives the example of a full backup at the weekend and differential backups every evening.
A system with a short RTO, such as a transactional database, needs as few sets to restore as possible: frequent full backups or differential backups, supplemented with snapshots for a quick rollback. A system with a large amount of rarely changed data, such as a document archive, copes well with a weekly or less frequent full backup and daily increments, because the longer restore fits within its RTO.
Workstations and SaaS services follow different rules: what counts there is restoring individual files and mailboxes, not the whole system. Retention and versioning decide most here. How cloud backups and Microsoft 365 backups work is described in the articles on cloud backup and Office 365 backup.
How do you check that your chosen scheme fits the restore time?
You check a scheme with a restore test on the worst day of the cycle, that is from the last point before the next full backup, and by measuring the time from the decision to restore to a working application. A test on Monday, when the chain has a single link, says nothing about Saturday.
NIST SP 800-209 recommends periodic backup tests, at least monthly for critical data, and for applications with strict restoration speed requirements a full end-to-end test restore to an isolated environment. As of 21 September 2026. Article 32(1) of the GDPR lists the ability to restore the availability of personal data in a timely manner and regular testing of the effectiveness of measures, and Article 21(2)(c) of the NIS2 Directive, which applies through national transposition law (in Poland, the Act on the National Cybersecurity System), lists business continuity, including backup management, among the risk-management measures that Member States must require of entities.
It is worth recording the test result as three numbers: restore time, number of sets and age of the oldest set in the chain. If the time exceeds the RTO, the solution is a more frequent full backup or a switch to differential backups, not an optimistic assumption in the plan.
How do you compare backup schemes before deciding?
You compare schemes on the same criteria: number of sets on the worst day, sensitivity to damage to a single copy, backup window, storage use and what has to be measured in the test. The table below sets out three common schemes for a weekly cycle.
| Criterion | Full backup every day | Full on Sunday plus differentials | Full on Sunday plus incrementals | What to measure in the test |
|---|---|---|---|---|
| Sets on the worst day | one | two | seven | restore time on Saturday |
| Damaged incremental or differential copy | one day is lost | one day is lost | the days until the end of the cycle are lost | restore while skipping the damaged copy |
| Damaged full copy | one day is lost | the whole cycle is lost | the whole cycle is lost | integrity check of the full backup |
| Backup window | longest, every day | grows towards the end of the week | shortest except on Sunday | backup time on the last day of the cycle |
| Storage use | largest | medium, grows during the cycle | smallest | storage use at full retention |
| Retention requirement | every copy is independent | full kept until the end of the cycle and beyond | full and the entire chain kept together | complete sets for the oldest point |
| Suits | small, critical systems with a short RTO | systems with a short RTO and a lot of data | large, rarely changed data sets, longer RTO | result consistent with RTO and RPO |
Each scheme wins in a different place, so the last column says what to check in a test before a scheme goes into the policy.
Key takeaways:
- Test the restore on the last day of the cycle, because that is where the chain is longest.
- Retention must protect the full backup for as long as any copy depending on it exists.
- Snapshots speed up restores, but beneath them there has to be an independent full backup.
How can nFlo help you choose and test backups?
As part of its Comprehensive Backup Services, nFlo starts with an audit of current backups: what is protected, what the RPO and RTO are and where the coverage gaps are. On that basis it designs a strategy matched to the RPO and RTO, implements Veeam or Commvault solutions and every month restores a random virtual machine or database to an isolated environment.
For companies that want to keep backups in the cloud in Poland, nFlo implements Xopero ONE. According to the product description, the platform protects workstations, Windows and Linux servers, Microsoft 365 and Google Workspace, stores data in data centres in Poland and offers deduplication, configurable retention (days or versions), immutable backups and versioning. As an Xopero partner, nFlo helps choose the plan, deploy the agents and configure the policies. If you want to check whether your backups will restore on the worst day of the cycle, contact us.
What else is worth knowing about backup types?
Which backup restores the fastest?
A full backup, because a single set is enough to restore it. A differential backup needs two sets, the full one and the latest differential, and an incremental backup needs the full one and every subsequent increment, as NIST SP 800-34 Rev. 1 describes.
Is an incremental backup less safe than a differential one?
Not in itself, but it creates a longer chain of dependencies. Damage to one incremental backup cuts off every later restore point, while with differential backups each point depends only on the full backup. That is why integrity checks of every copy matter more with increments.
How often should you run a full backup?
Often enough that a restore on the worst day of the cycle fits within the system’s RTO. NIST SP 800-34 Rev. 1 gives the example of a full backup at the weekend and differential backups every evening, but the right cycle comes from a restore test, not from the example.
Is a snapshot a backup?
Not on its own. NIST SP 800-209 describes a snapshot as a record of changes relative to the source data and notes that when the source is unavailable, the snapshots are often unusable too. A snapshot speeds up restores but does not replace an independent full backup.
Do regulations require a specific type of backup?
As of 21 September 2026. Neither the GDPR nor the NIS2 Directive specifies a type of backup. The GDPR requires the ability to restore the availability of data in a timely manner and regular testing of measures, and NIS2 lists backup management among the measures that Member States must require of entities, through national transposition law.
