A full backup copies all selected data. A differential backup copies what has changed since the last full backup, and an incremental backup copies what has changed since the previous backup of any kind. A transaction log backup is different in kind: it saves a database’s log records rather than data files, which makes point-in-time recovery possible. Full, differential, and incremental backups determine how long a restore chain is; log backups determine how much data you can lose.
Key Takeaways
A full backup is the only self-contained type. Differential and incremental backups cannot be restored without their earlier parent backups.
A differential restore needs two data backups (the full and the latest differential), but each differential grows until the next full backup, according to Microsoft's SQL Server documentation.
An incremental backup is the smaller per run, but a restore needs the full backup plus every incremental in order.
Transaction log backups exist only where a system keeps a log, such as SQL Server in the full or bulk-logged recovery model or PostgreSQL with WAL archiving. They, not data backups, set your recovery point.
Names are not portable. Oracle RMAN's default “incremental” is a differential, SQL Server has no incremental data backup, and PostgreSQL added native incremental backup only in version 17.
The Four Backup Types at a Glance
Type | Copies | Depends on | A restore needs | Size over time | Main job |
Full | All selected data | Nothing | The backup itself | Roughly constant | Baseline and restore starting point |
Differential | Data changed since the last full backup | The last full backup | Full + latest differential | Grows until the next full | Cap the data-backup chain at two files |
Incremental | Data changed since the previous backup of any type | The previous backup, back to the last full | Full + every incremental, in order | Follows the change rate per interval | Shortest backup window, smallest copy |
Transaction log | Log records since the previous log backup | A full backup, then an unbroken log chain | Full (+ differential) + every log up to the target time | Follows write volume | Point-in-time recovery and a short RPO |
What is a Full Backup?
A full backup copies the entire data source, so it can be restored on its own. Azure Backup's architecture documentation describes it as containing the entire data source and notes that it uses more network bandwidth than differential or incremental backups. For databases, Microsoft's SQL Server on Azure VMs training module states that a full database backup contains enough information to restore the database to the point at which the backup finished.
Why it matters: every other type hangs off a full backup.
Cost: the most time, bandwidth, and storage per run.
Best fit: small data sets and read-only databases, where Microsoft notes that full backups used alone are easier to manage than full plus differential.
What is a Differential Backup?
A differential backup copies only the data that has changed since the most recent full backup, and it keeps copying those same changes until a new full backup resets the base. In SQL Server, Microsoft explains that a bitmap holds one bit per extent, an extent being eight physically contiguous pages, and the bit is set for every extent updated since the base.
Example. Azure Backup's documentation uses a ten-block data source. Blocks A2, A3, A4, and A9 change in month one, and A5 changes in month two. The month-three differential contains A2, A3, A4, A9 and A5. A month-three incremental would contain only A5.
Restore. Restore the full backup, then only the latest differential. Microsoft cautions that a differential can eventually approach the size of its base and lose its speed advantage, and recommends a new full backup at set intervals, for example a weekly full with differentials during the week.
Limits.
Change is tracked per extent (eight 8 KB pages, or 64 KB), not per row, so scattered small writes can make a differential larger than the logical change volume. SQL Server differential backups rely on an extent-level differential bitmap, according to Microsoft SQL Server documentation.
A copy-only full backup does not become a differential base, and a copy-only backup does not change the bitmap. A non-copy-only full backup taken by another tool becomes the new base.
Under the full recovery model, differentials can reduce the number of log backups you must restore (Microsoft).
What is an Incremental Backup?
An incremental backup copies only the data that changed since the previous backup, whether that was a full or another incremental. It depends on a change-tracking mechanism that tells the backup tool which blocks changed, and the mechanism differs by platform:
VMware vSphere: Changed Block Tracking (CBT), a VMkernel feature that Broadcom documents as accessible to third-party backup applications through the vSphere APIs.
Microsoft Hyper-V: resilient change tracking (RCT), used with reference points for backups from Windows Server 2016 onward (Microsoft Learn).
Oracle Database: block change tracking, a change-tracking file that RMAN uses to avoid scanning entire data files (Oracle documentation).
PostgreSQL 17 and later: WAL summaries, which tell pg_basebackup --incremental which blocks changed (PostgreSQL documentation; version introduced per the PostgreSQL 17 release notes).
Cost: the chain. PostgreSQL's documentation states that restoring an incremental backup requires all earlier backups it depends on, combined with pg_combinebackup, and that PostgreSQL has no built-in way to tell which backups are still needed. You must track those relationships yourself (PostgreSQL documentation).
When it pays off. Microsoft SQL Server documentation states that incremental backups typically make sense for relatively large databases where a significant portion of the data changes slowly. For a small database, full backups are simpler, and for a large database that is heavily modified throughout, incrementals will not be much smaller than fulls.
What is a Transaction Log Backup?
A transaction log backup saves the database's log of changes instead of its data files, so a restore can replay changes and stop at a chosen point in time. In SQL Server, it applies to databases in the full or bulk-logged recovery model, and at least one full backup must exist first (Microsoft Learn). The simple recovery model does not allow log backups (Microsoft training module).
The log chain. The sequence of log backups is independent of data backups. Microsoft's example shows a log backup that spans the moment a full backup was taken without breaking the chain. If one log backup in the chain is lost or damaged, you can restore only the logs before the gap (Microsoft Learn).
Log truncation. Under the full and bulk-logged models, log space is reused only after a log backup (except for copy-only log backups), per Microsoft's transaction log documentation. A full backup does not do this.
How often. Microsoft says the frequency depends on your tolerance for work loss and suggests that every 15 to 30 minutes might be enough, with more frequent backups for tighter requirements.
PostgreSQL equivalent. PostgreSQL combines a base backup with archived write-ahead log (WAL) files. This supports restoring to any time since the base backup, and it needs an unbroken sequence of archived WAL files from the backup's start. pg_dump output cannot be used for it (PostgreSQL documentation).
Which Backup Type Should You Use?
Choose by the restore you need to survive, not by the backup you want to run. NIST SP 800-34 Rev. 1 says backup policies should specify minimum frequency and scope (for example daily or weekly, incremental or full) based on data criticality and how often new information is introduced, and it defines RPO as the point in time to which data can be recovered and RTO as the maximum time a resource can stay unavailable.
Scenario | Suggested pattern | Why |
Small database or VM, little change | Full backups only | Simplest chain; PostgreSQL's documentation says full backups are simpler for small databases |
Large data set, mostly static, tight backup window | Weekly full + daily incremental, with change tracking enabled | Smallest daily copy; accept a longer restore chain |
Restore time matters more than storage | Weekly full + daily differential (or Oracle cumulative level 1) | Restore touches two data backups; Oracle's older documentation says cumulative backups are preferable when recovery time matters more than disk space |
Database RPO shorter than the data-backup interval | Add log backups, often every 15 to 30 minutes | Only log backups give point-in-time recovery |
Large database that is heavily modified | Full backups + logs | Incrementals will not be much smaller than fulls |
VM fleet on VMware or Hyper-V | Full + incremental using hypervisor change tracking | Change tracking makes incrementals cheap; verify it works |
Read-only database | Full backups only | Microsoft notes that fulls alone are easier to manage |
The comparison matrix is based on: PostgreSQL, Oracle 10.2 backup guide (older version; verify for your release), Microsoft.
Compare Backup Types by Restore Dependency, Not Just by Size
Direct answer: the number of files that must all be present, intact, and in the right order is a better measure of restore risk than backup size, and it differs sharply between types.
Take a weekly full backup on Sunday, a daily backup Monday to Saturday, and a failure on Saturday evening, restoring to the Saturday backup (illustrative arithmetic):
Pattern | Data-backup files needed | What happens if one is missing |
Daily full backups | 1 | Restore from the previous day's full |
Weekly full + daily differential | 2 (Sunday full + Saturday differential) | Without the full, every differential is unusable; without Saturday's, fall back to Friday's |
Weekly full + daily incremental | 7 (Sunday full + six incrementals) | Restore stops at the last intact link; later increments cannot be applied |
On top of any pattern, log-based recovery adds every log backup after the last data backup. With a log backup every 15 minutes and a failure at 18:00, that is 72 files after a midnight data backup.
Evidence. Microsoft states that a differential must be restored on top of its base, and that a lost log backup limits restore to the logs before the gap (differential, log chain). PostgreSQL's documentation says you must keep earlier backups yourself because nothing tracks which are still needed. Oracle's older guide notes that differential incrementals must be applied in succession during recovery.
Why it matters. Vendors lead with storage savings, but the cost of an incremental chain is paid on the worst day. Three practical consequences follow:
1. Set the full-backup cadence by the longest chain you have actually tested restoring, not only by storage cost.
2. When a tool offers a differential or cumulative option, it is the cheapest way to cap the data-backup chain at two files.
3. Merging an incremental chain into a synthetic full (for example with pg_combinebackup) shortens the chain you must carry, but the merge itself must be tested.
FAQs
Q1: Does a full backup truncate the SQL Server transaction log?
No. Under the full and bulk-logged recovery models, truncation occurs after a log backup, unless it is a copy-only log backup (Microsoft).
Q2: Can one policy use both differential and incremental backups?
It depends on the tool. Azure Backup for SAP HANA lets you schedule only one delta backup type per database (Microsoft). In Oracle RMAN, each level 1 backup is either differential or cumulative (Oracle).
Q3: What if the last full backup is corrupted?
Every differential or incremental that depends on it is unusable, because the parent must be restored first (Microsoft; PostgreSQL). Retaining more than one full generation and testing restores reduces the risk.
Q4: If I back up the whole VM, do I still need database log backups?
Only if your RPO is shorter than the VM backup interval. If a two-tool setup is unavoidable, avoid two tools taking non-copy-only fulls or log backups of the same database, since each would hold only part of the chain.
Q5: Do VM backup tools usually support both incremental and differential backups?
For example, Vinchin's VMware job strategy offers full, incremental, and differential scheduling, and its VMware page describes CBT-based incremental backups. Platform support depends on product version, so check current documentation.
Conclusion
The useful question is not what a backup saves but what a restore must touch. Count the files that must all be intact, confirm how your tools define “incremental,” verify change tracking and the log chain, and rehearse a restore on a schedule. A backup type is only as good as the last restore that proved it.
