ONTAP Data Protection Tip – SnapLock for SnapVault

Several years ago, one of my customers, Dan, coined the term “Administrative Misadventure” to describe a mishap of deleted data by a storage administrator.  SnapVault of source volume Snapshot copies to a destination cluster with a different administrator was the solution.

But what if the same administrator had access to the source and destination cluster?  Or what if you want to lock a Snapshot copy so it is immutable until a specific date?  NetApp SnapLock is a solution that prevents this misadventure.  Most think of SnapLock as a file locking mechanism which it is, however it also has the capability to lock vaulted Snapshot copies.  SnapLock works at the Snapshot or file level.  This is not new and was formerly called “LockVault” in ONTAP 7-Mode. The feature is carried forward in ONTAP 9 as “SnapLock for SnapVault

The three NetApp links below describe the solution in detail.  All you need is a SnapLock license on the destination cluster and you are all set to lock your vaulted Snapshot copies. Note that SnapLock is only supported with NAS data and LUNs are not supported in a SnapLock volume.

NetApp Tech Report 4526

page 26, section 5.9 “SnapLock with SnapVault”

Committing Snapshot copies to WORM 


Archive and Compliance Using SnapLock® Technology Power Guide  

Page 22. “Committing Snapshot copies to WORM”

Here is some more information and a demonstration of the solution on my 9.7P1 VSIM

  • The source volume cannot be a SnapLock volume
  • The destination volume must be SnapLock
    • Enterprise (SLE) is listed in the TR, but Compliance (SLC) also works on the destination volume (set by the aggregate)
  • The destination volume cannot create scheduled Snapshot copies
  • The SnapLock default minimum setting is used to lock the Snapshot copy vaulted to the destination
  • The SnapLock “snaplock-expiry-time” is applied to the SnapShot copy and can be extended

Create a destination volume on a SnapLock Enterprise (SLE) aggregate

volume create -vserver dest_sl -volume vault -aggregate cmode_prod_01_aggr1_sle -size 10g -space-guarantee none -type DP

Set the default retention period

volume snaplock show -vserver dest_sl -volume vault           # default is min 0 years

volume snaplock modify -vserver dest_sl -volume vault -minimum-retention-period “365 days”

volume snaplock show -vserver dest_sl -volume vault

Peer the SVMs

vserver peer create -vserver source_data -peer-vserver dest_sl -applications snapmirror

vserver peer accept …             # on the source cluster

Create the snapmirror policy

snapmirror policy create -vserver dest_sl -policy sle_vault -type vault

Create a rule that defines the Daily label and specifies that 30 Snapshot copies matching the label should be kept in the vault

snapmirror policy add-rule -vserver dest_sl -policy sle_vault -snapmirror-label daily -keep 365

Create the SnapMirror Relationship

snapmirror create -source-path source_data:apps -destination-path dest_sl:vault -type XDP -policy sle_vault -schedule daily

snapmirror show

Initialize the SnapVault relationship

snapmirror initialize -destination-path dest_sl:vault

snapmirror show -destination-path dest_sl:vault

To extend the expiry time of a snapshot

snapshot modify-snaplock-expiry-time -expiry-time {“MM/DD/YYYY HH:MM:SS [{+|-}hh:mm] | infinite”}

NetApp ONTAP Tip – Dude, where’s my mirrored Snapshot copies?

ONTAP Data Protection – How to replicate missing source Snapshot copies

Dude where’s my mirrored Snapshot copies? A customer replicating with SnapMirror used the “MirrorLatest” policy to replicate from source to destination.  Later, they modified the policy to “MirrorAllSnapshots” to replicate all source Snapshot copies.  However, they found the destination was still missing the source snaps.  Note that Vault or MirrorAndVault policies would also cause this condition where you will miss source Snapshot copies on the destination when you convert to MirrorAllSnapshots.  For review, Extended Data Protection (XDP) mirrors are flexible between ONTAP releases, and are also flexible between policy type.  Vault policies allow you to replicate specific source Snapshot copies while keeping a different retention, typically more, on the destination.

I was unable to find a KB article on this workaround, and if you find one, please post a link in the comments below.  Below is a technical step-by-step procedure showing how we replicated all snapshots without having to reinitialize the mirrors.

  1. The initial setup without all the Snapshot copies.

The output below shows SnapMirror replicating only the latest Snapshot copy.  Notice that the source volume has five snapshots and the destination only has the latest snapmirror snapshot.

cluster1::> snapmirror show -fields policy

source:vol1 dest:vol1        MirrorLatest

cluster1::> snapshot show -vserver source -volume vol1

cluster1::> snapshot show -vserver dest -volume vol1

  1. When you modify the SnapMirror policy to “MirrorAllSnapshots” and update the mirror, the expected all source Snapshot copies are missing on the destination.

cluster1::> snapmirror modify -destination-path dest:vol1 -policy MirrorAllSnapshots

Operation succeeded: snapmirror modify for the relationship with destination “dest:vol1”.

cluster1::> snapmirror update -destination-path dest:vol1

Operation is queued: snapmirror update of destination “dest:vol1”.

cluster1::> snapshot show vol1

  1. REMEDIATION: This step-by-step method below will bring back older snapshots source to destination.
  • Break the mirror

cluster1::> snapmirror break -destination-path dest:vol1

Operation succeeded: snapmirror break for destination “dest:vol1”.

  • Delete the SnapMirror (note: this will not delete the baseline snapshots, so you can still resync later without a full baseline)

cluster1::> snapmirror delete -destination-path dest:vol1

Operation succeeded: snapmirror delete for the relationship with destination “dest:vol1”.

  • Recreate the mirror with -policy MirrorandVault (temporarily to resync the oldest snap in the next step)

cluster1::> snapmirror create -source-path source:vol1 -destination-path dest:vol1 -vserver dest -policy MirrorAndVault -schedule hourly

Operation succeeded: snapmirror create for the relationship with destination “dest:vol1”.

cluster1::> snapmirror show

  • Snapmirror resync with the -source-snapshot pointing to the oldest source snapshot, and the oldest snapshot copy will vault.  This will not replicate all snapshots, but having the oldest will allow us to replicate all in the next step.

cluster1::> snapmirror resync -destination-path dest:vol1 -source-snapshot snap1

Warning: All data newer than Snapshot copy snapmirror.1d7fa696-c999-11e8-a478-000c29c5b6a2_2152873203.2018-10-06_121255 on volume

         dest:vol1 will be deleted.

Do you want to continue? {y|n}: y

Operation is queued: initiate snapmirror resync to destination “dest:vol1” for the snapshot snap1.

cluster1::> snapmirror show

cluster1::> snapshot show -volume vol1

  • Now, change the policy back to MirrorAllSnapshots

cluster1::> snapmirror modify -destination-path dest:vol1 -policy MirrorAllSnapshots

Operation succeeded: snapmirror modify for the relationship with destination “dest:vol1”.

  • Update the SnapMirror and verify ALL source Snapshot copies are now on the destination

cluster1::> snapmirror update -destination-path dest:vol1

Operation is queued: snapmirror update of destination “dest:vol1”.

cluster1::> snapshot show -volume vol1

All the source snapshots are now on the destination