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.
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.
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).
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).
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
Event ID: 15
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.