Behaviour of WAN-X Digests when switching vCenters?

[pkelly_sts]

I recently migrated to a new vCenter which, as expected, needed various work etc. to get the backup/replication jobs in sync.

However, I've come in this morning to a failed Backup Copy job due to the WAN-X cache drive filling up. It was configured with 250Gb but only covers no more than around 6 OS/s (would be useful if there's a way we can actually review this info somewhere?

I've added another 50Gb & re-sync'd the job but it makes me wonder whether or not we're leaving "old" digests folders, related to previous instances of VMs on legacy vCenters behind when we do these kinds of migrations? If so, what's the safest way to clean them up given that everything is named with GUIDs etc. so not easily recogniseable?

**Feature Request**: As an aside, I can't remember which of our jobs are pointing to this WAN-X (I know someone is likely to ask how many jobs are using it) without editing every job to check, but it would be really cool if there was some way we could do the equivalent of, say, right click on a WAN-X in the console, select properties or simlar, then list all the jobs that are CURRENTLY dependent on that WAN-X? Would be even better in a standard pane (select WAN-X on the left, show useful info about it on the right etc.)

Actually, if my theory above is correct & there are defunct digests lurking around, it'd also be useful to be able to somehow automatically clear down legacy digests folders/caches...

[foggy]

Since VM ID's changed, digests re-calculation could be the reason. Cache data itself should be reused. Do you mean the source WAN-X cache drive filled up?

To cleanup the old ones, check the folders for the files with old moref ID's in the name.

[pkelly_sts]

Yes, it's the digests that consumed all the space & it was the source WAN-X cache drive that filled.

Is there an easy way of capturing the current moref IDs?

I did notice a pattern in the naming of the digest folders: the 5th section in the name seems to be either _2000_, _2001_, _2002_ etc. so presumably lower number (in the same pattern otherwise) = older version of?

[alanbolte]

2000+ would be disk keys - you can see these in the MOB. Typically 2000= disk 1, 2001 - disk 2, etc, unless there have been disks added and removed.

[pkelly_sts]

Sorry Guys, I've followed the KB ref'd in the last post & now have the moref id's for all the VMs on the datastores that are relevant, but how do I relate these IDs to the GUID-named folders in the digests folder of the WAN-x?

[alanbolte]

I think foggy was thinking of replica metadata. If I recall correctly, the GUIDs you're looking at are specific to Veeam B&R, though like foggy says you would generally only get a new GUID for a VM if its ref ID changed. You should be able to get the IDs from Powershell. I don't currently have a working lab to check, but it would be something like:

Code: Select all

$job = Get-VBRJob -name "name of your job"
$vms = $job.GetObjectsInJob()
$job.id (prints GUID for the job)
$vms | select id,name (prints GUID for each VM)

Might not work if containers are added to the job. Also, it's GUID_GUID_diskkey_GUID; I can't find my notes on what each of the three are.

[pkelly_sts]

Thanks Alan, I'll take a look at those commands...

[foggy]

The number going after _2000_ in the filename should be VM ID, for ex.:

VeeamWAN\Digests\60003413-9bef-4248-ba7a-8a8dfad11cdd_9a8c46df-bf7e-4747-b674-a05625372f2c_2000_217 - vm-ref-217

[alanbolte]

I guess I must have only been doing backup copies of Hyper-V VMs.

[pkelly_sts]

The number going after _2000_ in the filename should be VM ID, for ex.:

VeeamWAN\Digests\60003413-9bef-4248-ba7a-8a8dfad11cdd_9a8c46df-bf7e-4747-b674-a05625372f2c_2000_217 - vm-ref-217

Ahh, that could be useful, thanks!

(By that logic, my first thought is that I'll now only know the current VM-IDs, not the previous, but having a list of the current VM-IDs, if any of the folders /don't/ match current, AND their files haven't been changed recently, then there's a good chance they're legacy folders...)

[foggy]

Sounds reasonable.