Nimble with Veeam

[coopsam]

Hellos,

Just wondering if anyone else out there using Nimble storage with Veeam and has seen any issues with VMware snapshot consolidation with non-cached datastores.

We have a job that kicks off 11am Saturdays backing up C/D drives on a SQL server (system and program files drives, not logs or anything else) so it only backs up about 7GB of data and takes about 10 minutes. It then takes on average 9 hours to consolidate the VMware snapshot. We have other servers we do this with but don't seem to take anywhere near as long. The non-cached datastore has the VMDK for the logs drive in it only, all other disks are in datastores which are cached

I have requested the average rate of change for the server for 10 minute period from our DBA's as this is a very busy server.

I have also logged a ticket with Veeam support asking if anything they can think of to help, ref 00877854.

I'll keep the thread update with any info I find that might be of any use to anyone else with a similar issue.

[Vitaliy S.]

Hi Sam,

Just wondering what are latency and write rates for this datastore when snapshot commit operation happens. Can you please clarify?

Thanks!

[chrisdearden]

can you replicate the issue with a manual snapshot of the VM? leave it open for as long as the backup job takes ) does the actual VMware operation show as 9 hours in the VI client, or is the VBR job waiting for a suitably low datastore latency before it does the commit?

[coopsam]

Sadly I can not test versus this server with leaving snapshots open due to the risk of the stun that we have seen when it consolidates.

VMware operation show it taking 9 hours from the start of the snap remove to completion.

On the day in question the datastore was averaging 500 IOPS write and 5 IOPS read. the Vdisk on the server shows also low IOPS across the time period in question.

I can provide full Veeam ONE stats for this time but it really doesn't show much. On the VM it does show a huge spike in write latency that matches up with the outage the server suffered due to the snap removal.

The job now I have checked over it has been taking this length of time to do the consolidation since it began but no one picked up on it as it was being successful and it was not causing the stun on the VM to knock out the service based on it.