Change Repository for Backup Copy job without full backup

[hslee2]

Hello,

I have a question about changing our Veeam environment.

Here's a summary of our environment:
- We have sites A and B, each configured with local backups via NAS storage.
- Backup copies are configured as iSCSI-type Refs filesystems between sites.
- Site A has agents and unstructured data, while site B has agents and a Nutanix environment.
- Our goal is to convert all storage to immutable storage, while maintaining a backup chain between both sites. (Due to network usage restrictions.)
- Agent Jobs are configured with a 1:1 policy and source server, and Backup Copy is 1:N.

- The version is 12.3.2, and each Backup Copy repository has the Per-machine option enabled (the folders are actually separate).

Here's a brief summary of my plan:
- I'll link a new Linux repository to VBR and manually copy data (rsync). - After copying is complete, I use Repository Rescan -> Agent Job to change the repository and perform a map backup.
- For Backup Copies copied during the same period, I plan to split the 1:N copies and configure the source objects individually or in small groups.

There are some key considerations here:
- Will an incremental backup, rather than a full backup, be performed after the change?
- Can Nutanix Backup Copies change the repository in the same way?

I'd like to hear about everyone's experiences.
Thank you in advance for your advice.

[Mildur]

Hello Hu,

May I ask how much data you have to move? Is it Petabyte or just a few TB?

For Veeam Agent backup jobs, you can use the "Move Backup" feature to migrate your backups to a primary repository — no need for external tools. Simply select a new repository within the backup job and click on Move Existing:


Nutanix backups do not support the "Map Backup" capability. You’ll need to start a new backup chain with the new Hardened Repository.

For Unstructured Data backups, please follow this KB article:
https://www.veeam.com/kb4493

- For Backup Copies copied during the same period, I plan to split the 1:N copies and configure the source objects individually or in small groups.

May I ask what the reason is for creating more copy jobs? Having individual copy jobs for each source agent or VM would require dedicated primary backup jobs, which can be difficult to manage. In my opinion, it's best to keep things simple — use a single backup copy job, provided the target repository and retention is the same for all workloads.

Best,
Fabian

[hslee2]

Hello,
Thank you for the guide.

The data on site A is 12TB (NAS) for the first backup, and 15TB for the second backup copy from site B (Refs).
For site B, the first backup is 14TB (NAS), and the second backup copy from site A (Refs) is 14TB.

The reason I'm not using Move Backup is because, in my experience, it was much slower than manually copying.

If there's any performance improvement, I can try it.

I saw the KB link for Nutanix backups (https://www.veeam.com/kb2851). Doesn't that apply to my case? The key is actually moving the Nutanix backup copy data from site B stored on site A.

The purpose of the migration is to migrate the backup copy without a full backup.

The reason I can't do a new one is because the available bandwidth in the remote area is very low and cannot be increased.

Finally, the reason I'm separating the Backup Copy policy is to prioritize only some of the targets configured as Backup Copy sources, rather than migrating the entire data.

For proper incremental backups, I believe both the Backup job and Backup Copy job must be enabled simultaneously after data moving.

Thank you for your feedback.

[Mildur]

I'm not sure that using rsync for the machine backup files is the solution, as I don’t see how it could perform faster than Veeam Mover over a slow link.
Rsync copies each file without block cloning functionality, which means you’ll lose all space savings currently provided by ReFS. Our Backup Move feature, on the other hand, moves backup data with block cloning awareness.

If you like to test the performance first, you can use the Copy Backup option. It does the same as Move Backup.

Example:
You have 10 full backup files, each 10 TB in size. With ReFS and our Fast Clone Technology, you might only be using 15 TB of disk space today.
rsync will copy all 10 × 10 TB files to the new repository, requiring 100 TB of disk space. With Veeam Mover, the move functionality is Fast Clone–aware, preserving ReFS space efficiency.

For proper incremental backups, I believe both the Backup job and Backup Copy job must be enabled simultaneously after data moving.

Incremental backups do not depend on when the job is enabled. If mapping backups is supported for a specific workload, the next job session will be an incremental (if no full is scheduled on that day).
That said, in general, you should enable the copy job right after the backup job — there’s generally no need to wait for days before doing so.

Maybe you can use a temporary third server or NAS as migration storage, to overcome the network challenges?

Best,
Fabian