It just had to happen at some point... we enabled snapshot snaplocks on a snapmirror destination where we locked it down for 5 years.. Now the customer would like us to delete some old data because of lag of space... well... we simply can't 🙂 Or can we... I was thinking if you added a new shelf, created a new aggregate, moved the snaplocked volumes overthere... shut down the system, disconnect the shelf with your aggregate, and power up the system again... has anyone tried this? My guess is that it will work OK?
#Snapshot SnapLock pains...
sick herald
reef sleet
So you are talking about SnapLock (SLE or SLC), not Tamperproof Snapshots, right?
For SnapLock, the SnapLock state moves with the volumes, so after a vol move, the destination volume would still be a SnapLock volume
SnapMirror will also not work, the destination volume will again be SnapLocked
Also, what do you mean by "delete old data"? If you only need the data once, and no snapshots, you could do a FlexClone into a regular volume and then split that (by moving it to another volume). This will clear the SnapLock flag but you will only have 1 state/snapshot, no history
sick herald
So you are talking about SnapLock (SLE or SLC), not Tamperproof Snapshots, right...
We have some volumes that are locked with snaplock on the snapshot level (not sure if its tamperproff or not... it's an option we set on the snapshot schedule), that we would like to get rid off. So the plan was to move them to a newly created aggregate (volume move) then shutdown the system, remove the disks that this new aggregate consists of, and startup the system...
woven abyss
If you set the retention at the snapshot schedule, then they are tamperproof snapshots. If you move these volumes to another aggr the snapshots will still have their retention date. Won't help you much.
With tamperproof snapshots the only way to remove the data before the retention until date, is to reset the system (boot menu --> option 4). So you would need to migrate they data away to another cluster.
reef sleet
We have some volumes that are locked with snaplock on the snapshot level (not su...
so you want to remove the volumes as a whole? not just (some) snapshots?
If so, then there is no supported way. What you describe might work, although you will end up with stale volume and aggregate entries in your cluster DB that you would need to fix (since the cluster would still expect the volumes to be there, somewhere). I don't know if there's an (easy) way to fix those. You can probably fix it with debug vreport show/fix commands but I would surely test this in a non-production system (or simulator) first
sick herald
so you want to remove the volumes as a whole? not just (some) snapshots?
If so,...
Yeah I am aware that the vdb / cluster db will most likely have an issue with this, so it's a last resort kinda way... but I bet a debug vreport /fix will "fix" it... It "could" actually happen that you some some unknown reason lost one shelf (theft) and wanted to bring the system up and in order after this 😉 but as mentioned, this is just as a very last resort... another way could be to setup a new cluster, snapmirror over the volumes you need, and then just "nuke" the rest.. this will be the "supported" way to do it I guess...
...as a side note.. I sometimes miss the good old 7-mode days where almost everything was possible 😉 (in terms of moving aggregates arround...)
woven abyss
Snapmirroring the volumes to another system would also not help because the snapshot retain their retention date. Hm.... you could do a SnapMirror with the "MirrorLatest" policy so you do not bring your tamperproof snapshots over to the new system.