IDC Logo

Veeam #1 Worldwide in
Data Recovery & Protection in 2H'22


Manually moving backup files between Scale-Out Backup Repository extents

KB ID: 3100
Product: Veeam Backup & Replication | 9.5 | 10 | 11 | 12
Veeam Cloud Connect | 9.5 | 10 | 11
Published: 2020-02-11
Last Modified: 2023-02-21
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.

Cheers for trusting us with the spot in your mailbox!

Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest

error icon

Oops! Something went wrong.

Please try again later.

Article Applicability

This article's content was written for Veeam Backup & Replication 11a and older.

Starting in Veeam Backup & Replication 12, Rebalancing Extents of Scale-Out Backup Repositories is a built-in feature.

Read about all the new features in Veeam Backup & Replication 12 in the What's New document.


One of the extents is filling up faster than the others, and you want to balance them, but only certain backups/tenants need to be moved to another extent. 

This article applies to Backup, Backup copy, Agent backups, Agent backups with subtenant accounts.
If the SOBR Extents are using ReFS, before proceeding review ReFS Fast Clone limitations found here.
This article must not be used for migrating from a simple repository to a Scale-Out Backup Repository or for moving backup files between extents of different Scale-Out Backup Repositories. For such situations, refer to this article:


  • An extent has no free space because the Data locality placement policy has placed all files for a job on the same extent. 
  • After evacuating an extent another extent in the SOBR has no remaining free space, the user would like to redistribute the files manually.
  • A new extent was added to an existing SOBR and the user wants to redistribute files to the new extent manually.


Below are some key details to keep in mind when manually moving backup files between extents of a Scale-Out Backup Repository.
(Expand each for further details.)
Each job's unique VBM (metadata) file is identical across all extents of the SOBR the job is using and must be present in the folder next to the backup files.

The metadata file (VBM) contains information about the backup job, VMs processed by the backup job, number and structure of backup files, restore points, etc.  When a rescan operation is done for a Scale-Out Backup Repository (SOBR), the Veeam Backup & Replication software will look through all folders of each extent for vbm (Metadata) files. These VBM files indicate to the software that files may be in the folder with that VBM. The software will then scan the files in the same folder and record their location in its database.

Because the VBM only indicates that file may be in the folder next to it, it is possible to move any file for a given backup chain from/to any extent. Furthermore, it is possible to move files from different extents to a single extent, as long as the folder paths match and the VBM is in the folder.

Backup files must always be in the same folder structure relative to the path of each extent.

Backup files moved between extents of a SOBR must always be placed in the same relative folder structure to the path of the extent.

For Example:
The Scale-Out Backup Repository below is named "SOBR," there are 2 extents, “SOBR Extent 1” and “SOBR Extent 2”. Their "repository paths" are different, but if files are to be moved between them, the subfolders in those paths must remain the same.
User-added image
In this example, "SOBR Extent 1" has a path of E:\VeeamBackup\, and "SOBR Extent 2" has a path of C:\Backups\. If the backup files are initially in E:\VeeamBackup\DailyBackup when they are moved to SOBR Extent 2, they must be placed in a folder named "DailyBackup" (C:\Backups\DailyBackup).

If a new extent is added to the Scale-Out Backup Repository, and you want to move some/all of the files from the existing extents, you would have to create the same folder structure. Then place a copy of the vbm from any other extent, and proceed with moving the files you intend to move to this extent.

For example, if an NFS share were added as the third extent of the SOBR example above with a path of backupnas:/backups/, then the full path to the manually moved backup files would have to be backupnas:/backups/DailyBackup/ for the files to be recognized correctly.

  • If the folder names do not match, but the correct files are in place Veeam Backup & Replication will see these as a unique set of restore points and not associate them with restore points on the other extents. This will cause that set of restore points to appear under [Backups] > [Imported] and cause those incorrect moved files in the original backup set to be considered as unavailable.

  • If the folder names match, but the VBM is not placed in the folder next to the files Veeam Backup & Replication will not see the backup files.

For Local SOBR:

  1. Stop and Disable the job associated with the backup files you will be moving.
  2. Move backup files between extents as needed.
    Keeping in mind the details above about folder paths and vbm placement.
  3. In the Veeam Console, under Backup infrastructure > Scale-out Repositories, right-click on the affected SOBR, and select Rescan.
rescan sobr
  1. Enable/run the job.

For SOBR in use by Cloud Connect:

  1. Disable the tenant whose job has backup files that need to be moved.
  2. Move backup files (VBK, VIB, VRB) as need to other extents in the same SOBR.


    • Original folder on Extent: E:\VeeamBackup\Tenant1\Backup_Job_1\Backup_Job_1.vbm
    • New folder on Extent: C:\Backups\Tenant1\Backup_Job_1\Backup_Job_1.vbm

  3. On the Veeam Cloud Connect Server, in the Veeam Backup and Replication Console, under Backup infrastructure-> Scale-out Repositories, right-click on the affected SOBR and select Rescan.
  4. Enable the tenant/job.

Note that for Cloud Connect environments, there is a PowerShell commandlet available which can be used to perform an individual tenant evacuation from a specific extent.

More Information

Please keep in mind the following regarding ReFS Fast Clone and SOBR:

  1. Due to Microsoft limitations, all backup files in the backup chain must be stored on the same volume for ReFS Fast Clone to work. For more information, see Restrictions and Remarks at Microsoft Docs.
  2. When copying files from one ReFS volume to another location, the file system downloads cloned data blocks. For this reason, copied data occupy more space in the target location than it used to occupy in the source location. This can happen, for example, if you evacuate an extent that supports block cloning from a scale-out backup repository and migrate VM backup data to another extent: copied data will require more space than it originally took.
To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Spelling error in text

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

Oops! Something went wrong.

Please try again later.

You have selected too large block!

Please try select less.

KB Feedback/Suggestion

This form is only for KB Feedback/Suggestions, if you need help with the software open a support case

By submitting, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Verify your email to continue your product download
We've sent a verification code to:
  • Incorrect verification code. Please try again.
An email with a verification code was just sent to
Didn't receive the code? Click to resend in sec
Didn't receive the code? Click to resend
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

error icon

Oops! Something went wrong.

Please try again later.