Break Glass #09: ReFS and XFS Block Clone Failures: Diagnosing and Fixing Fast Clone Errors in Veeam v13

Why This Happens

Fast Clone is Veeam's name for block level cloning on ReFS (Windows) and XFS with reflink enabled (Linux). Instead of copying data blocks between files during synthetic full creation, VBR references existing blocks and only copies what changed. Synthetic fulls that take hours on NTFS complete in minutes on ReFS or XFS because very few blocks actually move. When Fast Clone breaks, you are back to full data copies. Slow jobs are the symptom, not the emergency. The emergency is when jobs fail outright.

The most common failure is a mismatch between what VBR believes about the repository and what is actually there. VBR marks a repository as Fast Clone capable when it first detects a compatible filesystem. If the underlying filesystem later changes. An admin reformats the volume from ReFS to NTFS, or a NAS firmware update changes how the share advertises capabilities. VBR still tries to use Fast Clone against a target that no longer supports it. The job fails with "Agent failed to process method {ReFs.SetFileIntegrity}."

For XFS repos, the most common issue is a misconfigured filesystem. XFS must be formatted with CRC enabled (crc=1) and reflink enabled (reflink=1) for Fast Clone to work. Formatting without these flags, or running an older kernel that does not support reflinks, means the feature is silently unavailable. Jobs do not fail. They just revert to full data copies and nobody notices until someone checks why synthetic fulls are slow.

The third class involves backup chains that were manually moved to a Fast Clone repository without running an active full afterward. VBR does not automatically enable Fast Clone on chains it did not create on the target filesystem. An existing chain moved from NTFS to ReFS continues using full copies until a new active full is taken from the new repository location.

Triage

1. 1Check the job session log for the exact error. In the VBR console, go to History, right click the failed job session, and select Statistics. Scroll through the log for error entries. The specific error tells you which path to take:
   Agent failed to process method {ReFs.SetFileIntegrity} ReFS compatibility mismatch [Fast Clone] log shows Fast Clone in use (not a failure) No [Fast Clone] in session log, synthetic full slow Fast Clone not being used XFS reflink check failed XFS filesystem not configured for reflink
2. 2For Windows ReFS repositories: verify the repository filesystem is still ReFS. RDP to the repository host and run:
   Get-Volume | Select DriveLetter, FileSystem, FileSystemLabel
   If the volume shows NTFS instead of ReFS, that is your problem. The filesystem changed.
3. 3For SMB share repositories: verify the share is backed by actual ReFS storage and not a NAS device that is advertising Fast Clone capability it does not actually have. Synology devices are the documented common offender here (Veeam KB4381).
4. 4For Linux XFS repositories: SSH to the Linux host and check the filesystem configuration:
   sudo xfs_info /dev/sdX
   Look for crc=1 and reflink=1 in the output. If either is 0 or absent, the filesystem was not formatted for reflink. This cannot be changed after formatting. The volume must be reformatted.
5. 5Check the VBR repository settings. In Backup Infrastructure, right click the repository and select Properties. Confirm whether the "Use fast cloning on XFS volumes" checkbox is enabled for Linux repos, and whether the repository type is set to Windows with ReFS. Also confirm the SOBR placement policy is Data Locality if this is a SOBR. Fast Clone does not work across extents regardless of filesystem.

Recovery Path A: ReFS Compatibility Mismatch (Jobs Failing)

1. 1If the underlying filesystem changed from ReFS to NTFS, VBR needs to recheck the filesystem. The fastest fix is to force a recheck by editing the repository properties: in Backup Infrastructure, right click the repository, select Properties, click through the wizard to the end, and click Finish without changing anything. This forces VBR to recheck filesystem capabilities and update its database. The job should succeed on the next run without Fast Clone.
2. 2If the repository is an SMB share on a NAS device that is incorrectly advertising Fast Clone support (common on Synology), disable Fast Clone for SMB shares entirely on the VBR server. Add the following registry value on the VBR server:
   Key: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\ Value: UseCifsVirtualSynthetic Type: DWORD Data: 0
   Per KB4381, this value takes effect on the next job run. No Veeam service restart is required. Once applied, the next job run uses full data copy for synthetic fulls on SMB repositories, which is slower but reliable.
3. 3If you want to restore proper ReFS Fast Clone: rebuild the repository volume with ReFS formatting. Use Windows Server 2019 or 2022, format with ReFS and 64 KB cluster size. Edit the repository in VBR to point at the new volume. Run an active full backup to start a clean chain on the new volume with Fast Clone active from the start.

Recovery Path B: XFS Not Configured for Reflink

An XFS volume formatted without reflink=1 cannot have it added after the fact. The filesystem must be reformatted. This means migrating the backup chains off the volume first.

1. 1If you need Fast Clone and the XFS volume was formatted without reflink, the path forward is: add a new Linux repository with correctly formatted XFS, migrate chains to it, then decommission the old repo. The new format command must include:
   mkfs.xfs -b size=4096 -m crc=1,reflink=1 /dev/sdX
2. 2Add the new repository to VBR and redirect jobs to it. After redirecting, run an active full backup for each job on the new repository. The active full is required to activate Fast Clone. Existing chains moved to the new repo do not automatically use reflink until a new full is created there.
3. 3If Fast Clone is not critical to your environment, leave the current XFS repo alone. Synthetic fulls are slower without reflink but not broken. Jobs complete correctly. They just run as full data copies. The decision depends on how large your VMs are and how long you can accept the synthetic full window.

Recovery Path C: Fast Clone Not Being Used (Slow, Not Failing)

1. 1Verify the repository settings in VBR. For Linux XFS: Backup Infrastructure, right click repo, Properties. Confirm "Use fast cloning on XFS volumes" is checked. If it is unchecked, enable it and click Finish to save.
2. 2If chains were manually copied to the repository from another location, Fast Clone is not active for those chains regardless of filesystem. Run an active full backup for each affected job. The new active full is the first backup file created natively on the repository, and Fast Clone activates from that point forward for all subsequent synthetic operations.
3. 3If using a SOBR with Fast Clone repositories: verify the SOBR placement policy is set to Data Locality. Fast Clone requires both the full (VBK) and the incrementals (VIB) to be on the same physical volume. Performance policy splits them across extents and Fast Clone cannot operate across filesystem boundaries. Switch to Data Locality if Performance policy is set.
4. 4Verify Fast Clone is active after the next synthetic full by checking the session log. A successful Fast Clone synthetic full shows [Fast Clone] in the log entries for the transform operation. If it still does not appear after confirming all settings, run a compact operation on the backup chain to force VBR to re evaluate the chain structure on the repository.

Gotchas

Prevention Checklist

• Format ReFS volumes with 64 KB cluster size on Windows Server 2019 or 2022. Keep repository hosts patched to maintain the required ReFS.sys version.
• Format XFS volumes with mkfs.xfs -b size=4096 -m crc=1,reflink=1. Verify with xfs_info before putting the volume in production.
• Never reformat a repository volume from ReFS to NTFS without first redirecting jobs to another repository. If you do reformat, edit the repository properties in VBR to force a filesystem recheck before the next job runs.
• After migrating chains to a new Fast Clone repository, always run an active full before relying on synthetic fulls to complete quickly.
• Use Data Locality placement policy on any SOBR that includes Fast Clone extents.
• Never enable Windows Server data deduplication on a ReFS volume used as a Veeam repository. Fast Clone and Windows data deduplication cannot be used simultaneously, and the two mechanisms conflict in ways that destroy the space and performance benefits of both.
• Check the session log for [Fast Clone] entries after setting up a new repository to confirm the feature is actually active, not just configured.