Veritas-bu

Re: [Veritas-bu] NDMP in Practice

2011-10-05 05:00:02
Subject: Re: [Veritas-bu] NDMP in Practice
From: Nic Solomons <Nic.Solomons AT attenda DOT net>
To: Heathe Yeakley <hkyeakley AT gmail DOT com>, NetBackup Mailing List <veritas-bu AT mailman.eng.auburn DOT edu>
Date: Wed, 5 Oct 2011 09:59:39 +0100

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

 

From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Heathe Yeakley
Sent: 04 October 2011 21:29
To: NetBackup Mailing List
Subject: [Veritas-bu] NDMP in Practice

 

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 edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
<Prev in Thread] Current Thread [Next in Thread>