Backing up 4.5tb SQL VM with 8 VMDKs

[jlaco1]

Hello. I am a Veeam Backup and Replication 5 newbie and I am going to be using it to back up a 5TB SQL Server VM. There are eight different datastores. What is the best way for me to back up this beast? Are there any gotchas I should know about? The product seems pretty slick and can't wait for version 6. Also, I'm using vmxnet 3 nics on the veeam 2008 R2 server guest, 10GBE storage network, and I'm not using RDMs. The VM disk specs\config are as follows. Let me know if you need any other info. Thanks!

OS Volume\Datastore
100GB thick

DBLogs Volume\Datastore
100gb thick
100gb thick
130gb thick

DB1 Volume\Datastore
1TB think

DB2 Volume\Datastore
1TB thick

TempDB Volume\Datastore
250GB thick

SmallDBs Volume\Datastore
1TB thick

BatchRestore Volume\Datastore
250GB thick

BackupToDisk Volume\Datastore
1TB thick

[foggy]

Jamey, you should keep in mind, that the VM snapshot is placed on the datastore where VMX file is stored and VMFS block size mismatch might prevent you from taking VM snapshot (if some file exceeds the maximum size supported by datastore).

You can change the default snapshot location to any datastore with enough disk space and appropriate block size using vSphere Client. Power off VM, then select VM > Summary > Options > General > Configuration Parameters > Add Row. Add workingDir parameter to set a new datastore path for the snapshots.

And of course, don't forget to enable "Application-aware image processing" to make transaction-consistent backups. You can also use search on this forum for the best practices on backing SQL up. Thanks.

[jlaco1]

Thanks for the reply Alexander. My sql vm OS disk resides on a datastore for Prod VM Operating Systems. All of the other disks(data, logs, tempdb, etc..) for the vm reside on their own datastores. All VM disks combined add up to about 5 tb. If I want to back up that sql server, since my vmx file is on a datastore used for other vm os disks, I need to create a new datastore with around 10TB(or enough space) for the snapshot. Then add the workingDir parameter that changes the default snapshot location on all hosts, and make sure the Application-aware image processing is enabled. Does that sound about right? Thanks again for your insight. I really appreciate it!

[foggy]

You do not actually need 10TB of space as typically snapshot is much smaller in size than the actual VM. Initially a snapshot is a brand new vmdk file of a zero size and as VM starts to write to this vmdk, it grows in size but not very quickly (depending on the VM's activity). More important that in your case, this datastore should be formatted using at least 4MB block size to be able to store snapshot file of the maximum size (as your largest volume size is 1TB).

[jlaco1]

Ah. Gotcha. I'll use 8mb as the block size for the snapshot datstore. The sql server has a lot of activity and the snapshot would grow huge and pretty quickly. When I run a backup using backup and replication, the snapshot gets deleted when the backup has completed right? The first backup I make of the VM will be a full backup and will be the same size of the original and this will take the longest time. Then the differential backups will happen nightly and will be only the changes made to the vm since the last backup. The nightly differential will create a snapshot and it will be stored in backup and replication right? I won't need to do a full backup again unless the job is deleted from B and R. Do I have this right? Thanks for the clarification.

[foggy]

When I run a backup using backup and replication, the snapshot gets deleted when the backup has completed right?

Yes, right.

The first backup I make of the VM will be a full backup and will be the same size of the original and this will take the longest time.

If you use compression and deduplication (see our sticky F.A.Q. topic for details), the backup file (VBK) will be much less than the original VM size.

The nightly differential will create a snapshot and it will be stored in backup and replication right?

If you mean the restore point with incremental changes, then it will be stored according to the specified retention policy. The snapshot will be deleted right after the backup is done.

I won't need to do a full backup again unless the job is deleted from B and R.

It is recommended to have periodic fulls due to several reasons. Please see this topic for some recommendations and our user guide for the description of backup modes.

[jlaco1]

Thanks alot for your help and information Alexander!

[jlaco1]

I was reading a VMware KB regarding changing the location of the snapshot using the workingDir option and there was a warning about using this method with ESXi 5. VMware KB link: http://kb.vmware.com/selfservice/micros ... Id=1002929

"Note: In ESXi 5.0 and later versions, virtual disk redolog (-delta.vmdk) files for snapshots are placed in the same directory as the parent virtual disk (.vmdk) file. Do not apply this method to virtual machines running on ESXi 5.0 and higher. If present, the snapshot directory settings are removed during a disk migration."

Eventually I will be moving to ESXi 5 and wouldn't want this to bite me later. What are your thoughts?

[tsightler]

Honestly, I never use this option anyway, too hidden and thus too easy to forget about later. For ESX(i) 4.1 and below I just make sure the vm configurtion file (the .vmx file) is on the volume that I want the snapshots to be created on. By default, snapshots are always created on the volume that stores the configuration file. Assuming you're licensed for Storage vMotion you can relocate this configuration file using the advanced option of the migrate wizard, leaving everything else in it's existing location. That means you can relocate where your snapshots to other volumes without downtime, unlike setting workingDir, which requires the VM to be powered off, and will still get overwritten if you perform a storage migration in the future.

It's interesting, although not surprising, that ESXi 5 changed this behavior, the old behavior was pretty non-scalable for larger, multi-volume VM's. Unfortunately companies that have put their efforts into optimizing existing 4.x environments for snapshots will have new issues. I know of quite a few clients that have dedicated "snapshot", "configuration" or "OS" datastores sized specifically for holding snapshots during backups. Ideally they would allow you to specify the snapshot location on a per-virtual disk level.

[averylarry]

But vmfs5 should obviate any need for the workingDir settings coming from datastore limits (if I understand things properly). That's probably why vSphere 5 dumps it. You don't have a 2Tb limit on datastores, you don't have a 1Tb limit on thick vmdk files (I believe), and you don't have any choices for block size.

Of course, upgrading to vSphere 5 is a much simpler task than migrating all your datastores to vmfs5. And you can run vSphere 5 using vmfs4 . . .

[tsightler]

But vmfs5 should obviate any need for the workingDir settings coming from datastore limits (if I understand things properly). That's probably why vSphere 5 dumps it. You don't have a 2Tb limit on datastores, you don't have a 1Tb limit on thick vmdk files (I believe), and you don't have any choices for block size.

Well, I'd say that remains to be seen. As far as I'm concerned it simply removes some issues and replaces them with new issues. With the old method many customers were dedicated high performance volumes (in a few cases even SSD's) to snapshot volumes to store snapshot during backup. This helped to mitigate the performance impact of snapshots both while they were open, and as they were committed. Also, many companies used this method to pool the free space for snapshots. Instead of having 50 volumes each with 80% free, they'd have 50 volumes that were 95+% utilized and two volumes that were mostly empty. These volumes would be sized appropriately to hold snapshots. This actually used less space overall as now they'll have to make sure that every volume has enough free space to hold any potential snapshot on that volume.

That being said, I haven't had time to really dig into VMFS5 and the options available there, so there may be other way to mitigate this on the new version, but at first glance it's a small step forward (allowing snapshots of a single VM across multiple datastores was a desired feature), but a couple of steps back. Ideally I'd like to see the snapshot space be allocated on a per-virtual disk bases, or at least per-VMFS volume.

[averylarry]

I would suppose there are other reasons as you've shown, but I always figured (and unclearly was referring to) these 2 reasons for using workingDir -- datastore disk space limits and block size incompatibilities. Both are either eliminated or nearly eliminated (I think there is technically a very, very big disk space limit on datastores).

I've never used the workingDir trick -- like you said, I just put the configuration files on the datastore I wanted the snapshots to be on. I've only done that once, because I have a maxed-out datastore (SAN is full) and no room for snapshots on that datastore (instead I'm using a slightly-slower separate SAN).

But anyway -- I guess I didn't want jlaco1 to think that workingDir was required -- there are other ways. vmfs5 should eliminate the reason foggy brought it up in the first place -- and jlaco1 then brought up ESXi 5 (which, as I said, doesn't have to mean vmfs5).