Professional Documents
Culture Documents
for Windows
Release 6.5
12308282
Technical support
For technical assistance, visit http://entsupport.symantec.com and select phone or email support. Use the Knowledge Base search feature to access resources such as TechNotes, product alerts, software downloads, hardware compatibility lists, and our customer email notification service.
Contents
Chapter 1
Additional configuration
Multiplexing .........................................................................................................13
When to use multiplexing ...........................................................................14
How to configure multiplexing ..................................................................14
Maximum streams per drive for a storage unit ...............................15
Media multiplexing for a schedule ....................................................15
Other configuration settings to consider using multiplexing ......18
Demultiplexing .............................................................................................19
Using multiple NetBackup master servers ......................................................20
Using multiple media servers with one master server ..................................21
Software on each server ..............................................................................22
NetBackup catalogs .....................................................................................23
Adding a media server .........................................................................................23
Registering a media server .........................................................................25
NetBackup configuration options .....................................................................27
NetBackup administration options ...........................................................27
NBRB_CLEANUP_OBSOLETE_DBINFO ............................................28
NBRB_ENABLE_OPTIMIZATIONS ....................................................28
NBRB_FORCE_FULL_EVAL ................................................................28
NBRB_REEVAL_PENDING ..................................................................28
NBRB_REEVAL_PERIOD .....................................................................28
NBRB_RETRY_DELAY_AFTER_EMM_ERR ......................................29
NBRB_MPX_GROUP_UNLOAD_DELAY ...........................................29
REQUIRED_NETWORK .......................................................................29
vm.conf options for media servers ............................................................30
ACS_mediatype ......................................................................................30
ADJ_LSM ................................................................................................30
API_BARCODE_RULES ........................................................................31
AUTHORIZATION_REQUIRED ..........................................................32
AUTO_PATH_CORRECTION ..............................................................32
AUTO_UPDATE_ROBOT .....................................................................33
AVRD_PEND_DELAY ...........................................................................33
AVRD_SCAN_DELAY ...........................................................................33
CLEAN_REQUEST_TIMEOUT ............................................................34
CLIENT_PORT_WINDOW ...................................................................34
CLUSTER_NAME ..................................................................................34
CONNECT_OPTIONS ........................................................................... 35
DAS_CLIENT ......................................................................................... 35
DAYS_TO_KEEP_LOGS ....................................................................... 36
EMM_RETRY_COUNT ......................................................................... 36
EMM_CONNECT_TIMOUT ................................................................. 36
EMM_REQUEST_TIMOUT ................................................................. 36
ENABLE_ROBOT_AUTH ..................................................................... 37
INVENTORY_FILTER .......................................................................... 37
MAP_ID .................................................................................................. 37
MAP_CONTINUE_TIMEOUT ............................................................. 38
MEDIA_ID_BARCODE_CHARS .......................................................... 38
MEDIA_ID_PREFIX .............................................................................. 39
MM_SERVER_NAME ........................................................................... 39
PREFERRED_GROUP .......................................................................... 40
PREVENT_MEDIA_REMOVAL ........................................................... 40
RANDOM_PORTS ................................................................................ 40
REQUIRED_INTERFACE ..................................................................... 41
SERVER ................................................................................................. 41
SSO_DA_REREGISTER_INTERVAL .................................................. 42
SSO_DA_RETRY_TIMEOUT ............................................................... 42
SSO_HOST_NAME ............................................................................... 43
TLH_mediatype .................................................................................... 43
TLM_mediatype ................................................................................... 43
VERBOSE ............................................................................................... 43
Example vm.conf file ........................................................................... 43
Direct I/O for backups ......................................................................................... 44
Disabling direct I/O ..................................................................................... 45
Dynamic host name and IP addressing ............................................................ 45
Setting up dynamic IP addresses and host names .................................. 46
Configuring the NetBackup master server .............................................. 47
Configuring a dynamic Microsoft Windows client ................................. 49
Configuring a dynamic UNIX NetBackup client ..................................... 49
Configuring email notifications ........................................................................ 50
Specifying the locale of the NetBackup installation ...................................... 51
Chapter 2
Reference topics
Rules for using host names in NetBackup ....................................................... 54
Qualifying host names ................................................................................ 54
How NetBackup uses host names .............................................................. 54
Policy configuration ............................................................................ 55
Image catalog ....................................................................................... 55
Error catalog ......................................................................................... 55
Catalog backup information ............................................................... 55
Chapter 3
Chapter 4
10
Chapter 5
11
12
Chapter
Additional configuration
This chapter explains settings that, in most instances, are optional. The sections in this chapter include the following:
Multiplexing on page 13
Using multiple NetBackup master servers on page 20
Using multiple media servers with one master server on page 21
Adding a media server on page 23
NetBackup configuration options on page 27
Direct I/O for backups on page 44
Dynamic host name and IP addressing on page 45
Configuring email notifications on page 50
Specifying the locale of the NetBackup installation on page 51
Multiplexing
NetBackup multiplexing sends concurrent backups from one or several clients to a single storage device. NetBackup multiplexes the backups sequentially onto the media. Multiplexed and unmultiplexed backups can reside on the same volume. Separate volume pools or media IDs are not necessary.
14 Additional configuration
Multiplexing
No special action is required to restore a multiplexed backup. NetBackup finds the media and restores the requested backup.
Clients
Disk
Disk
Disk
Slow clients. Instances in which NetBackup uses software compression, which normally reduces client performance, are also improved. Multiple slow networks. The parallel data streams take advantage of whatever network capacity is available. Many short backups (for example, incremental backups). In addition to providing parallel data streams, multiplexing reduces the time each job waits for a device to become available. Therefore, the storage device transfer rate is maximized.
Multiplexing reduces performance on restores because it uses extra time to read the images. Note: To reduce the impact of multiplexing on restore times, set the storage unit maximum fragment size to a value smaller than the largest allowed value.
15
Note: If you change these values, it does not take effect until the next time a schedule runs.
The maximum concurrent jobs that NetBackup can attempt equals the sum of the concurrent backup jobs that can run on all storage units. The maximum concurrent jobs that can run on a storage unit equals the Maximum Streams Per Drive value, multiplied by the number of drives.
When NetBackup multiplexes jobs, it continues to add jobs to a drive until the number of jobs on the drive matches either of the following:
This schedules Media Multiplexing setting. If the limit is reached for a drive, NetBackup sends jobs to other drives. In the following figure, when the Schedule A limit is reached on Drive 1, NetBackup adds Schedule A jobs to Drive 2. The storage units Maximum streams per drive setting. NetBackup can add jobs from more than one schedule to a drive. In the following figure, unshaded numbers denote a job starting. Shaded numbers denote job completion. For example, 1 denotes the start of job A1 on Drive 1. 9 denotes the completion of job A1 on Drive 1.
17
Figure 1-1
Schedule A Media Multiplexing per drive = 2 dog 1 2 9 10
cat 3 11 A3 Drive 2 4 A4 B4 8 B3 7
otter
Assume schedule A begins first (note that the schedules can be in the same or in different policies). Also, assume that Allow Multiple Data Streams is enabled, so a client can have multiple data streams. 1 3 5 7 2 4 6 8 Jobs A1 and A2 from client dog start on drive 1. Schedule A Media Multiplexing limit of 2 is reached for this drive. Jobs A3 and A4 from client cat start on drive 2. Schedule A Media Multiplexing limit of 2 is reached for this drive. Jobs B1 and B2 for client fox start on drive 1. Storage unit max mpx is reached for this drive. Jobs B3 and B4 from client otter start on drive 2. All jobs are now running for schedule B. Storage Unit Max mpx is reached for drive 2.
Jobs A1 and A2 from client dog finish on drive 1. However, jobs B1 and B2 for client fox 9 10 continue to run. Schedule A Media Multiplexing limit of 2 prevents job A5 from starting on drive 1. 11 12 Job A3 from client cat finishes on drive 2 and job B1 from client fox finishes on drive 1. Job B2 is the only job currently running on drive 1. Job A5 from client cat starts on drive 1. JobA5 is the last job for schedule A. Schedule A Media Multiplexing limit of 2 prevents job A5 from starting on Drive 2. Therefore, job A5 starts on Drive 1. NetBackup attempts to add multiplexed jobs to drives that already use multiplexing. If multiplexed jobs are confined to specific drives, other drives are available for non-multiplexed jobs.
13
Note: If the backup window closes before NetBackup can start all the jobs in a multiplexing set, NetBackup completes only the jobs that have started. For example, Figure 1-1 on page 17 assumes that the Activity Monitor shows A1 through A5 as queued and active. If only A1 and A2 start before the window closes, NetBackup does not perform the other jobs that are in the set. If the window closes before any jobs have started, then only the first queued and active job starts and completes. (A1 in this example.)
19
Demultiplexing
Demultiplexing speeds up future restores and is useful for creating a copy for off-site storage. Use duplication to demultiplex a backup. Duplication allows one multiplexed backup at one time to be copied from the source media to the target media. When duplication is complete, the target contains a single demultiplexed copy of each duplicated backup. (The target can also contain other backups.) The duplicate copy can be made into the primary copy. Do not select Preserve Multiplexing in the Setup Duplication Variables dialog box when backups are duplicated. Note: If you use the bpduplicate command instead of the NetBackup Administration Console, do not include the -mpx option on that command.
For a large site, you can use multiple NetBackup master servers to optimize the backup loads. You divide the clients between the servers as necessary. The following figure shows a multiple-server configuration where the two sets of networks (A1/A2 and B1/B2) each have enough clients to justify separate servers. In this environment, the two NetBackup server configurations are completely independent. You can also create a configuration where one server is the master and the other is a media server.
Workstations
Network A2
Additional configuration Using multiple media servers with one master server
21
One master server, which controls all backup scheduling. Multiple media servers, which write the backup images to disk or removable media. They may have peripheral devices to provide additional storage. Multiple protected NetBackup clients, which send their data to the media servers.
A protection domain refers collectively to the NetBackup master server, its NetBackup media servers, and its NetBackup clients. In a group of NetBackup servers, a client can have backups directed to any device on any server in the group. A common alternative strategy is to install extra peripherals on the clients that produce large amounts of data. The master server directs the data from the client to the clients peripherals, which reduces network traffic because the data does not traverse the network. This strategy also distributes the backup load between the master and the media servers. Two important points to remember about master and media servers:
There can be only one master server in a group. A NetBackup master server is a media server for itself but cannot be a media server for another master server.
22 Additional configuration Using multiple media servers with one master server
The following figure shows where software is installed and where the NetBackup catalogs are located (by default). The following topics provide more details on master and media servers and a procedure to configure them.
Master Server NetBackup Catalogs Configuration files Image database User Interface (BAR)
NetBackup Client
Storage Device
Administration Interface*
User Interface
Storage Device
Storage Device
* You can also use the Backup, Archive, and Restore user interface from a Windows client that has the Remote Administration Console installed.
23
NetBackup catalogs
Applies to NetBackup Enterprise Server only. The master server is the default location for the NetBackup catalogs. The catalogs include the media and the volume database (emm_data.db). The volume database contains the media usage information and the volume information that are used during the backups.
2 3
Select the host that you want to change in the right pane. To select more than one host, hold down the Shift key and select all the hosts that you want to change in the right pane. Select Actions > Properties.
d e f g
Select the Servers properties. Click Add next to the Additional servers window and type the name of the new server. Click Add to add the server to the additional server list for all selected hosts.
Click Close.
h Click OK.
For more information, see Servers properties on page 467 in the NetBackup Administrators Guide, Volume I. 4 5 6 7 8 9 Restart the NetBackup services on the master server, the EMM server, and the media servers on which you added the new server name. On NetWare target clients, add the new media server name by using a SERVER entry in the bp.ini file. Install the NetBackup media server software as explained in the NetBackup Installation Guide. Configure the drives and robots as explained in Devices in the NetBackup Administrators Guide, Volume I. Configure the volumes as explained in Media in the NetBackup Administrators Guide, Volume I. On the master server, do the following to the NetBackup configuration:
25
a b
Add storage units to the media server. Always specify the media server as the media server for the storage unit. Enter the catalog paths if necessary: To use the online, hot catalog backup method: NetBackup enters the paths automatically. To use the offline, cold catalog backup method: Add the catalog paths for the media server to the NetBackup catalog
backup configuration.
For more information, see Chapter 4, NetBackup Catalog on page 273
in the Administrators Guide, Volume I.
Paths on a Windows media server:
media_server_name:install_path\NetBackup\db media_server_name:install_path\NetBackup\var media_server_name:install_path\Volmgr\database Where install_path is the directory where the NetBackup software is installed on the media server. Paths on a UNIX media server: media_server_name:/usr/openv/netbackup/db
media_server_name:/usr/openv/var
media_server_name:/usr/openv/volmgr/database
Configure the NetBackup policies and schedules to use the storage units that are configured on the media server.
10 Test your configuration by performing a user backup or a manual backup that uses a schedule that specifies a storage unit on the media server.
Note: To avoid problems with NetBackup, ensure that the host name you use in NetBackup matches the host name in your TCP/IP configuration. For nbemmcmd command usage, see NetBackup Commands for UNIX and Linux or NetBackup Commands for Windows.
27
NetBackup configuration options allow an administrator to customize NetBackup to meet specific site preferences and requirements. Generally, these options are configured in the NetBackup Administration Console, under Host Properties. Options for configuring media and device management in the vm.conf file as explained in this chapter. The vm.conf file contains configuration entries for media and device management. However, some options cannot be configured by using the NetBackup Administration Console.
NetBackup administration options Media and device configuration options (vm.conf file)
NBRB_CLEANUP_OBSOLETE_DBINFO
The NBRB_CLEANUP_OBSOLETE_DBINFO entry serves as a performance tuning option for the Intelligent Resource Manager. This entry indicates the number of seconds (default: 60) that can elapse between the cleanup of obsolete information in the NetBackup Resource Broker (nbrb) database. No equivalent exists in the NetBackup Administration Console host properties.
NBRB_ENABLE_OPTIMIZATIONS
The NBRB_ENABLE_OPTIMIZATIONS entry serves as a performance tuning option for the Intelligent Resource Manager. This entry indicates whether the Resource Broker caches states of resource requests. Default: 1 (true). No equivalent exists in the NetBackup Administration Console host properties.
NBRB_FORCE_FULL_EVAL
The NBRB_FORCE_FULL_EVAL entry serves as a performance tuning option for the Intelligent Resource Manager. This entry indicates the number of seconds that can elapse between full evaluations of all NetBackup Resource Broker (nbrb.exe) queues, using no cached EMM information. (Default: 1800 seconds/30 minutes.) For example, full evaluations include matching job resource requests with available resources. No equivalent exists in the NetBackup Administration Console host properties.
NBRB_REEVAL_PENDING
The NBRB_REEVAL_PENDING entry serves as a performance tuning option for the Intelligent Resource Manager. This entry indicates the number of seconds (default: 60) that can elapse between evaluations of the pending request queue. For example, a pending request queue can include, jobs awaiting resources. No equivalent exists in the NetBackup Administration Console host properties.
NBRB_REEVAL_PERIOD
The NBRB_REEVAL_PERIOD entry serves as a performance tuning option for the Intelligent Resource Manager and NetBackup Resource Broker (nbrb.exe). NBRB_REEVAL_PERIOD indicates the time between evaluations if an outstanding request is not satisfied, and if no other requests or resources have been released. Default: 5 minutes passes before the initial request is reevaluated. No equivalent exists in the NetBackup Administration Console host properties.
29
NBRB_RETRY_DELAY_AFTER_EMM_ERR
The NBRB_RETRY_DELAY_AFTER_EMM_ERR entry serves as a performance tuning option for the Intelligent Resource Manager. This entry indicates how long NetBackup waits after an EMM error before attempting again. (Default: 60 seconds.) The error must be one where a retry is possible. For example, if a media server is down.
NBRB_MPX_GROUP_UNLOAD_DELAY
The NBRB_MPX_GROUP_UNLOAD_DELAY entry serves as a performance tuning
option for the Intelligent Resource Manager.
This entry indicates the number of seconds that the NetBackup Resource Broker
(nbrb.exe) waits for a new job to appear before a tape is unloaded.
(Default: 10 seconds.) This setting can help avoid unnecessary reloading of tapes
and applies to all backup jobs.
During user backups, nbrb.exe uses the maximum value of
NBRB_MPX_GROUP_UNLOAD_DELAY and the Media mount timeout host
property setting when unmounting the tape.
This host property is found in the NetBackup Administration Console under
NetBackup Management > Host Properties > Select master server > Timeouts >
Media mount timeout. See Chapter 7 in the Administrators Guide, Volume I for
more details.
During restores, Media mount timeout is used, not
NBRB_MPX_GROUP_UNLOAD_DELAY.
No equivalent exists in the NetBackup Administration Console host properties.
The RE_READ_INTERVAL entry determines how often NetBackup checks disk
storage units for available capacity. Default: 300 seconds (5 minutes).
REQUIRED_NETWORK
The REQUIRED_NETWORK entry specifies the required route for backup traffic in an environment where the network traffic is segregated. For example, an environment may contain a production network at 145.21.14.0 and a backup network at 192.132.28.0. To indicate that NetBackup should use only the backup network, add the following entry in the bp.conf file: REQUIRED_NETWORK = 192.132.28.0
Note: If the variable is set and the network is not available, all connections fail and no backups are performed.
ACS_mediatype
ACS_mediatype = Media_Manager_mediatype
This configuration entry applies only to NetBackup Enterprise Server If this entry is used in vm.conf, the ACS media type is mapped to the specified Media Manager media type. You can specify more than one ACS_mediatype entry. This entry is read and interpreted on the host on which vmcheckxxx and vmupdate run during a robot inventory operation. Use this entry on every NetBackup media server that functions as an ACS robot control host. For a list of the valid ACS_mediatype entries, see Media Type Mappings tab in the NetBackup Administrators Guide for Windows, Volume I.
ADJ_LSM
ADJ_LSM = robot_num ACS_ID,LSM_ID ACS_ID,LSM_ID
This configuration entry applies only to NetBackup Enterprise Server. In an ACS robot with multiple library storage modules (LSMs), pass-through mechanisms may move ejected media to the media access port (MAP). A pass-through mechanism passes media from one LSM to another. This travel time can be excessive when media must pass through several LSMs. Use this entry to specify the physical orientation of the LSMs in an ACS robot. If this entry is specified in vm.conf, you do not need to know which MAP (or ACS CAP) to select for efficient ejects. NetBackup determines the appropriate MAP to complete the media eject using a nearest-MAP algorithm. This nearest-MAP algorithm is based on the physical orientation of the LSMs that defined with this entry. This algorithm is only for the cases where more than one MAP has been requested to handle the eject. If this algorithm is used, any MAP_ID entries in vm.conf are ignored.
31
Note: The nearest-MAP capability is only available using the vmchange command with the -map option or the Vault administrative interface. It is not available from the NetBackup Administration Console. Without this entry present, NetBackup assumes that all LSMs are interconnected with pass-through ports, except for the first LSM and the last LSM. The LSMs are interconnected in a line formation. robot_num is the robot number. ACS_ID and LSM_ID are the coordinates of the LSM.
For example, the following entries are required to specify the physical layout of
LSM interconnections for robot number 700 (Figure 1-2 on page 31):
ADJ_LSM ADJ_LSM ADJ_LSM ADJ_LSM ADJ_LSM ADJ_LSM ADJ_LSM ADJ_LSM = = = = = = = = 700 700 700 700 700 700 700 700 0,0 0,0 0,1 0,1 0,2 0,2 0,3 0,4 0,1
0,6
0,2
0,6
0,6
0,3
0,4
0,5
The robot has pass-through mechanisms between 7 LSMs. Figure 1-2 Pass-through example
0 6 5 4
API_BARCODE_RULES
API_BARCODE_RULES
If this entry is specified in vm.conf, barcode rule support for API robots is
enabled.
NetBackup barcode rules allow default media mappings to be overridden.
Barcode rules are especially useful when multiple generations of the same tape
drive use the same type of media.
For example STK 9940A and STK 9940B drives use STK1R media, but write data
at different densities. The drive must be configured using different drive types
such as hcart or hcart2. You can specify a barcode rule for a series of barcodes to
configure some of the media as hcart2. Other STK1R media not in this barcode
range are configured as hcart (the default for STK1R). Without this entry, a
robot inventory operation configures all media of type STK1R as either hcart or
hcart2, depending on how the drive was configured.
AUTHORIZATION_REQUIRED
AUTHORIZATION_REQUIRED
This entry specifies that NetBackup should use the vm.conf file SERVER entry to control which hosts can monitor and control devices on this host. This entry is read and interpreted on the media server on which the NetBackup vmd service runs. If this entry is specified in vm.conf, the vm.conf file also must include a SERVER entry for every media server that controls devices on this host. If no AUTHORIZATION_REQUIRED entry exists and no SERVER entries exist, any NetBackup server can monitor and control devices on this host. For maximum security, Symantec recommends that you use this entry and SERVER entries. This entry is read and interpreted on media servers on which the NetBackup vmd service runs.
AUTO_PATH_CORRECTION
AUTO_PATH_CORRECTION = YES|NO
If this entry is specified in vm.conf, it specifies whether automatic device path remapping is enabled or disabled. If the value is NO, the device configuration remains unchanged when the NetBackup Device Manager service (ltid) is started. Therefore, the saved device configuration may be different than the actual configuration after you change devices and restart the server. If the value is YES, NetBackup tries to discover attached devices and then automatically update the device configuration for any device paths that are incorrect. On Windows computers, this entry is read and interpreted on the host
33
on which the NetBackup Device Manager service runs. On UNIX and Linux computers, this entry is read and interpreted on the host on which ltid runs. Device path remapping is enabled by default on Windows and Linux servers. It is disabled by default on all other servers.
AUTO_UPDATE_ROBOT
AUTO_UPDATE_ROBOT
Use this entry to inject media automatically from the Media Access Port (MAP)
into a TL8 or TLD robot and update the EMM database. Media are injected if the
robot generates a unit attention message.
This entry only operates with the TL8 or TLD robots that post a unit attention
when their MAP has been opened.
Symantec recommends that this entry not be used with partitioned libraries.
Most robotic libraries with multiple partitions do not post a unit attention when
the MAP has been opened.
AVRD_PEND_DELAY
AVRD_PEND_DELAY = number_of_seconds
If this entry is specified in vm.conf, avrd waits number_of_seconds before it displays a pending status (PEND) in the Device Monitor. This entry is read and interpreted on the host on which avrd runs. On some server operating systems (Windows, Tru64, and HP-UX), NetBackup reports PEND if the drive reports Busy when a volume is unmounted. Use this entry to minimize the display of this misleading status. The minimum for number_of_seconds is zero. The maximum is 255. The default value is 180 seconds.
AVRD_SCAN_DELAY
AVRD_SCAN_DELAY = number_of_seconds
If this entry is specified in vm.conf, avrd waits number_of_seconds between normal scan cycles. This entry is read and interpreted on the host on which avrd runs. Use this entry to minimize tape mount times. Without this entry, NetBackup delays mount requests by an average of 7.5 seconds. The minimum for number_of_seconds is 1. The maximum is 180. A value of zero is converted to 1 second. The default value is 15 seconds. If a value is used that is greater than the default, NetBackup delays mount requests and drive status updates in the Device Monitor.
Caution: If number_of_seconds is set to a value that allows media to be changed within one scan cycle, NetBackup may not detect media changes. Data loss may occur.
CLEAN_REQUEST_TIMEOUT
CLEAN_REQUEST_TIMEOUT = minutes
Use this entry to specify how long NetBackup waits for a drive to be cleaned before it removes the cleaning request from the cleaning queue. Unprocessed requests to clean a drive are removed from the queue after 30 minutes. minutes can be from 1 to 144000 (100 days). The default value is 30 and a value of zero is converted to the default value of 30.
CLIENT_PORT_WINDOW
CLIENT_PORT_WINDOW = start end
Use this entry to specify the range of non-reserved ports on this host that are used to connect to vmd on other hosts. This entry is read and interpreted on the host on which vmd runs. For example, the following entry permits ports from 4800 through 5000:
CLIENT_PORT_WINDOW = 4800 5000
The operating system determines the non-reserved port to use in the following cases:
CLUSTER_NAME
CLUSTER_NAME = cluster_alias
This entry and the following two entries determine the name other NetBackup servers and clients should use when they refer to this server:
MM_SERVER_NAME = host_name
REQUIRED_INTERFACE = host_name
Use the CLUSTER_NAME entry if present in vm.conf. Use the MM_SERVER_NAME entry if present in vm.conf. Use the REQUIRED_INTERFACE entry if present in vm.conf. Use the same name that NetBackup uses. Use the gethostname() name.
35
This entry is read and interpreted on the host on which the required interface is needed.
CONNECT_OPTIONS
CONNECT_OPTIONS = server_name 0 0 [0|1|2]
Add this entry in vm.conf to specify the options that enhance firewall
efficiency with NetBackup. Server connection options can be any of the
following: use vnetd or the daemons port number, use only vnetd, or use only
the daemons port number.
CONNECT_OPTIONS entries can be specified for multiple servers.
server_name is the name of the media server to connect to. The server must be
at NetBackup level 4.5 or higher for vnetd to operate correctly.
The first and second options currently are not used. Specify zero for these
options.
The third option specifies the connection method to use to connect to
server_name as follows:
A value of 0 specifies to use vnetd to connect to a daemon on the server. If vnetd is not active, connect by using the traditional port number of the daemon. A value of 1 specifies to use vnetd only to connect to a daemon on the server. A value of 2 specifies to use the traditional port number of the daemon to connect to the daemon on the server. The default value is 2.
Examples
The following entry specifies to use either vnetd or the daemons port number to connect to server shark:
CONNECT_OPTIONS = shark 0 0 0
The following entry specifies to use vnetd only to connect to server dolphin:
CONNECT_OPTIONS = dolphin 0 0 1
The following entry specifies to use the daemonss port number only to connect to server perch:
CONNECT_OPTIONS = perch 0 0 2
DAS_CLIENT
DAS_CLIENT = client_name
This configuration entry applies only to NetBackup Enterprise Server If this entry is specified in vm.conf, specify the DAS client name that the TLM robot uses for communications with the DAS/SDLC server. By default this client
name is the host name of the media server. This entry is read and interpreted on the host where tlmd is running.
DAYS_TO_KEEP_LOGS
DAYS_TO_KEEP_LOGS = days
If this entry is specified in vm.conf, specify the number of days to keep debug logs before vmd deletes them. This entry is read and interpreted on the hosts where vmd is running. A value of zero means that the logs are not deleted. The default is zero. This entry does not impact debug logs created by Unified Logging. For more information about Unified Logging, see the NetBackup Troubleshooting Guide for UNIX, Windows, and Linux.
EMM_RETRY_COUNT
EMM_RETRY_COUNT = number_of_retries
The vmd and the ltid daemons use this entry to determine how many times to retry requests to the NetBackup Enterprise Media Manager. Default: one retry. Only change the value of this vm.conf file entry when directed to do so by your NetBackup support representative. If you add this entry to the vm.conf file or change this value, you must restart the vmd and the ltid daemons / services.
EMM_CONNECT_TIMOUT
EMM_CONNECT_TIMOUT = number_of_seconds
This value applies for broken connections between the vmd and the ltid daemons and the NetBackup Enterprise Media Manager. The vmd and the ltid daemons use this entry to determine for how long they should try to reconnect to the NetBackup Enterprise Media Manager. Default: 20 seconds. Only change the value of this vm.conf file entry when directed to do so by your NetBackup support representative. If you add this entry to the vm.conf file or change this value, you must restart the vmd and the ltid daemons / services.
EMM_REQUEST_TIMOUT
EMM_REQUEST_TIMOUT = number_of_seconds
The vmd and the ltid daemons use this entry to determine how many seconds
to allow a request to the NetBackup Enterprise Media Manager to complete.
Default: 300 seconds.
37
Only change the value of this vm.conf file entry when directed to do so by your NetBackup support representative. If you add this entry to the vm.conf file or change this value, you must restart the vmd and the ltid daemons / services.
ENABLE_ROBOT_AUTH
NetBackup encourages the use of Symantec Product Authentication and Authorization for NetBackup Access Control (NBAC) instead of legacy security implementations. For information about the ENABLE_ROBOT_AUTH configuration entry, see the NetBackup 6.0 documentation. For information on Symantec Product Authentication and Authorization, see the NetBackup Security and Encryption Guide.
INVENTORY_FILTER
INVENTORY_FILTER = robot_type robot_number mode value1 [value2 ...]
This configuration entry applies only to NetBackup Enterprise Server. Used to filter robot inventory results in ACS or TLH robot types. This entry must be added to the configuration file (vm.conf) on the NetBackup server on which the inventory operation is invoked. This entry is read and interpreted on the host on which vmcheckxxx and vmupdate run. Note: This entry may be required for an ACS robot and the ACS library software host was an STK Library Station. Newer versions of STK Library Station allow robot inventory commands to function correctly so filters are not required. robot_type can be ACS or TLH.
robot_number is the number of the robot as was configured in NetBackup.
mode is BY_ACS_POOL for ACS or BY_CATEGORY for TLH.
See the following examples:
MAP_ID
MAP_ID = robot_num map_ID
This configuration entry applies only to NetBackup Enterprise Server. Use this entry to configure the default Media Access Port (MAP) to use to eject media from Automated Cartridge System (ACS) robots. This default is highlighted as a choice in the NetBackup Administration Console but you can also select other Media Access Ports for ejects.
If the MAP is not available or the vm.comf file does not contain this entry,
NetBackup uses the default MAP selection process. By default, NetBackup uses
the smallest MAP that can hold the number of media to be ejected.
If NetBackup selects multiple MAPs, NetBackup uses the nearest-MAP
algorithm rather than the MAP that is specified in the MAP ID entry. For more
information, see ADJ_LSM on page 30.
robot_num is the robot number. map_ID is in the format of an ACS CAP
(Cartridge Access Port) ID and cannot contain any spaces.
The following example specifies the MAP ID for ACS robot number 700. The ACS
CAP ID of 0,1,0 is used.
MAP_CONTINUE_TIMEOUT
MAP_CONTINUE_TIMEOUT = seconds
This entry applies only when the vmchange command is used and the -w option is specified. The default timeout value for seconds is 300 (5 minutes). seconds cannot be zero and values greater than 1200 (20 minutes) may cause the robotic daemon to cancel the operation. If this entry is specified in vm.conf, the SCSI robotic daemons wait the specified number of seconds before they time out. A timeout can occur while waiting for a reply from the user to continue after removing volumes from the media access port. A timeout results in the operation being aborted. This entry is read and interpreted on the host on which the SCSI-controlled robotic daemon or process runs. Caution: Non-mount activities such as a robotic inventory can not occur during this timeout period.
MEDIA_ID_BARCODE_CHARS
MEDIA_ID_BARCODE_CHARS = robot_num barcode_length media_ID_rule
Note: To use this entry, the robot must support barcodes and the robot type cannot be an API robots. If this entry is specified in vm.conf, it controls NetBackup media ID generation. This entry is read and interpreted on the host on which vmcheckxxx and vmupdate run as part of the robot inventory operation.
39
Choose how NetBackup creates media IDs by defining the rules that specify which characters of a barcode on tape NetBackup uses. Alphanumeric characters can be specified to be inserted in the ID. Multiple entries can be added to the vm.conf file. For example, specify media ID generation for each robot or for each barcode format that has different numbers of characters. The multiple entries allow flexibility for multimedia. If no MEDIA_ID_BARCODE_CHARS entries exist or the entry is invalid, NetBackup uses the rightmost six characters of the barcode to create its media ID. robot_num is the robot number. barcode_length is the length of the barcode. A media_ID_rule consists of a maximum of six fields that colons delimit. Numbers in the fields define the positions of the characters in the barcode that NetBackup extracts (from left to right). For example, 2 in a field extracts the second character from the barcode. The numbers can be specified in any order. If the pound sign (#) prefixes a character, that character is inserted in that position in the generated ID. Any alphanumeric characters must be valid for a media ID. Use rules to create media IDs of many different formats. However, if the generated media ID is different from the label on the media, media management may be more difficult. The following is an example rule and the resulting generated media ID:
Barcode on the tape: 032945L1
Media ID rule: #N:2:3:4:5:6
Generated media ID: N32945
MEDIA_ID_PREFIX
MEDIA_ID_PREFIX = media_id_prefix
If this entry is specified in vm.conf, it defines the media ID prefixes to use for media without barcodes. This entry is read and interpreted on the host where vmcheckxxx and vmupdate are running as part of the robot inventory operation. The best way to add media to a robot is to use the Robot Inventory Update Volume Configuration operation.
MM_SERVER_NAME
MM_SERVER_NAME = host_name
This entry determines the name other NetBackup servers and clients should use when they refer to this server:
CLUSTER_NAME = cluster_alias
REQUIRED_INTERFACE = host_name
Use the CLUSTER_NAME entry if present in vm.conf. Use the MM_SERVER_NAME entry if present in vm.conf. Use the REQUIRED_INTERFACE entry if present in vm.conf. Use the same name that NetBackup uses. Use the gethostname() name.
This entry is read and interpreted on the host on which the required interface is needed.
PREFERRED_GROUP
NetBackup encourages the use of Symantec Product Authentication and Authorization for NetBackup Access Control (NBAC) instead of legacy security implementations. For information about the PREFERRED_GROUP configuration entry, see the NetBackup 6.0 documentation. For information on Symantec Product Authentication and Authorization, see the NetBackup Security and Encryption Guide.
PREVENT_MEDIA_REMOVAL
Applies to the TL8 robots only.
Specifying this entry changes the default operation for TL8 robots. Without this
entry present, NetBackup allows the removal of media.
If this entry is specified in vm.conf, TL8 robots execute the SCSI command
PREVENT MEDIUM REMOVAL. The robot's main door or the MAP cannot be
opened while the robotic control daemon runs.
This entry is read and interpreted on the host on which the TL8 robot control
daemon or process (tl8cd) runs.
To override PREVENT_MEDIA_REMOVAL Do one of the following:
Use the test utility and run allow media removal. Use inject or eject for access, when volumes are added or moved.
RANDOM_PORTS
RANDOM_PORTS = YES|NO
41
Use this entry to specify whether NetBackup chooses port numbers randomly or
sequentially for communication with other NetBackup servers. This entry is
read and interpreted on hosts on which vmd runs.
If YES or no entry exists (the default), NetBackup chooses port numbers
randomly from those that are available in the allowed range.
If NO, NetBackup chooses numbers sequentially. NetBackup begins with the
highest number in the allowed range, then tries the next highest, and so on until
a port is available.
If random ports are not specified in the NetBackup configuration, specify
RANDOM_PORTS = NO in the vm.conf file.
To specify no random ports in the NetBackup configuration file
Specify RANDOM_PORTS = NO in the bp.conf file on UNIX. Use the NetBackup Host Properties on Windows.
REQUIRED_INTERFACE
REQUIRED_INTERFACE = host_name
This entry and the following two entries determine the name other NetBackup servers should use when they refer to this server:
CLUSTER_NAME = cluster_alias
MM_SERVER_NAME = host_name
Use the CLUSTER_NAME entry if present in vm.conf. Use the MM_SERVER_NAME entry if present in vm.conf. Use the REQUIRED_INTERFACE entry if present in vm.conf. Use the same name that NetBackup uses. Use the gethostname() name.
This entry is read and interpreted on the host on which the required interface is needed. A NetBackup server can have more than one network interface, and by default the operating system determines the one to use. To force NetBackup to connect through a specific network interface, use REQUIRED_INTERFACE and specify the network host name of that interface.
SERVER
SERVER = host_name
SERVER entries in the vm.conf file are used for NetBackup media server
security. The SERVER entries work with the AUTHORIZATION_REQUIRED entry
to control which hosts can monitor and control devices on this host.
If the AUTHORIZATION_REQUIRED entry exists, the vm.conf file must include
a SERVER entry for every media server that controls devices on this host. If the
vm.conf file contains any SERVER entries, it also must include a SERVER entry
for itself or it cannot manage its own devices.
If no AUTHORIZATION_REQUIRED entry exists and no SERVER entries exist, any
NetBackup server can monitor and control devices on this host.
For security, the entries that allow only specific hosts to access the devices must
be added remotely.
This entry is read and interpreted on media servers on which the NetBackup
vmd service runs.
SSO_DA_REREGISTER_INTERVAL
SSO_DA_REREGISTER_INTERVAL = minutes
This configuration entry applies only to NetBackup Enterprise Server. This vm.conf entry is for the Shared Storage Option (SSO) for Tape feature only. It is read and interpreted on the host on which ltid runs. ltid on a scan host periodically registers its shared drives with EMM/DA to ensure that it is still provides the drive scanning function. Only one of the hosts that share a drive scan the drive. This reregistration allows conditions such as a device allocator restart to have minimal impact on use of shared drives. The default for the reregistration interval is 5 minutes. Use the SSO_DA_REREGISTER_INTERVAL entry to tune this interval. After the entry is added, stop and restart ltid for the change to take effect.
SSO_DA_RETRY_TIMEOUT
SSO_DA_RETRY_TIMEOUT = minutes
This configuration entry applies only to NetBackup Enterprise Server. This vm.conf entry is for the Shared Storage Option (SSO) for Tape feature only. It is read and interpreted on the host on which ltid runs. If ltid encounters problems during communications with EMM/DA or a failure while trying to reserve a shared drive, ltid delays before trying again. The default value for the delay is 3 minutes. Use the SSO_DA_RETRY_TIMEOUT entry to tune this delay period. After the entry is added, stop and restart ltid for the change to take effect.
43
SSO_HOST_NAME
SSO_HOST_NAME = host_name
This configuration entry applies only to NetBackup Enterprise Server. This vm.conf entry is for the Shared Storage Option (SSO) for Tape feature only. It is read and interpreted on the host on which ltid runs.
This entry specifies the name that the current host uses to register, reserve, and
release shared drives with EMM/DA. The default is the local host name.
TLH_mediatype
TLH_mediatype = Media_Manager_mediatype
This configuration entry applies only to NetBackup Enterprise Server. If this entry is specified in vm.conf, IBM ATL media types in Tape Library Half-inch (TLH) robots are mapped to Media Manager media types. This entry is read and interpreted on the host where vmcheckxxx and vmupdate are running as part of the robot inventory operation.
TLM_mediatype
TLM_mediatype = Media_Manager_mediatype
This configuration entry applies only to NetBackup Enterprise Server. If this entry is specified in vm.conf, DAS/SDLC media types in Tape Library Multimedia (TLM) robots are mapped to Media Manager media types. This entry is read and interpreted on the host where vmcheckxxx and vmupdate are running as part of the robot inventory operation.
VERBOSE
If this entry is specified in vm.conf, all Media Manager components on the host
are started with verbose logging enabled.
Use this option only if problems occur or if requested by Symantec support.
After the problem is resolved, remove the debug logs or add a
DAYS_TO_KEEP_LOGS entry.
By default, the buffer size for disk storage units is 256K. If the buffer size is set to a value greater than 256K, backups written to that storage unit automatically use direct I/O. An increased buffer size can improve backup speed. To increase the buffer size, the following conditions must be met:
The storage unit must be owned by a Windows media server. The storage unit must be either a Basic Disk or an Array Disk storage unit. The backup to be stored cannot be multiplexed. The touch file that disables direct I/O must not be present (install_path\VERITAS\NetBackup\bin\DISABLE_DIRECT_IO).
To increase the buffer size, create one of the following touch files on the media server that owns the storage unit:
If both touch files are present, SIZE_DATA_BUFFERS_DISK overrides the value in SIZE_DATA_BUFFERS. At this time, Symantec recommends using SIZE_DATA_BUFFERS_DISK. Possible values to include in SIZE_DATA_BUFFERS_DISK or SIZE_DATA_BUFFERS include the following: Table 1-1 Absolute byte values for SIZE_DATA_BUFFERS_DISK, SIZE_DATA_BUFFERS enter this touch file value
32768 65536 98304 131072 163840 196608 229376
45
Table 1-1
Absolute byte values for SIZE_DATA_BUFFERS_DISK, SIZE_DATA_BUFFERS enter this touch file value
262144
Data buffer sizes continue in multiples of 32. Multiply the buffer size by 1024 for the touch file value.
A direct I/O backup triggers the following message: Enabling direct I/O. Buffer size: <buffer size>.
Note: All clients configured to use dynamic addressing and host names must trust each other, similar to the NetBackup altnames feature. The following steps are required to support the configurations that use dynamic IP addressing for NetBackup. Before you make changes to a configuration, read this entire section. 1 Configure your network to use a dynamic IP addressing protocol like DHCP. NetBackup requires that IP addresses of clients have a network host name. Be sure to define network host names for the range of dynamic IP addresses in the hosts file and (or) DNS on your network.
Determine the NetBackup client names for the machines that have dynamic IP addresses and network host names. These NetBackup client names are used in step 3 and step 6. Each NetBackup client must have a unique NetBackup client name. The NetBackup client name that is assigned to a client is permanentdo not change it. Make changes on the master server: a b Create NetBackup policies with client lists that include the names from step 2. Create entries in the NetBackup client database for the client names from step 2. Create the entries by using the bpclient command.
Make changes on each dynamic NetBackup Windows client: Start the Backup, Archive, and Restore user interface on the client. Select File > NetBackup Client Properties. The NetBackup Client Properties dialog box appears. Select the General tab. Change the Client Name to the correct NetBackup client name for the machine. On the master server, enable the Announce DHCP Interval option: Open the NetBackup Administration Console and navigate to the Host Properties for clients. (Select NetBackup Management > Host Properties > Clients.) Open the client properties for the Windows client(s). Under the Windows Client host properties, select Network. Check the Announce DHCP Interval checkbox. Make changes on each dynamic NetBackup UNIX client: a b Modify the bp.conf file to include a CLIENT_NAME entry with the correct NetBackup client name for the machine. Configure the system to notify the master server of the machine's NetBackup client name and current network host name during startup. The bpdynamicclient command is used to notify the master server. Configure the system to notify periodically the master server of the machine's NetBackup client name and current network host name.
47
NetBackup requires that the IP addresses of NetBackup clients have corresponding network host names. Ensure that each IP address that could be assigned to NetBackup clients has a network host name. The host name should be defined in the host file, NIS, and DNS on your network. As an example, suppose that you have 10 dynamic IP addresses and host names available. The dynamic IP addresses and host names might be:
123.123.123.70 123.123.123.71 123.123.123.72 123.123.123.73 .
.
.
123.123.123.79 dynamic00
dynamic01
dynamic02
dynamic03
dynamic09
Assign a unique NetBackup client name to each NetBackup client that might use one of these dynamic IP addresses. The NetBackup client name that is assigned to a client is permanent and should not be changed. The client name that is assigned to NetBackup clients with dynamic IP addressing must not be the same as any network host names on your network. If the NetBackup client names are changed or are not unique, backup and restore results are unpredictable. For example, suppose you have 20 machines that share the IP addresses as previously defined. If you want these machines to be NetBackup clients, you might assign them these NetBackup client names as follows:
nbclient01
nbclient02
nbclient03
nbclient04
.
.
.
nbclient20
install_path\NetBackup\db\client
You can create, update, list, and delete client entries with the bpclient command. The bpclient command is in the following directory:
install_path\NetBackup\bin\admincmd
48 Additional configuration
Dynamic host name and IP addressing
where client_name is the NetBackup client name. The -dynamic_address 1 argument indicates that the client uses dynamic IP addressing. You can create entries with -dynamic_address 0 for static IP addressing, but that is unnecessary and adversely affects performance.
In our example, you can enter these commands to create the 20 clients:
cd install_path\NetBackup\bin\admincmd
bpclient -add -client nbclient01 -dynamic_address bpclient -add -client nbclient02 -dynamic_address bpclient -add -client nbclient03 -dynamic_address bpclient -add -client nbclient04 -dynamic_address .
.
.
bpclient -add -client nbclient20 -dynamic_address 1
1
1
1
49
The NetBackup client notifies the NetBackup server of its NetBackup client name and network host name. Then, the Current Host, Hostname, and IP Address fields display the values for that NetBackup client.
CLIENT_NAME = nbclient00
You must run the bpdynamicclient command once when the system first starts up. bpdynamicclient notifies the NetBackup server of the machine's NetBackup client name and current network host name. The bpdynamicclient command is in the directory:
/usr/openv/netbackup/bin
When bpdynamicclient starts up, it checks for the existence of file_name. If file_name exists, bpdynamicclient determines if the host name that is written in the file is the same as the current network host name. If the host names match, bpdynamicclient exits and does not connect to the master server. If the host names do not match, bpdynamicclient connects to the master server and informs the server of its NetBackup client name and host name. If bpdynamicclient successfully informs the server, bpdynamicclient writes the current network host name into file_name. If
Ensure that the dynamic client startup script is called after the machine obtains its IP address.
You must also create a root crontab entry to call periodically the
bpdynamicclient command. For example, the following entry (one line) calls
bpdynamicclient at seven minutes after each hour:
7 * * * * /usr/openv/netbackup/bin/bpdynamicclient
-last_successful_hostname
/usr/openv/netbackup/last_successful_hostname
If you use DHCP, a good interval to use between calls to bpdynamicclient is one-half of the lease period.
51
UNIX
The /usr/openv/msg/.conf file contains information on the supported locales. This file defines the date and the time formats for each supported locale. The .conf file contains very specific instructions on how to add or modify the list of supported locales and formats. However, the format of the file is summarized here. The .conf file is divided into two parts, the TL lines and the TM lines.
TL Lines
The third field of the TL lines defines the case-sensitive locales that the NetBackup applications support. The fourth and the fifth fields define the date and the time fields and associated separators for that supported locale is as follows: You can modify the existing formats to change the default output. For example, the TL line for the
C locale is:
TL 1 C :hh:mn:ss/mm/dd /yyyy
An alternate specification to the order of months, days, and years would be as follows:
TL 1 C :hh:mn:ss -yyyy-mm-dd
or:
TL 1 C :hh:mn:ss/dd /mm/yy
You can add more TL lines; see the comments in the .conf file.
If the .conf file is not accessible, the default locales (TL lines) are:
TL 1 C :hh:mn:ss /mm/dd /yyyy
TL 2 ov :hh:mn:ss/mm/dd /yyyy
Note that C and ov are synonymous.
52 Additional configuration
Specifying the locale of the NetBackup installation
Chapter
Reference topics
The topics in this chapter provide additional information about various aspects of NetBackup configuration and management:
55
Policy configuration
The configured name for a client is the host name as it is added to a policy. This name is how the client is identified in the NetBackup configuration. The server uses the clients configured name to connect to the client and start the processes that satisfy client requests. Always use qualified host names to add clients to a policy so that all NetBackup servers can connect to the clients. When a client makes a user backup, archive, or restore request to the NetBackup server, the server uses the peer name of the client. The peer name (identified from its TCP connection) is used to determine the clients configured name. If you add a client to more than one policy, always use the same name in all cases. If the same name is not used, the client cannot view all the files that are backed up on its behalf. In this case, file restores become complicated because both user- and administrator-action is required to restore from some of the backups.
Image catalog
A subdirectory in the image catalog is created for a client when a backup is first created for that client. The subdirectorys name is the clients configured name. Every backup for a client has a separate file in this subdirectory. Each of these backup records contains the host name of the server on which the backup was written.
Error catalog
NetBackup uses entries in the error catalog for generating reports. These entries contain the host name of the server that generates the entry and the clients configured name, if applicable. The server host name is normally the servers short host name. (For example, shark instead of shark.null.com.)
56 Reference topics
Rules for using host names in NetBackup
Delete the clients old name from all policies where it exists and add the clients new name to those policies. You do not need to reinstall NetBackup software on the client. The client continues to have access to all previous backups. Create a file named ALTPATH in the image catalog directory. For example, if the client name is client1, the ALTPATH file is created in the following location: Install_path\VERITAS\NetBackup\db\images\client1\
ALTPATH
Create a directory for the new client2 in the \images directory: Install_path\VERITAS\NetBackup\db\images\client2 On the first line of the client1\ALTPATH file, specify the path to the directory for the new client. The path is the only entry in the ALTPATH file. Install_path\VERITAS\NetBackup\db\images\client2
b c
On the client:
On PC clients, change the client name setting either through the user interface or in a configuration file. (See the online help in the Backup, Archive, and Restore client interface.) On UNIX clients, change the CLIENT_NAME value in the bp.conf file to the new name.
Note: If users on UNIX clients have a bp.conf file in the $HOME directory, users must change CLIENT_NAME in that file to the new name.
57
the master server Domain Name Service, the master server may not be able to
reply to client requests.
This possible situation depends on how the client and the server are configured.
If gethostname on the client returns host the names that DNS on the master
server cannot resolve, problems occur.
One possible solution is to reconfigure the client or the master server DNS hosts
file. Another option is to create a special file in the altnames directory on the
master server. The file forces the translation of NetBackup client host names.
install_path\NetBackup\db\altnames\host.xlate
Each line in the host.xlate file contains three elements: a numeric key and
two host names. Each line is left-justified, and a space character separates each
element of the line:
Where
key is a numeric value used by NetBackup to specify the cases where translation is to be done. Currently this value must always be 0, which indicates a configured name translation. hostname_from_client is the value to translate. The client name must correspond to the name that is obtained by running the clients gethostname. The value must be sent to the server in the request. client_as_known_by_server is the name to substitute for hostname_from_client for request responses. The name must match the name in the NetBackup configuration on the master server and must also be known to the master servers network services.
The line specifies that when the master server receives a request for a configured client name (numeric key 0), the name xxxx.eng.aaa.com always replaces xxxx. The substitution resolves the problem if the following conditions are true:
When gethostname is run on the client, it returns xxxx. The master servers network services gethostbyname library function did not recognize the name xxxx. The client was configured and named in the NetBackup configuration as xxxx.eng.aaa.com. And, this name is also known to network services on the master server.
Compressed backups cannot be recovered. Multiplexed backups cannot be recovered. Solaris extended attributes cannot be restored to a client. VxFS named data streams cannot be restored to a client. Backups cannot be recovered that contain raw partitions. (Includes FlashBackup images.) NDMP client backup images cannot be restored, though NDMP vendors may have tools or the utilities that may perform a restore directly from the media. Non-NetBackup versions of tar may have trouble with sparse files and often skip sparse files. HP CDFs are restored with non-NetBackup versions of tar. The directory is no longer hidden and the name of the directory has a + appended to it. If the backup spans more than one piece of media, you must read and combine the fragments from the media to give to tar. To combine the fragments, the systems dd command may be useful. Another possibility is to use tar on the fragments. To use tar on fragments may allow recovery of any file in the backup other than the one that spanned the media.
59
Some versions of the HP9000-800 /bin/tar command are known to give a directory checksum error for the second fragment of a backup that crossed media.
Some versions of Solaris tar combine the atime, mtime, and ctime strings with the file name and create the file paths that are not desirable.
Total data
The total amount of data to back up depends on the size of the files for each client included the policy. The total amount of data also depends on whether the backup is a full backup or an incremental backup.
Full backups involve all the data. Therefore, a full backup usually takes longer than an incremental backup. Differential incremental backups include only the data that has changed since the last full or incremental backup. Cumulative incremental backups include all the data that has changed since the last full backup.
For incremental backups, the amount of data depends on the frequency with which files change. If a large number of files change frequently, incremental backups are larger.
Transfer rate
The transfer rate depends on the following factors:
The speed of the backup device. Backups that are sent to tapes with a transfer rate of 800 kilobytes per second are generally faster than tapes with
60 Reference topics
Determining NetBackup transfer rate
a transfer rate of 400 kilobytes. (Assume that other factors allow for the faster transfer rate.)
The available network bandwidth. The available bandwidth is less than the theoretical network bandwidth and depends on how much other network traffic is present. For example, multiple backups occurring on the same network compete for bandwidth. The speed with which the client can process the data. The speed varies with the hardware platform and depends on the other applications that run on the platform. File size is also an important factor. Clients can process larger files faster than smaller ones. A backup for twenty files, 1 megabyte each, is faster than a backup for 20,000 files that are 1 kilobyte each. The speed with which the server can process the data. Like client speed, server speed also varies with the hardware platform and depends on the other applications that run on the platform. The number of concurrent backups being performed also affects server speed. Network configuration can affect performance. For example, when some machines run full-duplex and some run half-duplex in an Ethernet environment, the throughput is significantly reduced.
For more information, see Determining NetBackup transfer rate on page 60.
Device delays
Device delays can be due to the following factors: the device may be busy or slow to load the media. Or, the device may be slow to find the location on the media at which to start writing the backup. These delays can vary widely and depend on the devices and the computing environments.
Network transfer plus end-of-backup-processing rate on page 61 Network transfer plus end-of-backup-processing rate on page 61
The Microsoft Windows System Monitor also displays the NetBackup transfer
rate.
For more information, see Using the system monitor on page 62.
61
The network transfer rate considers only the time it takes to transfer data over the network from client to server. This rate ignores the following:
The time the device requires to load and position media before a backup. The time that the tape file requires to close and write an additional NetBackup information record to the tape.
To calculate the transfer rate, divide this time (in seconds) into the total bytes that are transferred. (The total bytes that are transferred is recorded in the All Log Entries report.)
Examples
Assume that the reports provide the following data. Sample All Log Entries Report:
TIME SERVER/CLIENT TEXT
04/28/06 23:10:37 windows giskard begin writing backup
id giskard_0767592458, fragment 1 to
media id TL8033 on device 1 . . .
04/29/06 00:35:07 windows giskard successfully wrote
backup id giskard_0767592458,
fragment 1, 1161824 Kbytes at
230.325 Kbytes/sec
Schedule Type: Backup Retention Level: Backup Time: Elapsed Time: Expiration Time: Compressed: Kilobytes: Number of Files:
Full
one week (0)
04/28/06 23:07:38
001:27:32
05/05/06 23:07:38
no
1161824
78210
The following three rates were compiled with the backup data from the sample reports: Network transfer rate: 1161824 Kbytes at 230.325 Kbytes per second Network transfer plus end-of-backup processing rate: 23:10:30 - 00:35:07 = 01:24:30 = 5070 seconds 1161824 Kbytes/5070 = 229.157 Kbytes per second Total transfer rate: Elapsed time = 01:27:32 = 5252 seconds 1161824 Kbytes/5252 = 221.216 Kbytes per second
Disk/Tape Read Bytes (GB) Disk/Tape Read Bytes/sec (KB) Disk/Tape Write Bytes (GB) Disk/Tape Write Bytes/sec (KB)
63
locks the object instances, thus, the object instances remain until the system is rebooted. To use the system monitor with NetBackup 1 2 Open the System Monitor on your Windows system. The Performance dialog box appears. Click the plus sign (+) to add a counter to the display. Select NetBackup Disk/Tape from the Performance objects drop-down list.
Note: In order for the NetBackup objects to be available for selection, the following conditions must be met: - The drive must be connected to a Windows media server (or SAN media server).
- A NetBackup job must be active (a drive is in use).
- The user must have permissions to read the Windows registry.
- Performance data collection is enabled (select Host Properties > Media Servers
> Universal Settings > Enable performance data collection).
3 Select the counter to display from the list of available counters. Available counters are:
Disk/Tape Read Bytes (GB) Disk/Tape Read Bytes/sec (KB) Disk/Tape Write Bytes (GB) Disk/Tape Write Bytes/sec (KB)
Select one or more object instances from the list of instances. Instances are displayed when NetBackup begins to read or write from the disk or the tape drives.
64 Reference topics
Determining NetBackup transfer rate
Click Add. The NetBackup counter you select is displayed in the Performance dialog box. The number of bytes that are read or written is updated dynamically, along with the rate.
65
The following topics explain how NetBackup determines the order in which automatic backups occur for each client. This information is useful to evaluate problems with schedules.
When the job ran last How often the job is scheduled to run (the frequency of the job) How soon the next scheduled window is open for the job (if the window is not currently open)
While a job waits for resources (devices) to become available, the job is
considered Queued, and appears on the Jobs tab of the Activity Monitor.
Once a job receives the resources it needs, the job becomes Active and begins.
When the job completes, NetBackup computes the next due time for the job, thus
the worklist is perpetually calculated and reordered.
The order of the jobs on the worklist is dynamic. The following items are some of
the factors that affect the job order on the worklist:
Whether the job finished successfully or whether it failed and is Waiting for Retry. (The time that NetBackup waits before it tries the job again is configurable by setting the Job retry delay Global Attribute master server property. A retried job retains the original job ID. If the job does not succeed after the number of attempts that are allowed, the job is considered Done. The status of the job indicates that the job was not successful. The number of attempts counts toward the Schedule backup attempts limit. (Found under Host Properties > Global Attributes > Schedule backup attempts.) Whether attempts to run the job exceed the number of attempts that the Schedule backup attempts host property indicates.
66 Reference topics
How NetBackup builds a worklist
Whether the job is a child job. When a parent job is Active, all of the children from that parent job have precedence over other jobs. The precedence includes the children of another parent job.
67
Both clients are overdue for a backup. However, the job of client client_2 is the most overdue and runs first. This approach ensures that a backup that was unsuccessful during its previous backup window has priority over the successful backups. The priority of the most overdue jobs is important in a busy NetBackup configuration where the backup window can close before all backups can begin.
How long you want to retain the data. All backups on a given tape or optical disk have the same retention level unless the Allow multiple retentions per media property is enabled. If not enabled, additional media is required for each different retention level. Whether duplicates for off-site storage or extra security are needed. Allow for new software releases and other special backups. Allow for the replacement of old, worn media. Consider the changes in disk usage patterns over time. If disk usage and capacity increase, backup needs may also increase. Consider the number of backups on one tape. Tape marks are created between backups. A tape with many small backups (possibly incremental backups) contains less real data when compared to a tape that contains fewer large backups. The sizes of the tape marks vary depending on the media type. A tape that contains many small files has more backup overhead because each file requires an extra 512 bytes for catalog information on the media. Media sharing may be used to help maximize tape usage. If you have many different volume pools, ensure that enough media is defined to accommodate the data.
NetBackup uses the following scripts or batch files for collecting information
and providing notification of events.
The following scripts are active on the master server:
Install_path\VERITAS\NetBackup\bin\backup_notify.cmd
Install_path\VERITAS\NetBackup\bin\backup_exit_notify.cm
d
Install_path\VERITAS\NetBackup\bin\dbbackup_notify.cmd
Install_path\VERITAS\NetBackup\bin\diskfull_notify.cmd
Install_path\VERITAS\NetBackup\bin\mail_dr_info.cmd
Install_path\VERITAS\NetBackup\bin\nbmail.cmd
Install_path\VERITAS\NetBackup\bin\restore_notify.cmd
Install_path\VERITAS\NetBackup\bin\session_notify.cmd
Install_path\VERITAS\NetBackup\bin\session_start_notify
Install_path\VERITAS\NetBackup\bin\usereq_notify.cmd
Install_path\VERITAS\NetBackup\bin\goodies\parent_end_no
tify.cmd
Install_path\VERITAS\NetBackup\bin\goodies\parent_start_
notify
Scripts that run on clients: Install_path\VERITAS\NetBackup\bin\goodies\bpstart_notif
y.bat
Install_path\VERITAS\NetBackup\bin\goodies\bpend_notify.
bat
To use the client scripts, the scripts must first be created on the client. Use the procedures as described in bpstart_notify.bat (Microsoft Windows clients only) on page 72 and bpend_notify.bat (Microsoft Windows clients only) on page 76. For further information, refer to the comments in the scripts. Caution: Applies to NetBackup Enterprise Server only. If you use either the bpstart_notify or bpend_notify scripts, do not include any commands that write to stdout. NetBackup sends the output that is written to stdout to the server as part of the backup. The resulting backup can abort with an error message that pertains to block sizes. Also, ensure that all commands in the scripts are appropriate to the client platform. For example, the -s parameter is invalid for the UNIX mail command on some UNIX platforms. Its use can cause data to be written to stdout or stderr.
69
backup_notify.cmd
The backup_notify.cmd script runs on the NetBackup server where the storage unit is located. It is called each time a backup is successfully written to media. The parameters that NetBackup passes to this script are:
The name of the program doing the backup The backup-image name or path
backup_exit_notify.cmd
The backup_exit_notify.cmd script runs on the master server. It is called to perform site-specific processing when an individual backup completes. Table 2-3 Parameter
clientname policyname schedname schedtype
backup_exit_notify parameters
Description
Name of the client from the NetBackup catalog. Policy name from the NetBackup catalog. Schedule name from the NetBackup catalog. One of the following: FULL, INCR (differential incremental), CINC (cumulative incremental), UBAK, UARC Exit code for the entire backup job.
exitstatus
For example: backup_exit_notify.cmd freddie production fulls FULL 0 backup_exit_notify.cmd Dane production incrementals INCR 73
70 Reference topics
NetBackup notify scripts
bpstart_notify parameters
Description
Name of the client from the NetBackup catalog. Policy name from the NetBackup catalog. Schedule name from the NetBackup catalog. One of the following: FULL, INCR (differential incremental), CINC (cumulative incremental), UBAK, UARC
71
Caution: The bpstart_notify script also runs for NetBackup catalog backups if a .policyname[.schedule] is not specified. For example: bpstart_notify bpstart_notify bpstart_notify bpstart_notify bpstart_notify
To create a bpstart_notify script for a specific policy or policy and schedule combination, create script files with a .policyname or .policyname.schedulename suffix. The following are two examples of script names for a policy (production) that has a schedule (fulls): /usr/openv/netbackup/bin/bpstart_notify.production
/usr/openv/netbackup/bin/bpstart_notify.production.fulls
The first script affects all scheduled backups in the policy that are named production. The second script affects scheduled backups in the policy that is named production only when the schedule is named fulls. Note: For a given backup, NetBackup uses only one bpstart_notify script and that is the script with the most specific name. For example, if there are both bpstart_notify.production and bpstart_notify.production.fulls scripts, NetBackup uses only bpstart_notify.production.fulls. The bpstart_notify script can use the following environment variables: BACKUPID UNIXBACKUPTIME BACKUPTIME The NetBackup bpbkar process creates these variables. The following are examples of the strings that are available to the script to use to record information about a backup: BACKUPID=freddie_0857340526
UNIXBACKUPTIME=0857340526
BACKUPTIME=Sun Mar 2 16:08:46 2006
In addition, the following environment variables can be used to support multiple data streams: STREAM_NUMBER indicates the stream number. The first stream from a policy, client, and schedule is 1. A 0 value indicates that multiple data streams is not enabled.
STREAM_COUNT specifies the total number of streams to be generated from this policy, client, and schedule. STREAM_PID is the pid (process ID) number of bpbkar. RESTARTED can be used for checkpointed restarts or checkpointed backup jobs. A value of 0 indicates that the job was not resumed. (For example, upon first initiation.) A value of 1 indicates that the job was resumed.
Caution: The bpstart_notify script also runs for NetBackup catalog backups if a .policyname[.schedule] is not specified. The first script affects all scheduled backups in the policy named days. The second script affects scheduled backups in the policy named days only when the schedule is named fulls. For a given backup, NetBackup calls only one bpstart_notify script and checks for them in the following order: bpstart_notify.policy.schedule.bat
bpstart_notify.policy.bat
73
bpstart_notify.bat For example, if there are both bpstart_notify.policy.bat and bpstart_notify.policy.schedule.bat scripts, NetBackup uses only the bpstart_notify.policy.schedule.bat script. Note: bpend_notify scripts can provide a different level of notification than the bpstart_notify scripts. For example, to use one of each, the script names might be bpstart_notify.policy.bat and bpend_notify.policy.schedule.bat. When the backup starts, NetBackup passes the following parameters to the script. Table 2-5 Parameter
%1 %2 %3 %4 %5 %6
bpstart_notify.bat parameters
Description
Name of the client from the NetBackup catalog. Policy name from the NetBackup catalog. Schedule name from the NetBackup catalog. One of the following: FULL, INCR, CINC, UBAK, UARC Status of the operation is always 0 for bpstart_notify. Results file that NetBackup checks for a return code from the script. NetBackup uses %6 to pass the file name and then expects the script to create the file in the same directory as the script. If the script applies to a specific policy and schedule, the results file must be named
install_path\netbackup\bin\BPSTART_RES.policy.schedule
If the script applies to a specific policy, the results file must be named
install_path\netbackup\bin\BPSTART_RES.policy
If the script applies to all backups, the results file must be named
install_path\netbackup\bin\BPSTART_RES
An echo 0> %6 statement is one way for the script to create the file. NetBackup deletes the existing results file before it calls the script. After the script runs, NetBackup checks the new results file for the status. The status must be 0 for the script to be considered successful. If the results file does not exist, NetBackup assumes that the script was successful.
The server expects the client to respond with a continue message within the time that the NetBackup BPSTART_TIMEOUT option specifies. The default for
BPSTART_TIMEOUT is 300. If the script needs more than 300 seconds, increase
the value to allow more time.
For Windows 2000 clients, the bpstart_notify script can use the following
environment variables for the support of multiple data streams:
STREAM_NUMBER indicates the stream number. The first stream from a policy,
client, and schedule is 1. A 0 value indicates that multiple data streams is not
enabled.
STREAM_COUNT specifies the total number of streams to be generated from this
policy, client, and schedule.
STREAM_PID is the pid (process ID) number of bpbkar.
Note: Ensure that this script can be run by other on the client before it is used. To do so, run chmod 755 script_name, where script_name is the name of the script. To receive a notification whenever a UNIX client completes a backup or an archive operation, copy the following file from the server: Install_path\VERITAS\NetBackup\bin\goodies\bpend_notify
And place it to the following location on the UNIX client: /usr/openv/netbackup/bin/bpend_notify
Modify the script and ensure that you have permission to run the script.
The bpend_notify script runs each time a backup or archive completes. For
archives, it runs after the backup but before the files are removed.
If bpend_notify exists, it runs in the foreground and bpbkar on the client
waits until it completes. Any commands that do not end with an & character run
serially.
The server expects the client to respond within the time that the
BPEND_TIMEOUT NetBackup configuration option specifies. The default for
BPEND_TIMEOUT is 300.
If the script needs more than 300 seconds, set BPEND_TIMEOUT to a larger
value. Avoid too large a value because it can delay the server from servicing
other clients.
NetBackup passes the following parameters to the bpend_notify script.
75
exitstatus
Caution: The bpend_notify script also runs for NetBackup catalog backups if a .policyname[.schedule] is not specified. For example: bpend_notify freddie pol_1 fulls FULL 0
bpend_notify danr pol_1 incrementals INCR 73 To create a bpend_notify script for a specific policy or policy and schedule combination, create script files with a .policyname or .policyname.schedulename suffix. The following are two examples of script names for a policy that is named production with a schedule that is named fulls: /usr/openv/netbackup/bin/bpend_notify.production
/usr/openv/netbackup/bin/bpend_notify.production.fulls
The first script affects all scheduled backups in the policy production. The second script affects scheduled backups in the policy production only when the schedule is named fulls. Note: For a given backup, NetBackup uses only one bpend_notify script and that is the one with the most specific name. For example, if there are both bpend_notify.production and bpend_notify.production.fulls scripts, NetBackup uses only bpend_notify.production.fulls. If the UNIX client is running NetBackup 3.0 or later software, the bpend_notify script can use the following environment variables: BACKUPID UNIXBACKUPTIME
BACKUPTIME The NetBackup bpbkar process creates these variables. The following are examples of the strings that are available to the script for use to record information about a backup: BACKUPID=freddie_0857340526
UNIXBACKUPTIME=0857340526
BACKUPTIME=Sun Mar 2 16:08:46 2005
The following environment variables can be used for the support of multiple
data streams:
STREAM_NUMBER indicates the stream number. The first stream from a policy,
client, and schedule is 1. A 0 value indicates that multiple data streams is not
enabled.
STREAM_COUNT specifies the total number of streams to be generated from this
policy, client, and schedule.
STREAM_PID is the pid (process ID) number of bpbkar.
FINISHED can be used for checkpointed restarts of backup jobs. A value of 0
indicates that the client was not finished sending all of the data. A value of 1
indicates that the client was finished sending all the of data.
77
Caution: The bpend_notify script also runs for NetBackup catalog backups if a .policyname[.schedule] is not specified. The first script affects all scheduled backups in the policy named days. The second script affects scheduled backups in the policy named days only when the schedule is named fulls. For a given backup, NetBackup calls only one bpend_notify script and checks for them in the following order: bpend_notify.policy.schedule.bat
bpend_notify.policy.bat
bpend_notify.bat
For example, if there are both bpend_notify.policy.bat and bpend_notify.policy.schedule.bat scripts, NetBackup uses only bpend_notify.policy.schedule.bat. Note: bpstart_notify scripts can provide a different level of notification than the bpend_notify scripts. For example, if you had one of each, they could be bpstart_notify.policy.bat and bpend_notify.policy.schedule.bat. When the backup completes, NetBackup passes the following parameters to the script. Table 2-7 Parameter
%1 %2 %3 %4 %5
bpend_notify parameters
Description
Name of the client from the NetBackup catalog. Policy name from the NetBackup catalog. Schedule name from the NetBackup catalog. One of the following: FULL, INCR, CINC, UBAK, UARC Status of the operation. It is the same as sent to the NetBackup server. The status is 0 for successful backups and 1 for partially successful backups. If an error occurs, the status is the value associated with that error.
Parameter
%6
Description
Results file that NetBackup checks for a return code from the script. NetBackup uses %6 to pass the file name and then expects the script to create the file in the same directory as the script. If the script applies to a specific policy and schedule, the results file must be named Install_path\netbackup\bin\BPEND_RES.policy.schedule If the script applies to a specific policy, the results file must be named Install_path\netbackup\bin\BPEND_RES.policy If the script applies to all backups, the results file must be named Install_path\netbackup\bin\BPEND_RES An echo 0> %6 statement is one way for the script to create the file. NetBackup deletes the existing results file before it calls the script. After the script runs, NetBackup checks the new results file for the status. The status must be 0 for the script to be considered successful. If the results file does not exist, NetBackup assumes that the script was successful.
The server expects the client to respond with a continue message within the time that the BPEND_TIMEOUT option specifies. The default for BPEND_TIMEOUT is 300. If the script needs more than 300 seconds, increase the value to allow more time. For Windows 2000 clients, the bpend_notify script can use the following environment variables for the support of multiple data streams: STREAM_NUMBER indicates the stream number. The first stream from a policy, client, and schedule is 1. A 0 value indicates that multiple data streams is not enabled. STREAM_COUNT specifies the total number of streams to be generated from this policy, client, and schedule. STREAM_PID is the pid (process ID) number of bpbkar.
dbbackup_notify.cmd
NetBackup calls the dbbackup_notify.cmd script each time NetBackup completes an offline, cold catalog backup. The script runs on the server that receives the data for the offline catalog backup. NetBackup passes the following parameters to this script: Table 2-8 Parameter
device
79
Parameter
vsn_or_path status
Description
Volume serial number (for tape) or path (for disk) used for the backup. Specifies whether the backup was successful and must have a value of either SUCCESS or FAIL.
diskfull_notify.cmd
The diskfull_notify.cmd script runs on the NetBackup server that contains the storage unit. The disk media manager (bpdm) calls this script if it encounters a disk full condition while it writes a backup to a disk storage unit. The default action is to report the condition and immediately try to write the data again. (The file being written is kept open by the active bpdm). The script can be modified to send a notification to an email address. Or modified to perform actions such as removing other files in the affected directory or file system. NetBackup passes the following parameters to this script. Table 2-9 Parameter
programname pathname
For example:
80 Reference topics
NetBackup notify scripts
diskfull_notify.cmd bpdm
/disk1/images/host_08193531_c1_F1
Note
In previous releases, the diskfull_notify.cmd script default condition was to sleep for five minutes when a disk storage unit became full. To retain this behavior upon upgrade, either:
Copy the netbackup/bin/diskfull_notify.old_revision_number script to netbackup/bin/diskfull_notify, or Modify the script, to change sleep 0 to: sleep 300
mail_dr_info.cmd
Use mail_dr_info.cmd to send NetBackup disaster recovery information to
specified recipients after running an online, hot catalog backup.
To create the script, copy the following script from the master server:
Install_path\VERITAS\NetBackup\bin\nbmail.cmd
Install_path\NetBackup\bin\mail_dr_info.cmd.
NetBackup checks to see if mail_dr_info.cmd is present in Install_path\NetBackup\bin. If mail_dr_info.cmd exists, NetBackup passes the parameters to the script. Note: All NetBackup email notifications require that a public domain SMTP mail client be configured. (For example, blat.) For details, see the comments in the nbmail.cmd script.
81
nbmail.cmd
Use nbmail.cmd to send specified recipients notifications about scheduled backups. The recipients email addresses must also be configured in the host properties. For more information, see Universal Settings properties on page 480. Windows systems also require that an application to transfer messages using the Simple Mail Transfer Protocol be installed in order to accept script parameters. UNIX platforms have a built-in SMTP transfer method. To create the script on a client, copy Install_path\VERITAS\NetBackup\bin\nbmail.cmd from the master server into Install_path\NetBackup\bin of each client that is to receive the notification. Update the script using the following script parameters. Table 2-11 Parameter
%1
%2 %3
%4
NetBackup checks to see if nbmail.cmd exists is present in Install_path\NetBackup\bin. If nbmail.cmd exists, NetBackup passes the parameters to the script.
parent_end_notify.cmd
NetBackup calls the parent_end_notify.cmd script each time a parent job
ends.
Update the script using the following parameters.
Table 2-12 Parameter
clientname policyname
Parameter
schedname schedtype
Description
Schedule name from the NetBackup catalog. One of the following: FULL, INCR (differential incremental), CINC (cumulative incremental), UBAK, UARC Exit code for the entire backup job. The stream number for a parent job is always -1.
status streamnumber
parent_start_notify.cmd
NetBackup calls the parent_start_notify.cmd script each time a parent job
starts.
Update the script using the following parameters.
Table 2-13 Parameter
clientname policyname schedname schedtype
status streamnumber
restore_notify.cmd
Note: Applies to NetBackup Enterprise Server only. If the files are restored to a UNIX disk storage unit that Storage Migrator manages, the restore_notify script notifies Storage Migrator to perform migration as quickly as possible after the restore is complete. The restore_notify.cmd script runs on the server that contains the storage unit. The NetBackup tape or disk manager (bptm or bpdm) calls the script when it is finished sending data to the client during a restore. The script is called regardless of whether data is sent. NetBackup passes the following parameters to this script:
83
session_notify.cmd
The session_notify.cmd script runs on the master server. It is called at the end of a backup session if at least one scheduled backup has succeeded. NetBackup passes no parameters to this script. Scheduling is suspended until this script completes, so no other backups can start until that time.
session_start_notify.cmd
The session_start_notify.cmd script runs on the master server. When a set of backups is due to run, NetBackup calls this script to do any site-specific processing before it starts the first backup. NetBackup passes no parameters to this script.
userreq_notify.cmd
The userreq_notify.cmd script runs on the master server. NetBackup calls it each time a request is made to:
List files that are in backups or archives Start a backup, archive, or restore
You can alter this script to gather information about user requests to NetBackup. NetBackup passes the following parameters to this script. Table 2-15 Parameter
action
clientname
Parameter
userid
Description
Defines the user ID.
General practices
The following are general best practices for media and device management:
Use only Symentec documented and Symentec supported options for NetBackup commands. Refer to the NetBackup release notes to see if the methods you use are eliminated in the current release or eliminated in future releases. The release notes also contain information about all new functionality in each release. Use the documented methods for terminating the NetBackup Media Manager daemons and services. Periodically verify your backups using NetBackup Management > Catalog in the NetBackup Administration Console. Also, periodically restore files to prove that restores work correctly. Always back up the NetBackup catalogs. You may also want to back up the vm.conf and bp.conf (UNIX system) files on your media servers. Those files contain configuration settings. When you restore the NetBackup catalog (for example, master server databases and the EMM database), use backups from the same point in time.
85
Ensure that all names and numbers for devices and all media IDs and barcodes are unique across the entire enterprise. To use devices with other applications and NetBackup controls those devices, you must down the drive if the drive is in the UP state.
Media management
The following are media management best practices:
Use the robot inventory update operation for media management. Use a scratch pool for unassigned media. Configure cleaning cartridges for your tape drives, and use TapeAlert for automatic drive cleaning if the drives support automatic cleaning. Replace old media according to the life-span recommendations of the manufacturer. Replace old cleaning media also. Use robotic libraries that have a barcode reader and use only barcode labels that the robot vendor recommends. Use barcode rules for media type assignment when you inventory multimedia libraries. Use barcode naming conventions to differentiate between data and cleaning tapes and different physical media types. A common convention is a prefix that identifies the type of media. Before performing inject or eject commands, ensure that the media access port is empty. Although NetBackup can handle a port that is not empty, some libraries may have problems.
Device management
The following are device management best practices:
Monitor the NetBackup system log for device errors encountered. Monitor devices by using the NetBackup Device Monitor. Investigate the causes of all drives that are down. Do not use the robotic test utilities while running backup or restore jobs. Read the NetBackup Device Configuration Guide before configuring devices on media servers (or SAN media servers). Use only robots, tape drives and tape drivers, and server platforms and hardware that are tested and supported by Symatec. For supported devices, see the NetBackup hardware compatibility list on the NetBackup support site.
Use only fully-serialized devices. A fully-serialized SCSI library should report a serial number for the robot and also a serial number for each drive in the robot. Always configure and use pass-through paths for robotic libraries and drives. When possible, use SCSI reserve. Use persistent bindings for fibre-attached devices. Use the NetBackup Device Configuration wizard to configure your devices. Download and install the latest device mapping file from the NetBackup support web site before you use the Device Configuration wizard. Use consistent logical drive types for all physical drive types on all servers in your environment. For example, use dlt as the logical drive type for all DLT7000 drives. Do not load vendor medium-changer drivers on Microsoft Windows hosts. The default Microsoft medium-changer driver is acceptable (but is not required) for use with NetBackup.
Use the performance-tuning documents available on the NetBackup support Web page. Use only a dedicated server for the NetBackup master server and Enterprise Media Manager (EMM) server. Do not use a server that hosts other applications or stores data. Plan periodic maintenance periods for all of your backup servers. Consult the Troubleshooter in the NetBackup Administration Console or the NetBackup Troubleshooting Guide for all error conditions. Always install the latest NetBackup release updates that are available from Symantec. Verify all SCSI-related operating system configuration files (for example, the Solaris st.conf file), when you install operating system release updates. For problems with devices, consult the vendor for firmware upgrades and consult the NetBackup hardware compatibility list for supported firmware levels. Do not use the NetBackup DISABLE_RESOURCES_BUSY touch file. Do not disable the operating system TCP_NODELAY functionality.
87
See the NetBackup Shared Storage Guide before you install and configure the NetBackup Shared Storage Option, OpenStorage, or SharedDisk.
Using TapeAlert
TapeAlert is a tape drive status monitor and message utility. The TapeAlert utility can detect tape quality problems, defects in tape drive hardware, and the need to clean drives. For the tape drives that support TapeAlert, the TapeAlert firmware monitors the drive hardware and the media. Error, warning, and informational states are logged on a TapeAlert log page. NetBackup writes TapeAlert conditions into:
The bptm log The error log The job details log The system log on UNIX and Event Viewer on Windows
For more information, also see Reactive cleaning (TapeAlert) on page 91.
The drive must support the TapeAlert capability, and the TapeAlert must be enabled on the drive. To determine if a drive supports TapeAlert, see the Symantec support site. To clean drives using TapeAlert, a cleaning tape is configured and available in NetBackup for the robotic library. The cleaning tape has not reached its end of life. Passthru device files must be configured on UNIX media servers. For more information, see the NetBackup Device Configuration Guide.
Recoverable read and write drive problems Unrecoverable read and write drive problems Hardware defects
88 Reference topics
Using TapeAlert
A set of TapeAlert conditions are defined that can cause the media in use to be frozen. An additional set of conditions are defined that can cause a drive to be downed. Table 2-16 on page 88 describes the TapeAlert codes.. Table 2-16 TapeAlert log codes Error type
Warning - WRN Warning - WRN Warning - WRN Critical - CRT Critical - CRT Critical - CRT Warning - WRN Warning - WRN Critical - CRT Informational INFO Informational INFO Informational INFO Critical - CRT
Error message
READ WARNING WRITE WARNING HARD ERROR MEDIA READ FAILURE WRITE FAILURE MEDIA LIFE NOT DATA GRADE WRITE PROTECT NO REMOVAL
0x0b
None
CLEANING MEDIA
0x0c
None
UNSUPPORTED FORMAT REC. MECH. CARTRIDGE FAILURE UNREC. MECH. CARTRIDGE FAILURE MIC FAILURE FORCED EJECT READ ONLY DIRECTORY CORRUPTED ON LOAD
0x0d
0x0e
Critical - CRT
89
Table 2-16
Error message
NEARING MEDIA LIFE
CLEAN NOW CLEAN PERIODIC EXPIRED CLEANING MEDIA INVALID CLEANING TAPE RETENSION REQUESTED DUAL-PORT ERROR COOLING FAN FAILURE POWER SUPPLY FAILURE POWER CONSUMPTION DRIVE MAINTENANCE HARDWARE A HARDWARE B INTERFACE EJECT MEDIA DOWNLOAD FAIL DRIVE HUMIDITY DRIVE TEMPERATURE DRIVE VOLTAGE PREDICTIVE FAILURE DIAGNOSTICS REQ. UNDEFINED
0x17
Critical - CRT
0x18
None
Warning - WRN
0x19 0x1a
None None
0x1b
None
Warning - WRN
0x1c
None
Warning - WRN
0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 - 0x31
None Down drive - DOWN Down drive - DOWN None None None None None None None None None
Warning - WRN Critical - CRT Critical - CRT Warning - WRN Critical - CRT Warning - WRN Warning - WRN Warning - WRN Warning - WRN Critical - CRT Warning - WRN Informational INFO
90 Reference topics
Drive cleaning overview
Table 2-16
Error message
LOST STATISTICS DIRECTORY INVALID ON UNLOAD SYSTEM AREA WRITE FAILURE SYSTEM AREA READ FAILURE NO START OF DATA LOADING FAILURE UNREC. UNLOAD FAILURE AUTOMATION INTERFACE FAILURE FIRMWARE FAILURE WORM MEDIUM INTEGRITY CHECK FAILED WORM MEDIUM OVERWRITE ATTEMPTED UNDEFINED
0x34
Critical - CRT
0x35
Critical - CRT
0x39
None
Critical - CRT
0x3a 0x3b
0x3c
Warning - WRN
0x3d - 0x40
None
Informational INFO
Reactive cleaning Symantec recommends that you use reactive cleaning. Library-based cleaning Frequency-based cleaning Operator-initiated cleaning
91
TapeAlert cleaning
A drive with TapeAlert capability tracks how many read and write errors it has encountered within a certain time period. Although a drive can recover from these errors, the drives sets a CLEAN_NOW or CLEAN_PERIODIC flag when a threshold is reached. If bptm detects that either of these flags is set, it performs a cleaning at one of the following times:
At the end of a backup or a restore to the drive. Before the next backup or restore to the drive.
Library-based cleaning
NetBackup does not support library-based cleaning (also known as robotic cleaning or auto cleaning) for most robots because robotic library and operating systems vendors have implemented this cleaning in different ways. These different methods often interfere with NetBackup robotic control operations.
92 Reference topics
Drive cleaning overview
NetBackup does not define cleaning media that is used for library-based cleaning, and the robotic library manages the cleaning media. Because TapeAlert provides the same type of cleaning as library-based cleaning, Symantec recommends that you disable library-based cleaning when using TapeAlert.
Frequency-based cleaning
Frequency-based cleaning occurs when the accumulated mount time exceeds the time you specify for the cleaning frequency. NetBackup updates the mount time for the drive each time a tape is unmounted. The cleaning frequency is configured when you add a drive to NetBackup. You can also change the cleaning frequency by changing the drive properties or by using the Media and Device Management Device Monitor. If the following conditions are met, drive cleaning occurs when the accumulated mount time exceeds the time you specified for cleaning frequency:
The drive is in a robotic library that supports drive cleaning. A cleaning tape is configured and available for the robotic library. The cleaning tape has cleanings that remain.
NetBackup cleans the drive immediately after a tape is unmounted. Drive cleaning never causes an unmount in the middle of an active backup. The mount time is reset after the drive is cleaned. The cleaning frequency value remains the same. A cleaning can occur within a backup if the backup spans tapes. For example, if cleaning is due after the first tape is full, NetBackup cleans the drive before it mounts the next tape.
Media can remain in a drive for extended periods. It does not affect cleaning
frequency because NetBackup increments the mount time only when NetBackup
assignes the media to a process.
93
Operator-initiated cleaning
You can initiate a drive cleaning regardless of the cleaning frequency or accumulated mount time of the drive. You can clean stand-alone drives or robotic drives if a cleaning tape of the correct media type and residence for the drive was added to NetBackup. NetBackup reports that a drive needs cleaning if either of the following conditions are true:
The value for the mount time is greater than the cleaning frequency. The TapeAlert CLEAN_NOW or CLEAN_PERIODIC flag is set. The drive is a stand-alone drive and a cleaning tape is not defined. The drive is a stand-alone drive and no cleaning tape has any cleanings that remain. The Tape Cleaning Comment column of the Drive List in the Devices node of the NetBackup Administration Console. The comment field of the output from the tpclean -L command.
94 Reference topics
Volume pool and volume group overview
Volume pools
The volume pool concept is relevant only for NetBackup storage units and does not apply to disk storage units. Volumes pools protect volumes from access by unauthorized applications. You can create volume pools for applications or other reasons, and as you add volumes, associate them with the appropriate pool. You can also move unassigned volumes to a different pool. With the exception of the CatalogBackup, NetBackup, and DataStore volume pools, you must create a volume pool before you can add volumes to it. By default, NetBackup creates volume pools named None, NetBackup, CatalogBackup, and DataStore.
Volume groups
Volume groups show the location of a volume, such as the robot in which it resides. If you move a volume physically, you also must move it logically (a logical move means to change the volume attributes to show the new location). Volume groups are convenient for tracking the location of volumes, such as the case when a volume is moved off-site. Volume groups let you perform operations on a set of volumes by specifying the group name rather than each individual media ID of each volume. Operations include moves between a robotic library and a stand-alone location or deletetions from NetBackup.
All volumes in a group must be the same media type. However, a media type and its corresponding cleaning media type are allowed in the same volume group (such as DLT and DLT_CLN). All volumes in a robotic library must belong to a volume group. You cannot add volumes to a robotic library without specifying a group or having Media Manager generate a name for the group. The only way to clear a volume group name is to move the volume to stand-alone and not specify a volume group.
95
More than one volume group can share the same location. For example, a robotic library can contain volumes from more than one volume group and you can have more than one stand-alone volume group. All volumes in a group must be in the same robotic library or be stand-alone. That is, you cannot add a group (or part of a group) to a robotic library if it already exists in another robotic library.
Standalone Robotic
Group 1 Group 2
NB_pool
Off-site 1
Group 3
Group 4 Off-site 2
In Figure 2-4 on page 96, members of the same volume pools are in different volume groups. Note that the data is stored on separate volumes by assigning different volume pools. The volumes in a pool can be in more than one physical location and in more than one volume group. In this example, the volumes in the pool NB_pool_dept_1 are spread among the rob_A, standalone1, and off-site volume groups. These groups also have volumes from more than one pool (though the volumes in each group must all be the same type).
NB_pool _dept_1
NB_pool _dept_2
Robot B
Group rob_B
NB_pool _dept_3
You also can configure a scratch pool from which NetBackup can transfer volumes when a volume pool has no media available. For more information, see Scratch volume pools on page 96.
NetBackup requires a DLT volume, so Media Manager attempts to assign one from NB_pool_dept_1 in Robot C. Robot C has no unassigned volumes available in the NB_pool_dept_1 pool.
97
NetBackup searches the scratch pool for an unassigned DLT volume in Robot C. If a volume is available, NetBackup moves it to NB_pool_dept_1. Otherwise, NetBackup logs a media unavailable status. Scratch pool example
Robot C - DLT
Group rob_C NB_pool_dept_1
Figure 2-5
Robot A - TL8 Group
rob_A
NB_pool_dept_2
If the scratch pool contains assigned volumes, these volumes remain in the scratch pool. Media Manager does not move assigned volumes to other pools as it does with unassigned volumes. NetBackup does not assign volumes while they are in a scratch pool. For example if a NetBackup policy or schedule specifies the scratch pool, all requests for those volumes are denied. Media Manager returns expired media to the scratch volume pool automatically (media that is returned must have been originally in the same scratch pool).
98 Reference topics
Barcode overview
To have Media Manager manage the allocation of your volumes to your volume pools, do the following: a b Create volume pools as required, but do not add any volumes to the pools. Define a scratch pool and add all of your volumes to it. NetBackup moves volumes to the other pools as they are needed.
Barcode overview
When a robotic library has a barcode reader, it scans the media for barcodes and saves the results. The results associate the slot number and the barcode with the media in that slot. NetBackup obtains barcode and slot information from the robotic library.
Barcode advantages
NetBackup functions well whether or not barcodes are used. However, Symantec suggests that you use media with barcodes in the robots that can read barcodes. Barcodes offer the following advantages:
Automatic media ID assignment. When you add new media to a robot, NetBackup is able to assign media IDs according to the criteria that you specify. More accurate tracking of volume location. A robot inventory update can determine which volumes are in a robot. Increased performance. Not using barcodes can adversely affect performance for some robots. A robot that reads barcodes performs a scan each time it moves a tape. The robot stores the correct barcode in memory or verifies a previously saved barcode. However, if a tape does not have a barcode, the robot retries the scan multiple times, degrading performance.
Barcodes usually appear on the labels that you attach to the outside of tape volumes. Barcodes are not generally used on optical disks, and NetBackup does not support barcodes for optical disk libraries (ODL robots). The maximum barcode length that NetBackup supports depends on the type of robot.
99
When you purchase barcode labels for use with NetBackup, always follow the robotic library vendors recommendations. Ensure that the barcodes have the correct number of characters. Barcodes can represent any combination of alpha and numeric characters, but different robots support different lengths of barcodes. See the robot vendors documentation to determine the requirements for a specific robot type. Use barcodes without spaces (at the beginning, at the end, or between any characters). Otherwise, the robot or NetBackup may not read them correctly. Volumes in an API robot have a real or a logical barcode. This volume identifier is used as the NetBackup media ID. This volume identifier is the volume serial number in ACS, TLH, and TLM robots. For API robots, the barcode for a volume must be identical to the NetBackup media ID. You can match barcodes to media IDs by getting custom labels in the same series as your media IDs. For example, to match a set of media IDs from AA0000 to ZZ9999, get barcode labels in that series. When a robotic library can contain more than one media type, you should assign specific characters in the barcode to different media types using media ID generation rules. Also, you should use barcodes to differentiate between data tapes and cleaning tapes or to differentiate between volume pools.
Barcode rules
A barcode rule specifies criteria for assigning attributes to new robotic volumes. NetBackup assigns these attributes using the barcode for the volume that the robotic library provides and your barcode rules. In NetBackup, you choose whether to use barcode rules when you set up the robot inventory update operation. The barcode rules are stored on the EMM server .
NetBackup searches the list of rules (from first to last) for a rule that matches the new barcode. If a rule matches the barcode tag, NetBackup verifies that the media type in the rule is compatible with the media type you specified for the update.
If the media types match, NetBackup assigns the attributes in the rule to the volume. The attributes include the media type, volume pool, maximum number of mounts (or number of cleanings), and description.
Note: NetBackup does not use barcode rules if a volume already uses a barcode.
Checking barcodes
In the robots that have barcode readers, NetBackup verifies the barcode to ensure that the robot loads the correct volume. If the barcode on the volume does not match the barcode in the EMM database, NetBackup:
May assign the request a pending status (for media-specific jobs such as a restore) May use another volume (for backup or duplicate jobs) May fail the job (cold catalog backup jobs)
Check the Device Monitor to find a suitable drive and mount the requested volume in that drive. Move the volume into the robot, update the volume configuration to reflect the correct location for the media, and resubmit the request.
If the volume is labeled (tape or optical platter), the automatic volume recognition daemon reads the label and the drive is assigned to the request. If the volume is unlabeled and not associated with a robot, the operator manually assigns the drive to the request.
Volume pool
b_pool d_pool
Description
new 008 volumes dlt backup
101
Volume pool
None None t_pool None None NetBackup
Description
dlt cleaning 8-mm cleaning 8-mm backup 8-mm no pool no barcode other barcodes
Refer to the previous table for example barcode rules for the following
examples. Assume that you select the following media settings (update options)
for the update operation for a new 8-mm volume in a TL8 robot:
Media Type = 8MM
Volume Group = 00_000_TL8
Use Barcode Rules = YES
Volume Pool = DEFAULT
If a new volume in this robotic library has a barcode of TL800001, NetBackup
uses the rule with the barcode tag of TL8 and assigns the following attributes for
the volume:
Media ID = 800001 (last six characters of barcode)
Volume Group = 00_000_TL8
Volume Pool = t_pool
Max Mounts = 0 (no maximum)
If a new volume has a barcode of TL000001, NetBackup uses the rule with the
barcode tag of TL and assigns the following attributes for the volume:
Media ID = 000001 (last six characters of barcode)
Volume Group = 00_000_TL8
Volume Pool = None
Max Mounts = 0 (no maximum)
Replacing devices
If you replace an existing device in your configuration, the serial number of the new device is different than the old device. NetBackup recognizes the change and updates the EMM database without restarting ltid. NetBackup also
103
recognizes device firmware upgrades. For devices on NetBackup 5.x hosts, you must restart ltid before NetBackup recognizes the new device. In upgrades from NetBackup environments earlier than 6.0, devices retain their serial numbers. In NetBackup 6.0 and later, a change to a serial number formatting algorithm may affect a small number of tape drives and robotic libraries. Those devices may be configured as unserialized or configured with a different serial number. Therefore, NetBackup integrity checks that query the device serial number and compare it with the serial number in the database may fail. If so, a device may be unusable (such as the tape drive may be downed). Integrity checks occur when ltid performs automatic path correction or when the run-time Plug-n-Play code (Windows only) performs serial number checks. In such cases:
Update the serial number or reconfigure the device so that the new serial number to be stored in the EMM database. For procedures, see
To swap a serialized drive or to update drive firmware on a single host on page 103 For a shared drive, To swap a shared serialized drive or to update drive firmware on a shared drive on page 104
Disable runtime serial number checks by using the AUTO_PATH_CORRECTION vm.conf option.
To swap a serialized drive or to update drive firmware on a single host 1 Down the drive. In the Device Monitor, select the drive to swap or update. From the Actions menu, select Down Drive. Alternatively, down the drive using the vmoprcmd command with the -downbyname drive_name option. Replace the drive or physically update the firmware for the drive. If you replace the drive, specify the same SCSI ID for the new drive as the old drive. Up the drive. In the Device Monitor, select the new drive. From the Actions menu, select Up Drive. If you replace a drive with a drive of a different type or replace a serialized drive with an unserialized drive, configure the new drive by using the NetBackup Device Configuration wizard. The drive must first be recognized by the operating system of each server. Device configuration may require remapping, rediscovery, and possibly a reboot of the operating system. For more information, see the NetBackup Device Configuration Guide.
2 3
To swap a shared serialized drive or to update drive firmware on a shared drive 1 2 3 Down the drive. In the Device Monitor, select the drive to swap or update. From the Actions menu, select Down Drive. Replace the drive or physically update the firmware for the drive. If you replace the drive, specify the same SCSI ID for the new drive as the old drive. To produce a list of new and missing hardware, run tpautoconf -report_disc on one of the reconfigured servers. This command scans for new hardware and produce a report that shows the new and the replaced hardware. Ensure that all servers that share the new hardware are up and that all NetBackup services are active. Run tpautoconf with the -replace_drive drive_name -path path_name options or -replace_robot robot_number -path robot_path options. The tpautoconf command reads the serial number from the new hardware device and then updates the EMM database. If the new device is an unserialized drive, run the device configuration wizard on all servers that share the drive. If the new device is a robot, run the device configuration wizard on the server that is the robot control host. Up the drive. In the Device Monitor, select the new drive. From the Actions menu, select Up Drive.
4 5
105
server, you must import the media. Importing media consumes more time than performing the following procedure. To decommission a media server 1 Run the bpmedialist command to determine which tapes on the old_server contain NetBackup images that have not expired. The -l option produces one line of output per tape.
bpmedialist -mlist -l -h old_server
Select another server or the master server (new_server) to manage the tapes from the old_server. Run the bpmedia command for each tape that has active images as identified in step 1. The command replaces the old_server with the new_server in the EMM database and updates the images database on the master server.
bpmedia -movedb -ev media_ID -oldserver old_server -newserver new_server
Add the following command to the end of the bp.conf file on the master server. The command allows restores from the media that are associated with the old_server to occur from a new_server.
FORCE_RESTORE_MEDIA_SERVER = old_server new_server
Use the NetBackup Administration Console to move the tapes that are in the robots that are attached to the old_server to non-robotic status (stand-alone). Select each robot that is attached to the old_server, highlight all of the tapes, and move them to stand-alone. Use the NetBackup Administration Console to delete the drives and then the robots from the old_server. Use the NetBackup Administration Console to delete all storage units that use the robots that are associated with the old_server. If any robots from the old_server are reused on other media servers, do the following: a Power down the affected servers, disconnect the robots from the old servers, and then connect them to the new media servers. Verify that the operating systems on the new media servers recognize the robots. Use the NetBackup Administration Console to add the robots and drives to those media servers. You can use the NetBackup Device Configuration wizard. Use the NetBackup Administration Console to create the appropriate NetBackup storage units.
5 6 7
Use the NetBackup Administration Console to inventory the robots that are attached to the new_server. The inventory updates the location of all tapes in these robots.
Modify any policies that explicitly specified any of the storage units on the old_server. These policies must be changed to point to any other defined storage units in the NetBackup configuration or to Any Available, as appropriate. Remove all reference to the old_server in the bp.conf files (UNIX only) and vm.conf files on the NetBackup master server and all NetBackup media servers.
10 Use the nbemmcmd command to remove the host aliases and host names that reference the old_server. Run nbemmcmd -listhosts to verify that all references have been removed. 11 Update the server list on all clients to no longer refer to the old_server. Restart the NetBackup daemons (or services) on any system that was updated.
The drive is configured. The drive is in the robotic library that contains the media. The drive allows the requested media density.
The EMM server (nbemm) manages the drives and requests for locally-attached or shared drives in the EMM domain by doing the following:
Determines which of the drives are currently available. A drive is available if it is:
107
Picks an available drive that was used least recently. NetBackup selects the robotic-based drives over stand-alone drives unless the corrrect media already is loaded in a stand-alone drive.
The first drive in the drive configuration is used first, then the second drive, and so on. You can see the drive order in the configuration by using the tpconfig -d command. The following applies only to NetBackup Enterprise Server. If some of the drives are shared drives, NetBackup chooses a nonshared drive first (if one is available). NetBackup chooses a shared drive first so the shared drives can be used on other hosts that share the drives. Shared drives require the Shared Storage Option.
You operate NetBackup media servers in a cluster environment. NetBackup can recover and use a reserved drive after a failover (if NetBackup owns the reservation). (With SPC-2 SCSI reserve, a drive reset usually is required because the reservation owner is inoperative.) You want very high drive availability. NetBackup can resolve NetBackup drive reservation conflicts and maintain high drive availability. (SPC-2 SCSI reserve provides no method for drive status detection.)
However, the SCSI persistent reserve method is not supported or not supported correctly by all device vendors. Therefore, you should thoroughly analyze your
SCSI persistent reserve. This option provides SCSI persistent reserve protection for SCSI devices. The devices must conform to the SCSI Primary Commands - 3 (SPC-3) standard. SPC-2 SCSI reserve. (The default option.) This option provides SPC-2 SCSI reserve protection for SCSI devices. The devices must conform to the reserve and release management method in the SCSI Primary Commands - 2 standard. No protection. Other HBAs can send the commands that may cause a loss of data to the tape drives.
You can configure access protection for each NetBackup media server. The protection setting configures tape drive access protection for all tape drive paths from the media server on which the setting is configured. You can override the media server setting for any drive path. SCSI reservations provide protection for NetBackup Shared Storage Option environments or any other multiple-initiator environment in which drives are shared. SCSI access protection is used on tape drives only.
Register with the tape drives device server (the server is a logical unit within a drive that processes SCSI tasks) Request an exclusive access reservation
If the tape drives device server grants the reservation, the NetBackup process has exclusive use of the device. The reservation prevents other host bus
adapters (HBAs) from issuing any commands that can cause data loss.
If the reservation fails, NetBackup fails the job.
When the NetBackup process is finished with the drive, NetBackup unloads the
drive and sends a persistent reserve clear command to the drive. The command
removes both the reservation and the registration.
SCSI persistent reserve also provides device status detection, which NetBackup
uses to resolve reservation conflicts within NetBackup.
109
The reservation does not prevent other applications on the host that has the reservation from using the same device and from causing data loss. For example, if a user on the same host issues a UNIX mt command, the mt command may take control of the drive. Also, other HBAs can clear or release an SCSI persistent reservation. Therefore, an application can clear another HBAs reservation (although it should not do so).
Released by the HBA that reserved it. Power cycled (usually). Preempted by an SCSI persistent reserve command.
The drive does not process commands from any other host bus adapters (HBAs) until NetBackup releases the reservation or the reservation is broken. If the reservation fails, NetBackup fails the job. The reservation does not prevent other applications on the host that has the reservation from using the same device and from causing data loss. For example, if a user on the same host issues a UNIX mt command, the mt command may take control of the drive. After the NetBackup process has finished with the media, it issues an SPC-2 SCSI command to release the reservation during the unmount operation. The release frees the device for access by another HBA. SCSI reserve does not provide a method to determine if a device is reserved. Only the reservation owner (the host bus adapter) can release the reservation. However, these limitations do not interfere with NetBackup operations in most environments.
Released by the HBA that reserved it. Released by a TARGET or a LOGICAL UNIT RESET. These resets are protocol dependent and differ between parallel SCSI and FCP (SCSI on fibre channel). These resets may be issued from any HBA. Released by fibre channel LOGO, PLOGO, PRLI, PRLO, or TPRLO action or failed discovery (link actions). Power cycled.
A negative consequence of SPC-2 SCSI reserve occurs if the HBA that owns the
reservation fails. A device that an HBA reserves stays reserved until the
reservation is removed or broken. Only the original HBA can remove the
reservation, which means the system must be available. If the HBA that owns
the reservation fails, it cannot remove the reservation. Therefore, the
reservation must be broken.
To break a reservation, the device must be reset by any of the following:
111
LUN device reset Power cycle Fibre channel link actions may break reservations.
SPC-2 SCSI reserve commands are mandatory for all SCSI-2 and SCSI-3 devices.
See the SCSI 2 standard for a detailed description of SCSI reserve command
operation and behavior.
Also, the NetBackup Administration Console Device Monitor or the output from the vmoprcmd command shows PEND in the Control column. If a conflict occurs, a reservation problem may exist. If the HBA that reserves the drive is unavailable (for example, due to a system crash or hardware failure), it cannot release the reservation. NetBackup cannot release or break an SPC-2 SCSI reservation automatically. You must force a release or break the reservation to make the drive available, even for a failover server in a cluster environment. When the conflict is resolved, the following message is written to the log:
Reservation Conflict status cleared from DRIVENAME (device NUMBER)
Forcing a release
To force a release of an unavailable HBAs SPC-2 reservation, you can use the
following NetBackup vmoprcmd command and option:
This option requests that all hosts that are registered to use the drive issue
SPC-2 SCSI release commands to the drive.
Issue the vmoprcmd command on the host that is the device allocator (DA host).
Alternatively, use the -h option of the command to specify the DA host. The DA
host is also the EMM server.
Caution: You can use this command after a PEND status has been displayed in the NetBackup Administration Console Device Monitor. However, do not issue this command during backups. For more information about using the vmoprcmd command, see NetBackup Commands for UNIX and Linux or NetBackup Commands for Windows.
Breaking a reservation
If you cannot release an SPC-2 SCSI reservation, you can try to use an operating system command that forces a device reset. A device reset breaks a reservation. The procedure depends on the operating system type. Caution: The reset operation may reset other devices in your configuration. Loss of data is also possible. You should first try alternate methods to break the reservation on a device (using switch and bridge hardware). Lastly, if the following operating system commands cannot break the reservation, you can power-cycle the drive. A power cycle breaks SPC-2 SCSI drive reservations (and usually breaks SCSI persistent drive reservations). To break an SPC-2 reservation on Solaris 1 2 Issue mt -f drive_path_name forcereserve. Issue mt -f drive_path_name release.
See the mt(1) man page for more information. To break an SPC-2 reservation on HP-UX
See the st(1m) man page for more information. To break an SPC-2 reservation on AIX
See the tctl man page (in the IBM AIX Commands Reference) for more information.
113
There must be passthru driver access to all shared drives. The passthru driver must be installed and all required paths must be created. For information about how to configure and use the passthru driver for UNIX operating systems, see the NetBackup Device Configuration Guide . You must configure the operating systems on the NetBackup media servers so they allow NetBackup to control SCSI persistent reserve or SPC-2 SCSI reserve. On HP-UX systems, you must disable the operating system's use of SPC-2 SCSI reserve. For instruction, see Enabling SPC-2 SCSI reserve in the Hewlett-Packard HP-UX chapter of the NetBackup Device Configuration Guides. Depending on your tape drives, you may have to disable the operating systems use of SPC-2 SCSI reserve. AIX and Solaris may require such a change. For more information, see the appropriate operating system chapter of the NetBackup Device Configuration Guide.
The NetBackup implementation of SCSI persistent reserve and SPC-2 reserve has the following limitations:
SCSI persistent reserve and SPC-2 reserve do not apply to NDMP drives. The NDMP filer is responsible for providing exclusive device access. Third-party copy configurations must be configured correctly. To retain reservation of a tape device during a third-party copy backup, you must configure the NetBackup mover.conf file. For procedures, see the NetBackup Snapshot Client Administrator's Guide. Do not use SCSI persistent reserve on the drive paths that are used for third-party copy backups. With SPC-2 SCSI reserve, devices may remain reserved after a failover in cluster environments or multipath environments with failover capability. You cannot use SPC-2 SCSI reserve if the following are true: the failover does not break the device reservations and those devices that were in use during the failover must be available without manual intervention. You can use SCSI persistent reserve. If a drive path changes, backups and restores fail. Therefore, jobs fail in cluster environments or any multipath environments that share paths dynamically. If you cannot disable dynamic path sharing, you cannot use SPC-2 SCSI reserve or SCSI persistent reserve in NetBackup. HP Tru64 is a system that uses dynamic path sharing.
The tape is frozen. The backup fails. The following error message entry is written to the bptm log:
FREEZING media id xxxxxx, External event caused rewind during
write, all data on media is lost
115
Unfortunately, data loss cannot be prevented only recognized after the fact. NetBackup does not remove catalog information about the backup sessions that were lost. You must use the bpexpdate command to expire the images for the lost backup sessions.
The tape is frozen. The backup fails. The following error message entry is placed in the bptm log:
FREEZING media id xxxxxx, too many data blocks written, check
tape/driver block size configuration
The backup data may be usable. If so, you can import the image using the NetBackup bpimport command so the data is available for restores.
How NetBackup selects media depends on whether the media is in a robot or a stand-alone drive.
NetBackup searches the media catalog for a volume that is already mounted in a drive and meets the following criteria:
Configured to contain backups at the retention level that the backup schedule requires. However, if the NetBackup Media host property Allow multiple retentions per media is specified for the server, NetBackup does not search by retention level. In the volume pool that is required by the backup. Not in a FULL, FROZEN, IMPORTED, or SUSPENDED state. Of the same density that is required by the requested backup andin the robot that is requested by the backup. Not currently in use by another backup or a restore.
Not written in a protected format. NetBackup detects tape format after the volume is mounted. If the volume is in a protected format, NetBackup unmounts the volume and resumes the search. If a suitable volume is found, NetBackup uses it.
If NetBackup cannot find a mounted volume that satisfies all of the previous conditions, it checks the media catalog for any volume that is suitable.
If a suitable volume is in a robot, NetBackup issues the commands that move the volume to a drive, position the heads to the beginning of the volume, and assign it to the request. No manual intervention is required. If a suitable volume is not in a robot but is in a stand-alone drive, NetBackup automatically mounts and assigns it. No manual intervention is required. If a suitable volume is not in a robot or a stand-alone drive, NetBackup does one of the following:
117
Attempts to to use another volume (for backup jobs where any other media can be used).
If the media catalog does not have a suitable volume or if a suitable volume is at end of media (EOM), a new volume is assigned. NetBackup may assign a new volume even if a volume is not full (because NetBackup received an EOM message from the drive). The new volume must meet all of the following criteria:
Is the correct media type. Is for the correct robot type (if applicable). Is located in the requested robotic peripheral (if applicable). Resides on the requested host. Is in the correct volume pool. Is not currently assigned (not already allocated to NetBackup). Is not expired (if an expiration date is defined in NetBackup). Has not exceeded the maximum number of mounts allowed.
If more than one volume qualifies, NetBackup chooses the volume that was least recently used. NetBackup then adds it to the media catalog and assigns it the specified retention level. If there are no unassigned volumes of the requested type, the backup terminates with an error message that no media was available.
Spanning media
After an end of media (EOM) is reached, automatic media selection depends on whether NetBackup is configured to allow backups to span media, as follows:
NetBackup spans media if the NetBackup Media host property Allow backups to span media is specified for the server. In this case, NetBackup uses another volume to start the next fragment and the resulting backup is composed of fragments on different volumes. NetBackup does not span media if Allow backups to span media is not specified. In this case, the backup terminates abnormally and the operation is retried according to the NetBackup Global Attributes host property, Schedule backup attempts.
If a backup is requested and an appropriate stand-alone drive does not contain a volume, NetBackup selects a volume as explained in How NetBackup selects media on page 116. The Device Monitor shows the mount request, and an operator must manually insert the volume and assign it to a drive. If an appropriate drive contains a volume, NetBackup tries to select and use that volume.
A volume that has been used previously for backups must meet the following criteria:
Not be FULL, FROZEN, or SUSPENDED. Contain backups at the retention level and be in the same volume pool as the backup that requires a volume. However, if the NetBackup Media host property Allow multiple retentions per media is specified for the server, NetBackup does not require a specific retention level.
NetBackup uses media that was not used previously. If the media is unlabeled, the following actions occur:
NetBackup labels the media. NetBackup adds a media ID to the volume configuration, if necessary. If a media ID is added, the NetBackup Media ID prefix (non-robotic) is used as the first characters of the media ID. If a media ID prefix is not specified, the default prefix is the letter A. For example, A00000. NetBackup adds the requested volume pool to the volume configuration (if the backup policy specifies a volume pool).
If the unused media is not labeled, you can label it by using the bplabel command. You can specify the -u parameter ito force assignment of a specific drive index, which eliminates the need to assign the drive manually.
119
Spanning media
Media selection after an end of media (EOM) condition depends on whether NetBackup is configured to allow backups to span media, as follows:
NetBackup spans media if the media server host property, Allow backups to span media, is specified for the server. NetBackup selects another volume to begin the next fragment, and the resulting backup has data fragments on more than one volume.
After an EOM condition, NetBackup attempts to use an unassigned volume rather than one that already has images on it. NetBackup checks the EMM database for a volume that is the correct media type, in the correct volume pool, and so on. If a suitable unassigned volume is unavailable, NetBackup selects a volume.
NetBackup does not span media if Allow backups to span media is not specified. The backup terminates abnormally when the end of media is reached. The operation is rescheduled according to the master server host property Schedule backup attempts.
When NetBackup spans media and an EOM is encountered on a stand-alone drive, you can direct NetBackup to wait until a volume is loaded in a compatible stand-alone drive. NetBackup then does not search for other media or generate a pending mount request. The wait period is helpful when a gravity feed tape stacker takes a long time to load the next media in the drive. (A gravity feed tape stacker is not controlled by software.) To direct NetBackup to wait, specify the Media request delay media server host property. This property specifies the number of seconds NetBackup waits to use a volume that is loaded in a compatible drive before looking for another drive. NetBackup also waits to generate a pending mount request during tape span operations. The Media request delay property is effective only when stand-alone drive extensions are enabled.
Media formats
NetBackup writes media in a format that allows the position to be verified before appending new backups. The format for tape and optical media differs slightly because of characteristics of the media. The following symbols are used in the media format descriptions in the following subsections. Symbol
MH * BH BH1 ... BHn
Description
Media Header (1024 bytes). Tape mark. Backup Header (1024 bytes). Backup Headers (1024 bytes). One for each job that is part of the set of jobs being multiplexed Data from the backup. Empty Backup Header, which is used for position validation.
Image EH
121
Fragmented backups
For fragmented backups, the media format is similar to the standard tape format. The difference is that NetBackup breaks the backup image into fragments of the size that you specify when you configure the storage unit. The following is an example: MH * BH Image (frag 1)* BH Image (frag 2)* BH Image (frag n) * EH * Fragmentation is intended primarily for storing large backup images on a disk type storage unit. The following are some benefits of image fragmentation:
For multiplexed backups, faster restores because NetBackup can advance to the specific fragment before starting its search for a file. Faster restores from any backup images that NetBackup Storage Migrator migrated. For example, if a 500-MB backup is stored in 100-MB fragments, Storage Migrator has to retrieve only the fragment that has the files. Storage Migrator does not have to retrieve the entire 500 MBs.
Note: If an error occurs in a backup, the entire backup is discarded and the backup restarts from the beginning. It does not restart from the fragment where the error occurred. Exception: checkpoint and restart backups resume from the last checkpoint fragment.
Multiplexing format
The tape format for multiplexed backups is as follows:
MH * BH1 ... BHn Image...
By default, the data image is in 64-kilobyte blocks. Each block also contains 512
bytes that are reserved for multiplexing control information and to identify the
backup to which the block corresponds.
When a job ends or a new job is added to the multiplexing set, NetBackup writes
a tape mark and starts multiplexing the revised set of jobs. The following is an
example:
MH * BH1 BH2 BH3 Image* BH2 BH3 Image* BH2 BH3 BH4 Image. .
Spanning tapes
By default, NetBackup spans a backup image to another tape if it encounters the
end of media during a backup. The format is the same as described for
fragmented backups. The first fragment on the next tape begins with the buffer
of data where the end of media occurred.
The following is the first tape format (NetBackup does not write an EH, and
terminates the tape with two tape marks):
MH * ... *BHn Image (frag 1) * *
The following is the second tape format:
MH * BHn Image (frag2)* ... * EH *
Note
Applies only to NetBackup Enterprise Server.
avrd
The Automatic Volume Recognition process. This process is started by ltid. Starts the NetBackup Device Manager service. Starting ltid also starts the robotic, robotic control, Media Manager volume, and automatic volume recognition daemons. The Tape Library 4MM robotic process. This process is started by ltid.
ltid
tl4d
123
Note
tl8d
tldcd
tldd
tlhcd
tlhd
The Tape Library Half-inch robotic process. This process is started by ltid.
tlmd
vmd
The NetBackup Volume Manager service. This process is started by ltid. The NetBackup Status Collection service. vmscd is started by nbemm on the same host as the EMM server if one or more NetBackup 5.x servers are present in the configuration.
vmscd
Note
tldcd -t tl8cd -t
Note
Applies only to NetBackup Enterprise Server.
Device serialization
Device serialization is a firmware feature that allows device identification and configuration. A unique serial number identifies a device. NetBackup determines device relationships by comparing serial numbers from multiple sources that refer to the same device. If both a robotic library and a drive fully support serialization, NetBackup can determine the drive's position (or address) in the robotic library. Most robots and drives support device serialization. If a device supports serialization, the following actions occur when the Device Configuration Wizard queries the devices.
125
For any robots in the configuration, the wizard issues an additional command. The robot returns the number of drives and the serial number for each of the drives in the robot. The wizard uses the information to determine the correct drive number for each drive in the robot.
NetBackup uses the information to construct your configuration. If a device does not support serialization, ask the vendor for the new firmware that returns serial numbers. Even with the proper firmware, some devices require the vendor to perform another action to enable serialization for the device. If you know that your devices do not support serialization, make sure that you follow the maximum configuration limits that they allow.
The greater the number of drives and robots in your configuration that do not
support serialization, the greater the chance of configuration problems using
the Device Configuration Wizard.
SCSI-based robotic libraries (such as changers, autoloaders, and stackers). SCSI-based tape drives. Native parallel SCSI, Fibre Channel Protocol (FCP) and FC-AL (loop) connections. SCSI over IP (reported). ACS, TLM, and TLH robots. NDMP devices that run NDMP version 3 or later.
The NetBackup Administration Console used on the master server Device configuration wizards that are used on the master server The tpconfig command that is used locally on each media server An internal API
The EMM database also contains the discovered device attributes that are required for device correlation and for validation of consistency in the configuration. The EMM database ensures consistency between drives, robotic libraries, storage units, media, and volume pools across multiple servers. The EMM server contains information for all media servers that share devices in a multiple server configuration. The NetBackup scheduling components use the EMM database information to select the server, drive path, and media for jobs. When the device manager ltid starts up, it reads device information from the EMM database into a shared memory segment. Components on the same host communicate by using shared memory IPC or socket protocols. Socket protocols are used between components across multiple hosts. Command line interfaces are available to obtain run-time (shared memory) information and static device configuration information.
127
from NetBackup. During a mount request, NetBackup uses the host that requests the mount to poll the shared drive. (A scan host is the host from which the automatic volume recognition process (avrd) scans unassigned drives.) This design enables NetBackup to support Dynamic Loop Switching or SAN zones. Each tape drive needs to be detected only from a single host. Each tape drive can potentially have its own scan host that switches dynamically to process errors and continue availability. A central device arbitrating component manages scan host assignments for shared drives. The arbitrating component also provides a network drive reservation system so that multiple NetBackup media servers can share a drive. Polling a shared tape drive allows dynamic loop switching and reduces the number of device accesses and reduces CPU time. However, it cannot detect connectivity breaks (for example, discontinuity in the Fibre Channel fabric) until I/O occurs.
Media and Device Management in the NetBackup Administration Console Menu-based device configuration interface (tpconfig on UNIX) Command line interface for device configuration (tpconfig -d command)
You can verify your device configuration by running the Device Configuration wizard. However, some details of a device configuration cannot be validated without attempting tape mounts. You can use the NetBackup robtest utility to mount tapes and validate the configuration.
Related topics
2 3 4
Optionally, use the appropriate NetBackup robotic test utility to verify the configuration. For information about the robotic test utilities, see the NetBackup Troubleshooting Guide.
129
After you create device files and configure NetBackup, you can verify the
configuration.
To verify the configuration (UNIX)
1 2 Stop the NetBackup device daemon (ltid).
Start ltid, which starts the Automatic Volume Recognition daemon (avrd). You must stop and restart ltid to ensure that the current device configuration has been activated. The following point applies only to NetBackup Enterprise Server. If robotic control is not local to this host, also start the remote robotic control daemon. Use the robotic test utility to mount a tape on a drive. Use the NetBackup Administration Console Device Monitor to verify that the tape was mounted on the correct robot drive.
3 4
Verify configuration example For example, assume a TLD robot includes three drives and the operating system includes the following device paths:
Also assume that in step 3 in To verify the configuration (UNIX), you requested that the tape be mounted on drive 1. If the device path for the drive is configured correctly, the Device Monitor shows that the tape is mounted on drive 1. If the Device Monitor shows that the tape is mounted on a different drive, the device path for that drive is not configured correctly. For example, if the Device Monitor shows that the tape is mounted on Drive 2, the device path for drive 1 is incorrect. Replace the drive 1 device path (/dev/rmt/0cbn) with the correct device path (/dev/rmt/1cbn) for drive 2. You may need to use a temporary device path while making these changes. You also know that the device path for drive 2 is incorrect. Possibly, the device paths were swapped during configuration. Use the robotic test utility to unload and unmount the tape from drive 1. Repeat the test for each drive. The following point applies only to NetBackup Enterprise Server. If the path to the drive where the tape is mounted is not on the host with direct robotic control, you may have to unload the drive with a command from another host or from the drives front panel.
3 4
Optionally, use the appropriate NetBackup robotic test utility to verify the configuration. For information about the robotic test utilities, see the NetBackup Troubleshooting Guide. To verify the configuration (Windows) 1 2 Stop the NetBackup Device Manager (ltid). Restart ltid, which starts the Automatic Volume Recognition process (avrd). You must stop and restart ltid to ensure that the current device configuration has been activated. The following point applies only to NetBackup Enterprise Server. If robotic control is not local to this host, also start the remote robotic control daemon. Use the robotic test utility to mount a tape on a drive. Use the NetBackup Device Monitor to verify that the tape was mounted on the correct robot drive.
3 4
Verify configuration example For example, assume a TLD robot includes three drives at the following SCSI addresses:
Also assume that in step 3 in To verify the configuration (Windows), you requested that the tape be mounted on drive 1. If the SCSI coordinates for the
131
drive are configured correctly, the Device Monitor shows that the tape is mounted on drive 1. If the Device Monitor shows that the tape is mounted on a different drive, the SCSI coordinates for that drive are not correctly configured. For example, if the Device Monitor shows the tape mounted on drive 2, the SCSI coordinates for drive 1 are incorrect. Replace the drive 1 SCSI coordinates (5,0,0,0) with the correct SCSI coordinates (5,0,1,0) for drive 2. You also know that the SCSI coordinates for drive 2 are incorrect. Possibly, the SCSI coordinates were swapped during configuration. Use the robotic test utility to unload and unmount the tape from drive 1. Repeat the test for each drive. The following point applies only to NetBackup Enterprise Server. If the data path to the drive where the tape was mounted is not on the host with direct robotic control, you may have to unload the drive with a command from another host or from the drives front panel.
Chapter
Cross mount points on page 134 Exclude and include lists on UNIX clients on page 136 Schedules for user backups or archives on page 140
The following information applies specifically to UNIX clients. The Cross Mount Points attribute controls whether NetBackup crosses file system boundaries during a backup or archive on UNIX clients or whether NetBackup enters volume mount points during a backup or archive on Windows clients.
Enable Cross Mount Points, to back up all files and directories in the selected path, regardless of the file system. For example, if you specify root (/) as the file path, NetBackup backs up root (/) and all files and directories under it in the tree. Usually, this means all the clients files, other than those available through NFS. Disable Cross Mount Points to back up only the files and directories that are in the same file system as the selected file path. This lets you back up a file path such as root (/) without backing up all the file systems that are mounted on it (for example, /usr and /home).
Cross Mount Points has no effect on UNIX raw partitions. If the raw partition that is backed up is the root partition and has mount points for other file systems, the other file systems are not backed up even if you select Cross Mount Points. Do not use Cross Mount Points in policies where you use the ALL_LOCAL_DRIVES directive in the backup selection list.
Resulting behavior
No crossing of mount points (default). Back up NFS files if the file path is (or is part of) an NFS mount. Cross local mount points but not NFS mounts. Follow the specified path across mount points to back up files and directories (including NFS), regardless of the file system where they reside.
135
/home /home/njr
d2
d3
Here, the client has /, /usr, and /home in separate partitions on disk d1. Another file system named /home/njr exists on disk d2 and is mounted on /home. In addition, disk d3 contains a directory named /net/freddie/home that is NFS-mounted on /net/freddie.
Example 1
Assume that you clear Cross Mount Points and Follow NFS and have the following entries in the backup selection list:
/
/usr
/home
In this case, NetBackup considers only the directories and files that are in the same file system as the backup selection list entry it process. It does not back up /home/njr or /net/freddie/home.
Example 2
Assume that you select Cross Mount Points and Follow NFS and include only / in
the backup selection list.
In this case, NetBackup backs up all the files and directories in the tree,
including those under /home/njr and /net/freddie/home.
To prevent the policy from backing up everything, leave / out of the list and
separately list the files and directories you want to include. The following
backup selection list backs up only /usr and individual files under /:
/usr
/individual_files_under_root
136 UNIX reference topics Exclude and include lists on UNIX clients
Note: Exclude and include lists do not apply to user backups and archives. On UNIX clients, you create the exclude and include lists in the following files on the client: /usr/openv/netbackup/exclude_list
/usr/openv/netbackup/include_list
The following topics explain the rules for creating these lists on UNIX clients.
*.o files
core files a.out files Files that begin or end with ~ (backups for editors) Files and directories under /tmp, /usr/tmp Man pages Software that you can restore from original installation tapes Automounted directories CD-ROM file systems NetBackup automatically excludes the following file system types:
mntfs (Solaris) proc (all UNIX platforms) cdrom (all UNIX platforms) cachefs (AIX, Solaris, SGI, UnixWare)
137
Note: Veritas suggests that you always specify automounted directories and CD-ROM file systems in the exclude list. Otherwise, if they are not mounted at the time of a backup, NetBackup must wait for a timeout before proceeding. Check with users before any files are excluded from backups.
Syntax rules
The following syntax rules apply to exclude lists:
Blank lines or lines that being with a pound sign (#) are ignored. Only one pattern per line is allowed. The following special or wildcard characters are recognized: [] ? * {} To use special or wildcard characters literally, precede the character with a backslash (\). For example, assume the brackets in the following are to be used literally: /home/abc/fun[ny]name
In the exclude list, precede each bracket with a backslash as in /home/abc/fun\[ny\]name
Note: A backslash (\) acts as an escape character only when it precedes a special or a wildcard character. NetBackup normally interprets a backslash literally because a backslash is a legal character to use in pathnames.
If all files are excluded in the backup selections list, NetBackup backs up only what is specified by full path names in the include list. Files can be excluded by using / or * or by using both symbols together (/*). Spaces are considered legal characters. Do not include extra spaces unless they are part of the file name. For example, if you want to exclude a file named /home/testfile (with no extra space character at the end) and your exclude list entry is /home/testfile (with an extra space character at the end) NetBackup cannot find the file until you delete the extra space from the end of the file name.
138 UNIX reference topics Exclude and include lists on UNIX clients
End a file path with / to exclude only directories with that path name (for example, /home/test/). If the pattern does not end in / (for example, /usr/test), NetBackup excludes both files and directories with that path name. To exclude all files with a given name, regardless of the directory path, enter the name without a preceding slash. For example: test
rather than /test
This is equivalent to prefixing the file pattern with a slash: /
/*/
/*/*/
/*/*/*/
and so on. Do not use patterns with links in the names. For example, assume /home is a link to /usr/home and /home/doc is in the exclude list. The file is still backed up in this case because the actual directory path, /usr/home/doc, does not match the exclude list entry, /home/doc.
The file or directory named /home/doe/john. The directory /home/doe/abc (because the exclude entry ends with /). All files or directories named test that are two levels beneath home. All files or directories named temp that are two levels beneath the root directory. All files or directories named core at any level.
139
The first file affects all scheduled backups in the policy that is named wkstations. The second file affects backups only when the schedule is named fulls. For a given backup, NetBackup uses a single exclude listthe list that contains the most specific name. For example, if there are files named: exclude_list.wkstations and exclude_list.wkstations.fulls NetBackup uses only:
exclude_list.wkstations.fulls
To create an include list for a specific policy or policy and schedule combination, use a .policyname or .policyname.schedulename suffix. The following are two examples of include list names for a policy that is named wkstations that contains a schedule that is named fulls.
/usr/openv/netbackup/include_list.workstations
/usr/openv/netbackup/include_list.workstations.fulls
The first file affects all scheduled backups in the policy that is named workstations. The second file affects backups only when the schedule is named fulls.
For a given backup, NetBackup uses only one include list: the list with the most specific name. Given the following two files: include_list.workstations
include_list.workstations.fulls
NetBackup uses only include_list.workstations.fulls as the include list.
These options can also be added to a users $HOME/bp.conf file on the client.
Chapter
Installation
System requirements
Solaris 7 and HP-UX 11.0, or IBM AIX 4.3.3 platforms NetBackup 5.0 or 5.1 clients AFS level 3.6 or later installed
Configuration
To configure backups for NetBackup AFS clients, add an AFS policy to the NetBackup configuration on the master server. The requirements are the same as for other NetBackup policies, except for the differences that are mentioned here. To back up the files and directories that are not in AFS volumes, create separate policies.
Client list
In the client list, specify the names of the AFS file servers to be backed up. These systems must have the NetBackup client installed.
Backup selections
In the backup selection list for the AFS policy, specify the AFS volumes and vice partitions to be backed up. The following example shows both volumes and vice partitions: user.abc
/vicepb
/vicepc/user.*
In this instance, NetBackup backs up the following:
The volume user.abc All volumes in vice partition vicepb All volumes in vicepc that begin with user. When the list includes a vice partition, all the volumes in the partition are backed up one at a time.
Note: NetBackup supports the maximum AFS 3.6 volume size of 8 GB.
CREATE_BACKUP_VOLUMES This directive causes NetBackup to create .backup volumes before it performs the backup. If a .backup volume already exists, NetBackup overwrites it to create a more recent copy. Because NetBackup backs up only the .backup copy of AFS volumes, this directive is useful if an automated mechanism is not in place to create .backup copies. Creating .backup copies also ensures that the backups include the latest changes.
143
Caution: If an automated mechanism is not in place to create .backup copies, include the CREATE_BACKUP_VOLUMES directive in the backup selection list or AFS volumes are not backed up.
REMOVE_BACKUP_VOLUMES This directive causes NetBackup to remove .backup volumes after performing the backup. The directive removes .backup volumes that are created using the CREATE_BACKUP_VOLUMES directive or created by another mechanism. SKIP_SMALL_VOLUMES This directive allows small or empty volumes to be skipped during backups. For example: SKIP_SMALL_VOLUMES=5
(do not include spaces on either side of the = sign)
In this example, NetBackup skips volumes 5 KB. Specify any number for
the volume size.
If no number is specified, the size defaults to 2 KB. For example:
SKIP_SMALL_VOLUMES
Directives must be all upper case. Although directives can be located anywhere in the backup selection list, try to place directives at the top. For example: CREATE_BACKUP_VOLUMES
SKIP_SMALL_VOLUMES
/user.abc
/vicepb
Regular expressions
NetBackup supports regular expressions in backup selection list entries. These are useful to perform the following actions:
Add or move volumes without having to change the backup selection list. Add vice partitions without having to change the backup selection list. Split volumes and vice partitions on AFS file servers into groups that can be backed up by separate policies. The different groups allow for concurrent backups or multiplexing. The following examples use regular expressions: user.[a-m]*
/vicep[a-c]
Automatic backup
The most convenient way to back up NetBackup for AFS clients is to configure an AFS policy and set up schedules for automatic, unattended backups.
Manual backup
The administrator on the master server can use the NetBackup Administration
Console to run manually a backup for an AFS policy.
For information about manual backups, see Chapter 3 of the NetBackup
Administrators Guide, Volume I.
Restores
The administrator performs all restores on either the NetBackup AFS client or the master server. Restores are performed on the basis of volumes. To restore a vice partition, the administrator must select all the volumes in that partition. Caution: If the Overwrite Existing Files option is selected, the volumes are overwritten. All changes or files that were created since the last backup are lost.
145
client. An administrator can perform a redirected restore as well. A redirected restore restores a volume to another volume or another vice partition.
If the administrator does not specify Overwrite Existing Files or an alternate name for the volume, NetBackup adds an R to the name of the restored volume. For example:
If the volume name is less than 22 characters long, NetBackup adds a leading R to the name of the restored volume. For example: If the volume name is: /AFS/shark/vicepa/user.abc
The restored name is: /AFS/shark/vicepa/Ruser.abc
If the volume name is 22 characters long, the first character of the original volume name is replaced with an R. (The maximum allowable length for a volume name is 22 characters.) For example: If the volume name is: /AFS/shark/vicepa/engineering.documents1
The restored name is: /AFS/shark/vicepa/Rngineering.documents1
To specify an existing volume to restore to an alternate path, enable the Overwrite Existing Files option. In this case, the entire volume is overwritten. If Overwrite Existing Files option is not enabled, the restore fails. To restore a volume to an alternate vice partition, the vice partition must exist or the restore fails.
Troubleshooting
The following sections provide tips and information for troubleshooting problems with NetBackup for AFS. See the NetBackup Troubleshooting Guide for UNIX and Windows for overall troubleshooting information.
Troubleshooting backups
To increase the level of detail in the logs:
Add the VERBOSE option to the /usr/openv/netbackup/bp.conf file on the NetBackup for AFS client. Create the following debug log directory on the NetBackup for AFS client: /usr/openv/netbackup/logs/bpbkar
If the AFS backup terminates with a status code of 9, the code indicates that NetBackup AFS client software was not properly installed. (An extension release update is needed.) If the AFS backup terminates with a status code of 78, the code indicates an AFS vos command failure. (afs/dfs command failed) The NetBackup Problems Report provides additional information as to why the command failed. The bpbkar debug log shows the command that was run. Run the vos command manually to attempt to duplicate the problem. Also, examine the /usr/openv/netbackup/listvol file on the NetBackup client for irregularities. The vos listvol command can demand much from system resources so NetBackup caches the output of the vos listvol command in this file. NetBackup uses the cached listvol file to obtain the volume list instead of running another vos listvol command. (If the cached listvol file was created less than four hours before the backup.)
Troubleshooting restores
If the restore of an AFS volume fails, check the restore process log for additional information. Create a /usr/openv/netbackup/logs/tar debug log directory if a vos restore command failure is indicated. Then, retry the operation and check the resulting log to see that the vos restore command was run.
Chapter
Changes for NetBackup 6.0 and later on page 148 explains limited supported for IDR in NetBackup 6.0 and later. Supported Windows editions on page 148 documents the Windows versions that IDR supports. Overview of IDR use on page 150 explains the main steps that are involved in using the disaster recovery software. About the DR files on page 150 introduces the Disaster Recovery files and explains their importance in disaster recovery Configuring NetBackup policies for IDR on page 151 explains how to configure the policies that contain the clients that use IDR. Backing up the protected computer on page 152 explains that you must back up the computer before you create the bootable media that is used in recovery. Creating IDR media on page 152 explains how to use the IDR Preparation Wizard to prepare the bootable media that is used to recover data. Updating IDR media on page 158 explains how and when to update the IDR media so it is always ready when it is needed.
148 Intelligent Disaster Recovery Changes for NetBackup 6.0 and later
Recovering your computer on page 161 explains how to perform disaster recovery. Notes on recovering specific platforms on page 167 provides information on data recovery for specific types of platforms. IDR frequently asked questions on page 169 answers questions that are frequently asked about IDR.
To protect NetBackup 5.1 and 5.0 clients. To generate bootable media for supported clients (master server only). Backup jobs for NetBackup clients earlier than 6.0 return a status of 0 (successful). Backup jobs for NetBackup 6.0 or later clients return a status of 1 (partially successful). The NetBackup server tries to collect IDR information from those clients and is unable to do so. If no other problems exist, the client data is backed up.
If you use IDR with NetBackup 6.0 or later to protect NetBackup 5.1 or 5.0 clients, the NetBackup master server must be licensed for IDR.
Windows Server 2003 (Standard Edition, Enterprise Edition, and Web Edition). Windows XP 32-bit versions. Windows 2000 Server, Advanced Server, and Professional. Windows NT 4.0 Enterprise Server, Small Business Server, and Workstation editions with Service Pack 6A or later. Requires a supported NetBackup 5.x media server to back up the client.
149
NetBackup client software must be installed on the Windows computers that you want to protect. The IDR software is installed automatically when that client software is installed. IDR is not installed on NetBackup 6.0 and later client computers. The IDR software is not required (and cannot be installed) on UNIX computers. The NetBackup master server that collects the disaster recovery information must be licensed for IDR. The NetBackup master server that collects the disaster recovery information can reside on either a Windows or UNIX computer. The IDR Preparation Wizard that runs on the client computer generates recovery media only for the computers that have the same IDR version installed. The protected computer must be an Intel computer that runs a supported Windows operating system. For more information, see Supported Windows editions on page 148. At least 40 MB of hard drive space to hold the minimal recovery computer on the protected computer. The protected computer must contain sufficient space to accommodate the restored data. The protected computer must contain sufficient swap space to support the computers RAM. For example, for 128 MB of RAM, the minimum swap that is used is 128 MB. For a 2-GB partition that stores 1.8 GB of data, the required hard drive space for that partition is 1.8 GB. In addition, it must contain 128 MB plus 40 MB, for a total of 1.97 GB. The partition on the first physical drive on the protected computer must be the boot partition and must be labeled C:\. A protected computer must use a network card that does not require a Windows service pack to be installed. Refer to the Network LAN Adapters section of the Hardware Compatibility List that accompanies the Microsoft Windows software. This section contains a list of cards that have passed Microsoft compatibility tests without service packs. Windows must support the required driver of the CD-ROM drive on a protected computer. Windows NT computers: The IDR Preparation Wizard may detect that the driver on the protected computer is different than the driver on the Windows NT installation CD. In that case, select a driver to use. Symantec
recommends using the SCSI drivers currently installed on the protected computer because the drivers on the Windows CD may not be up to date. For IDE hard disks greater than 8 GBs, use the SCSI driver currently installed on the computer.
NetBackup client software must be installed on the Windows computers that you want to protect. The IDR software is installed automatically when that client software is installed. IDR is not installed on NetBackup 6.0 and later client computers. The IDR software is not required (and cannot be installed) on UNIX computers. Licensing. To activate IDR for backups, you must enter an IDR license key on the master server. Configuration. On the NetBackup master server, select the Collect disaster recovery information general attribute when setting up the policy configuration for protected clients. You can use a NetBackup master server on either a Windows or UNIX computer to collect disaster recovery information. Backup. An initial full backup must be completed of a protected computer before you create IDR media. Also, you should back up your computer frequently and update the DR files often. Preparing the IDR media. Use the IDR Preparation Wizard on the client computer to help prepare the media that is used to recover protected computers. Recovery. Use the Disaster Recovery Wizard to help rebuild the protected computer and restore data to that computer. The protected computers should be backed up regularly by NetBackup.
The installation, configuration, backup, and media preparation steps are necessary for to recover a Windows computer through a network connection to a NetBackup server.
151
Network interface card information. NetBackup configuration information necessary to restore data files.
The automatic recovery of an IDR-protected computer requires a copy of the DR file for that computer. IDR must be installed on the server and client. The server must be configured to collect disaster recovery information for NetBackup to create a DR file. NetBackup stores a copy on the client and the master server after each of the following backups:
Full backup Incremental differential or incremental cumulative backup User backup User archive
Ensure that each protected client is in an MS-Windows-NT type policy. Select the Collect disaster recovery information policy attribute for at least one of the MS-Windows-NT policies that backup protected clients.
The NetBackup master server that collects disaster recovery information must be licensed for IDR. If not, the Collect disaster recovery information attribute cannot be selected. Ensure that all the clients in this policy have IDR installed. If a client does not have IDR installed, the backups for that client by this policy can never end with a status of 0. A successful backup in this instance
shows a status of 1 (partially successful). The status is a result of NetBackup being unable to find a DR file to store in its catalog after each backup.
NetBackup 6.0 and later collects the DR information from the clients that run versions of NetBackup earlier than 6.0. However, you must use the IDR software revision on the client to prepare the bootable media for that client. For example, for a NetBackup 5.1 client, use the same IDR version to prepare the IDR media. Ensure that the client name that is used in the NetBackup policy configuration matches the clients computer name. If the names do not match, rename the DR file that is created after each backup before using it in a recovery. (Use the format computer_name.dr.)
The bootable media that is used to boot the computer and install and configure the operating system. System-specific drivers and the Disaster Recovery Wizard. The disaster recovery (DR) file. For Windows XP and Windows Server 2003 computers, Windows Automated System Recovery files.
153
At least one full backup of the computer to be protected. The Windows installation CD for the version and language that is installed on the protected computer. The license key for the Windows 2000, Windows XP, or Windows Server 2003 operating system. Administrative privileges for the protected computer. A device that can create bootable media:
CD-R drive (CD Recordable CD-ROM) CD-RW drive (CD Rewritable CD-ROM) Diskette drive (IDR does not support bootable diskette media for Windows XP or Windows Server 2003)
Diskettes work on most computers but require more time for preparation and recovery than CDs. Diskettes require the Windows installation CD during recovery. Because of space limitations, diskettes hold SCSI driver information for only one computer. To use one set of diskettes to protect multiple computers, choose one computer that represents all the other computers and create bootable media for it. For computers with different SCSI drivers, create a set of diskettes for each computer with a different driver. CDs require less time for preparation and recovery than diskettes. CD media has enough space to store SCSI driver information for multiple computers. Use a single CD for multiple computers during disaster recovery.
CD media requires that the protected computer have a BIOS that supports a CD boot. CD media requires CD writing hardware. The protected computer does not require a CD writer. The IDR Preparation Wizard creates a bootable image to write to a CD on any computer that contains a CD writer. For CD media, third-party CD writing software is required if the protected computer does not have a CD writer. The software is also required if the IDR Preparation Wizard cannot detect the CD writer that is attached to the protected computer. The CD hardware and software must be able to write ISO 9660 CD images. With both diskettes and CDs, prepare separate media for each operating system level and language being protected.
Windows setup diskettes. A Microsoft Windows utility creates the Windows Setup diskettes. The utility is on the Windows installation CD. The IDR Preparation Wizard modifies these setup diskettes for use specifically with NetBackup for Windows. Intelligent Disaster Recovery Diskettes that contain the computer-specific information that is necessary to perform disaster recovery. The IDR Preparation Wizard creates these diskettes.
Windows NT requires five and Windows 2000 requires six blank, formatted 1.44-MB diskettes for each set of disaster recovery diskettes. Note: Windows XP and Windows Server 2003 do not support bootable diskettes.
Note: The Windows installation CD is required both to prepare disaster recovery diskettes and for disaster recovery using those diskettes. You also need the Windows 2000 license key, either during bootable diskette preparation or during recovery.
155
To create bootable diskettes 1 Format the diskettes. Windows NT requires five diskettes and Windows 2000 requires six. Windows XP and Windows Server 2003 do not support bootable diskettes. To prepare the diskettes, select Start > Programs > Veritas NetBackup > Intelligent Disaster Recovery PrepWizard. The IDR Preparation Wizard Welcome screen appears. Click Next to continue. The Create or Update IDR Boot Media screen appears.
Select Create - Full Set of Diskettes to boot the Windows Installation CD and click Next. The Starting Bootable Diskettes Creation screen appears. Follow the prompts until the IDR Preparation Wizard is completed.
To modify diskette sets for use with multiple Windows 2000 computers
To use the same diskettes 2 through 5 for all IDR-protected Windows 2000 computers, do not select Let IDR Automatically Partition the Boot and System Drive. The option appears on the Select Computer for Diskette Preparation screen of the wizard. You can use the same diskettes 2 through 5 for all of the
Windows 2000 computers. However, you have to create a different diskette 1 for each computer protected with IDR. Diskette 1 contains a file named winnt.sif. It is the script used to automate the installation of Windows 2000 for disaster recovery. This scripted installation of Windows 2000 requires that the name of the computer being recovered be listed in the winnt.sif file. Therefore, for each Windows 2000 computer that shares diskettes 2 through 5, make a copy of diskette 1 (and its files). For each copy of diskette 1, edit the winnt.sif file and change the computer name to the name of the computer to be protected. If you do not change the computer name, duplicate computer names on the network may occur. The duplicate names may prevent the recovered computer from participating on the network.
157
Select Create - Bootable CD Image for Use with CD Writers (ISO 9660) and click Next. The Starting CD Image Creation screen appears. Follow the prompts until the IDR Preparation Wizard is completed.
Caution: Test your bootable CD to ensure that your computer can boot from it. (See Step 1: Boot your computer on page 162.)
Click Next to continue. The Create or Update IDR Boot Media screen appears.
3 4
Select Create - IDR Diskettes Only (Includes ASR Files for XP/2003) and click Next. The Creating the IDR Diskettes screen appears. Follow the prompts until the IDR Preparation Wizard is completed.
Updating a bootable CD
You cannot update a bootable CD, you must create a new bootable CD image and then burn a new CD. If you install new hardware or change components on a protected computer, create a new bootable CD. For procedures, see Creating a bootable CD image on page 156.
159
After hardware changes. After SCSI driver updates. After other computer driver updates. When you already have a full set of bootable diskettes that you want to update.
To update IDR bootable diskettes 1 Select Start > Programs > Veritas NetBackup > Intelligent Disaster Recovery PrepWizard to prepare the IDR diskettes. The Welcome screen for the IDR preparation wizard appears. Click Next to continue. The Create or Update IDR Boot Media screen appears.
3 4
Select Update - Full Set of Diskettes Used to Boot the Windows Installation CD and click Next. Follow the prompts until the IDR Preparation Wizard is completed.
3 4
Select IDR Diskettes Only (Includes ASR Files for XP/2003) and click Next. Follow the prompts until the IDR Preparation Wizard is completed.
161
contains the DR file. The name of the DR file should match the computer name of the client (the name that IDR requires). The name is required, even if it differs from the name that is used in the NetBackup policy configuration. 1 Go to install_path\NetBackup\bin and double-click drfile.exe. The drfile.exe program creates (or updates) the DR file that is located in the install_path\NetBackup\Idr\Data directory on your computer. If the NetBackup client name is different than the computer name, rename the DR file. The DR file name is in the form computer_name.dr. The name of the DR file must match the computer name of the client. If the NetBackup client name is different than the computer name, you must rename the DR file so it can be used in a recovery. Insert the diskette that contains the DR file and copy the DR file to it. The diskette can be one of the IDR diskettes or a separate diskette. If you use a separate diskette, insert the separate diskette when prompted for the DR file during disaster recovery.
Step 1: Boot your computer. Use the previously prepared IDR bootable media to boot the computer being recovered. Step 2: Windows setup in IDR recovery. Use the Windows installation program to partition and format the computer drive on the computer being recovered. The IDR bootstrap process loads and runs the Windows installation program from the Windows installation CD. Step 3: Disaster recovery wizard. Use the NetBackup IDR Disaster Recovery wizard to restore your computer to its pre-disaster state and restore your data files.
Automating the recovery with the Disaster Recovery wizard requires the following:
A NetBackup server that can restore the latest backups to the computer being recovered. The latest DR file for the computer being recovered. If you have not updated the DR file since the last backup, it may contain out-of-date hard disk partition, network-interface-card driver, or backup set information.
Bootable IDR CD media or the original Windows installation CD. The license key for your Windows operating system (if you did not enter the license key during preparation of the IDR bootable media). For Windows XP and Windows Server 2003 computers, the ASR files for the computer being recovered. If your network adapter requires special driver software, use the installation program that the CD manufacturer provides. Special drivers are the drivers that are not on the operating system installation program. For example, a driver for a network interface card (NIC) supplied by the manufacturer.
Note: Windows 2000: if Let IDR Automatically Partition the Boot and System Drives was not selected during IDR preparation,reinstall any utility partitions before the recovery process begins. Reinstall the partitions by using the OEM-supplied installation program. During recovery, select the option to partition and format the drives manually.
To boot from a bootable CD 1 2 Insert the bootable CD. Start the computer and perform the tasks necessary to boot from the CD. For example, you may have to press a function key to boot from the CD drive. The NetBackup Intelligent Disaster Recovery Bootstrap screen appears. Perform one of the following actions:
163
To test the CD to determine if it can boot the computer, press Esc to exit. Then remove the CD from the drive. To perform disaster recovery, press Enter to continue with the boot process. For Windows NT and Windows 2000, go to Step 2: Windows setup in IDR recovery on page 163. For Windows XP and Windows Server 2003, press F2 to load the ASR files when prompted by the boot process. If you have an ASR diskette, place it in the floppy disk drive so the ASR files can be loaded.
For Windows NT, Express Setup or Custom Setup. Usually, Express Setup is the best choice. Use Custom Setup if SCSI drivers are not present on the boot media or if RAID hardware needs to be reconfigured. For Windows NT, FAT or NTFS file system. If a new hard drive is detected, you must choose which file system format to use. Select FAT format for the C drive. IDR cannot partition to the old layout if you build the partition as NTFS.
Ensure that no diskettes or CDs are in the drives when prompted to reboot. Press Enter to reboot the computer. After the reboot, the Disaster Recovery Wizard starts automatically. Go to Step 3: Disaster recovery wizard on page 164.
Whether to replace the current hard drive partition with the partition information contained in the DR file or to keep the current hard drive partitions. Run the Windows Disk Administrator (or Disk Manager) program. The program lets you make additional changes to the partition information. To make partition changes, click Run Disk Administrator or Run Disk Manager. For more information, see Notes on altering hard drive partition sizes on page 167. Otherwise, click Next to continue the recovery process. For more information about Disk Administrator and fault tolerant configurations, see the operating system documentation.
For Windows 2000, a Completed IDR Phase 1 dialog box appears. Perform one of the following actions:
If your network adapter requires special driver software, click Pre-install Custom Network Driver. Follow the prompts to find and install the appropriate driver software. Special drivers are the drivers that are not on the operating system installation program. For example, a driver for a network interface card (NIC) supplied by the manufacturer. To continue, click Next and go to step 5 to continue the recovery.
165
For Windows NT only, you are asked to select either Automatic Restore or Manual Restore for network installation. Perform one of the following actions:
If your network adapters use the drivers and the software that is included with the operating system, select Automatic Restore. Click Finish to complete the network installation. Proceed to step 5 to continue the recovery. If your network adapters require special drivers and software, select Manual Restore. Select Wired to the Network and click Next. Proceed to step a. To select the network adapter, perform one of the following actions:
Click Select from list if the network adapter requires a manufacturer-supplied setup diskette. Then click Have Disk.
If the network adapter does not require a manufacturer-supplied setup diskette, click either Select from list or Start search. A list of network adapters appears.
Note: If your network adapter is not listed, click Select from list. Then click Have Disk add an adapter to the Network Adapter List. For automatic network installation to succeed, the Windows NT installation program must be able to recognize the network interface card being used. b c The next screen lists the default network protocols. Select the networking protocols that are used on the network. Click Next. Windows NT is ready to install the networking components. Insert the Windows NT installation CD or the IDR bootable CD into the CD-ROM drive. Click Next to continue. (If you created a bootable CD, it may include the appropriate network drivers if the drive were found during the IDR preparation process.)
Note: If additional screens about setting up your network interface card appear, respond as appropriate. d If TCP/IP is selected as the network protocol, you are prompted to use DHCP. If you do not want to use DHCP, enter a TCP/IP number. The Windows NT Networking Installation dialog box appears. Click Next to start the network and complete the installation of the networking components. Enter the name of the workgroup or domain for your computer and click Next.
e f
Note: Symantec recommends that you enter the name of a temporary workgroup rather than the name of a domain. When the recovery is complete, the computer is restored to its original workgroup or domain. g 5 Click Finish to complete the network installation and continue with recovery. If you selected Automatic, click Next and proceed to step 6. If you select Manual, click Next and proceed to step 8.
The restore process merges hardware information from the current live version of the registry into the saved version of the registry when recovering the registry. (The saved version is the registry version that was backed up.) The registry merger ensures that the computer reboots after the restore if the hardware changed. If the hardware changed, select the server from which you want to restore files. Click Start Restore to submit the restore request to the selected server. The files are restored and the hardware information from the current live version of the registry is merged with the saved version of the registry. Go to step 7. If the hardware has not changed, you do not have to merge the live version and the saved version of the registry. The hardware registry settings are identical to the setting in the saved version of the registry. To prevent merging the registries, continue with step a: a b Start a command window by pressing F1. Navigate to the following directory (the default location;
%SYSTEMROOT% is usually C:\Windows) :
%SYSTEMROOT%\System32\VERITAS\NetBackup\Bin
Type the following command, then press Enter. W2KOption -restore -display -same_hardware 1
The following output appears:
167
d 7 8
Make sure that Assume Same Hardware is displayed in the Same Hardware Restore field, then continue with the restore process.
After the restore is complete, click Next. Go to step 10. Select Start NetBackup Interface to start the NetBackup Backup, Archive, and Restore interface. Using this interface, you can make changes to the NetBackup configuration and you also have more control over the restore. (See the NetBackup Backup, Archive, and Restore Getting Started Guide for more information on using the interface.) When the restore is complete, close the Backup, Archive, and Restore interface and any other open NetBackup windows. When the restore is complete, click Next.
10 Remove any diskettes from drive A and click Finish to reboot the computer.
4 5 6 7 8
169
Secondary IDE
SCSI Adapter 1
SCSI Adapter n
Other types of mass storage controllers are usually seen as SCSI controllers by Windows.
Note: Windows NT: If the IDR Recovery Wizard does not detect the hard drive order, set up hard drive partitions manually. To do so, use the Windows NT Disk Administrator option within the Disaster Recovery Wizard. Then, continue with the automated restore of the backup media. If the recovery wizard reports drives greater than 8 GBs as being only 8 GBs, create bootable diskettes. To do so, enable the Use SCSI drivers currently installed on this computer option.
Index
A
ACS_ vm.conf entry 30
ADJ_LSM, vm.conf entry 30
Administrators e-mail address property 50
AIX cachefs file system 136
Allow Backups to Span Media 117
alternate client restores, host.xlate file 56
Andrew File System (AFS)
backup selection list 142
directives 142
installing 141
regular expressions 143
restores 144
troubleshooting 145
Announce DHCP interval property 46
API robots 99
API_BARCODE_RULES, vm.conf entry 32
AUTHORIZATION_REQUIRED, vm.conf entry 32
auto cleaning 91
AUTO_PATH_CORRECTION, vm.conf entry 32
AUTO_UPDATE_ROBOT, vm.conf entry 33
AVRD_PEND_DELAY, vm.conf entry 33, 114
AVRD_SCAN_DELAY, vm.conf entry 33
multiplexed 58
session_notify script 83
session_start_notify script 83
barcodes 98, 99
boot managers and IDR 169
booting a computer
with IDR bootable media 162
bp.conf file 105
UNIX client options 50
bpdynamicclient 49
bpend_notify script
UNIX client 74
Windows client 76
bpstart_notify script
UNIX client 70
Windows client 72
C
catalog backups backup notification script 78
catalogs
offline, cold backups 78
cdrom file system 136
CLEAN_REQUEST_TIMEOUT, vm.conf entry 34
cleaning
frequency-based 92
library-based 91
reactive 91
times allowed 93
CLIENT_PORT_WINDOW, vm.conf entry 34
clients
changing host names 56
dynamic UNIX client 49
exclude files list, UNIX 136
include files list 139
cluster environments 34, 113
CLUSTER_NAME, vm.conf entry 34
Compaq computers, recovering with IDR 169
compressed backups 58
CONNECT_OPTIONS, vm.conf entry 35
crawlreleasebyname, vmoprcmd option 111
B
backup selection list, AFS 142, 143
backup_exit_notify script 69
backup_notify script 69
backups
backup_exit_notify script 69
backup_notify script 69
bpend_notify script
UNIX client 74
Windows client 76
bpstart_notify script
UNIX client 70
Windows client 72
compressed 58
diskfull_notify script 79
estimating time required 59
media requirements 67
172
F
FlashBackup 58
Follow NFS mounts with cross mount points 134
format
description for optical 121
fragmented backups 121
frequency-based drive cleaning 92
D
DAS_CLIENT, vm.conf entry 35
DataStore volume pool 94
DAYS_TO_KEEP_LOGS, vm.conf entry 36
dbbackup_notify script 78
decommission a media server 104
Dell PowerEdge 6100/200 with RAID
recovering with IDR 168
device
delays 60
discovery 124
DHCP server 45
directives for AFS 142
disaster recovery
diskettes, updating 160
procedure 161
disk administrator 167
disk overhead, for catalogs 67
diskfull_notify script 79
Domain Name Service (DNS) hostnames 56
drfile.exe command 160
drives
cleaning
manual 93
operator-initiated 93
overview 90
Dynamic host name and IP addressing 45
G
GNU tar 58
H
hardware compression 102
host names
changing client name 56
changing server name 54, 56
client peername 55
correct use 54
short 55
host.xlate file and alternate client restores 56
E
e-mail notifications 50
EMM_REQUEST_TIMOUT, vm.conf entry 36
EMM_RETRY_COUNT, vm.conf entry 36
Enable performance data collection property 63
ENABLE_ROBOT_AUTH, vm.conf entry 37
escape character on UNIX 137
Exclude files list
UNIX 136
exclude lists
creating 136
example 138
files on UNIX 136
for specific policies and schedules 139
173
overview 150
preparation wizard 152
recovery wizard 161
requirements for using 149
supported Windows editions 148
updating bootable media 158
updating IDR media
recovery diskettes 159, 160
using drfile.exe 160
when to update 158
using boot managers 169
Windows
disk administrator 164
editions supported 148
setup 163
wizards
disaster recovery 161
IDR preparation 152
INVENTORY_FILTER, vm.conf entry 36, 37
demultiplexing 19
Maximum jobs per client property 18
recovering backups 58
schedule media multiplexing 15
storage unit max per drive 15
tape format 121
N
named data streams
VxFS 58
nbmail.cmd 81
NBRB_CLEANUP_OBSOLETE_DBINFO 28
NBRB_ENABLE_OPTIMIZATIONS 28
NBRB_FORCE_FULL_EVAL 28
NBRB_MPX_GROUP_UNLOAD_DELAY 29
NBRB_REEVAL_PENDING 28
NBRB_REEVAL_PERIOD 28
NBRB_RETRY_DELAY_AFTER_EMM_ERR 29
NDMP 58, 113
NetBackup Access Control (NBAC)
use of 37, 40
network transfer rate 60
notification scripts 68
L
library-based cleaning 91
M
mail_dr_info.cmd 80
MAP_CONTINUE_TIMEOUT, vm.conf entry 38
MAP_ID, vm.conf entry 37
maximum barcode lengths 98
media
determining requirements 67
formats 120
ID generation rules 102
pool 93
selection algorithm 116, 117
server register 25
spanning 117, 119
using tar to read images 58
Media Manager
best practices 84
configuration file 30
security 42
MEDIA_ID_BARCODE_CHARS, vm.conf entry 38
MEDIA_ID_PREFIX, vm.conf entry 39
MM_SERVER_NAME, vm.conf entry 39
mntfs file system 136
multiple servers 20
multiplexing (MPX)
backups 121
O
optical disk
format 121
OS/2, boot manager and IDR 169
P
peername, client 55
Performance Monitor, using with NetBackup 63
PREFERRED_GROUP, vm.conf entry 40
PREVENT_MEDIA_REMOVAL, vm.conf entry 40
proc file system 136
R
RANDOM_PORTS, vm.conf entry 40
raw partitions 58
reactive cleaning 91
reconfiguring devices in a shared drive
configuration 103
register a media server 25
regular expressions, AFS file list 143
remove a server from a configuration 104
REMOVE_BACKUP_VOLUMES 143
replacing a device in a shared drive
174
configuration 102
REQUIRED_INTERFACE 29
REQUIRED_INTERFACE, vm.conf entry 41
RESERVATION CONFLICT status 111
restore_notify script 82
restores
AFS clients 144
restore_notify script 82
robotic cleaning 91
S
schedules how processed 65
scratch pool 96
scripts
backup_exit_notify 68
backup_notify 68
bpend_notify 68
bpstart_notify 68, 70, 72
dbbackup_notify 68
diskfull_notify 68
mail_dr_info.cmd 68
nbmail.cmd 68
notification 68
parent_end_notify 68
parent_start_notify 68
restore_notify 68
session_notify 68
session_start_notify 68
userreq_notify 68
SCSI persistent reserve 108
SCSI reserve/release
break a reservation 110, 112
error recovery 111
limitations 113, 114
overview 108
PEND status 111, 112
requirements 112
RESERVATION CONFLICT 110, 111
SERVER, vm.conf entry 41
servers
changing host names 54, 56
NetBackup
master 21
media 21
multiple 20
session_notify script 83
session_start_notify script 83
SGI cachefs file system 136
T
tape
overhead, for catalogs 67
spanning 117, 119
tape format
fragmented 121
multiplexed 121
non-QIC 120
QIC/WORM 120
spanned tapes 122
TapeAlert 87, 91
log codes 87
requirements 87
tar
GNU 58
to read backup images 58
TLH_ vm.conf entry 43
TLM_ vm.conf entry 43
transfer rate 59, 60
troubleshooting AFS backups 145
U
UnixWare cachefs file system 136
userreq_notify script 83
using Media Manager devices with other
applications 85
175
API_BARCODE_RULES entries 32
AUTHORIZATION_REQUIRED entries 32
AUTO_PATH_CORRECTION entries 32
AUTO_UPDATE_ROBOTentries 33
AVRD_PEND_DELAY entries 33
AVRD_SCAN_DELAY entries 33
CLEAN_REQUEST_TIMEOUT entries 34
CLIENT_PORT_WINDOW entries 34
CLUSTER_NAME entries 34
CONNECT_OPTIONS entries 35
DAS_CLIENT entries 35
DAYS_TO_KEEP_LOGS entries 36
ENABLE_ROBOT_AUTH entries 37
INVENTORY_FILTER entries 36, 37
MAP_CONTINUE_TIMEOUT entries 38
MAP_ID entries 37
MEDIA_ID_BARCODE_CHARS entries 38
MEDIA_ID_PREFIX entries 39
MM_SERVER_NAMEentries 39
overview 30
PREFERRED_GROUP entries 40
PREVENT_MEDIA_REMOVAL entries 40
RANDOM_PORTS entries 40
REQUIRED_INTERFACE entries 41
SERVER entries 41
SSO_DA_REREGISTER_INTERVAL entries 42
SSO_DA_RETRY_TIMEOUT entries 42
SSO_HOST_NAME entries 43
TLH_ entries 43
TLM_ entries 43
VERBOSE entries 43
volume
group
rules for assigning 94
pool
configuring a scratch pool 96
overview 93
VxFS
named data streams 58
W
wildcard characters
in AFS file list 143
in exclude lists 137
UNIX escape character 137
wizards
disaster recovery 161
IDR preparation 152
worklist, prioritizing 66
176