Large snapshot on busy VM

[aparker]

Hi,

I have a Windows 2003 VM configured with disks as follows:

HD1 - 12 GB VMDK
HD2 - 10 GB VMDK
HD3 - 500 GB vRDM
HD4 - 500 GB vRDM

The backup proxy has direct SAN access to the VMDKs but I am wary of
presenting the RDMs to the backup proxy, and so it only has network
access.

I started a test backup job of this VM and had to cancel it after 15
mins. The delta redo log on HD4 had grown to 7 GB in 15 mins. I
estimated it would take about 10 hours to complete the backup at 15MB/s
(network mode), and so the redo log would likely be over 250 GB and
certainly fill up the datastore.

I see my options as follows:

Reduce the backup window by either:
1) Presenting the RDMs to the backup proxy and then getting SAN access
speeds (this does concern me though and always tried to avoid this)
2) Converting the RDMs to VMDKs

I still think if I do either the window will be around 2-3 hours and create a 60 - 90GB delta.
This would be for the initial full backup, but I also think subsequent incrementals will also
take a fairly long time. I don't really want to have to allocate a lot of dead space just
for the snapshots.

Aside from that I think I'm stuck with our existing guest based solution which is just a
daily robocopy mirror job of the vRDMs to our backup proxy, and a snapshot of the two
VMDKs (with the vRDMs excluded/independent).

I was wondering if i'm missing anything or any other options.

Thanks and regards,
Adrian

[tsightler]

You should check to see if your SAN allows you to present the LUNs to the Veeam server as read-only. Many SANs now provide this feature and it's great for presenting LUNs to the Veeam server in complete safety. Also, if your Veeam server is 2008R2 then you can verify that the default SAN policy is "offline shared", that way Windows will show the disk, but they will disable as "offline". Veeam will still be able to access them via vStorage API, but for someone to do "damage" to them via Windows would require them to manually "Online" the volume.

Also, based on your load you should not assume that the snapshot will grow "linearly". Snapshot files are basically "sparse" VMDK files, so they grow as blocks are changed, however, the chunks are allocated the VMFS block size. What normally happens is, for a server that has a lot of random change (Exchange, SQL, etc.) the snapshot grows quickly at first, because there are lots of small changes being made across the entire disk, but then the growth begins to taper off.

I'm not really sure why converting the RDMs to VMDK would help as the snapshot would still grow. Also, remember that you can redirect the snapshot data to another volume if required.

[aparker]

Thanks for the quick response and appreciate your comments.

Our array (HP EVA 4400) doesn't have the capability to present a LUN read-only to one host and read-write to others unfortunately. But I will definitely try the snapshot again and give it longer this time to check if the growth tapers off. I will also experiment with presenting a test RDM to our proxy (Windows 2003 at present with automount disabled etc) to see just what it would take for someone to corrupt the volume, perhaps it isn't as bad as i'm imagining...or maybe it is