V11 Service Pack 11
Loading...

Synthetic Full Backups

Synthetic full backups consolidate the data from the latest full backup or synthetic full backup together with any subsequent incremental backups into one archive file, instead of reading and backing up data directly from the client computer. Since synthetic full backups do not back up data from the client computer, this operation imposes no load on the client computer.

During a synthetic full backup, a list of objects scanned by the previous backup is used to read the same objects from protected storage. The latest version of each object is found.

For example, the last full backup scans and backs up 1,000 files. The last incremental backup scans 1,500 files but only backed up 100. A subsequent synthetic full will use the scan list from the last incremental to search protected storage for the most recent versions of those 1,500 files and use them to create the synthetic full backup.

The following image describes how a synthetic full backup is created:

You can start a synthetic full backup at the subclient, backup set or agent level. If you start the synthetic full backup at the backup set or agent level, then an individual job starts on each subclient. In other words, if you start a synthetic full backup on a backup set that contains two subclients, then two synthetic full backup jobs run, one for each subclient. If you choose to use a new media for synthetic full backups, then you might need to have additional spare media available.

Using synthetic full backups can cause unintentional expiration of data since retention periods are defined by the number of full backup cycles. For example, running a synthetic full immediately after a standard full backup does not consolidate any data (as the full already includes all the backup data); storage resources might be unnecessarily consumed.

A synthetic full backup extracts the index data of each participating subclient. Using this index data and the previously backed up user data images, it builds new full backup images, one for each subclient. The new backup images consolidate the index and user data stored in the related incremental, differential, and latest full backups. As the synthetic full backup for each subclient proceeds, the system writes an archive file to the storage policy for each subclient from which the backup data originated. Since each archive file represents one synthetic full backup for each subclient, a synthetic full backup of a backup set containing three subclients would initiate three operations, each resulting in an archive file.

Running a synthetic full with non-deduplicated data requires writing each new object to a new location. For tape media, this means a synthetic full must write the new data to a new tape since you cannot read and write simultaneously to the same tape. As such, a synthetic full using tape media requires at least two tape drives – one for reading and one for writing.

A synthetic full backup done on disk or cloud media will also read and write objects. Unlike tape, disk media can perform concurrent reads and writes to the same media. However, if the source path is full or marked as read-only, objects may be written to other disk media paths available in the storage policy copy.

With deduplicated data, a synthetic full will read each block, generate a signature, update the Deduplication Database and index, and discard the block since it already exits. However, a faster variation of a synthetic full is available called a DASH full. Enabling DASH full causes a synthetic full backup to just update the deduplication and index records. Without the associated disk IO, a DASH full is obviously much faster.

Last modified: 3/20/2018 7:28:27 PM