VSC Backsups (Virtual Storge Console)

[WILLIAMCODY]

I am using VCS for VMware VM Backups I have a 2.5TB Volume with 20% snapshot reserve using Dedup and compression. I have 987.94GB of Data and my Snapshot space is 828.6GB as I was looking at the Snapshot copies I noticed a SMVI Snapshot was 742GB total Size Cumulite Total size was 778.92GB this snap was taken at 11:50PM as I have my SMVI snaps on a 6hr schedule. The rest of the smvi snapshots are between 1 and 3GB and the oldest one I have is 16GB. I am looking for and help on what I should be troubleshooting on this as my .snap is almost as large as the used space in my volume.

Thanks..

[paulstringfellow]

Did you run anything like a space reclaim or copy in any new VMs to the data store?

A snap that size is caused by a large amount of change…

Compression is another thing to look out for, if you post compress, it can write an awful lot of new blocks as part of the compression job…

But you are looking for changes between the two snapshots.

Sorry if that’s all basic stuff…but always a good place to start…

[WILLIAMCODY]

I do run Dedup at 12am  and compression is enabled on the volume but compress Inline is not checked. VMs should have not been added the datastore at this time and the smvi is on a VM level not the entire datastore.

[TBRADLEYFARRIS]

Any storage vMotion activity in VMware Tasks & Events or system time change between your vCenter server and the NetApp filer?

[TBRADLEYFARRIS]

William,

Check the VSC server log on your vCenter server. If no event is present during that time, the snapshot must be from a source other than VSC, such as an OnCommand/DFM server or a manually initiated snap command.

C:\Program Files\NetApp\Virtual Storage Console\smvi\server\log\server.log

https://kb.netapp.com/support/index?page=content&id=3012940&locale=en_US

Also, you can spot check the snapshot history on the filer by using the snap list command.

Example: snap list [ -A | -V ] [ -n ] [ -l ] [ -b ] [ [ -q ] [ vol_name ] | -o [ qtree_path ] ]

[paulstringfellow]

Just be wary of that post compression job…

Basically when compression runs it can potentially rewrite an awful lot of data blocks…as there is a rewrite process when the compression runs… dedupe has less of an effect, but both can have an effect.

Does the large snapshot straddle the dedupe/compression job?