Backup Chain Legitimacy

Before transferring data to object storage repositories, Veeam validates the backup chain state to ensure that the restore points to be offloaded belong to an inactive backup chain.

Inactive Backup Chain for Backup Job

When a backup job is being executed for the first time, Veeam creates an initial full backup file that contains complete information about the VMs that are being backed up. Each subsequent backup job sessions initiate creation of new incremental backup files that contain only changes which have occurred since the last backup session.

Such a chain can be considered active as there are more incremental backups have yet to be created, depending on the backup job schedule configuration. For more information, see Define Job Schedule.

To send data to object storage repositories, an active backup chain must be reset, that is, transformed into inactive.

To transform an active backup chain into inactive, a new Active Full (or Synthetic Full) backup file must be created for such a chain. This can be done either manually, as described in Performing Active Full Backup, or you can configure a schedule, according to which new active full backups will be created automatically, as described in Active Full Backup.

Once a new full backup file is created and the offload session is being executed, Veeam collects all the restore points (full and incremental) that were created prior to the latest active full, and prepares them to be transferred to the object storage repository, as described in SOBR Offload Job.

The following figure shows both inactive and active backup chains created with the incremental method. The inactive backup chain consisting of one .vbk file and five .vib files can easily be offloaded once it satisfies validation criteria, whereas the active backup chain consisting of a .vbk file and a .vib file would continue to grow with another incremental backups until it is reset by another full backup and so on.

The same applies to backup chains created with the reverse-incremental method, except for in this method, all the .vrb files starting from the third restore point will be considered inactive automatically, as illustrated in the Figure A below. That said, you do not have to create an Active Full (nor Synthetic Full) backup manually unless you want to offload all the restore points including a .vbk file and the first two .vrb files, as illustrated in the Figure B.

Consider the following examples:

• The Figure A shows a backup chain consisting of 1 .vbk file and 6 .vrb files, of which only 4 .vrb files (represented as gray blocks) can be offloaded.
• The Figure B shows a backup chain consisting of 2 .vbk files and 7 .vrb files, of which only 6 .vrb files and a .vbk file (also represented as gray blocks) can be offloaded.

Backup chains can be of different structure, depending on whether your backups were created using the per-VM method or as a single storage when all the VMs are placed into a single file (.vbk — for full backups and .vib/.vrb — for incremental backups). Both structure types can be offloaded to object storage repositories as long as these types are inactive.

For more information on how Veeam creates and manages backup chains, see Backup Chain.

Inactive Backup Chain for Backup Copy Job

When offloading backup chains created by backup copy jobs, only full backup files that have a GFS flag on them will be offloaded. That said, you must select the Keep the following restore points as full backups for archival purposes check box and (optionally) combine it with the Read the entire restore point from source backup instead of synthesizing it from increments check box at the Target step of the New Backup Copy Job wizard.

For more information on how to configure a backup copy job and how the GFS retention works, see Creating Backup Copy Jobs and GFS Retention Policy respectively.

Consider the following figures:

• The Figure A shows a backup chain consisting of 2 .vbk files and 5 .vib files created with the synthetic full method.

The Weekly Full Backup file (represented as a gray block) can be offloaded to object storage since it has a GFS flag assigned to it (as per example, the flag is Weekly), whereas the second .vbk file cannot be offloaded until it is also assigned a GFS flag, which happens after another full backup file is created.

• The Figure B shows a backup chain consisting of 3 .vbk files and 11 .vib files created with the active full method.

In this figure, a Weekly Full Backup file (represented as a gray block in the middle) has a Weekly flag, therefore, this full backup file can be offloaded to object storage. The second weekly full backup file (represented as an orange block on the rightmost side) also has a Weekly flag assigned, but since this file is active and is yet to be succeeded by another incremental backups during subsequent sessions of your backup copy job, it will not be offloaded until another full backup file is created and so on.

The first backup file (represented as a green block on the left) will never be offloaded since it does not have any GFS flag assigned.