#Cascaded Snapmirror - SM snapshots are being retained in the second leg.

1 messages · Page 1 of 1 (latest)

scenic stag
#

I'm running into odd behavior with a cascaded mirror.

A) RWVOL -> B (Mirror-Vault XDP Volume) -> C (Vault(For Snaplock Volume))

Within the B leg, I have a sm policy setup like below:

Vserver Policy             Policy Number         Transfer
Name    Name               Type   Of Rules Tries Priority Comment
------- ------------------ ------ -------- ----- -------- ----------
eqxontapcl1 
        vault_mirror_standard 
                           mirror-vault  2     8  normal  -
  SnapMirror Label: sm_created                         Keep:       1
                    hourly                                        24
                                                 Total Keep:      25

Then for the C leg the snapmirror policy is setup like below:

Vserver Policy             Policy Number         Transfer
Name    Name               Type   Of Rules Tries Priority Comment
------- ------------------ ------ -------- ----- -------- ----------
eqxontapcl1 
        Vault_Snaplock_hourly 
                           vault         2     8  normal  -
  SnapMirror Label: hourly                             Keep:      48
                    daily                                          8
                                                 Total Keep:      56

The replication relationships are working, however on the B leg, it is retaining all of the snapmirror.* snapshots and not cleaning them up. Any ideas on if that is a feature? 😄

I'm running 9.11.1, and have validated this behavior on other clusters.

This seems similar to the following bug, but the workaround doesn't work, and I'm run on a 'fixed' release:

https://mysupport.netapp.com/site/article?lang=en&page=%2FAdvice_and_Troubleshooting%2FData_Protection_and_Security%2FSnapMirror%2FSnapMirror_Snapshots_build_up_on_SnapVault_destination_in_a_Mirror-Vault_cascade&type=solution

keen zenith
#

It looks like your C volume is SnapLock. That would be the reason why. Normally ONTAP replicates an extra "snapmirror" Snapshot for the B->C leg in a cascade of A-mirror->B-vault->C but only retains one copy. In your case, these Snapshots are being made WORM and cannot be deleted until they expire.

#

If you wanted to avoid this, you'd probably have to move to a fan-out configuration A->B and A->C so we don't back up the extra snapmirror Snapshot.

scenic stag
#

Sorry, I don't think I communicated this clearly. The snapmirror.* snapshots in question are in the B volume which is not snap locked. The C volume is snaplocked, but is retaining the appropriate single snaplock snapshot.

#

This also is the same behavior when snaplock is turned off on the C volume

keen zenith
#

Oh.. Well, that's odd.

#

What's the specific release you're on for these clusters? Is it 9.11.1 GA/flat or is there a P-release?

scenic stag
#

On my test cluster it is:

eqxontapcl1::> version
NetApp Release 9.11.1: Tue Jul 12 10:21:46 UTC 2022
keen zenith
#

@scenic stag I think what you're seeing could be legit baseline Snapshots. I looked up your ASUPs and noticed that B is in a fan-out to several destinations, some of which haven't backed up anything except the single "snapmirror" baseline. That baseline will stay on B until those fan-outs have a new baseline Snapshot of whatever properly-labeled Snapshot they're looking for in their SnapMirror policy (hourly it looks like).