In a previous life where we had weak change control and this scenario was a problem, I wrote a script to dump and sort the policy (bppllist -l... | grep "^Include:" | sed…| sort…), and compare that list to a similarly transformed list of "ls /net/$filer/" on the (Solaris) NetApp management host, which was guaranteed to see all of our shares in that instance. Once a week, this ran out of cron and mailed the internal NBU list. If you have a host that has key-based (passwordless) ssh into the filers, you can either use "exportfs" or "vol status" as appropriate for your shop, and run the script there, etc -- there are a few ways to grab the info, then just sort the two lists and alert on anything but a clean diff. If there are scratch-type shares that are not backed-up, or snap to another site, have WORM requirements, etc, build this into the list-generation in the script before you sort and diff.
Cheers,
jcf
On Oct 5, 2011, at 2:59 AM, Nic Solomons wrote: I would say firstly: disregard shares… NDMP is performed at the volume level, so that is what I would be looking at (“vol status” or “df”) For me, we track the backups using change control (so our documentation required for creating a new volume also highlights the requirement for a backup request to be raised), because there really isn’t a fantastic way to backup ‘everything’, because of the way the NetApp does its volumes (and also due to the sizes etc involved). I would suggest, potentially, that you could use a policy that mounts the network equivalent of /vol/ with exclusions for the volumes you are already backing up – then do a notification if that network backup policy picks up more data than 2MB, someone’s added a volume that needs to be backed up with NDMP, and you can act accordingly. I’m sure someone else on list will come up with something better than that, though J Cheers,
Nic I have a procedural question, not a technical one.
I just switched over to capacity based licensing and I'm trying to setup NDMP.
Master Server - RHEL 5
Media Server #1 - RHEL 5
Media Server #2 - RHEL 5
Storage Array - NetApp 6080
I've read the release notes, the NDMP guide, and the related guide mentioned in the NDMP guide (the one that tells you how to enable NDMP on the different filers out there).
I've:
* Run a fiber to the array
* flagged that port as an initiator
* zoned the array to see my library
* setup authentication from my master server to the array
* activated ndmpd on the array
* set the scsi reservation setting on the array
* verified connectivity from my master server via tpautoconf -verify 'array name'
* Built a policy and tested a backup.
Everything seems to be working. I can backup and restore.
I go to setup my policy and note that according to the NDMP guide, there is no equivalent directive to the "ALL_LOCAL_DRIVES" option for server backups.
I asked my NetApp storage administrator if there is a command that displays a list of exported NFS and CIFS shares. He directed to the command 'exportfs'. I'm using the output of that command as the basis for what goes into the "Backup Selection" section of the policy.
Here's my question. I'm the backup administrator, but I am *NOT* the SAN administrator. Since there is no NDMP equivalent of ALL_LOCAL_DRIVES, I forsee a scenario where my SAN team deploys a new share and doesn't tell me about it. Since I'm not aware of the new share, I don't add it to the backup selection list and it doesn't get backed up.
I've been brainstorming a solution to this. What I'm doing for now, is I've setup a reminder in my calendar to remind me the first week of every month to just walk over to my SAN team and ask them if they've added any new shares that I need to be backing up.
It works, but I'm wondering if there is a more sophisticated way to keep track of the shares on an NDMP policy.
For those of you that utilize NDMP, how do you account for this?
Thanks. The information contained in this e-mail and its attachments is confidential. It is intended only for the named address(es) and may not be disclosed to anyone else without Attenda's consent. _______________________________________________ Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT eduhttp://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
