Forum Discussion

amoramo's avatar
amoramo
Level 4
10 years ago

NFS mount point on NetBackup 5230 Appliance

Hi Team, Please I need your expert advise on this solution: Customer has proposed implementing backup solution via NFS; this solution is based on having the centralized server IPs & file path w...
Backing Up
Backup and Recovery
Best Practice
Configuring
Installing
Integration
NetBackup Appliance
Restore
Tip-How to
UNIX
  • sdo's avatar
    sdo
    10 years ago

    Apologes, I didn't mean to imply that using an appliance as an an NFS client, and therefore as a backup client, will not work - just that it might not be supported.

    Does anyone know the official line on this?

    Certainly the appliance has the ability, via CLIsh functions/commands, to mount NFS exports from other NFS servers, and so yes, you could then backup these mount points.

    manage

mountpoints

mount srv-target:/export-name /mnt/remote/srv-target-export-name nfs

return

    ...and then you should be able to create a backup policy, with the client as the appliance, and a backup selection of /mnt/remote/srv-target-export-name.  I think the trick with this will be to ensure that every mount-point name is unique on the appliance, i.e. hence a long 'mount point' name of '/srv-target-export-name' - so that if you have exports of the same name on different NFS servers, then you can still have unique 'mount point' names on the appliance.

    I'd certainly do some extensive backup and restore testing.  I think restore testing would be critical here (permissions/ownerships/ACLs).  And your test data would be need to be large enough (say a minimum of 10GB) to give you enough time to use the CLIsh monitor network function to check which ethN/bondN interfaces were/are actually being used by the NFS reads/writes - i.e. to be sure that your bulk data traffic is flowing over your main (10Gb?) data ports, and not via perhaps smaller (1Gb) management port.

sdo's avatar
sdo
Moderator
10 years ago

Apologes, I didn't mean to imply that using an appliance as an an NFS client, and therefore as a backup client, will not work - just that it might not be supported.

Does anyone know the official line on this?

Certainly the appliance has the ability, via CLIsh functions/commands, to mount NFS exports from other NFS servers, and so yes, you could then backup these mount points.

manage

mountpoints

mount srv-target:/export-name /mnt/remote/srv-target-export-name nfs

return

...and then you should be able to create a backup policy, with the client as the appliance, and a backup selection of /mnt/remote/srv-target-export-name.  I think the trick with this will be to ensure that every mount-point name is unique on the appliance, i.e. hence a long 'mount point' name of '/srv-target-export-name' - so that if you have exports of the same name on different NFS servers, then you can still have unique 'mount point' names on the appliance.

I'd certainly do some extensive backup and restore testing.  I think restore testing would be critical here (permissions/ownerships/ACLs).  And your test data would be need to be large enough (say a minimum of 10GB) to give you enough time to use the CLIsh monitor network function to check which ethN/bondN interfaces were/are actually being used by the NFS reads/writes - i.e. to be sure that your bulk data traffic is flowing over your main (10Gb?) data ports, and not via perhaps smaller (1Gb) management port.