Veeam B&R 6.1 Patch 1b and replication job retention policy

[farge]

Hello,

I'm configuring new Replication jobs on Veeam 6.1 Patch 1b and need to configure a data retention policy for deleted VMs. The problem is that, despite the fact that it is well described in the userguide (ver 6.1 Rev1, pg 120), the field "VM retention" is not present under "Job settings" -> "Advanced settings" -> "Advanced", where it should be between "File selective image processing" and "Post job activity". Has this feature been removed? I hope not since it is absolutely necessary to me,

Thank you in advance,
E.

[Gostev]

Hi, this setting never existed for replication jobs to start with. It is only applicable to backup jobs that run in modes involving full backup file transformation. Thanks!

[foggy]

Seems to be the wrong screenshot/description in documentation.

[farge]

Ok now I have a problem. Our customers' replication jobs are configured with LUNs as source containers; let's assume we have job1 with LUN1 as source and VM1 on it, and job2 with LUN2 as source. If I svmotion VM1 from LUN1 to LUN2, job2 will process VM1 at the next schedule instead of job1, and job1 won't have anything to process anymore; but, an old VM1 replica still resides on job1's targer datastore (typically different than job2's). How can I control space allocation on target datastores in such a scenario? It seems that it's not covered by the product,

Thanks for your help

[farge]

uhm or job2 is smart enough to see that VM1 replica already exists and resides on a certain target datastore and keeps using both?

[tsightler]

If SVmotion is in use then configuring jobs by datastore is not likely to be a good idea, whether for backup or replication. Either select the VMs individual for the jobs or use a different container object that would not be impacted by the physical location of the VM.

[farge]

Hi Tom,
such jobs have been chosen since total number of VMs to replicate (on site) is around 1300, distributed through different clusters, resource pools and folders in such a way to make the use of other cointainer than LUNs rather impracticable; moreover production LUNs have no more than 20/25GB free space, so the customer cannot afford the risk to fill them by having more than one snapshot active (LUN based jobs process VMs in series); this was the only easily manageable way to replicate VMs with Veeam 5.x in such an environment, at the price of manually keeping track of svmotions, that's why a retention policy would have been so welcomed with the new version (unless it's not needed because version 6.x re-use replicas and their target datastore regardless of processing job),
Thanks,
E.

[tsightler]

If you had to track SVmotions with V5, then it doesn't change with V6. When a VM moves you can manually map the VM in the new job with V6 which wasn't possible with V5 so that's a slight improvement, but it won't just magically use the target VM when it moves jobs.

I still think making a more automated solution would be better, some Powershell scripting could be an option if folders can't be used. A simple script which created jobs based on datastore (adding individual VMs to the job), and then monitored for their movement, but it sounds like you already have some manual process in place for tracking such movements.