Automatic Configuration Backup

[ALEJANDROB]

Hi All!

I'm trying to do daily NetApp configuration backups. I know i can do this locally running config dump but the idea is to run this remotly in a linux box to cron this job. The only idea i have is to use root ssh keys to login to NetApp devices and execute config dump and config dump -v to dump NetApp configuration to standard output  and save that to a file. I still think this is not the best solution. can i do somethoing better? How do you guys do backups? Any tip or advice is welcome..

Cheers.

.

[aborzenkov]

What exactly is missing in standard vol0 snapshots? They provide full backup and can be scheduled …

How are you going to use these configuration backups later? I’m really interested, I never was clear what they are useful for ☺

[scottgelb]

Great point...snapshot has everything.  Config dump -v I have used to restore exports and cifs shares... exports are easy from the exports file, but cifs shares can be painful (but if a root snapshot you can just copy the cifsconfig_share.cfg file with cifs terminated from that same system).  When a share is added manually it defaults everyone full control so often any script we have has to delete or modify that entry...when cifsconfig_share.cfg is processed it doesn't need to do that.  I see little other use for it though... one glaring thing that seems missing is igroups and lun maps... when you restore a config dump they aren't there (unless I missed it) so might have not had any changes in the functionality.

I like taking the GX/Cluster-Mode best practice...a little different since root is common to all nodes, but taking each 7-mode system root to keep a local mirror of root and a copy on another node...ideally if more than one aggregate on a node, then the local mirror on that other aggregate so if you lose the aggregate with root, you can create AUTOROOT on boot then break and mark the mirror as root and be back in business (except for the failed aggregate...a rare thing though, but for ~250GB not a big cost)... I could see using QSM or SnapVault too to keep different retentions then keep a copy of etc in case of volume failure.

Do your customers typically do tape backup or replication of root to keep a copy in a different place?

[aborzenkov]

Usually it is NDMP backup to tape if anything at all; snapmirror/snapvault are not always available (or are almost always unavailable ☺ ) and majority of configurations have single aggregate anyway, which rather defeats purpose of replication.

[ALEJANDROB]

Many thanks  aborzenkov !!!

[ALEJANDROB]

Well i want backups in case someone make a mistake with something related to Aggregates / Volumens / Exports / General Options and also in case Device / Controller needs to be replaced. The first one is solved with a snapshot but the second one no. We already faced a similar situation when one BiIP F5 LTM was replaced. A Complete restore was easy and fast.

[aborzenkov · Accepted solution]

When controller is replaced (keeping old disks) configuration is completely preserved. When the whole filer (meaning controller+disks) is replaced, you usually need to migrate data anyway, so root volume is migrated too.

For disaster recovery I would rather make vol0 backup (NDMP, snapmirror, snapvault - whatever is available).

Sorry, I simply do not have any experience with configuration backup done this way, nor had I ever feel a need for something like this, although I went through quite a number of head swaps and migrations.

[scottgelb]

Another use case is some automation when taking resources from vfiler0 into a vFiler... config restore can bring the exports and shares back quickly into the vfiler.. but I don't see much other use for it and would prefer snapshots like Andrey said for restores of root.

[HENRYPAN2]

Yes I'm second for aborzenkov.

All my vol0s had been snap mirrored to DR site.

Good luck

Henry