Client Add to NetBackup Procedures
This document shows the steps to add new physical (non-VM) clients to the NBU (NetBackup) environment, including if the client is clustered and backed up by a cluster resource (sometimes also called an "alias" or "VIP")
The basic principles apply to all clients, but not all steps are needed for all clients as noted in the Procedures below.
In order to add a client to the NBU backup environment, the customer/requester must FIRST submit a properly formatted ITSM ticket:
- See: Ticket Templates for NetBackup Client adds and removals
- You can also assist the customer in creating the ticket if needed.
For the purpose of this document we are going to add the client sqlprodbkup.
Physical Servers = sql51 & sql52 Cluster Alias Name = sqlprod OS = Windows 2008 CPU = x64 Purpose = SQL Server Network Location = DMZ Development or Production = Production Backup Directives = T:\sqlbackup\netbackup1\ U:\sqlbackup\netbackup1\ T:\sqlbackup\netbackup2\ U:\sqlbackup\netbackup2\ T:\sqlbackup\netbackup3\ U:\sqlbackup\netbackup3\ T:\sqlbackup\netbackup4\ U:\sqlbackup\netbackup4\
1) Determine if a correctly configured policy exists. Refer to Configuration Standards.
- Since theres already are policies for the target environment, server type (SQL production) to backup the "T:\" and "U:\" we do not create new policies. If these did not exist then we would need to follow the directions in Creating New NBU Policies for Backups.
2) We need to test the connectivity for the "client(s)". This check process needs to be run from the media server(s) that will be used for the backups (on Nexus this will be ALL media servers). The check also needs to be run against the network interface on the client(s) that will be used for backups.
- For clustered environments this must not only be done on the clustered backup interfaces, but also the individual backup interfaces on each node - physical server - of the cluster. For this example we'll use the CLI on the master server, to run the connectivity check script. This script will check for the Forward & Reverse DNS entries, a PING response, and a response to a NBU request.
- Note: The physical server names should be the same name returned by the "C:\Program Files\VERITAS\NetBackup\bin\bpclntcmd.exe" -self" command, if the server is configured properly
- The command to run on on the media server is...
sudo /admin/nbu/bin/nb_client_check.pl <clientname>
- You can run this command for multiple clients like in the example below. When running the script it is best to test the backup client name and the names of the physical servers.
[spaldam@mymaster ~]% sudo /admin/nbu/bin/nb_client_check.pl sqlprodbkup sql51bkup sql52bkup CLIENT NAME => NAME RESOLUTION | REVERSE RESOLUTION | PING RESULT | NBU CONNECTION --------------------------------------------------------------------------------------- sqlprodbkup => Forward DNS OK | Reverse DNS OK | Ping OK | NBU Connection OK sql51bkup => Forward DNS OK | Reverse DNS OK | Ping OK | NBU Connection OK sql52bkup => Forward DNS OK | Reverse DNS OK | Ping OK | NBU Connection OK
- In the example above, all aspects of the networking for the client's connectivity are working, so we can proceed. If any of the aspects of the script's output shows any failures or issues then the requester/customer will need to be notified and the process will be stopped until those issues are resolved.
3) A one time test backup must be performed on the physical nodes that make up the cluster. (This step is only needed on clustered systems that require client side restore functionality were the physical nodes/hosts are not already, or going to become, a part of a regular backups schedule - skip this step for all other systems).
- 3.1) Add the physical hosts as clients to the policy used to run the "one-time" backup of the client. If the policy does not exist then follow the procedures in Creating New NBU Policies for Backups while configuring the new policy with the appropriate retention requested.
- 3.1.1) From the NetBackup Java Administration Console, under NetBackup Management, click on Policies, then find the test policy and double click on it.
- 3.2.2) From the Clients tab, click on the New button. Enter the first physical server name in the Client name: field. Choose the Hardware and operating system as provided in the request, and click on the Add button.
- 3.1.3) Enter the second physical server name in the Client name: field. Choose the Hardware and operating system as provided in the request, and click on the OK button.
- 3.1.4) Once all the necessary "clients" have been added, click on the Close button.
- 3.1.5) Remove any old "client(s)" that are not needed for this one-time backup.
- 3.2) Double Check the Storage Unit and Volume Pool used by the test policy to make sure it is using an appropriate tape on the appropriate media server. If the wrong Storage Unit or Pool is specified, the backup might fail or data will be retained on an incorrect device for too long:
- 3.2.1) From the NetBackup Java Administration Console, under NetBackup Management, click on Policies, then find the test policy and double click on it.
- 3.2.2) Under Policy Storage select the correct Storage Unit then click on the OK button. In the window to the right of the policy list, you should now see the correct Storage Unit for the policy in the Storage column.
- 3.2.3) Under Policy volume pool make sure the appropriate volume pools is selected.
- 3.2.4) Under the "Schedules" tab, make sure an appropriate Schedule exists that will allow the backup images to be retained for a period of time that satisfies either the maximum length of time backup images are kept in the given environment, or how long the cluster is expected to be active.
- 3.3) Now the physical servers are ready for the test backup. Right click on the test policy in the window listing all the policies. Choose Manual Backup from the list. This will open the Manual Backup window.
- 3.3.1) Select the appropriate schedule, and physical server name(s) that were added, then click on the OK button to start the backups.
- 3.3.3) In the main NetBackup Java Administration Console, click on the Activity Monitor to view the progress of the backups. Once the backups have completed successfully, the process can continue in the next step.
- 3.3.4) Be sure to deactivate the test policy once you are done with this step.
4) Next is to add the client's backup interface (or clustered backup interface) to the necessary policy(s). Using the information gathered in step one, locate the correct policy(s).
- 4.1) In the NetBackup Java Administration Console, under NetBackup Management, click on Policies, then find the appropriate policy and double click on it.
- 4.1.1) Click on the "Client" tab in the Change Policy window.
- 4.1.2) Click on the New... button.
- 4.1.4) In the Add Client popup window, enter the client name.
- 4.1.4) Choose the correct Hardware and operating system for the client you are adding in the drop down box.
- 4.1.5) Click on "OK" and the client should now appear in the list.
- 4.1.5) Click on the "Close" button and this process is complete.
- 4.2) Repeat the steps in 4.1 for any additional policies required.
5) Run the initial backup as a test for the policies where the new client resides.
- 5.1) In the NetBackup Java Administration Console, under NetBackup Management, click on Policies, then find the appropriate policy.
- 5.1.1) Right click on the policy name and choose Manual Backup.
- 5.1.2) In the "Schedules" box, click on Daily to select it.
- 5.1.3) In the "Clients" box, click on the client you added in step 4.
- 5.1.4) Click on the "OK" button to start the backup.
- 5.2) Repeat the process in step 5.1 for any additional policies as needed.
- 5.3) In the main NetBackup Java Administration Console, click on the Activity Monitor to view the progress of the backups. Once the backups have completed successfully, the process can continue to the next step.
6) (Do not do this step for clients running the NetBackup 7.1 client software - We first need to see how well the improvements in the new version deals with VSS). To eliminate some frequent backup issues, the next step is to Disable Windows Snapshot Backups. This is also know as Windows Open File Backups (WOFB).
7) (This step is only needed on clustered SQL and Oracle systems were client side restores functionality is required - skip this step for all other systems - some environments may not require this step as they do not restrict client side restores) Update the NBU Altnames configuration to allow "client side" restores to work properly.
Note: The ability for restores to work properly is dependent upon the correct name for the physical severs not only being configured here, but also having been backed up in step 3. If their DNS or server names on the physical nodes change or where not entered properly for the test backups and the Altnames configured done properly, then "client side" restores will hang and timeout.
8) Verify Standard excludes are setup on the client(s) - add them if needed.
- For clustered environments, check each physical node. The Platform and/or build team should be putting these in place as part of the standard NetBackup client software install. Make sure they are configured to work with the "Backup Selections" with in the policy; keeping in mind that excludes lists can be specific to a specific policy.
9) Inform the requester that if they want to insure client side restores work, they will need to test them at this point and work with the NetBackup team to fix any issues they encounter.
- Also see: Reasons why Client side restores might not work in NetBackup and Client Side Restores and Verification.
10) If you want this backup controlled and monitored by an operation staff, using Control-M may work. See the directions in Requesting new Control-M Jobs for NetBackup.
- Be sure to relate any control-m request ticket to the client add ticket.
11) (This step is only needed if you completed step 3 - skip this step for standalone systems) Our Glasshouse reporting tool also needs to be updated to prevent us from being double charged for the physical servers and clustered interfaces on the same server.
- 11.1) Inform our Glasshouse "Service Account Manager" of the new cluster, and that the virtual server name is associated with the physical client names.
- 11.2) If the Physical nodes do not get regular backups performed on them, login to Glasshouse] and permanently remove the entries for the physical server that you did one-time backups on.
12) Once backups are verified to be scheduled and working, Close the ticket, noting the policy(s) the client was added to, and that the customer may want to test restores from the system(s) that were added to backups.
Back to NetBackup