Host-based backup of VMware vSphere VMs.
Post Reply
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Behaviour of WAN-X Digests when switching vCenters?

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Behaviour of WAN-X Digests when switching vCenters?

Post by 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
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Behaviour of WAN-X Digests when switching vCenters?

Post by 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
Veteran
Posts: 635
Liked: 174 times
Joined: Jun 18, 2012 8:58 pm
Full Name: Alan Bolte
Contact:

Re: Behaviour of WAN-X Digests when switching vCenters?

Post by 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
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Behaviour of WAN-X Digests when switching vCenters?

Post by 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
Veteran
Posts: 635
Liked: 174 times
Joined: Jun 18, 2012 8:58 pm
Full Name: Alan Bolte
Contact:

Re: Behaviour of WAN-X Digests when switching vCenters?

Post by 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
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Behaviour of WAN-X Digests when switching vCenters?

Post by pkelly_sts »

Thanks Alan, I'll take a look at those commands...
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Behaviour of WAN-X Digests when switching vCenters?

Post by 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
Veteran
Posts: 635
Liked: 174 times
Joined: Jun 18, 2012 8:58 pm
Full Name: Alan Bolte
Contact:

Re: Behaviour of WAN-X Digests when switching vCenters?

Post by alanbolte »

I guess I must have only been doing backup copies of Hyper-V VMs.
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Behaviour of WAN-X Digests when switching vCenters?

Post by pkelly_sts »

foggy wrote: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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Behaviour of WAN-X Digests when switching vCenters?

Post by foggy » 1 person likes this post

Sounds reasonable. ;)
Post Reply

Who is online

Users browsing this forum: Google [Bot], IvanK, SysSadMan and 80 guests