Synthetic Full Backup
A synthetic full backup is a fresh full backup copy created through consolidating an existing older full copy with all subsequent changes (incremental backups) directly in the backup repository.
What is a synthetic full backup?
Rather than pulling all the data from the source environments, which is the case for active full copies, a synthetic full backup uses the capabilities of dedicated backup software to merge an existing full copy with subsequent incremental backups directly in the backup target storage.
Such an approach offers all the benefits of full and incremental backups: the same restore capabilities as with traditional, active full backups, plus time and resource savings you expect from incremental copies.
Why is a synthetic full backup important?
Creating a complete copy of a large data set takes time and puts a heavy load on your production environment. A synthetic full backup solves this by moving the heavy lifting from source environments to your backup repository. IT leaders rely on this backup strategy to maintain tight backup windows without sacrificing data protection.
Reduced infrastructure load
Reading data directly from on-premises production systems (like physical servers or virtual machines) slows down their performance, while pulling complete data sets from cloud platforms like GitHub or Microsoft 365 quickly triggers API throttling.
Since synthetic full backups do not require backup software to pull all the data from your source environments every time, your infrastructure maintains peak performance for daily operations.
Shorter backup window
You avoid slow and repetitive creation of full backups that depend on source environments’ and network performance. This shortens your backup window, minimizing the impact on production systems and end users’ work. An extra benefit for cloud environments, like DevOps platforms or Microsoft 365, is the reduced risk of throttling.
Improved backup reliability
Long backup chains are prone to corruption. Synthetic full backups can limit the dependency on potentially vulnerable incremental chains by resetting the sequence regularly. This creates a clean starting point for any new backup.
đź’ˇ GitProtect allows you to run cyclical synthetic full backups. Thanks to that, it keeps your incremental chains short (e.g., limited to a month). Essentially, this provides multiple complete restore points within your retention period, making your data recovery faster and more reliable.
Quick recovery
A synthetic full backup file restores at essentially the same speed as an active full copy. That’s because you restore data from a single point rather than waiting for the system to process a long chain of incremental changes. As a result, you achieve faster recovery and can meet strict Recovery Time Objective (RTO).
How does a synthetic full backup work?
Understanding how a synthetic full backup works requires looking at the step-by-step process. The primary goal of this backup strategy is to create a new full backup without transferring all source data across the network again.
Here’s how the process goes:
- First, your backup software runs an initial full backup. It covers all the data you wish to protect and is transferred to your backup storage.
- Next, the software runs automated incremental backups on a set schedule. An incremental backup only copies data changed since the last backup. These subsequent incremental backups are small and fast.
- Finally, on a scheduled day, a full synthetic backup is created. Instead of asking the source environments for all the data directly, your backup software reads the previous full backup and the changed data from the incremental backups already sitting in the backup repository. Then, it pieces these unique blocks together to create a synthesized backup. This new backup is identical to an active full backup in structure.
- Once finished, this new full backup resets the backup chain. Any subsequent backups will use this synthetic full as their baseline.
Differences between backup types
Choosing the right backup copy type dictates how much data moves across your network, how much storage space you need, and how fast you can restore data.
Synthetic full backup vs. active full backup
An active full backup copies all data from the source environments over the network. A synthetic full backup builds the exact same full backup file locally on the backup storage, using previous backups. Both create an independent backup file, but the synthetic backup eliminates the need to copy data from sources again.
Full backup vs. incremental backup
A full backup copies all data from the source environments. Incremental backups only copy data changed since the last backup. While incremental backups use less storage space, they require more time to restore than full backups because the recovery process must reconstruct data from multiple files in the backup chain.
Differential backup vs. incremental backup
Differential backups are another type. Each differential copy includes all changes since the last full backup. They require more storage space than incremental backups but make the recovery process faster. You only need the last full backup and the most recent differential backup file to restore data.
Challenges and limitations of synthetic full backups
While highly efficient for source production environments and the network, synthetic full backups place specific demands on your backup infrastructure.
High storage I/O requirements
Synthesizing the unique data blocks into a new full backup is an I/O-intensive process, so your backup repository must offer high read and write speeds. If your backup storage is slow, creating a synthetic backup takes a long time and slows down concurrent backup operations.
If your software supports multi-storage backup, you need to choose efficient storage to run synthetic full backups.
Risk of corrupted data propagation
A synthetic full copy uses previous full and incremental backups to build a new file. If the previous full backup or any backup file in the backup chain is corrupted, the new synthesized backup will inherit that corruption.
Disk space consumption
Even though you transfer less data over the network, a synthetic full backup creates a complete restore point that requires dedicated capacity in your backup repository. Each synthetic full consumes essentially the same amount of space as an active full backup file.
While the capacity is usually not a problem for DevOps backups, backing up Microsoft 365 services such as Exchange and SharePoint Online very often requires substantially more storage capacity.
Synthetic full backup best practices
To get the most out of this backup strategy, configure your retention settings and schedules to balance performance and disaster recovery readiness.
Schedule periodic active fulls
Regular full backups are recommended to maintain a reliable backup chain. Run an active full backup periodically to verify data integrity and ensure you are not carrying over hidden corruption from older files. Many administrators run weekly synthetic fulls and monthly active fulls.
Optimize retention settings
Keep your backup chain short. Regular synthetic fulls keep your backup storage manageable while ensuring you always have a recent full backup file ready.
Monitor storage performance
Ensure your backup repository has enough throughput to handle the synthesis process and capacity to store synthetic full copies according to your data retention policy.
If building a full synthetic backup is too time-consuming, you might need to upgrade your storage or adjust the schedule so the backup works during off-peak hours.
Recommended use cases for synthetic full backup
Certain environments benefit significantly from using a synthetic full backup to create restore points without disrupting daily operations.
Virtual machines
Virtual machines often contain massive amounts of data. Running an active full backup on hundreds of VMs can overload the hypervisor and the production network. A synthetic full backup allows you to protect these systems without impacting their performance.
Cloud platforms
Cloud providers apply API throttling to cap excessive data transfers to and from the cloud. The limited bandwidth can affect you if your organization has accumulated large volumes of data in the cloud and wants to create regular full copies of it in independent storage, ensuring a high level of security.
Synthetic full backups solve the problem by syncing only incremental changes between your cloud platform (e.g. Jira) and storage, while handling the full backup consolidation directly in the storage.
Remote offices with slow connections
When a remote site has limited bandwidth, transferring all files for a new full backup can be impossible within a standard backup window. With synthetic full backups, an initial full backup is transferred once. After that, you send only the changes over the slow link and build the synthetic full directly in the central backup repository.
Related terms
(Active) full backup
A complete and exact copy of all your data, where all the data is copied from the source systems to your backup repository over the network.
Incremental backup
A backup type that saves only the data blocks that have changed since the last backup, heavily reducing the time a backup takes to complete.
Backup window
A scheduled period during which automated backup software creates a backup copy without interrupting production IT environments.
Recovery Time Objective (RTO)
A disaster recovery and business continuity metric that defines the maximum acceptable amount of time your applications, systems, or data can remain unavailable.