Search <book_title>...

Important Update: Cohesity Products Documentation

All Cohesity product documentation are now managed via the Cohesity Docs Portal: https://docs.cohesity.com/HomePage/Content/home.htm. Some documentation available here may not reflect the latest information or may no longer be accessible.

NetBackup™ Web UI Administrator's Guide

Last Published: 2026-02-23

Product(s): NetBackup (11.1.0.2)

Examples of redirected restores

This topic provides some example configurations that allow clients to restore the files that were backed up by other clients. These methods may be required when a client connects through a gateway or has multiple Ethernet connections.

In all cases, the requesting client must have access to an image database directory on the primary server or the requesting client must be a member of an existing NetBackup policy.

On Windows: install_path\NetBackup\db\images\client_name
On UNIX: /usr/openv/netbackup/db/images/client_name

Note:

Not all file system types on all computers support the same features. Problems can be encountered when a file is restored from one file system type to another. For example, the S51K file system on an SCO computer does not support symbolic links nor does it support names greater than 14 characters long. You may want to restore a file to a computer that doesn't support all the features of the computer from which the restore was performed. In this case, all files may not be recovered.

In the following examples, assume the following conditions:

client1 is the client that requests the restore.
client2 is the client that created the backups that the requesting client wants to restore.
On Windows: install_path is the path where you installed the NetBackup software. By default, this path is C:\Program Files\Cohesity NetBackup.
Note:
On Windows: You must have the necessary permissions to perform the following steps.
On UNIX: You must be a root user for any of the steps that must be performed on the NetBackup server. You may also need to be a root user to make the changes on the client.

Example of a redirected client restore

Assume you must restore files to client1 that were backed up from client2. The client1 and client2 names are those specified by the NetBackup client name setting on the clients.

On Windows:

Log on to the NetBackup server.
Add client2 to the following file and perform one of the following:
- Edit install_path\NetBackup\db\altnames\client1 to include the name of client2.
- Create the following empty file:
  install_path\NetBackup\db\altnames\No.Restrictions

On UNIX:

Log on as root on the NetBackup server.
Perform one of the following actions:
- Edit /usr/openv/netbackup/db/altnames/client1 so it includes the name of client2. Or,
- Run the touch command on the following file:
  /usr/openv/netbackup/db/altnames/No.Restrictions
  Note:
  The No.Restrictions file allows any client to restore files from client2.
Log on to client1 and change the NetBackup client name to client2.
Restore the file.
Undo the changes that were made on the server and client.

Example of a redirected client restore using the altnames file

This example explains how altnames provides restore capabilities to clients that do not use their own host name when they connect to the NetBackup server.

By default, the NetBackup client name of the requesting client must match the peer name that is used in the connection to the NetBackup server. When the NetBackup client name is the host name for the client and matches the peer name (normal case), this requirement is met.

However, problems arise when clients connect to multiple ethernet or connect to the NetBackup server through a gateway.

Figure: Example restore from a token ring client

In this example, restore requests from client1, client2, and client3 are routed through the TCP gateway. Because the gateway uses its own peer name rather than the client host names for connection to the NetBackup server, NetBackup refuses the requests. Clients cannot restore even their own files.

To correct the situation, do the following

Determine the peer name of the gateway:
- Try a restore from the client in question. In this example, the request fails with an error message similar to the following:
  client is not validated to use the server
- Examine the NetBackup problems report and identify the peer name that is used on the request. Entries in the report may be similar to the following:
  01/29/12 08:25:03 bpserver - request from invalid server or client client1.dvlp.null.com
  In this example, the peer name is client1.dvlp.null.com.
Do one of the following:
On Windows: Determine the peer name, then create the following file on the NetBackup primary server:
install_path\NetBackup\db\altnames\peername
In this example, the file is:
install_path\NetBackup\db\altnames\client1.dvlp.null.com
On UNIX: Run the touch command on the following file:
/usr/openv/netbackup/db/altnames/peername
In this example, the file is:
/usr/openv/netbackup/db/altnames/client1.dvlp.null.com
Edit the peername file so that it includes the client names.
For example, if you leave file client1.dvlp.null.com empty, client1, client2, and client3 can all access the backups that correspond to their NetBackup client name setting.
If you add the names client2 and client3 to the file, you give these two clients access to NetBackup file restores, but exclude client1.
Note that this example requires no changes on the clients.
Restore the files.

Example of how to troubleshoot a redirected client restore using the altnames file

If you cannot restore files with a redirected client restore by using the altnames file, troubleshoot the situation, as follows.

On Windows:

Create the debug log directory for the NetBackup Request Daemon:
install_path\NetBackup\logs\bprd
On the primary server, stop and restart the NetBackup Request Daemon. Restart the service to ensure that this service is running in verbose mode and logs information regarding client requests.
On client1 (the requesting client), try the file restore.
On the primary server, identify the peer name connection that client1 uses.
Examine the debug log for the NetBackup Request Daemon to identify the failing name combination:
Examine the failure as logged on the All log entries report. Or, examine the debug log for the NetBackup Request Daemon to identify the failing name combination:
install_path\NetBackup\logs\bprd\mmddyy.log
On the primary server, do one of the following:
- Create an install_path\NetBackup\db\altnames\No.Restrictions file. The file allows any client to access client2 backups if the client changes its NetBackup client name setting to client2.
- Create an install_path\NetBackup\db\altnames\peername file. The file allows client1 to access client2 backups if client1 changes its NetBackup client name setting to client2.
- Add client2 name to the following file: install_path\NetBackup\db\altnames\peername.
- client1 is allowed to access backups on client2 only.
On client1, change the NetBackup client name setting to match what is specified on client2.
Restore the files from client1.
Perform the following actions:
- Delete install_path\NetBackup\logs\bprd and the contents.
- In the NetBackup web UI, open the host properties for the primary server. Click Logging. Clear the Keep logs for days setting.
If you do not want the change to be permanent, do the following:
- Delete install_path\NetBackup\db\altnames\No.Restrictions (if existent).
- Delete install_path\NetBackup\db\altnames\peername (if existent).
- On client1, change the NetBackup client name to its original value.

On UNIX:

On the NetBackup primary server, add the VERBOSE entry and a logging level to the bp.conf file. For example:
```
VERBOSE = 3
```
Create the debug log directory for bprd by running the following command:
mkdir /usr/openv/netbackup/logs/bprd
On the NetBackup server, stop the NetBackup Request Daemon, bprd, and restart it in verbose mode by running:
```
/usr/openv/netbackup/bin/admincmd/bprdreq -terminate
/usr/openv/netbackup/bin/bprd -verbose
```
Restart bprd to ensure that bprd logs information regarding client requests.
On client1, try the file restore.
On the NetBackup server, identify the peer name connection that client1 used.
Examine the bard debug log to identify the failing name combination:
Examine the failure as logged on the All log entries report or examine the bard debug log to identify the failing name combination:
/usr/openv/netbackup/logs/bprd/log.date
On the NetBackup server enter the following command:
mkdir -p /usr/openv/netbackup/db/altnames touch /usr/openv/netbackup/db/altnames/No.Restrictions
This command allows any client access to client2 backups by changing its NetBackup client name setting to specify the client2.
Run the touch command on the following file:
/usr/openv/netbackup/db/altnames/peername
The command allows client1 access to any client2 backups by changing its NetBackup client name setting to specify client2.
Add client2 to the /usr/openv/netbackup/db/altnames/peername file. The addition to the peername file allows client1 access to the backups that were created on client2 only.
On client1, change the NetBackup client name setting in the user interface to match what is specified on client2.
Restore the files to client1.
Do the following:
- Delete the VERBOSE entry from the /usr/openv/netbackup/bp.conf file on the primary server.
- Delete /usr/openv/netbackup/logs/bprd and the contents.
Return the configuration to what it was before the restore.
- Delete /usr/openv/netbackup/db/altnames/peer.or.hostname (if it exists)
- Delete /usr/openv/netbackup/db/altnames/No.Restrictions (if it exists)
- On client1, restore the NetBackup client name setting to its original value.

More Information

Allowing a single client to perform redirected restores

Allowing redirected restores of a specific client's files