Snapdrive: Inconsistent snapshots on mirror

[mikepalandri]

Hi all,

I have a Windows 2008 R2 server with 3 LUNs on a local Netapp filer that’s mirrored to an off-site filer. We have Data Ontap 7.3.3   Snapdrive 6.2 is installed on the server, and I remote desktop to the server to use it.

My question regards the mirror update snapshots.  Whether these are created using “snap create” or  “snap update_mirror”, the result is always a consistent local snapshot, but the mirror snapshot is always an inconsistent snapshot copy.  For example, after a “snap update_mirror”, snap list shows (skipping the Used, Total, and Created columns):

fh-1-remote(0101179405)_fshr1.69                    Mar 30 00:02 Inconsistent snapshot copy
@snapmir@{CD29A4B1-4752-471F-8251-57D6C2ABE91F}     Mar 30 00:02 Consistent snapshot copy

The inconsistent status of the mirror makes me a bit nervous.  When I first contacted Netapp about this several month ago, I got this: “ It’s normal to see “inconsistent snapshot” on the original snapshot that was used to create the mirror.”

Yet I see it on every mirror update to this day.  I more recently opened a new case with Datalink, our support provider which was eventually routed to an Advanced Technical Support Engineer. His response was:

A. The base snapshot, the one that was named when the snapshot was created in Snapdrive, is consistent.
B. Even though the mirror snapshot, the one named fh-1-remote(nnnnnnnnnn)_fshr_nn that was created as a result of checking “Initiate snapmirror update after Snapshot creation” in A above is not consistent, the consistent snapshot created in A is mirrored properly, and therefore could be mounted or restored from.

However, while I can start the process of connecting a mirrored LUN, Snapdrive does not permit me to connect  to mirrored snapshot.  We don’t have a flexclone license for the mirror filer, it’s for major disaster recovery, so I can’t actually complete the connection, but at least I can get to this point when connecting to a mirrored LUN: “You are attempting to connect to a LUN residing on a read-only SnapMirror destination Storage System volume.  The SnapMirror replication for this volume will be broken before a connection to this LUN can be established.  A SnapRestore operation will be performed from the most recent consistent Snapshot copy of the LUN. Do you wish to continue?”

I cannot get that far when trying to connect to a mirrored snapshot, Snapdriveshows a red X near the LUN path. Yet according to the support engineer, I need to connect to a snapshot to get to consistent data.

Does anyone have any experience with this that can tell me if I’ve got anything to be concerned about?

Thanks.

Mike
.

[watan]

For use snapmirror with snapdrive you need to create the volumes, create the snapmirror relationship, remove the snapmirror schedule, create the LUN via Snapdrive.  When a snapshot is created in Snapdrive it will automatically kick off a snapmirror replication.  You can also manually kick off replication but everything needs to be from Snapdrive.

Check out page 154 in the IAG - http://now.netapp.com/NOW/knowledge/docs/snapdrive/relsnap62/pdfs/admin.pdf

[mikepalandri]

Thanks for responding.

The  LUNs were created according to the manual. The volume was created and the mirror relationship was created without a schedule at the Netapp admin console, and the LUNs and all snapshots were created in Snapdrive.

All the snapshots are consistent, with the single exception of the mirror.

[watan]

What happens when you try an update from the GUI?  Have you tried a different volume as a test to see if it produces the same thing?

[mikepalandri]

I get the same results in the GUI as the CLI, actually first encountered this in the GUI.

The volume I'm working with is the only one that uses LUNs and is managed with Snapdrive.

[jakub_wartak]

That's simple, not!

Snapmirror works that way, by creading additonal snaps and replicating earlier ones (differential). You will always see both snaps (it is ok).

In the event of DR you need to connect the consistent snaps. You have two basic ways:

a) connect to that LUN in consistent snapshot by using FlexClones (and typically what Snapdrive for UNIX sometimes does)

b) by breaking the snapmirror relationship and doing a "snap revert" to that consistent snapshot.

Test it somewhere before doing on production, espeically if you really want to use option "b", which is intrusive. You might need to develop way of resync the snapmirror.

-Jakub.

[mikepalandri]

Thanks Jakub.