A full backup is a backup that copies the entire selected dataset, such as all files on a volume, a whole database or a complete virtual machine, into a self-contained backup set at a specific point in time. In backup and recovery for servers, it is the baseline of every backup chain: incremental and differential backups record only changes relative to it, while the full backup alone is enough to restore the data.
The method trades higher storage use and longer backup windows for the simplest and most dependable restore. Most production strategies therefore combine periodic full backups with more frequent incremental or differential backups.
How a full backup works
During a full backup, the backup software reads every object in scope, regardless of whether it changed since the last run, and writes it to the target together with a catalog that lists what was copied. On file systems, the tool then typically clears the archive attribute or records a timestamp or change journal position, which later incremental and differential runs use as their reference point.
To capture consistent data from running servers, the backup usually reads from a point-in-time snapshot rather than from live files. Databases are handled with application-aware methods such as a native dump, a hot backup API or a quiesced volume snapshot, because copying open database files byte by byte often produces an unrestorable, inconsistent copy.
- Freeze or snapshot the source so the data does not change during the copy.
- Read all selected data and optionally compress, deduplicate and encrypt it.
- Write the backup set and its catalog to disk, tape, object storage or a remote site.
- Verify the result with checksums and record the new reference point for later backups.
Full, incremental and differential backups compared
The three classic backup levels differ in what they copy and what a restore needs. The comparison below shows why the full backup is the most expensive to create but the cheapest to restore.
| Backup type | Data copied | Sets needed for a restore | Backup time | Restore time |
|---|---|---|---|---|
| Full backup | Everything in scope | One | Longest | Shortest |
| Differential backup | Changes since the last full | Last full plus latest differential | Grows each day | Moderate |
| Incremental backup | Changes since the last backup of any level | Last full plus every incremental since | Shortest | Longest |
Storage consumption follows the same pattern. The next table assumes a 1 TB dataset with 5% daily change, no compression or deduplication, and changes that do not overlap from day to day, which is a conservative upper bound for the differential figure.
| Strategy | Calculation | Total stored |
|---|---|---|
| Daily full backups | 7 × 1 TB | 7 TB |
| Weekly full plus daily differentials | 1 TB + (0.05 + 0.10 + … + 0.30) TB | 2.05 TB |
| Weekly full plus daily incrementals | 1 TB + 6 × 0.05 TB | 1.3 TB |
Variants of the full backup
Several techniques produce a complete restorable image without copying all the data again from the production server. They keep the restore benefits of a full backup while reducing load on the source.
| Variant | How it is created | Main benefit |
|---|---|---|
| Traditional full | All data read from the source | Independent, simple and easy to verify |
| Synthetic full | Built on the backup target from the last full and later incrementals | No extra read load on production |
| Virtual full | Pointers to existing deduplicated blocks | Near-instant creation, minimal storage |
| Image-level full | Block copy of a disk or virtual machine | Bare-metal or whole-VM recovery |
| Copy-only full | Full copy that does not reset backup markers | Ad hoc copies without breaking the chain |
A synthetic full is only as good as the incrementals it is assembled from, so corruption in one incremental propagates into it. Periodic traditional fulls or integrity checks of the repository remain good practice.
Planning full backups in practice
The key planning constraint is the backup window, the time available before the copy disturbs production. Backup duration is roughly the dataset size divided by the slowest sustained throughput in the path, whether that is the source disk, the network or the target. For example, 2 TB at a sustained 200 MB/s takes 2,000,000 MB ÷ 200 MB/s = 10,000 seconds, or about 2.8 hours.
- Weekly full plus daily incremental is the most common schedule for general file and application servers.
- Daily full backups suit small datasets or databases where a fast, single-step restore justifies the storage.
- Grandfather-father-son retention keeps daily, weekly and monthly fulls for different durations.
- The 3-2-1 rule recommends three copies on two media types with one copy off-site, ideally including an immutable or offline copy that ransomware cannot encrypt.
Limitations and common mistakes
A full backup is only a promise until it has been restored. Regular restoration tests confirm that the media are readable, the encryption keys are available and the data is consistent.
| Symptom | Likely cause | Remedy |
|---|---|---|
| Backup overruns its window | Dataset grew faster than throughput | Switch to synthetic fulls or add incrementals |
| Database fails to start after restore | Files copied without quiescing | Use application-aware or native database backups |
| Restore impossible after disaster | Keys or catalog stored only on the lost server | Keep keys and catalogs separately and off-site |
| Ransomware encrypted the backups | Backup share writable from production | Use immutable storage or air-gapped copies |
A full backup is also not the same as a snapshot. A storage snapshot usually lives on the same array as the original data, so it shares the same hardware failure risk, while a proper full backup is stored independently of the source.
A plain-language summary
A full backup is a complete copy of everything you chose to protect, made at one moment. If the original disappears, that single copy is enough to bring it all back.
It is like photocopying an entire binder instead of only the pages that changed. It takes longer and uses more paper, but when you need it, you grab one stack and you are done. That is why most organizations make a full copy regularly and record only the changes in between.
An example from practice
An accounting firm runs a file server with about 2 TB of client documents. Its administrator schedules a traditional full backup every Saturday night to a backup appliance over a 10 Gb/s link, which sustains about 200 MB/s from the source disks and finishes in roughly three hours. On weekdays, incremental backups take only minutes.
Every month, an encrypted copy of the latest full backup is replicated to immutable object storage. When ransomware later encrypts the server, the team restores the most recent full backup and the incrementals that follow it, and then verifies a clean restore within the same working day. Without that independent full copy, the firm would have faced a complete rebuild.