NTAP_PM_RUN_BACKUP=N ignored? And PM non-conformant issue

[magnus_nyvall]

Hi it seems despite NTAP_PM_RUN_BACKUP=N is set a snapvault is triggered every time SC is run.

Could Ctrl+M make this being handled as NTAP_PM_RUN_BACKUP=Y on a Redhat Linux server?

It seems odd though.

This is on a 3.4p2 install on a Redhat 5.7 server.

Or any other explanation?

We schedule the backups via PM and the scedule is none on primary and 23:00 daily on secondary.

Also we want Protection Manager to handle all retention times.

It workes just fine.

Bu if the PM dataset is in a non-conformant state then SC just wanrs about it and do not update PM with the snapshot.

This creates a primary snapshot that PM is unaware of.

Any way to secure that SC is not allowed to take any snapshots that PM is unaware of?

Or to clean up and remove all snapshots unknown by PM?

Regards Magnus Nyvall

[magnus_nyvall]

Update: It seems like the flag is working.

Pictures says more than a thousand words they say.

Until PM runned its backup at 23:00 only "Primary data: NetApp Snap Creator Framework Backup" entrys showed between 22:13  Sunday to 22:11 Monday.

But after all the "Backup: NetApp Snap Creator Framework Backup" suddenly showed up.

This is why i thought that the NTAP_PM_RUN_BACKUP=N was not working.

Is this a feature or a bug?

Refards Magnus

[ktenzer]

This is not a bug

NTAP_PM_RUN_BACKUP=Y means Snap Creator will kick off a secondary backup in protection manager after primary backup is done. You can schedule secondary backup through PM but if you are doing so you should set this option to NTAP_PM_RUN_BACKUP=N so secondary backup will only be done when PM schedule runs.

Does this make sense?

Keith

[magnus_nyvall]

What actually is happening now that i have looked in to it more closely is.

Snapcreator takes hourly snapshots on primary system every 4th hour and register the snapshots in Protection Manager.

(We have NTAP_PM_RUN_BACKUP=N configured)

All is fine from this point of view.

But when Protection manager runs its daily schedule at 23:00 it runs a snapvault update for all primary snapshots that has been added since the last time it runned.

So instead of just making a snapvault update on the most recent primary snapshot it does this for all snapshots.

I am not sure if am explaining whats happening in an understandable way.

Is this a feature or a bug somehow?

I cannot remeber seeing this behaviour in PM with Snapmanager Applications. There it just runs a snapvault update on the most recent primary snapshot.

Regards Magnus

[ktenzer]

Ok this makes sense

This is working as is intended. This is the way Protection Manager works, when it does snapvault update it will update for all new snapshots taken after last update.

Maybe a better way to do this is to turn off schedule in PM and set RUN_PM_BACKUP=Y this would make it so SC triggered PM to do backup right after snapvault is done. Another option if it is desired to NOT snapvault certain backups, create two configs 1) without PM setup 2) with PM setup.

Regards,

Keith

[magnus_nyvall]

So Protection Manager cannot see any difference on snapshots regarding policy?

I would have thought it only should have transferred the daily snapshots on a daily schedule.

But obviously it also transferrs all the hourlys as well, and these becomes daily snapshots on secondary.

This is not good. We will reach the 255 limit on secondary storage i am afraid then.

Regards,

Magnus

[ktenzer]

One thing i think you can do is use different policies so hourly and daily. When SC runs PM backup schedule NTAP_RUN_PM_BACKUP=Y or if you run backup form PM you select a retention type: hourly, daily, weekly, or monthly. It is my understanding that PM will only do updates for snapshot within a given retention. So if you have 10 new hourly snapshots then PM will update 10 but if you have 10 hourly and 10 daily and choose hourly as policy it should only update 10.

Hope this helps

Keith

[magnus_nyvall]

We did try that.

We whiped all snapshots from both sides.

Created 1 daily and 3 hourly manually with SC.

Then started a backup in PM with daily policy.

It backed up all of them im afraid. So it didnt care about policy it seems.

[ktenzer]

I would open a case or ask the PM community about this. It sounds like a PM issue, since SC is sending the retention type, PM should not be vaulting retentions which dont match the retention type. This in my opinion is a design flaw or a bug.

In the short-term I hate to say it but only way to do this is to not use PM and use SC to do snapvault. SC will only vault 1 snapshot, the one being taken and only vault the snapshot which matches the correct retention. I know this is less desired than using PM but maybe this would provide a gap solution until PM can support this?

Let me know what you thinkg

Regards,

Keith

[magnus_nyvall]

Sadly your suggestion for short-term resolution will not be allowed at Volvo.

They do not allow database servers to control retention times, they demand that it is administred centrally and only storage team are allowed access.

This is because database group purshase the backup service internally from storage/backup group.

Before i log a case, are you sure that the PM update dataset function do register the retention type?

It does seem that it does not, or perhaps it does but not in a correct way, since this is working with Snapmanager products in PM.

Regards Magnus

[ktenzer]

Snap Creator only registers the snapshot it has nothing to do with snapmirror or the snapmirror update that is Protection Managers problem.

SC does register retention type. Just run with the --debug argument or look in log file. Search for "retention-type" this is where SC creates a backup version in PM and you will see here it is whatever you have set for --policy. The only valid arguments are: hourly, daily, weekly, monthly, or none.

If there is something we can do better on SC side let me know. I have looked at API documentation so it appears we are doing everything correctly.

Regards,

Keith