How to split up a backup job into separate jobs?

[Dave-Departed]

Hi All,

We initially created an all-encompassing backup job for our Exchange servers, which contained all servers, but now we'd like to break this down for granularity.

Could anyone tell me if it's possible to do this, and somehow still retain the restore points from each VM in the job, please?

Thanks in advance.

Dave

[Vitaliy S.]

Hi Dave,

The only way to accomplish it is to re-use existing backup file with multiple jobs (use backup mapping feature), no other way to split one file into separate ones. If you re-use this file with multiple jobs, VMs that are no longer present in the backup job will age out according to the "Deleted VMs" retention policy settings and your backup file will decrease in size after you schedule the active full backup.

Thanks!

[Dave-Departed]

Thanks Vitaly,

So I could just create 3 x new backup jobs, and map each to the existing combined backup file, then carry on like that? And each VM that is added from the new job will be treated as a 'new' VM, correct? And the old restore points will eventually time out via 'Deleted VMs' settings... Ok, I understand.

Or... Couldn't I just create new separate jobs for each VM, and then remove those VMs from the original job? That way, they would remain as per the 'Deleted VMs' setting in the old job, and restore points would begin from today for the new jobs, if both 'Restore points' and 'Deleted VMs' settings are the same value, that should cover it?

[Vitaliy S.]

So I could just create 3 x new backup jobs, and map each to the existing combined backup file, then carry on like that?

Yes, but the existing combined file should be copied three times to match the number of backup jobs. Each job should have its own backup file.

Or... Couldn't I just create new separate jobs for each VM, and then remove those VMs from the original job? That way, they would remain as per the 'Deleted VMs' setting in the old job, and restore points would begin from today for the new jobs, if both 'Restore points' and 'Deleted VMs' settings are the same value, that should cover it?

Correct.

[Dave-Departed]

Excellent. Many thanks, Vitaly!

And just to be sure, the correct way to remove a VM from a backup (and initiate the 'Deleted VMs' retention settings for that VM) is to go into the properties of the job, and into the Virtual Machines tab, select the machine you want to remove, and then click the 'Remove' button?

[foggy]

And just to be sure, the correct way to remove a VM from a backup (and initiate the 'Deleted VMs' retention settings for that VM) is to go into the properties of the job, and into the Virtual Machines tab, select the machine you want to remove, and then click the 'Remove' button?

Correct.

[dbirnseth]

I presently have a replication job containing 8 VMs. I'd like to move 2 of the VMs to a different replication job that can run on a more frequent schedule. What is the best method of doing this without losing my restore points or taking disproportionate amount of time to re-digest.

My environment has two SANs (I'm replicating from one to the other). My Veeam server is physical and I don't have any other proxies deployed.

Thank you!

[marius roma]

I have an incremental backup job that manages a large number of VM.
I want to split the job in 2 jobs, each one managing half of the VMs.
Based on my experience, if I create a new job for half of the VMs a full backup is performed for all the VMs managed by the new job the first time the new job is executed.
Is there any way to tell the new job going on using the backup created by the original job?
Regards
Marius

[foggy]

Mario, yes, you can map the newly created job to the existing backup, please review the answers above. Thanks.

[pinkerton]

Dear Community,

we are running Veeam VBR 7.0R2 with vSphere 5.1 and are now facing the issue that our backup storage runs out of capacity. Currently we are backing up all VMs in one Job to one repository. Instead of purchasing additional storage we think about reducing Restore Points to make backup files smaller. Since the Retention Policy / amount of Restore Points is tied to the Job this means we need to split the existing Jobs into multiple Jobs with different Retention Policy Settings.

However, if I'm informed correctly Veeam uses per-Job Deduplication and Splitting one Job into multiple ones means that it is likely to loose the benefits of Deduplication, which means the backup size will increase. Is that correct?

Another question: Is it possible to use the existing backups in the current backup repository for the new Jobs so that no full backup for VMs that exist in the repository is necessary? Do I have to use the "map backup" Option for this?

Thanks
Michael

[foggy]

However, if I'm informed correctly Veeam uses per-Job Deduplication and Splitting one Job into multiple ones means that it is likely to loose the benefits of Deduplication, which means the backup size will increase. Is that correct?

You will lose a bit in space, since deduplication is performed within a job, not between backup files produced by different job.

Another question: Is it possible to use the existing backups in the current backup repository for the new Jobs so that no full backup for VMs that exist in the repository is necessary? Do I have to use the "map backup" Option for this?

Correct, please see the topic above for details.

[pinkerton]

Thanks. But reading the Information above states that each Job should have its own backup file. Would this mean, to follow the recommendation, to create a new backup repository for each new Job and copy the files from the exiting repository to it? This would mean that initially I Need three times the space of the current repository as the files will only shrink once the Deleted VMs period kicks in.

[foggy]

Correct. Unless your concern is transferred traffic, you'd probably better perform an active full for all the new jobs as this would take time comparable to mapping the jobs to existing backups.

[pinkerton]

I guess you mean that the time for active fulls might be the same as for the Digest calculation when using mapping the Job to the existing backup?

[foggy]

Correct.

[sasap]

Is it possible to move only one VM backup from one backup job to another or new backup job and preserve already existing VM backups?
Backup repository is the same, not changed.

[Shestakov]

Hello,
You can add the vm to a new(another) backup job and remove it from the former job, restore points of the vm will be kept and deleted in accordance with the job`s retention policy. You will be able to restore from the backup files even if the vm is already not in the job. Does it work for you?
Thanks!

[foggy]

And you can map the new job to existing backup file to avoid full job run.

[perjonsson1960]

Folks,

Is there a way to move existing backup chains from one backup job to another? We have a job that is backing up 215 VMs in VMware, and we want to split that job into three jobs, thus moving some of the VMs to a new job. Or is the only option to create new backup chains for the moved VMs?

Regards,
Per Jonsson
Sweden

[Egor Yakovlev]

Hi Per.

Best way in your scenario is to start new backup chains with 2 fresh jobs and tune the settings of existing one you have right now to serve as 3rd.
After retention hits primary chain, existing backup data of VMs you will shift to another jobs will get removed from the backup chain.

/Thanks!

[perjonsson1960]

Of course! Now that you mention it, I knew that!

What I wanted to avoid was to create new backup chains, since the first backups in the new jobs will be full backups, which take much longer. But I guess that I will have to live with that.

Thanks!

[Egor Yakovlev]

Well if you have free capacity on the repository, and TIME is the main problem to solve, you can copy existing chain 2 times*(to have 3 copies of all restore points in the chain Full+Increments) and use Backup Job Mapping for new backup jobs....however yeah, that will be 3x of backup size for the price of 1 Full backup time execution. Your choice!

[perjonsson1960]

Yes, well, I have never really understood the backup mapping procedure, so I think I'll just go with the new chain scenario... Thanks!

[foggy]

Hi Per, mapping is fairly simple and if you have per-VM chains enabled, you do not even need 3*x space to perform the split.

[liamiha]

Hi

I have a backup copy job with 20 VMs but it doesn’t always complete during the night and runs during the day which slows down our WAN connection.

I would like to perform the following:

1. Create a new BCJ and split the VMs between the two jobs
2. Create a copy of the existing VBK in a new folder on the target repository (simple copy and paste on same NAS)
3. Rescan in Veeam
4. Map the new BCJ to the new copied folder with VBK
5. Run new BCJ
6. If successful, wait a few days and then delete the duplicate VMs within each BCJ

I am then going to run the jobs on alternate days to get successful copy data at the target site

Due to the very slow WAN connection I cannot perform a full pass of data and cannot perform a local seed and drive it to the target site (COVID-19 and essential travel).

Would what I am suggesting work? Someone suggested I may need to also copy the VBM and edit it to fool Veeam into thinking there is just a single full backup and not complain about missing chain.

Any help appreciated!

Thanks

[liamiha]

Just looking at the vbm file, it doesn’t look easy to edit, so scrap that.

If I rescan the directory with the single VBK will the vbm be re-created when the job runs?

Appreciate I am trying to do something unusual (perhaps unsupported) but I can’t transfer the 1TB of data in these 10 VMs.

[foggy]

Hi Liam, your approach will work provided you copy VBM file along with backups. This file is required for successful rescan/mapping.

[liamiha]

Thanks foggy.

I attempted this but it didn’t work but I didn’t copy the VBM file as I wasn’t copying the whole chain including full backup and several incremental passes; I was only copying the full VBK and assumed Veeam would complain about the missing incrementals.

Suffice to say, the re-scan didn’t find the backup and so I was unable to map it to the job.

I logged this query with support too (Case # 04105535) and the response said it wasn’t possible so I deleted the copy of data.

I am currently running a manual seed and will be driving it to site.

[foggy]

Rescan doesn't work without VBM and full chain is required. You should duplicate the entire contents of the target folder.