The case is for Veeam Backup & Replication version 12.
The repositories are ExaGrid appliances configured as a scale-out backup repository.
Two separate Veeam Backup & Replication instances use different shares on the same ExaGrid appliances.
Fast Clone was enabled on both Veeam instances after the ExaGrid firmware was updated to a version that supports Fast Clone.
The SOBR placement policy is Data Locality.
Fast Clone worked on one Veeam instance during synthetic full backups and initially did not work on the second Veeam instance.
We later observed that synthetic full backups on the second Veeam instance used Fast Clone on the second day without running an Active Full backup.
Veeam treats a synthetic full backup as a regular full backup that resets the backup chain.
Veeam uses Fast Clone for synthetic full backups and other synthetic operations.
We understood that a synthetic full can serve as a chain reset point and enable Fast Clone utilization. However, in our environment, most jobs started leveraging Fast Clone on the very first synthetic full created after Fast Clone was enabled.
These jobs did not follow the expected sequence of a synthetic full created without Fast Clone, followed by a subsequent synthetic full after the chain reset. Likewise, an Active Full was not performed before Fast Clone became active.
In other words, Fast Clone was applied immediately on the first synthetic full, even though the backup chain had not yet been reset through either a prior synthetic full or an Active Full.
We would appreciate clarification on what conditions or mechanisms allowed Veeam to apply Fast Clone in these scenarios without a chain reset. Please help us to understand this behavior .
Environment summary:
- 2x ExaGrid appliances in scale-out
- 2x Veeam B&R instances, each using separate shares
- Scale-out repository policy: Data Locality
- Fast Clone: enabled on both instances, working only on one
