Backup Central

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.

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.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.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.

Hi,

I have solved this problem by gathering (every morning) a list of all the netapp volumes in my estate (>vol status), and a list of all my netbackup policies (>bppllist), and effectively doing a "difference" between them..

No difference => No volumes being missed by netbackup
Differences => Some volumes being missed by Netbackup

Filer:-
ssh <filer> vol status | grep online | awk '{print $1}' | sed 's/^/\/vol\//g' | sort > netapp_volumes.txt

Netbackup:-
for x in $(bppllist); do bppllist $x | grep "INCLUDE" | grep "\/vol\/" | sed 's/INCLUDE //g'; done > netbackup_volumes.txt

#sdiff netapp_volumes.txt netbackup_volumes.txt
/vol/vol0 /vol/vol0
/vol/restore /vol/restore
/vol/robots /vol/robots
/vol/satellite /vol/satellite
/vol/syslogs <


...Whoops, those pesky Storage Engineers have made the /vol/syslogs volume and not told me!

I actually do it by gathering all the info into a MySQL DB and using SELECT to find the differences, but it's the same thing.

Best wishes,
Geoff


From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.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.

hkyeakley
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.

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

From: veritas-bu-bounces < at > mailman.eng.auburn.edu ([email]veritas-bu-bounces < at > mailman.eng.auburn.edu[/email]) [mailto:veritas-bu-bounces < at > mailman.eng.auburn.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.edu ([email]Veritas-bu < at > mailman.eng.auburn.edu[/email])
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

I worked around this problem by running scripts against each filer and comparing this to the include/exclude list for each policy. I was in an environment with over 200 netapp filers and this was a constant problem.

Also you don't want to use exportfs to glean a list of what to back up (this shouldn't work anyways if its an NDMP policy), you want to use "vol status" or something similar. (Ideally you should get the perl API so you can interface with the Netapp OS in a robust, enterprise grade manner)
So I use the perl API to glean a list of volumes and then make sure each is present in either the exclude or include list. If not, it adds it to the include list and then sends out an email alert.

Even if ALL_LOCAL_DRIVES worked (actually I think this directive did work for NDMP policies in some version along the way) you probably wouldn't want to use it.