Sanity Check on Disk mode

[samugi]

Scenario:

Exchange 2003 VM with OS (c:) on VMDK and mail stores(m:) / Logs(l:) on SAN RDM LUNs. I Use VISBU script to make backup images and will eventually use VCB. I am considering setting RDM LUNS to Independent : Persistent so that snapshots taken for backup will not stop I/O to Data/Log LUNS. I've had one scary incident where coworker left snapshot active on the Exchange VM for a long time and it took a very unsettling 9 hours to commit. The use of Independent : Persistent disk mode would be targeted to prevent this type of situation. My understanding is that in this mode all I/O is immediately written to the disk regardless of if there is an active snapshot or not. The only data I want to preserve from these image backups with shapshots are the OS/Exchange binaries, not mail store / log data.

Question:

Is this an appropriate use of Independent : Persistent mode and are there any issues / concerns from snapping the VM OS drive this way. I saw at least one old topic indicating that Independent mode was not operating properly and could cause VM shutdown. But I do not know if this is accurate or its been resolved.

Input is greatly appreciated.

SCP

[RParker]

Well if you want to backup these VM's, you must leave snapshots enabled. You could simply turn off snapshot ability by use of permissions on VM's, so that "co workers" can't do crazy stuff.

That would be my suggestion.

[samugi]

My understanding is that the use of independent disk does not take away snapshot ability for the VM but allows you to exclude specific disks from snapshots. Backups of the servers RDM LUns are done by a different process than the 'snap' backup done by VISBU.

So in my scenario....

VM files - snapshopt VISBU backup

Disk C: -VMDK file- (os and Exchange binaries) - Snapshot VISBU Backup

Disk M: -RDM LUN- Independent disk(Exchange data store) - No snapshot, traditional backup

Disk L: -RDM LUN- Independent disk(EXchange Logs) - No snapshot, Traditional backup

Is this correct?

[oreeh]

With "Independent" (regardless if persistent or not) you disable snapshots completely!

[samugi]

This doesn't seem right.. If setting one disk up as an independent disk renders snapshots functionality for the entire VM unusable, why are independent disks done on a disk basis as opposed to just making a VM 'unsnapable'

I was under the impression I could have one disk independent (unsnapable) and another disk on the same VM setup normally and able to snap shot it.

Guess if that is not the case I have some testing to do

[oreeh]

Having one disk unsnapable and another one snapable IMHO takes the idea of snapshots ad absurdum.

[samugi]

I don't see why. Not every disk assigned to a VM has the same type of data. In my scenario I may want to snap the exchange server prior to applying a patch to the OS or Exchange so that If it causes problems I can roll the changes back by reverting. However in doing so I would not want any new mail messages or legitimate changes made to the production databases rolled back as well.

I keep an image backup of each VM for DR purposes. In doing so I dont want to include RDM LUNS. VISBU allows me to do this by excluding specific drives from the backup, but the snap is still made of all drives. I thought using independent drives would allow me to keep all the same functionality but not snap the RDM's

[oreeh]

Not every disk assigned to a VM has the same type of data.

That's true - but VMware has to draw the line somewhere.

If this was possible I know there were complaints like this:

"My SQL server was installed on drive 😧 and the database was on E:. E: was independent / persistent and 😧 was snapshotable."

"After taking a snapshot and upgrading SQL server I needed to roll back, but SQL modified the database during the upgrade...."

Does that make sense?

But nothing prevents you from creating a VM with mixed independent and snapable disks and taking / reverting the snapshot manually!

For backup purposes it is best (as RParker already mentioned) to leave the snapshots enabled and restrict access to the snapshot functionality using the roles / permissions in VC.

To clarify again: independet disks don't prevent snapshots but effectively prevent backups with most (snapshot based) backup solutions.

[samugi]

Yes that does make sense. and I can see where problems could arise in scenarios like the one you gave, 'IF' the upgrade to SQL server modified the database structure as well. In such a situation the upgrade being performed on the snapped drive also updates the data independent disk. A roll back from such a situation would be 'ugly' at best, and independent disks / snapshots should be used in the way I suggested.

However, The scenario I'm posing is pretty much the opposite. If I snap a production Exchange VM and ALL drives are snapped to include the Mail stores and Logs any roll back would result in loss of data from mail sent from the time of the snap being created. If this is the only way to do it then snapshots are useless on such systems because they present a window of production data loss when the goal is just to create a backup of the OS, or allow a quick 'undo' for a system change.

I am just trying to establish if the independent disk functionality is granular to the disk level as it seems it should be. If it is, then it has use that can be applied where appropriate. If however setting one disk as persistent means the entire VM and all of its other disk assignments can no longer be snapped, then I do not understand it's usefulness and why they didn't just make an 'unsnappable' setting for the entire VM config.

V/r

SCP

[oreeh]

You can snapshot the Exchange with the mail store disk set to independent / persistent and you can revert to the snapshot - no problem at all.

(I guess my English sometimes is too bad to really express what I wanted to say)

But you won't be able to use snapshot based backup solutions!!!

And since the "good" (don't have a better English word at hand) backup solutions are snapshot based you are in a trap - unless of course you use other backup methods.

[samugi]

Ah ok.. that answers my question then. I can do it the way I was suggesting. I will still be able to backup the VM (os) with VISBU and perform normal (backup exec) backups of the exchange mail stores.

I was using VCB with Backup Exec but determined it posed too large a risk to production data. So for now I am using normal backup exec backups of data. I know it isn't best for performance and network utiliztion but until I can provide a locked down VCB proxy server it is the safest way to go.

Thank you for your help on this.

[bodlak · Accepted solution]

Hi,

I am not sure, but how do you want to divide access to disks for image backups ?

Because if you want to do image backups of system disk c: and not disks 😧 and E: it seems to be a bit problem.

When you make image backups, all the drives are snapshoted and transferred to local drive of VCB proxy server.

Does it make sense ?