Need some clarification on backing up NetApp NDMP in cluster-mode.

[LT2013]

I've been reading up on the documentation for backing up a NetApp NAS in cluster mode via NDMP.

My environment is 7.5.0.6, with RH Linux master and media servers, backing up to Data Domains. My storage admin wants to know if we can backup via the virtual hostname of the cluster  (I assume that to be the vServer name).

Based on what I've read, the options are:

- backup the volumes by physical node, in which case any failover would result in a change on the NB DNMP policies.

- backup using LIFs (recommended) where a failover woud require an action on the part of the storage admin to change the lif to point to the proper physical node.

- backing up using the vServer as the NDMP host.

That last one is where I'm a bit confused. We only have one vServer with 2 nodes for testing. If I'm going this route, where would the physical node come into play in the policy setup, since in one of the docs it states:

"Because NetBackup has not yet implemented the CAB extension, the storage administrator must tell the backup administrator to modify the policy for the volume(s) moved to another node. The storage administrator will likely be aware of the failover and can also notify the backup administrator to modify policies related to the failover."

Also, since I am doing 3-way NDMP, writing to DD via a media server using boost (no VTL), I assume each option is available to me.

Thanks

[mnolan · Accepted solution]

Per the NDMP for NAS documentation you mentioned:

http://www.symantec.com/docs/TECH31885
 

Page 31 mentions that the vserver method is the default mode for new installations.

For upgraded NetApps, it is easier to do one of the other two methods and my favorite is LIFs as it takes the responsibility out of the NetBackup admin for making changes when the volume failsover.

For the VServer method being 3-way, I have not seen that in action but this describes it transfering data to a node and then to tape drives owned by that node. (As NetBackup can only scan nodes for tapes not vServers, they just won't report any tapes as it is virtual after all.)

In your case, you currently are doing Remote NDMP which sends data directly back to a NetBackup server, which should also work for VServers.

One caveat I have also been discovering is a change in what is required for the backup policy.

While in 7 mode you would go to a filer and backup, say, /vol/vol0

In c-mode it tends to be /vfiler/vol0

So in my expierience,  not only do we need the correct node, but the selection has to have the correct vfiler for the volume.

[mnolan]

The issue with a script like that is in a NetApp cluster, the volume can be moved from one to the other. So the node might remain pingable, but not be the one needed for a backup.

[Jim-90]

A generic workaround ....................

The method I haved used for backing up different boxes based on criteria the can be established via IP is: 

On the Linux/Unix master write a script that does something like this:

IF primary service is good THEN # run the policy & schedule for goodness
   bpbackup -i [-p policy] [-h hostname_primary] [-s schedule] etc
   rc=$? 
ELSE # run the policy & schedule for badness.
   /bpbackup -i [-p policy] [-h hostname_other] [-s schedule] etc
   rc=$?
   optionally add some alerting that things have changed. 
FI 
exit $rc  # required if you run script from NBU 
          # or some batch scheduler like CNTRL-M 

Notes

• For IP testing avoid using anything that uses UDP or ICMP (ping) during backup time these packets get sent to the back of the transmission queue by TCP and will produce false alerts when the network becomes congested.   TCP has higher priority for packet transmission.
• Run the script on the master, only on the master can you select a schedule (check this, things may have changed since I last did this)
• Start this by cron or by NBU (RMAN policies that don't backup anything are good for scheduling scripts. The scripts or commands can be anything they don't have to be oracle stuff)

[Jim-90]

I wouldn't use ping (see notes).  Personally I would use ssh on the master server to send a command to run on the device to return something relevant for a test.  NetApp can be set-up for using ssh to run NetApp commands from remote machines or desktops without passwords.   There are probalby other methods.
 

[LT2013]

Thanks for the replies.

Currently, we've tested using the physical hostname as the NDMP host, and the backup selection is /vservername/vol_test.

So if I understand this correctly, I can use the vservername as the ndmp host and not have to reference the physical host(s) anywhere. So if a volume moves from one physical host to another, NB will still backup since the ndmp host is the vserver? That paragraph on page 31 leads me to believe otherwise...

"If a volume is requested from a node that does not host that volume, the backup job will fail."

[mnolan]

Reviewing previous cases of mine as well as our documentation and NetApp's, I would suggest to check the status of:

 node-scope-mode

I suspect that with it off (the defaul Vserver mode) is what has perhaps required previous customers to use the vfiler name in the pathing.

This still required the client to be specified as the node for that volume.

There does not seem to be a way around going directly to the node in some fashion until if and when we support the CAB plugin.

I still highly recommnd the LIF method to take away from the NB admin's need to change the policy.

[LT2013]

I ended up opening up a case with symantec, and the response I got was that backing up using the vserver name is currently not supported (and they admitted the documentation was misleading).

I am going down the LIF path now.