SAN Snapshot usage

[BGS-IT]

Hi,

Yesterday I converted a 2TB mirrored (3.4TB utilised) thinly provisioned volume to a fully provisioned volume which consumed 4TB. The volume contains part of the clustered Hyper-V virtual machines.

However when DPM runs and creates an application snapshot it consumes a further 3.4TB of storage until the snapshot is finshed with and deleted, the snapshot is listed as being Thin in CMC.

When I switch it back to Thin provisioning the snapshots only take up a few gigabytes of space.

This is with DPM 2012 R2 and the SAN is running on version 10.5.

Does anyone know a way around this?

Regards.

[oikjn · Accepted solution]

unfortunately that is how it is.  Keep it thin provisioned.

Why do you want to make it thick?  Just leave it thin and if you are paranoid, just make sure that you don't overprovision your LUNs.

[BGS-IT]

Thanks for that.

Is this a v10.5 issue or does it affect all HP SANs?

We wanted to make it Full provisioned because we've run out of space in the past due to snapshots not being removed automatically after backups

[oikjn]

it applies for all versions that I've dealt with (at least since v8.5)

What I do is I create an "emergency space" LUN that isn't actually filled with any data, but is thick provisioned.  That way, if I"m not paying attention and the san actually fills with space and stops serving IO, I can quickly delete that LUN, get back enough space to get the SAN functioning again and then deal with freeing up space for real or purchasing extra space.  In my case, I keep a 50GB LUN for this ammount, but you might want to keep more/less depending on what your data usage rate is and how quickly you think you can respond to get more storage or delete unneeded space to free things up.

On of the major problems with the SAN as it is now is that there is no space reclaimation for thin volumes other than deleting the LUN once its expanded.  There is a rhumor that will change in an upcomming release, but I'm not holding my breath given their history of updates.