Another question about SMVI, app consistency and SMSQL/SMExch

[MARCO_CAMPANA]

Hello there,

I know that this argument is widely discussed in a lot of posts, but after hours of reading I'm not able to clarify a doubt.

I have a customer with a vmware VM (win 2008R2) located into an nfs datastore (both os disk and data disk) and doesn't have snap manager software but has a DR site synced via snapmirror relationship.

The question is: Using the backup feature of the VSC plugin with the options to trigger a vmware snapshot before taking the netapp snapshot will the sql database (located in D:) be usable after a restore (or, same question: in case of DR does the snapmirror copy contains usable database data?)

Reading the tr-3737 pdf at page 29 (chapter 9.2.3) seems that shouldn't be a problem and the only feature that you cannot use is point in time recovery cause missing rollforward capabilities but, if the scenario with only one backup per day is acceptable, then could I sleep with peace of mind about the DB consistency?

i attach a piece of tr-3737...

Sorry for my poor english, I hope you can understand.

9.2.3  Application Consistency in Combined Solution Environments

NetApp  offers  two  solutions  today  for  addressing  application-consistent  data  protection  in  a  VMware environment:

•  SMVI,  working  through the  VMware  guest  VSS  stack, provides  application-consistent  backup  and recovery  for  applications  that  have  VSS  writers  and  store  their  data  on  virtual  disks  (VMDKs). Recovery, in this scenario, is at the full VM level only.

•  SnapDrive® and application-specific SnapManager products such as SnapManager for Exchange (SME)  and  SnapManager  for  SQL  (SMSQL)  running  in  the  guest  OS,  provide  application-consistent backup and fine-grained recovery for applications whose data is stored using Microsoft iSCSI Software Initiator LUNs or RDMs. 

The  critical  difference  in  the  level  of  protection provided  by  each  of  these  solutions  is  in  the  granularity  of

recovery.  To  understand  the  significance  of  this,  you  need  to  understand  the  concept  of  roll-forward

recovery. Roll-forward recovery replays information stored in transaction log files to return a database to the

state it was in at an exact point in time. In order to perform a roll-forward recovery, archival logging must be

enabled, a full backup image of the database must be available, and there must be access to all logged files

created since the last successful backup.

Since  the  only  recovery  mode  available  today  for  applications  backed  up  using  SMVI  (using  the  VMware

built-in  VSS  support)  is  recovery  to  the  point  of  the  last  backup,  customers  must  use  the  relevant

SnapManager application if more fine-grained, roll-forward recovery is required. 

[radek_kubka]

Hi Marco,

Two things to bear in mind:

- VMware snapshots triggered via VSC tend to be temperamental & sometimes refuse to work

- Exchange / SQL logs will not be truncated during VSC backup, so additional log maintenance is required.

Regards,

Radek

[pedro_rocha]

Hello Marco,

This is not clear for me also. I understand that the VMware consistency snapshot will guarantee file system consistency. So your DB should be consistent in terms of the the file system upon which it is placed.

But searching a bit fore I found a VMware paper where they talk about app-consistency for Exchange using VMware VDR (http://www.vmware.com/files/pdf/exchange-2010-on-vmware-availability-and-recovery-options.pdf).

I understand that it will work the same for quiesced VMware snapshots of Windows Server VMs with VMware tools and VSS configured. On the other hand, as Radek mention, I've seem several issues with quiesced VMware snapshots of MS Exchange DAG nodes, where clients lost connection with the server quite often. And other problems where those types of snapshots does not complete.

I would go with crash-consistent VSC snapshots of the involved VMs and use SME to protect mailboxes and databases (which will do the log management thing).

Kind regards,

Pedro Rocha.

[MARCO_CAMPANA]

So.... it will works but there are more work to do in case of recovery?

[pedro_rocha]

Marco,

If you choose to only run app consistent snapshots using VSC, and if they work all along, recovery is easy since you would just revert to some snap, mount and verify DBs and restart the rest of the Exchange services...

If you go with crash consistent snapshots + SME, you would revert the VM, and from the SME console choose the recovery point of the DBs (so you could get more granularity and even point in time/up to the minute automated recovery using SME).

Regards,

Pedro Rocha.

[JustinM]

I would like to resurrect this conversation thread.

I am in a similar position in that I am attempting to backup SQL servers consistently.  One SQL server has several VMDKs attached of varying sizes.  When I run the VSC backup we see the following within the Windows System logs:

The device, \Device\Harddisk13\DR20, is not ready for access yet.

Log Name: System

Source: disk

Event ID: 15

Level: Error

There are seven similar errors, one for each connected VMDK disk.  This also causes disruption to SQL services in that the disks cannot be used for the duration of the backup.  In this case the backup takes approximately 45 minutes.

How can we mitigate this?  The VMDKs are fully provisioned because the customer requires 64bit clusters.