Starting with Veeam Backup & Replication 12, a new "Move Backup" feature is now built-in. The methods documented in this article are still viable. However, we encourage customers to use the built-in functionality, when possible, for the best experience.
This article documents two methods for changing the repository where backup files are stored.
For documentation on changing the backup location of Veeam Agent jobs not directly controlled by Veeam Backup & Replication, but targeting a Veeam Backup & Replication server's repository, refer to vee.am/kb2321
Limitations and Considerations
Customers are strongly encouraged to use the built-in Move Backup function. The legacy method documented in this KB article has the following limitations, which are not present with the built-in Move Backup function (explained in italics for each entry below).
Backup files manually moved to a Fast Clone capable repository (ReFS or XFS) will not be able to utilize Fast Clone until a new Active Full is created. The built-in Backup Move function, on the other hand, has technology that is able to migrate backup files allowing Fast Clone to function with migrated backup files.
If synthetic fulls that were created using Fast Clone are moved using the method documented in this article, they will be inflated to their full size on the destination storage when they are manually moved. Conversely, the integrated Backup Move function is able to preserve the space savings of fast clone created synthetic fulls when used to move backup files between Fast Clone compatible repositories.
The manual method documented in this article should not be used to move backup files to or from an Immutable Hardened Linux Repository. Whereas, the built-in Backup Move function is capable of handling the intricacies of managing the immutable state of the files on the source or destination Immutable Linux Repository, allow it to be used to migrate to or from an Immutable Hardened Linux Repository.
There are two primary situations and respective methods that this KB article documents. Below is a summary of each.
Method A: Same Job, New Backup location The backup files are being moved to a new repository, but the existing Backup Job will continue to be used. This method will use the automapping function built-in to the software.
Method B: New Job, New Backup location You are seeding a job or mapping a job to a backup chain in a new location. This method does not require that the job doing the mapping be the same as the job that initially created the restore points, as it requires that you manually use the map backup function.
Method A: Same Job, New Backup location
This method uses a feature built-in to Veeam Backup & Replication that seamlessly switches between repositories when old and new repositories contain the same backup files for the job (VBM, VBK, VIB, VRB). When the new repository is selected within the job, Veeam Backup & Replication will check if the backup files in the selected repository match the existing repository. If matching files are found in the new repository, the job will auto-map to backup files in the new repository.
Disable the backup job(s) planned to be moved; this will prevent additional restore points from being created during the repository transition. Disabling the job/jobs will also stop any SQL Transaction Log backups, as those running during the transition will cause the final step to fail.
Manually move the backup files to the new repository path. You must include the metadata file (.vbm), full backup files (.vbk), and any needed incremental files (.vib or .vrb).
It is recommended to move all backup files, but you may omit incremental files if needed. However, if you decide not to move/copy all backup files to the new storage, you will need to use the “Forget Missing Restore Points” function to clear any references to backup files that were not moved/copied after the final step.
There will be folders created inside the directory/path for job names. If your repository path is set as E:\Backups, Job A will go to E:\Backups\Job A.
If the backup files are not encrypted, skip this step. If the backup files are encrypted, the encrypted backup will appear under the Backups > Disk (encrypted) node in the inventory pane. In the working area, select the imported backup and click Specify Password on the ribbon or right-click the backup and select Specify password. More InformationThis is also relevant for encrypted Veeam Agent backups.
Observe that after the Rescan has been completed, there will be duplicate entries for the backup files. One is associated with the old Repository under Backups > Disk, and the other is associated with the new repository under Backups > Disk (Imported).
Backups listed under Backups > Disk still linked to the old repository.
Backups listed under Backups > Disk (Imported) linked to the new repository.
Edit the Backup or Backup Copy Job, and go to the Storage or Target tab, and from the drop-down menu, select the new repository.
Press Next through the rest of the pages of the wizard to finalize the setting. If no error occurs, and the job now lists the new repository in its Repository column, the mapping has been completed.
Note: If you encounter the following error: “Move all backup files to the new backup repository first”, some restore points the software was expecting to find were not found in the new repository. Cancel out of the job configuration and check both the old repository location and the new location to verify that all restore points have been moved. Then return to step 3 again.
Verify migration by checking under Backups > Disk to see that the Job's backup files listed there are now associated with the new repository.
Enable the job that was disabled in Step 1.
Persistent "Move all backups files to the new backup repository first" Error
If the steps in "Method A" continue to lead to the "Move all backups files to the new backup repository first" error, and you have made sure all the backup files from the initial repository are in the new repository. You may need to use "Method B" below to forcefully map the job.
If "Method B" also does not allow you to map correctly, please contact Veeam Support.
Method B: New Job, New Backup location
To map the existing backup files to a new or different job, follow these steps:
Under Backups > Disk, right click the job you are changing repository for, and select Remove from Configuration.
If you are mapping the backup set from one job to another, but the backup location will stay the same, skip this step. If you are moving the backup files to a new location create a new repository for the new location where backup files are located.
Rescan the repository where the backup files are located.
If the backup files are not encrypted, skip this step. If the backup files are encrypted, the encrypted backup will appear under the Backups > Disk (encrypted) node in the inventory pane. In the working area, select the imported backup and click Specify Password on the ribbon or right-click the backup and select Specify password. More Information This is also relevant for encrypted Veeam Agent backups.
Edit the Backup\Backup Copy Job. Go to the Storage\Target tab, and from the drop-down menu, select the repository where the backup files you wish to map are located.
Click Map Backup and select the existing backup chain
If you are attempting to seed failover cluster Veeam Agent for Microsoft Windows job’s restore points, please follow the actions below (it has a bit different workflow due to the product design):
If you have attempted to manually import the backup, before performing the steps outlined in this article, you must first "Remove from configuration" any backups that were manually imported. These will be identifiable in the Backups > Disk (Imported) section. They will be listed with the suffix _imported and will have no repository listed in the Repository column.
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
Your feedback has been received and will be reviewed.