Question regarding Veeam 12 backup move funcitonality

[galbitz]

I know it is probably difficult for you to speak about future product features, but I was hoping you could entertain my problem a bit. We are currently using Veeam 11. We have a local XFS repo housing about 65tb of data. We keep GRT backups and also have all backups immutable for 7 days. We run synthetic fulls on Saturdays. We also have backup copy jobs to another XFS repo offsite. We recently purchased a new array for both locations. It is slightly smaller than our old one (old one was 165tb the new one is only 120tb) but they are both sufficient as we only have 65tb after many months of veeam usage. We ran into issues attempting to move the files to the new repo. Basically, any file copy results in the backup files being rehydrated and we run out of space. This seems to be somewhat well known although truthfully we didn't realize how big of a challenge it was until we tried =).

That has left us really with what seems to be only 2 options. One would be to retarget all backups, run active fulls, and redo the backup copy jobs as well requiring us to transport our secondary san back to HQ for the initial seeding. Basically start over. Block level cloning isn't an option due to the mismatch in array size, but also the amount of downtime associated with that copy would be in excess of a week as the copy runs we would need to pause veeam, that isn't an option.

Our hope is the new backup move features in Veeam 12 will possibly resolve this problem. My main concern is if it somehow allows us to retarget the backup copy jobs to a new repo as well without reseeding everything. Since details are light I don't want to put forward the proposition that we wait for Veeam 12 at work only to find out it doesn't meet our needs/resolve this issue. It seems like it should work for our primary backup jobs, but reseeding the copies is likely our bigger hurdle.

so the main 2 points are:

1. I assume we can move our backup jobs from our primary xfs repo to a new repo without breaking the backup copy jobs (needing to reseed)
2. I am hoping their is a mechanism to move the backup copy jobs to a new repo as well without needing to reseed.

Restarting the backups from scratch sounds simple, but we run into performance issues when the backup jobs are running (we have some vms that are over 20tb) so they run for a long time. This results in weekend outage windows just to get the active full out of the way etc. It would likely take over a month to find suitable windows for all new active fulls.

[mkretzer]

The main problem with waiting for V12 is that while the backups are moved the backup chain is locked, which means you can't run backups for the backup in question.

But i am quite sure you don't have to reseed when doing active fulls to a new storage. Just remove the backups from config, repoint to a new location and do active full. The copy job will still only copy changes (which to me was always kind of magic). But since you want to switch backup target and backup copy target this would only help on the primary site and also would not solve your backup window issues.

I wonder if you could do a local backup copy to the new storage and use that backup as a basis for switching your primary backups to. But i am not sure about this.

[galbitz]

We have a backup job for every VM, so pausing 1 backup as we move it to a new repo isn't a concern. Similarly, we have 1 backup copy job per VM so we do have some flexibility there.