Veeam 12 Move Backup Job Function

[galbitz]

Hello,

We are currently on veeam 11. We have around 90 backup jobs, each job is for a single VM. Currently the job backs up to a hardened xfs linux repo. The repo is currently using a per backup job chain.

We then have a backup copy job for each job that goes over the wan to another site. This is also an xfs immutable repo but the repo is setup for per VM backup chains at the remote site.

We have new storage hardware for each location. We were waiting for veeam 12's new move backup function since we were having problems moving xfs data without it ballooning out. I am somewhat concerned about the primary repo's chains being set to per job. It seems this no longer aligns with Veeams recommended approach. There is technically only 1 VM per job, but I assume the file structure is different.

i opened a ticket, but its really a question not a problem: 05901565

What are our options here? We basically want to move to the new hardware without reseeding the remote backup copy jobs. This will not be possible over our wan connection (its hundreds of TB). My hope was to do a backup move at the main site and then a backup move at the remote site both targeting the new repos.

I then started encountering info regarding upgrading to the new backup chain in v12 and I am not sure if that will work with the primary repo being per backup job chains. If i set the new primary repo to per VM chains and i try to move from a repo that was set to per backup job chains will that fail? If i do a new active full locally, will that cause a complete reseed of the existing backup copy job or is there some magic that can only move changes? Looking for advise with the primary goal being to avoid a large wan transfer or needing to pull that repo back to the main site for seeding.

[Egor Yakovlev]

Hi Grant.

Your case should work out of the box with no additional tricks.

- upgrade to v12
- add a new SiteA repository
- use Move Backup feature to migrate source Backup Jobs to a new hardware: that will preserve source jobs, source backup chains, source backup format(even if repository settings are set to "Use per-machine backup chains") and will have zero effect on Backup Copy Jobs traffic
- add a new SiteB repository
- use Move Backup feature to migrate target Backup Copy Jobs to a new hardware: that will also have zero effect on a cross-site traffic. Please double check each repository gateway settings, as gateways play essential role when organizing traffic flow from repository to repository.

That should do it!

Some notes here:
- source backups jobs are currently in so-called "single storage mode". That format cannot be upgraded to per-machine backup files(when repository is set to use per-machine backup files), and will require a manual Detach operation to do so(if in the future you decide to go with the tech flow). That will essentially split existing chain into Orphaned node and trigger a new, fresh, Active-Full chain in a new format. That will have no effect on cross-site Backup Copy Job traffic, but anyhow will storm the source side.
- it is easier to move backups directly from the job wizards themselves. Open the job and change the target from a dropdown - a new dialog will pop up asking if you want to move backups to a new location. Answering positive will trigger a Move Backup session for that job.
- since you have 1:1 job-machine relationship, you can always "evaluate" the whole route on a single job first...

p.s. out of curiosity, why 1:1 design?

/Cheers!

[galbitz]

is there any reason to upgrade the local target at the main site from the single file per backup job to a per VM backup job? I mostly am asking from a forward looking perspective, we don't want to go through this move only to learn its not supported down the road etc. We are about to switch to a new repo, since that is a per repo setting now would be the time to change it, if the wan impact isn't as significant as I was assuming.

Just to clarify one more time, if we switched the new repo at the local (primary site) to per VM backup and ran all new active fulls, are you saying this would not impact the backup copy jobs? I thought that is what you said but that seems a little too good to be true. Do you have any documentation about the detach operation. I am a bit unclear as to why that would be necessary. is that somehow a less impactful active full, and does it create a different outcome then just manually running a new active full?

If you feel its best to change the primary repo to a per VM based storage, what is the correct order of operation. Should we perform a backup copy move to the new repo with it still set to single storage mode and then change it, or is it best to do this on the old storage before moving?

We have single backup jobs for a variety of reasons, the majority was scheduling. We had a fairly slow primary array and we had to strategically schedule backup jobs over the course of a 24 hour period to not only get them to complete but also not impact business. We just upgraded to a pure array this past week and those days are behind us.

[galbitz]

i posted a new thread, we attempted to use the move function. The move itself went fine, however, once the move completed the backup copy job started over and its in the process of moving every restore point that exists for the particular vm we moved. I reached out to support, I am not sure why the associated backup copy job would reseed if we perform a move on the source backup. That was the main reason we needed the move functionality..

[Egor Yakovlev]

Let me answer one by one:
- Per-machine backup chains is the future and it is a safe way to go forward.
- Backup Copy Jobs increments do not depend on what happens with the source backup - full or incremental, single-storage or per-machine - backup copy will transfer changes only.
- Changing repository settings to support per-machine backup chains is as simple as setting a respectful checkbox in repository advanced settings. Making existing repository "per-machine" does not change any existing backup chains format - they will continue to operate in previous mode. Your single-storage backup chain will continue generating single-storage increments and active full will not change it. Only absolutely new chains will have new meta format(new jobs, existing jobs with backups removed from configuration(11), existing jobs with detached backups(12)). Active Full does not re-create backup chain meta and continues using previous format.
- Moving backup between repositories also does not change existing backup chain format. If it was in a single-storage mode, when landed on a repository with said per-machine checkbox, it will continue operate in a previous mode.
- Detach is required to make job "forget" everything it was doing before and start from the scratch. Old backup chain will be handled to Orphaned node, new meta will be generated on a first job run and it will respect current repository backup format settings.
- Note that there are two per-machine backup chain formats as of today. One from v11 times, and a new one in v12. We have improved handling of backup chains metadata, thus if you have v11 per-machine chains, these chains will require an upgrade to per-machine chains of a new format in v12.

/Thanks!

[galbitz]

thanks egor, we are having issues with the move of the normal backup repo triggering a full resend of the backup chain across the backup copy job. I started another thread just so we arent discussing this 2 places.