By continuing to use our website, you agree with our use of cookies in
accordance with our Cookie Policy.
You can reject cookies by changing your browser settings.
Andreas Neufert wrote: ↑Feb 10, 2019 12:42 pm
Each time we create a snapshot for a VM we check how many snapshots we have created for backup. This is per Datastore. There is no counter, we check actual situation.
Sorry but how other jobs that stucking on such step - "Active snapshots limit reached for datastore" understand how many snapshots on datastore if Veeam don't have counter about it?
I have more then 80 jobs on different datastores - and I don't understand how many snapshots at different time exist.
I have different datastores -VSAN, ISCSI on Windows,Linux repositories - is it normal to change this parameter for all of them at one time?
As I said this was configured in a way that there will be no issues at our 300.000 VMware customers. Individual storages are much faster and do not run into high latency when you create snapshots or snapshot commits. So you need to test maybe in a way by increasing the setting by 1 each day and see if you run into issues.
We are running v.9.5.0.1922, our vSphere Storage is Cisco Hyperflex v.3.5(2a) with ESXi 6.5u2.
Today I saw the limitation of active Snapshots "Resource not ready: Active snapshots limit reached for datastore".
All the Google researches pointe to the registry entry "MaxSnapshotsPerDatastore (REG_DWORD)", but we don't have that registry entry.
Therefore my first question is, where is that limitation set?
Secondary, is that "MaxSnapshotsPerDatastore" registry still valid?
The current limit of 4 is extremely conservative. Its fair if you have an older vSphere/Storage solution, but most current implementation of vSphere on a modern storage solution would have no difficulty processing a lot more than that. We have to pretty much "tweek" this on every implementation now as its actually causing a significant bottle neck in job processing, for no real reason. Would really like to see this as an GUI option on the vSphere cluster or hosts properties in the Backup Infrastructure. That way its not left to people hacking the registry to "fix" it.
I do not know if this is working correctly in 9.5u4a. I have a greenfield installation of 9.5u4 and in one of my backups jobs I have added a VMware Datastore cluster that contains two datastores. When I run this job, it will only process 4 VMs at a time instead of 8. Does it treat a datastore cluster of multiple datastores at 1 datastore or am I missing something else?
I read the previous posts but I am a little bit confused.
I am using B&R version 9.5.4.2615 and I got the message "Active snapshots limit reached for datastore" but I cannot reduce the number of snapshots in my infrastructure.
So, what should I do in order to:
Verify that the number of snapshots is really critical (I am not sure it is…)
To be honest I simply solved the problem by reducing the number of snapshots.
If changing the registry values is the right solution I'll apply it as soon as I face the problem again.
Regards
marius
I'm running version VBR 9.5.4.2866 and the registry value MaxSnapshotsPerDatastore supposedly located at HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\ is not there. Hoegimator mentioned he doesn't see it either is that the case with the rest of you? We are experiencing the same issue and also looking for a solution. Marius Roma mentioned he solved the issue by reducing the number of snapshots can you elaborate on where you did that?
Hi Michael, just create the registry value and set it to the required number. It's a REG_DWORD value under HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication, right.
Considering that this has been an issue since (at least) v7, wouldn't it make sense to finally build the setting into the UI instead of still relying on a manual reg key?
RubinCompServ wrote: ↑Feb 04, 2020 4:15 pm
Considering that this has been an issue since (at least) v7, wouldn't it make sense to finally build the setting into the UI instead of still relying on a manual reg key?
We prefer to keep this one as an advanced setting. Putting it in the UI is best compared to tying a grenade to the steering wheel.
Was this key originally created by the Veeam installer or patcher? I've got it on my old VBR server (that I just migrated away from) and can't for the life of me remember creating it myself (it's set to 20). The new server I just migrated to with a fresh VBR v10 install doesn't have it.
Almost all registry values don't exist by default, in which case the backup server uses their default value (a constant from the code). So, someone did create that value at some point, even if it was not you.
I don't suppose Veeam uses the datastore *name* to determine how many snapshots there are? So, like, if you've got multiple clusters each with one large datastore (Nutanix) and for simplicity you've used the same generic datastore name for each cluster, Veeam will count all of the snapshots it sees as being from the same datastore... Please say that isn't so. (Though it looks like it is...)
These are Nutanix clusters; Nutanix presents storage to vSphere as NFS datastores. If what you say applies in this case, seems like you've got something to fix - two separate datastores on completely different clusters should not share the same snapshot count with regards to this registry key. (I am working around the problem by setting MaxSnapshotsPerDatastore to a ridiculously high number, and allowing the proxy/repository task limits do the job instead.)
They both show up as ds:///vmfs/volumes/[hexcode]-[hexcode]/. (Each [hexcode] is 8 digits.) Both datastores have identical URLs, despite being on different clusters.
So the issue is not the key but the fact that the datastores have identical GUIDs for some reason. Any chance you could check with Nutanix regarding that?
Just a +1 eight years later for this to get into the GUI. I'd think it has become fairly commonplace for enterprise SAN (iscsi or FC) storage to easily accommodate far more snapshots at a time. We're using large capacity flash and/or NVMe arrays with compression, dedupe, and thin provisioning, so more than eight deltas are hardly a concern from performance or capacity standpoints.