Choose from the following topics:
See Also:
As the name suggests, a synthetic full backup is a synthesized backup. It is created from the most recent full backup (i.e., standard or synthetic) and subsequent incremental and/or differential backups. The resulting synthetic full backup is identical to what would have been created had the last backup for the subclient been a full backup. Unlike full, incremental, and differential backups, a synthetic full backup does not actually transfer data from a client computer to the backup media. In this sense it is not really a backup at all, rather a backup consolidator.
Because synthetic full backups consolidate backup data into one archive file, they provide a means of enhancing restore performance, particularly when a given full backup cycle contains many incremental backups. For a discussion on the benefits of data consolidation, see Comparing Full, Incremental, and Differential Backups.
Synthetic full backups are treated by the QiNetix system as standard full backups. As a result, they delineate full backup cycles in the same manner as standard backups. This is an important point to remember, since retention periods are defined in part by the number of full backup cycles. Using synthetic full backups in an unguided manner may cause the unintentional expiration of data.
Synthetic full backups can either be started manually or scheduled to occur at regular intervals. Scheduling allows you to incorporate synthetic full backups into your regular backup schedules as described in Using Synthetic Full Backups.
You can start a synthetic full backup at the subclient, backup set or iDataAgent level. When started for a backup set or iDataAgent, the operation acts on each constituent subclient individually. In other words, if you start a synthetic full for a backup set that contains two subclients, the system automatically conducts two synthetic full backups, one for each subclient.
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 previous full backups. As the synthetic full backup for each subclient proceeds, the system writes an archive file to the storage policy from which the backup data originated (i.e., one archive file per subclient). 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.
The following illustration demonstrates the operation of a synthetic full backup that was initiated at the backup set level. For simplicity, assume:
From this figure, we can see that from a single request on 4/7, two synthetic full backups were created: one for each subclient. When we requested a synthetic full backup for the backup set, the system identified all the backups that were created for each subclient back to the most recent full (F), which in this case occurred on 4/1. Using the index data from these backups, the system created new consolidated index and user data images and wrote them to new archive files (SF) on the same storage policies.
In this example, we assumed that the standard backup was written to a dedicated storage policy and that the user data and corresponding index were both backed up to the same storage policy. Note that these conditions do not affect the overall operation of a synthetic full backup. In either case, (i.e., non-dedicated storage policies or divided index/user data) the system locates the applicable index and user data and creates a new archive file.
An important point to remember is that a synthetic full backup consolidates data; it does not back up data from the client computer. Consequently, the data in a synthetic full backup always reflects the data of the previous backup, regardless of when the synthetic full backup was requested. In this example, the synthetic full backup was started on 4/7; however, the data it contains is from the 4/1 through 4/6 backups. To secure data for 4/7, we would need to run a conventional (i.e., full, incremental, or differential) backup on 4/7.
Also, keep in mind that synthetic full reads the data from the copy whose restore copy precedence is set to 1. And like a real backup, synthetic full is always created in the primary copy. i.e., its destination is always a primary copy.
Like standard full backups, synthetic full backups create full backup images, thereby promoting restore efficiency. There is however one important distinction: synthetic full backups do this without actually backing up data. Consequently, they impose no load on the client computer. Given this fact, you may find it advantageous to incorporate synthetic full backups into your standard backup cycles.
There is a trade-off in using synthetic full backups. Synthetic full backups do not impose a load on the client computer; however, they do require new media each time they are run. Therefore, you must determine your priorities for media usage versus restore efficiency.
The following figures show two examples of using synthetic full backups in standard backup schedules. The figures show a series of full backup cycles where each cycle is a week in length. The longer lines indicate full backups while the shorter lines indicate incrementals. Note that both sets of backups begin with the required standard full backup.
In the first figure, both synthetic and standard full backups are used to define the full backup cycles. Synthetic full backups are used more often because they do not affect the operation of the client computer. In the second figure, synthetic full backups are used exclusively. To ensure that client data is properly secured, each synthetic full backup is followed by an incremental backup on the same day. If you decide to incorporate synthetic full backups into your standard backup schedules, the approach you take is entirely dependent upon your needs.
|
|
If a synthetic full backup fails to complete successfully, we suggest that you run a standard full backup in its place. |
When starting a synthetic full backup, keep the following points in mind:
If you want to perform a synthetic full backup using an alternate MediaAgent (one other than the MediaAgent used for the Primary backup), you must configure an Incremental Storage Policy.
NOTE: To configure the Incremental Storage Policy: Configure a Storage Policy (e.g., Storage Policy1: MediaAgent 1 and TapeLibrary1) and configure the Incremental Backup to use another Storage Policy (e.g., Storage Policy2: MediaAgent2 and MagneticLibrary2). Regular daily backups can be performed as incremental backups with Storage Policy2, and, when necessary, synthetic full backups can be initiated using Storage Policy1. For more information, see Incremental Storage Policy.
The Backup Options dialog allows you to run an incremental backup either before or after a synthetic full backup. Running an incremental backup immediately before the synthetic full ensures that any new or recently changed data is included in the synthetic full. Running an incremental backup immediately after the synthetic full ensures that any new or recently changed data since the backup that occurred prior to the synthetic full, but was not included in the synthetic full, is backed up by the incremental.
