Hi, I've a setup with snapcreator that will do snapshot and then register the backup on Protection Manager. I have a retention of 4 backup.
On PM I've setup a protection policy with a retention on the backup higher that the normal number of days that the backup will be normally retained (i've setup 1 week while I retain normally 4 days).
Every now and then I see on PM warnings related to my Dataset of this kind: Dataset Backup: Prematurely Deleted, "A backup for node primary data of dataset xxxx with backup version xxxx has been prematurely deleted (Backup expiration: xxx)".
There's some way to not generate those kind of alerts other than setup the retention into Protection Manager exactly like the one setup into SnapCreator? This will be a "double" work and mostly also based on different kind of retention (number of backup in SnapCreator, days in Protection Manager) and changing one retention in protection manager will need also a change into Protection Manager to get the same retention.
Any way to disable completely the jobs that checks and delete backup inside PM? We will be scheduling and managing backup completely from SnapCreator so we don't need to manage them from Protection Manager.
PS: any idea of the release date of SC 3.5? Thanks
At this moment I'm using 2) and I'm doing primary (local) backup with SC and snapmirror (no snapvault) with PM. I prefer to delete snapshot with SC because in this way I'm sure of the time of when backup are deleted and retention is setup from SC itself instead of having to setup the retention on PM. This will also make a better understandable backup. If i configure 1) I will have backup schedule on SC and delete old backup that run "automatically" when dfm decide to do it and with a retention that can be different. An example:
I've a backup scheduled every hour and i leave online only 6 backup. Putting it into PM I should put a Protection Group that should retain 6 hours of hourly backup. If tomorrow I change the schedule from 1 hour to 4 hour without changing the PM protection policy to 24 hours it will delete backup that should not be deleted.
My problem is that having SC doing the backup i get warnings like this one: Dataset Backup: Prematurely Deleted, "A backup for node primary data of dataset xxxx with backup version xxxx has been prematurely deleted (Backup expiration: xxx)".
This is not on a secondary but on a primary. It seems that in the Policy is always controlled so if I have 4 daily snapshot I have those cases:
1) PM retention of daily snapshot is setup to "0" (or less than the retention in SC) days, PM delete snapshot leaving only the last 2 online
2) PM retention of daily snapshot is setup to "4" (not tested), I imagine that PM will find that there's no snapshot to delete because the policy is consistent with SC policy (but if I change frequency or retention it will delete backup that should not be deleted)
3) PM retention of daily snapshot is setup to more than "4", PM jobs that delete backup checks the dataset and see that the last backup was deleted but it should not be deleted because it should exist because the schedule is "more than 4 days" and complains with the warning event.
It seems that there's no option in a protection policy (or it's me that did not see it) so that PM will not delete any backup (disable completely the job that delete backups). I'm right on this? Anything that can be done? What's the suggestion in this cases, to use 1) and let PM delete snapshot in his way or put "999" weeks to retention in policy for hourly/daily/weekly/yearly and get the warning for every DataSet every day?
Regarding 3.5 does the code freeze means that the release date is not to ahead in the future?
About warnings you are getting those because SC deleted a snapshot before PM could on primary. My only idea not to get them is either set PM policy to same as Snap Creator or set NTAP_SNAPSHOT_NODELETE=Y in SC and let PM delete snapshots on primary. Other than that I dont have any ideas on this one.
I am not sure about option for not deleting or managing snapshots on primary in PM. It is possible there is such an option but I am not sure.
About code freeze, it just means we arent adding any more features to the code. I cant release a date since it could change but you can expect to see SC 3.5.0 in a few months. I will post more info on this as date gets closer.
We will also be releasing a community version of SC 3.5.0 soon so you could get your hands on that and test it out but community version wont be supported by NGS so probably not for production environments.
This isn't really an error more of an annoyance. I think OC 5 just complains when something external like SC deletes snapshots.
In SC 3.5 which releases on Jan 12, 2012 we have made an improvement here. You can in 3.5 allow PM to manage all snapshots primary and secondary and this would be the recommended way to do things going forward.
You would do following::
2. You would create the dataset "snapcreator --profile <profile> --action pmsetup"
3. Finally configure dataset in PM and SC config file
It is critical that the option NTAP_SNAPSHOT_NODELETE=Y is set at time when dataset is created as the setting to control if PM deletes snapshots on primary is set at the dataset layer.
In the future we will be adding a way to update existing datasets but right now the dataset needs to be re-created to take adv of this feature.
The other option is to have SC delete snapshots NTAP_SNAPSHOT_NODELETE=N on primary which in case of PM will have SC delete them from PM and this will cause PM to complain.
If you try out SC 3.5 please let me know how this feature it working
Hi Keith, probably I've not understood well the new options.
I was thinking that also in 3.4 if I set NTAP_SNAPSHOT_NODELETE=Y SC will not delete the snapshot and they'll be deleted with normal PM dataset policy.
Do you mean that with 3.5 if I create a new dataset with "NTAP_SNAPSHOT_NODELETE=Y" Protection Manager will "ignore" it's configured policy for snapshot retention and SC will delete the snapshot through PM with it's own schedule/retention settings?
In 3.4 if NTAP_SNAPSHOT_NODELETE=Y SC wont delete snapshots on primary. SC however also WONT set the flag on the dataset that says PM is responsible for snapshots on primary.
In 3.5 if NTAP_SNAPSHOT_NODELETE=Y SC wont delete snapshots on primary. SC however also WILL set the flag on dataset at time of dataset creation that says PM is responsible for snapshots on primary. This ensures PM will delete primary snapshots, at least with OC 5.
If you tested this with 3.4 and it works, that SC wont delete primary snapshots and PM will then it must be something new in OC 5. Though OC 5 works with SC 3.4 it is really only supported with SC 3.5 since SC 3.4 came out before OC 5 so we couldn't properly test it.
In summary if you have tested this and it works with 3.4, ignore If you are deploying SC + PM solutions in future or currently and want PM to handle snapshot deletion of primary and secondary please use SC 3.5 which again releases on Jan 12, 2012, in a few days.
This is in the Snap Creator Community release 3.5.0c
Also the dataset flag is called is-application-managing-primary-backup-retention. I think it can only be set by API but not sure, there may be a way to change this from CLI too.
Did I clear things up?
Sorry I sent such a confusing response, I need some more coffee
Keith the explanation is good just one question: with 3.5 having NTAP_SNAPSHOT_NODELETE=Y will PM delete the snapshot on primary with retention (day or number of backup) specified in OC or it will use dataset policy to delete backup? In this last case, setting the parameter to N will tell PM to don't care about Snapshot retention so that SC can delete snapshot and Oncommand will not complain about already deleted ones?
Yes PM will delete snapshots based on retention specified in in OC. However the way it knows which policy to use hourly, daily, weekly, or monthly comes from which policy you use in SC.
As far as PM complaining about snapshots SC deletes, we didn't change anything about how SC deletes snapshots. It removes them in PM and then deletes them, we need to look into why OC is complaining in OC5 and not OC4 this could be something changed in OC. On this I would probably open an NGS case so they can analyze and so it gets escalated to engineering.