Veeam Backup & Replication will transfer to the capacity extent only those restore points that belong to inactive backup chains. To ensure a backup chain is inactive, Veeam Backup & Replication verifies its state. This does not apply to the copy policy: all newly created restore points are copied immediately.
Inactive Backup Chain of a Backup Job
When a backup job runs for the first time, Veeam Backup & Replication creates an initial full backup file. It contains complete information about the VMs that are being backed up. With each subsequent backup job session, new incremental backup files are created. They contain only the changes that have occurred since the last backup session.
For Forward incremental backup method, the active backup chain is the one that has not yet been sealed with a new full backup file. To move data to the capacity extent, 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 this chain. This can be done either manually, as described in Performing Active Full Backup. Else, you can configure a schedule according to which new active or synthetic full backups will be created automatically, as described in Active Full Backup and Synthetic Full Backup.
Once a new full backup file is created and the offload session is being executed, Veeam Backup & Replication collects all the restore points (full and incremental) that were created prior to the latest active full, verifies that they belong to an inactive chain, and prepares them to be moved to the capacity extent. This process is called detect. For more information, see Moving Inactive Backup Chains to Capacity Tier.
Note that Veeam Backup & Replication will not transfer to the capacity tier the corrupted restore points and the files dependent on those. For more information on the corrupted restore points, see Health Check for Backup Files.
The following figure shows both inactive and active backup chains created with the forward incremental method. The inactive backup chain consisting of one .vbk file and five .vib files. They can be offloaded. The active backup chain consisting of a .vbk file and a .vib file will continue to append other incremental backups until it is reset by another full backup.
The same applies to the backup chains created with the reverse-incremental method. In this case, all the .vrb files starting from the third restore point will be considered inactive automatically, as illustrated in the Figure A below. Thus, you do not need to create an Active Full (nor Synthetic Full) backup manually unless you want to offload all the restore points including the most recent .vbk file and the first two .vrb files, as illustrated in the Figure B.
Mind that a full backup file and the first two incremental backup files (that is, two .vrb files that immediately follow the most recent .vbk file) will not be offloaded until another full backup file is created successfully, as illustrated in the Figure B.
Consider the following examples:
- On Figure A, four .vrb files (represented as gray blocks) are inactive and can be offloaded.
- On Figure B, six .vrb files and a .vbk file (represented as gray blocks) belong to an inactive chain and can be offloaded.
The structure of the backup chains can be different. That depends on whether your backups were created using the per-VM method (for more information, see Per-VM Backup Files) or as a single storage, with all VMs placed into a single file. The type of the backup chain structure does not affect the offload process.
For more information on how Veeam Backup & Replication creates and manages backup chains, see Backup Chain.
Inactive Backup Chain of a Backup Copy Job
When offloading backup chains created by backup copy jobs, Veeam Backup & Replication will move only full backup files that have a GFS flag.
To enable the GFS retention policy for the files, select the following check boxes at the Target step of the New Backup Copy Job wizard:
- Keep the following restore points as full backups for archival purposes check box
- (optionally) Read the entire restore point from source backup instead of synthesizing it from increments.
Consider the following examples:
- The Figure A shows a backup chain consisting of two .vbk files and five .vib files created with the synthetic full method.
The Weekly Full Backup file (represented as a gray block) has a GFS flag (Weekly) assigned to it and can be offloaded to object storage. The second .vbk file cannot be offloaded until it is also assigned a GFS flag. It will happen after another full backup file is created.
- The Figure B shows a backup chain consisting of three .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, so it can be offloaded to object storage. The second weekly full backup file (represented as an orange block on the far right) also has a Weekly flag, but this file is active. It will not be offloaded until another full backup file is created.
The first backup file (represented as a green block on the left) does not have any GFS flag, so it will not be offloaded at all.
The following types of backup files are never offloaded from backup chains created by backup copy jobs: