Altnames Configuration for NetBackup

From World History Wiki
Jump to: navigation, search
World History Wiki is Brought to you by:
S.J.'s Adventures


These documents are for entertainment purposes only. Use at your own risk. This site is in no way affiliated with Veritas or NetBackup, and any trademarks are those of their respective companies.

If you need assistance with anything NetBackup and/or Disaster Recovery related, You can find me on linkedIn.

NetBackup uses a directory called "altnames" under it's "db" directory to determine which clients are allowed to perform restores of data from other servers. The location of the "altnames" configuration is /usr/openv/netbackup/db/altnames.

There are 2 methods of allowing clients to restore data to other servers:

1. Create a file named after the client you want to allow to do the restore(s). Then populate that file with the names of the clients whose data is allowed to be restored.
  • /usr/openv/netbackup/db/altnames/peername
2. Create a file called No.Restrictions in the "altnames" directory.
  • /usr/openv/netbackup/db/altnames/No.Restrictions
    NOTE: Applying the No.Restrictions file allows any client to restore any data backed up from all the other clients in the same NetBackup environment; which may present a security risk.
For more details on these options see page ??? of the Admin Guide.

Using links with the first option we can accomplish some interesting things. The files are named after the server type(s) or departmental divisions. For example:

  • SQL_HOSTS - Contains a list of the clustered aliases for MS-SQL clients.
  • UNIX_HOSTS - Contains the a list of the aliases/VIPs for Oracle RMAN clients (typically run on UNIX/Linux systems).

These files are then linked to with the links named after the physical server names as they will appear to NetBackup when restores are requested (NetBackup must also recognize these names a valid clients). These links reside in the same "altnames" directory. This allows all clients with a similar function (those linked to the same "*_HOSTS" file) to be able to restore data from only clients of the same type.

I.E.: Oracle database, listed in the "UNIX_HOSTS" file, can be restored to any UNIX client, linked to the "UNIX_HOSTS" file.



This should be used as a service primarily groups who want to do their own restores, and need to be able to perform client side restores of clustered VIPs/aliases, were the destination "client" doesn't match the source client.

If there is a specific need for as specific server to do restores for other systems, you can create another file named after the server the restores are to be done from (if the file is left empty it will be allowed to restore data from any server).

Do not add more then is absolutely necessary to this configuration, as the more files/links in the "altnames" directory, and the more systems listed in the files, the more it will slow down and negatively impact the end user experience when doing client side restore functions.


Procedures For Client Altanames Configuration

These procedures assume a basic understanding of UNIX commands and the VI editor command on UNIX platforms. Please read through the procedures below and confirm that you are comfortable performing the steps as shown before proceeding. If you are uncomfortable with the steps below, please contact a senior Administrator for assistance.


1) Identify the names of the servers that could be use to perform the backups for the given client.

If the server has both public and private interfaces that can be used for the backups, make sure it's configured properly so that the backup interfaces will be used. This will prevent needing to also configure the public interface, and help keep the "altnames" directory clean. I.E: For the backup network, be sure to only use interfaces ending in "bk.domain".
For this example we will used the client sqlprodbkup.dmz.com. This client could be restored on the backup interfaces for servers sql51 & sql52.


2) Login to the master server via the CLI. This can be done with any SSH tool or VNC client software.


3) Change directories to the directory with the "altnames" configuration.

cd /usr/openv/netbackup/db/altnames/


4) Locate the appropriate "*_HOSTS" file for the client type/platform that will be added. The example is a SQL client so we will be modifying the "SQL_HOSTS" file.


5) Make a temporary backup copy of the SQL_HOSTS file using the bk.

cp SQL_HOSTS SQL_HOSTS.MMDDYY.<initials>

Example:

[spaldam@mymaster altnames]% ls -l SQL_HOSTS*
-rw-rw-r--+  1 root     nbuadmin    1215 Mar 10 15:35 SQL_HOSTS
[spaldam@mymaster altnames]% cp SQL_HOSTS SQL_HOSTS.031011.sd
[spaldam@mymaster altnames]% ls -l SQL_HOSTS*
-rw-rw-r--+  1 root     root        1215 Mar 10 15:35 SQL_HOSTS
-rw-rw-r--+  1 spaldam  nbuadmin    1215 Mar 10 15:35 SQL_HOSTS.031011.sd
Be sure to clean-up/delete any older temporary backup copies to help keep the "altnames" directory clean. Paper written by the experienced essay writer could give students a possibility to reach highest grades.


6) Using vi, open the SQL_HOSTS file and add the following line:

vi SQL_HOSTS

sqlprodbkup.dmz.com


7) After saving the SQL_HOSTS file with the changes made, verify that the client(s) is in the file with a grep command, or use egrep if adding multiple clients:

egrep -e "<client1|client2|client3>" SQL_HOSTS

Example:

[spaldam@mymaster altnames]% egrep -e "sqlprodbkup|sqlprod2bkup" SQL_HOSTS
sqlprod2bkup.dmz.com
sqlprodbkup.dmz.com


8) A "soft" link will need to be created for server names which points to the SQL_HOSTS file.

ln -s SQL_HOSTS server.name

Example:

[spaldam@mymaster altnames]% ln -s SQL_HOSTS sql51bkup.dmz.com
[spaldam@mymaster altnames]% ln -s SQL_HOSTS sql52bkup.dmz.com
[spaldam@mymaster altnames]% ls -l sql5*
lrwxrwxrwx   1 spaldam  nbuadmin       9 Apr 26 16:30 sql51bkup.dmz.com -> SQL_HOSTS
lrwxrwxrwx   1 spaldam  nbuadmin       9 Apr 26 16:30 sql52bkup.dmz.com -> SQL_HOSTS


9) Make sure the servers represented by the newly created links are recognized as valid NetBackup clients.

If they are not backed up on a regular basis and clients, you can do a one time backup as described in the Client Add to NetBackup Procedures.


Optionally, you can now do a test restore, or let the requester know and have them run a test restore if they desire.

Results of the Example

In the above example, the servers sql51 and sql52 can now restore data (via their backup interfaces) that was backed up via the client names sqlprodbkup.dmz.com and sqlprod2bkup.dmz.com (clustered VIPs that live on sql51/52) as well as any others listed in the SQL_HOSTS file.



Back to NetBackup