nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Component react.community-search had an error.

ref must be one of: categoryID, siteSectionID, category, category/categoryID, category/name, category/description, category/url, category/allowedDiscussionTypes, locale, siteSection, siteSection/basePath, siteSection/contentLocale, siteSection/sectionGroup, siteSection/sectionID, siteSection/name, siteSection/description, siteSection/apps, siteSection/attributes, layoutViewType, discussionID, commentID, page, latest, sort, sortType, lookupSort, discussion, discussion/name, tags, breadcrumbs, discussionApiParams, serverDraftID, serverDraft.

Compare current export policies/rules with last know good policies/rules

rogerpeinetapp

We had an incident whereas a mistake was made and it messed up a policy. After that, we are discussing a way to fix incidents like this. One idea is to use scripts (ex, Ansible) to compare current policies/rules against 'last know good status", and then restore all good values back. Does that make sense to you?

Is there any mechanism I can restore policies back to previous good status?

We can modify some values using CLI, if we know what needs to change to. But just completely restore all export policies/rules using our own saved database(last know good status), that sounds dangerous. We have to develop a script to save such database, and compare, change accordingly, that sounds not easy. Are we over thinking?

We are talking about CDOT cluster, and there about 700 polices along with thousands rules.

Thank you for your inputs!

Find more posts tagged with

Comments

GidonMarcus

Hi.

I guess if you're using Ansible, the right thing to do is to start manage the exports configuration from there, and use some version-control to test and audit these config files. https://netapp.io/2018/06/08/sample-ansible-playbook-ontap-nfs-export-provision-and-present/

You can certainly also run a "backup" and compare. In PS I guess the way I would do it is capture to a variable the settings you like, then pipe it to export-clixml or ConvertTo-JSON (you favourite format), then every day load yesterday's file to a variable (import-clixml or ConvertFrom-Json) and compare the today's and yesterday's variables using compare-object cmdlet. In case a restore ever needed, you should be able to pipe yesterday's variable into the new-* or set-* commands.

I for example have a nightly script do go through best practice or common mistakes people do - and report them:

https://github.com/MGidi/NetAppCdotBestPracticeReportForNAS/blob/master/NetAppCdotBestPracticeReportForNAS.ps1

There's also a built-in config backup in ONTAP (but I wouldn't use it for anything but full cluster re-build), and you should have some of the exports settings kept by default in the weekly AutoSupport (which you can retrieve from ActiveIQ, the filer itself, or by setting you email in the AutoSupport settings). Lastly, there's an audit log in ONTAP (easiest to see in ActiveIQ) where you can see such changes to the settings....

rogerpeinetapp

Well, I can understand your first and last part. Not sure of the 2nd part, and I am not so familiar with PwerShell.

There are about 25 vservers, about 700 policies, and thoughts and thoughts of rules across the cluster here. To pull and save them on a Linux server in daily basis, it should be easier, and in ASUP already. However, based on these saved files to "restore" or rebuild the Export, that seems not straightforward to do, and not sure of it is right thing to do.

If anything goes wrong, it could screw up the whole cluster, because it is NFS based environment here.

As Storage admin, we can write our own script, but may not be that good.

Is anybody there doing the similar thing? Or does this make sense at all?

>> you should be able to pipe yesterday's variable into the new-* or set-* commands.

As I said, I am not good at PowerShell. But, is it really possible just to capture the entire Export including every single policy/rule to a variable, and compare today's with yesterday's, and if there is difference, pipe yesterday's variable which contains entire Export information into new-* or set-* commands, and these commands are going to rebuild the entire Export for me back to yesterday's status? Am I understanding you correct?

I am not asking about just taking NAS reports.

paul_stejskal

If you send autosupports, that data may be there on Active IQ (aiq.netapp.com). Just a thought. Not the best answer, but you can at least see your config from week to week, as well as see the command changes in audit-mlog-txt.gz.

GidonMarcus

For the question about the PS approach - yes, you got that right. And I see someone did exactly that here:

https://github.com/DatacenterDudes/cDOT-CIFS-share-backup-restore (Ignore the project name, it covers NFS too)

The only thing I didn't anticipate in my description was that the new-* command don't seems to really work with pipe, so he re-creates the full command with his script...

It also seems as his script will not remove any old/wrong config, just append missing one...