topic Re: Another question about SMVI, app consistency and SMSQL/SMExch in ONTAP Discussions

Another question about SMVI, app consistency and SMSQL/SMExch

MARCO_CAMPANA — Thu, 05 Jun 2025 05:59:31 GMT

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.

Re: Another question about SMVI, app consistency and SMSQL/SMExch

radek_kubka — Fri, 28 Jun 2013 16:10:48 GMT

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

Re: Another question about SMVI, app consistency and SMSQL/SMExch

pedro_rocha — Fri, 28 Jun 2013 21:26:28 GMT

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.

Re: Another question about SMVI, app consistency and SMSQL/SMExch

MARCO_CAMPANA — Mon, 01 Jul 2013 12:57:32 GMT

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

Re: Another question about SMVI, app consistency and SMSQL/SMExch

pedro_rocha — Tue, 02 Jul 2013 17:11:50 GMT

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.

Re: Another question about SMVI, app consistency and SMSQL/SMExch

JustinM — Thu, 25 Jun 2015 12:38:30 GMT

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.