Recreate snapmirror with existing snapshots

[cgrossman]

I've implemented a qtree snapmirror QSM relationship between a primary FAS2050 filer, named pna, to a backup FAS2020 filer, named wna.  I update the QSM every night using a line in the snapmirror.conf.  That is the equivalent of having a nightly backup off site.  I have a script that runs on a Windows machine that initiates a snapshot on wna every four weeks.  This is because I have hourly/nightly/weekly on the primary pna for up to 4 weeks.  I've been taking snapshots of the backup wna every four weeks for about 2 years.  Those snapshots are critical to keep for restoration purposes.  The snapshots are relatively small, but the data overall is over 600GB.

We had to relocate pna, and somehow, some way, we lost the baseline snapshot.  If I rebaseline, it will run out of space because it will keep all of the existing snapshots, and consider all the data coming from the new baseline as new data, effectively doubling my storage usage.

My next plan was to initialize it from pna to a new volume/qtree on wna.  Then, do a file copy from each snapshot (one by one) on the old qtree to the new qtree, and take a new snapshot.  After doing that for every snapshot, I would then bring the snapmirror from pna current, and resume nightly snapmirrors.  I started this, and have the qtree fully snapmirrored to wna, but I can't perform the file copy/sync because the qtree is not writeable unless I quiesce/break the snapmirror.  I did that, but now I find that when I get to the point where I have to do a snapmirror resync, it's going to delete all of the snapshots I plan to take after each file copy.

Is there any way to keep my snapshot data, and the snapmirror operations?  Keeping snapshot copies seems like such a great asset to owning NetApp until you lose a baseline!

Thanks,

Carlo

[billshaffer]

In your orignal setup, you were doing the QSM, then taking snapshots of the parent volume on wna  to mimic nightly backups you can revert to, correct?  So volume level snapshots are not overwritten on a QSM update to a qtree within that volume.

So I don't understand, in your new setup, why the final resync would overwrite the volume level snapshots you've taken after the file copies?  If the relationship is broken, you copy files from one snapshot to the qtree, take a volume snapshot, and repeat as needed, when you resync the QSM, the volume snapshots should still be there.  The blocks they point to may get overwritten, which will increase your space utilization, but the snapshots themselves should persist.

I have not done any qtree snapmirrors, so maybe I'm missing something?

It sounds like it may be best to just leave the initial copy with its snapshots, rebaseline to a new volume/qtree as you've done, and start taking snapshots there.  True, you've doubled your space on wna, but it may be the best option available...

Bill

[cgrossman]

The QSM happens nightly in case of a catastrophic failure on pna, we have something as recent as last night, but we don't take nightly snapshots - each night the snapmirror overwrites.  I only take snapshots every 4 weeks, so that I can go back in time as far back as possible 4 weeks at a time.

I was following the same logic in thinking that the final resync would update the baseline snapshot to the current data, until I read the following.

According to this document

https://library.netapp.com/ecmdocs/ECMP1196817/html/snapmirror/resync.html

The default behavior of the snapmirror resync command is defined as follows:

• Finds the most recent common Snapshot copy between the source and destination volumes, removes Snapshot copies on the destination volume that are newer than the common Snapshot copy and mounts the destination volume as a DP volume with the common Snapshot copy as the exported Snapshot copy.

In this case, the most recent common snapshot copy between pna and wna is going to be the baseline.  If I do my file copies from each folder in ~snapshot and take new snapshots, then do a resync, per documentation, it will remove the snapshot copies that I made because they are newer than the common snapshot copy.

That seems to totally foil my plan.

[billshaffer]

I would have to test it, but I suspect that this applies to volume level snapmirror, in which case removing destination snaps newer than the common snapshot makes sense, since they won't exist on the source and the entire source volume (including snapshots) will be transferred.  It does not seem reasonable to me that the destination volume's snapshots would be removed for a qtree snapmirror (that being said, I have seen plenty of things that don't seem reasonable to me...).

Like I said, I haven't used QSM, and I don't know for sure what its snapshots look at, but I think the bit you quote is for volume snapmirror.  Easy enough to test with a small data set....

Bill

[aborzenkov]

I do not understand how resync (or rebaseline) can double space consumption. If you keep snapshots for several years, having one more snapshot during SnapMirror should not cause any issues.