Per-VM Backup Files using Per-Host Backups

[collinp]

If we enable Per-VM Backup on our backup repository and then pin each backup job to a different VMWAre host, what is the result if the VM live migrates to another VMWare host...is that single per-vm backup file still maintained?

For instance, VM1 lives in a VMWare Cluster comprised of VMHost1 and VMHost2. We have backup jobs VMHost1_Backup and VMHost2_Backup. On Monday night when the backup occurs, VM1 is on VMHost1 and gets captured by the VMHost1_Backup job. On Tuesday, VM1 live migrates to VMHost2 and VM1 gets captured by Tuesday nights backup job VMHost2_Backup. Are there 2 different per-VM Backup chains for VM1 since it is a part of 2 different backup jobs?

[foggy]

Hi Collin, yes, each job stores its backups in a separate folder in a repository so there will be two independent backup chains for this VM in this case.

[collinp]

Are there any inefficiencies surrounding backing up VM's per host or is it seamless?

First thing, if a VM is moving between two hosts and we are backing up by host, will it create extra backup storage space because both jobs will have to do full backups of that VM at some point? We are using Synthetic fulls.

Second. Also, will restores for that VM be seamless because I foresee that the restore console will have to piece together the restore of files within that VM across 2 different jobs?

[foggy]

For the first one, yes, double space will be required as backup chains are independent and each of them will have a separate full with subsequent increments. For the second, restore will be performed from the particular restore point you specify and will require just the backup chain the restore point belongs to - there's no interference between the chains of different backup jobs.

[collinp]

It would not be quite double the size in my scenario, correct?

My scenario is I am using 90 day retention, weekly synthetic fulls and no scheduled active fulls. So for that 90 day period of retention, the vm is either in job1 or job2. Let's say the vm was on each host half the time (45 days on each host during the 90 day retention). Job1 would only be storing 45 days of backups for that vm and job2 would only be storing 45 days of backups for that vm. So there is no ineffeciencies there since each jobs data size will only be for the 45 days the vm was on each host. The weekly synthetic fulls will also only process the data for the 45 days that the vm was on that host.

The only ineffeciency is the first time the backup occurs with that vm on it which is always a full backup.

[foggy]

Correct. I missed the synthetic fulls and was thinking more of a forever forward incremental scenario with just a single full where the second job would also need space for a full backup. In your case, space considerations are not that relevant.