Hi there,
We have a *hitload of snapmirrored volumes with 60 months worth of snapshots each... We have just upgraded to ONTAP One and enabled SnapLock of snapshots which is great and all... but our old snapshot are not locked... this required GUI which is a no-go, or the command "snapshot modify -volume vol -snapshot snap -expiry-time MM/DD/YYYY HH:MM:SS" ... this is of cause also a no-go to do from the commandline.. I was wondering if anyone has done a powershell script that can do this? Basically we need to get all the snapshots, check the snapshot creation time, then add 60 months to this date and set the expiry-time... I'm just hoping that someone has done this 😉
#Snapshot snaplocking old snapshots prior to snaplock?
1 messages · Page 1 of 1 (latest)
you only need to do that once for the existing snapshots. For new snapshots, you can modify the snapshot policy to automatically lock the snapshots.
I don't see why the CLI is a "no-go" for something you only have to do once 🤔
Well we have 100+ volumes with each 60 months of snapshots.. (about 500 snapshots for each volume)..
I just tried the powershell toolkit and quickly found out that Get-NcSnapshot times out even if I feed it just one volume.. I can fix this with -ZapiCall, but for some reason this returns nothing in the "SnapmirrorLabel" which I need in order to determine which policy I need to apply... say, Daily, Weekly, Monthly etc.. so I'm kinda stuck 😉
high-level logic (pseudo-code):
for each vol in vols
get snaps where expiry is empty
for snap in snaps
set expiry (ctime + 60 days)
wow, my last post just went MIA...
any way...
What I would address first is the timeout. describe the relationship of the host running powershell and the cluster. Is there a WAN, WAN accelerator, or something else between the host and the cluster? if so, can you connect to a host local to the cluster and test for a timeout?
Hi James... oh yes the good old pseudo-code 😉 I have actually spun up the old Powershell editor, downloaded the latest PStoolkit from the support site, just to find out that "Get-NcSnapshot" will just hang there for several minutes per volume, just to timeout... even after setting "$global:CurrentNcController.TimeoutMsec = " to a high value... then I found out that you would set the -ZapiCall option on the call and everything sped up... but then the SnapmirrorLabel attribute was not populated for some unknown reason... only after adding -Attributes @{ "snapmirrorlabel" = ""} did I get that specific attribute, but no other... and I need the "Created" attribute, which for some still unknown reason isn't avalibale.... so I'm taking a break now because I started to curse so hard that my wife looks at me funny... 😉 how could NetApp break API this so hard? (ONTAP 9.12.1P3, PSToolKit 9.13.1) and no routes between the executing Windows server 2012R2 and the Cluster...
Oh and the reason I need both the snapmirrorlabel and snapshot created time is that we have both monthly, weekly and daily snapshots that need to have the snaplock expiry time set differently...
Understood. I hear ya, I’m in the depths of the APIs via the Powershell module constantly. I personally recommend removing the binary install of the toolkit and install the latest from the Powershell Gallery.
Many times the attribute names are not what we expect. I may have a few cycles tomorrow to look at it a bit more.
I didn't get to check this out today...
I bet that by specifying the attributes necessary and not doing zapi will return without timing out as it will reduce the payload substantially.
I think you'd need only the As this would be in a loop of the volumes, when requesting the snapshots you won't need the volume name, snapshot name, snapmirror label, ctime, and expiry.
In case you weren't aware, Windows Server 2012 and all subversions ended support 2023-10-10.
https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support
I'm pretty sure Windows 2012 isn't the problem here 🙂 And if I do not use the -zapicall option it just site there forever... no CPU acticity on the server I execute the script from, and no load on the cluster I am running it against... even it I limit it to one specific volume with just 10 snapshots, it just hangs forever... I am 99% sure this is a ONTAP issue because I just tested this against ONTAP 9.11.1P9 where everything just works as expected... so 9.12.1P3 is broken 😦 We will upgrade this system to 9.13 soon so I will cross my fingers that this has been fixed, and if not I will have to open yet another case with netapp support...
Well I got much further now... created an array to match the snapmirror labels to a expiration days to add as the SnapshotSnapLockExp... like ("monthly", "30"), ("daily","7") etc... all works fine.. but the main "star" of the show "Set-NcSnapshotSnaplockExpTime" doesn't lock the snapshot... I get the $snapshot.Created date/time value from the snapshot, then do $expdatetime = $snapshot.Created.AddDays(7) and I of cause verify that the variable ha actually been set 7 days into the future... but when I then use the Set-NcSnapshotSnaplockExpTime with the -ExpiryTime option, it runs OK, but does not set the snapshotsnaplock... only the "ExpiryTime" option and not the "snaplock-expiry-time" value. I verified this via commandline... but there is NO option to set the snaplock-expiry-time even though the cmdlet is called Set-NcSnapshotSnaplockExpTime.... makes no sense to me... am I missing something here?
I didn't say it was '2012' causing the issue, simply a friendly nudge.
Nice progress!
Do you mind providing some scrubbed/redacted CLI output so I can understand what you're looking at a little better? You are welcome to DM that data to me directly if you prefer.
Any news on this? The Get-NcSnapshot cmdlet is still ridiculously slow with NetApp.ONTAP 9.14 against ONTAP 9.13. Is it a bug in the PowerShell toolkit or in ONTAP? Either way, it is something for NetApp to deal with before we can move away from ontapi/zapi.
Not sure if this will help or if already attempted, but to make sure which exact layer is slow (Powershell or Ontap), you may want to curl the problematic (slow) volume api directly at the ontap and observe the response. For example, to get all snapshots from given volume: curl --request GET --insecure --user user:pass https://svmname/api/storage/volumes/84c32cb6-c20d-11ee-ad19-00a098d5877a/snapshots
These commands return the results in a fraction of a second, so I would say that the API endpoint is doing its job:
$cred = Get-Credential
$uri = "https://<hostname>/api/storage/volumes/<volume-uuid>/snapshots?fields=name,snapmirror_label&snapmirror_label=daily"
(Invoke-RestMethod -Method Get -Uri $uri -Credential $cred).records
That is good info. So it appears the slowdown is somewhere in PowerShell layers... Unfortunately I am using Python almost exclusively, for both ontap rest and other purposes, and cant help you much with troubleshooting PS... I mean, if you feel like it, you can try to parse the raw curl records yourself using ps and then curl the snapshot patching the same way, without suspected slow layers...
I guess that's the only way forward until the powershell toolkit is fully rest-based. It will probably take some time but I read that ontapi will stay with us until 9.17... 😁
Thanks for your input!
Wait a minute. Assumption is the mother of all screw-ups. Nevertheless, I assume that the reason that Get-NcSnapshot is running forever is that it collects hundreds of snapshot attributes, probably through a number of nested API calls. There is a way to limit the number of attributes:
$attrs = Get-NcSnapshot -Template
$attrs.SnapmirrorLabel = "whatever"
Get-NcSnapshot -Attributes $attrs -Volume <volume-name> | select Name,SnapmirrorLabel
Bang. Command completes instantly. Problem solved. More or less.
Well welll... to be honnest I dropped the idea, mainly because I think PS Toolkit is broken somehow... The problem is not getting a list of snapshots with a specific label set. The problem is to set the snaplock value, so to lock down the snapshot x-days... none has been able to provide me with an expample of this that makes sense... It's kinda sad as we have a few customers who would like their snapvault destinations locked down with snaplock according to their snapmirror labels and creation date... apparently the only way is via the webgui, which will take years to complete 😂
It's the Set-NcSnapshotSnaplockExpTime function that doesn't seem to work or maybe works in mysterious undocumented ways 🙂
Wait a second. Was the volume created with snaplock on? I don't think the expiry time mentioned is snaplock feature but a snapshot feature.
Pretty sure the snaplock was enabled on the system, and on the volume it self. because I tested quite a bit... does it make a difference if the volume was initally created with snaplock? Because the snapshots initially ment fo this script was of cause not created with snaplock enabled... we added the feature because of the "free" upgrade from "Complete Bundle" with "ONTAP One" where you get snaplock for free... and of cause the fact that snaplock is now able to lock snapshots... which is very useful, but when you have several thousand old snapshots that you would like to lock acording to their creation time and snapmiror label, you really need a script and the GUI is pretty much useless 🙂
I could script this very easy, rest api methods. However, DP volume is immutable by default. You can set a max number of snapshots to keep. Thus, if you transfer one everyday you can set the keep value to x. I've actually never tried, but can snapshots be modified on DP? Names, Labels, Expiry ,etc.
You can just access all the snapshots at once if you want to do it globally. snapshot show, that is less calls to the API.
Well first of all you are able to set a SnapLock retention on your SnapMirror Protection Rule.. so that all daily snapmiror labels should be locked in 7 days... also I am able to set the snapvault duration on older existing snapshots via the GUI... so I guess it's not that immutable afterall :-). Pretty sue I am able to change other volume parameters as well.. like dedupe and volume size etc..
The default data protection relationship changed a while ago from DP (Volume Snapmirror) to XDP (SnapVault). XDP with an 'all snapshots' policy is the latest equivalent to DP but it's still XDP meaning some snapshot metadata can be changed. Ensure about how that's impacted by SnapLock.
If you're curious how System Manager (OCSM) is doing something, the audit log always logs changes. The interface also has this in the interface: