Home  ›  Glossary  ›  Full Backup

What is full backup?

Full backup is a backup that copies all selected data in one run, whether or not it changed since the previous backup. The restore point it produces stands alone: bringing it back needs no other backup file. Incremental and differential backups both start from a full.

The copy every later restore point depends on

During a full run the backup software takes a consistent snapshot of the source, reads every file or block in scope, writes the result to the repository and records the new restore point in its catalog. It then resets change tracking so the following run knows where to start counting. Because every block has just been read, a completed full also shows that the whole data set was readable at that moment.

The level of the backup decides what can come back from it. File-level fulls allow single folders and documents to be restored. Image-level fulls capture a whole disk or virtual machine, operating system included, so a complete machine can be rebuilt. Database fulls go through the database engine and carry enough transaction log to make the copy consistent.

Each incremental or differential taken afterwards is a set of changes applied on top of that base. Once the full is deleted, encrypted or corrupted, every restore point built on it stops being restorable as well. That puts the full at the top of an attacker's list inside any repository.

An active full reads production again from scratch. A synthetic full backup is assembled on the backup storage from the previous full and its incrementals, which spares production servers and the network. The active version starts clean, while the synthetic one carries forward whatever damage already sits in the older files.

Hours, terabytes and lock dates

A full runs as long as its data size divided by the slowest rate along the path. At a sustained 1 GB/s, 10 TB takes about 2.8 hours and 100 TB about 28 hours, far longer than any nightly backup window. Larger estates therefore stagger active fulls across weekends or switch to synthetic ones.

Capacity follows the schedule. Four weekly fulls of a 10 TB source amount to 40 TB before data reduction. Deduplication strips out most of the repetition between consecutive fulls, yet the monthly and yearly fulls kept for compliance still account for much of a repository's growth over the years.

Immutability adds a dependency that is easy to miss. Object Lock retention is set per object, so a full and the incrementals resting on it can carry different retain-until dates. When the full's lock runs out first, those incrementals sit on a base that can now be deleted, and their own locks end up protecting files that no longer restore anything. The chain is only as protected as the lock on its full.

In a recovery the full is usually the largest single read, so the restore throughput of the repository does more than anything else to set how quickly a lost server returns.

ARTESCA and full backup

Backup applications write each full to ARTESCA as S3 objects, and the S3 Object Lock retain-until date on those objects decides how long the chain above them stays restorable. In compliance mode no user, the root account included, can delete or overwrite a locked full before that date; in governance mode an identity holding the bypass permission still can.

Lock lengths come from the backup application or the bucket's default retention, so a full that expires ahead of its incrementals is a backup-policy setting that ARTESCA enforces as written and does not correct. After a lock lapses, per-bucket S3 Lifecycle rules can clear expired versions, and room for months of retained fulls grows by adding servers, up to a validated 8.5 PB.