NetBackup7.7_AdminGuideII_Server
NetBackup7.7_AdminGuideII_Server
Administrator's Guide,
Volume II
Release 7.7
Symantec NetBackup™ Administrator's Guide,
Volume II
Documentation version: 7.7
Legal Notice
Copyright © 2015 Symantec Corporation. All rights reserved.
Symantec, the Symantec Logo, the Checkmark Logo, NetBackup, Veritas, and the Veritas
Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the
U.S. and other countries. Other names may be trademarks of their respective owners.
The product described in this document is distributed under licenses restricting its use, copying,
distribution, and decompilation/reverse engineering. No part of this document may be
reproduced in any form by any means without prior written authorization of Symantec
Corporation and its licensors, if any.
The Licensed Software and Documentation are deemed to be commercial computer software
as defined in FAR 12.212 and subject to restricted rights as defined in FAR Section 52.227-19
"Commercial Computer Software - Restricted Rights" and DFARS 227.7202, "Rights in
Commercial Computer Software or Commercial Computer Software Documentation", as
applicable, and any successor regulations. Any use, modification, reproduction release,
performance, display or disclosure of the Licensed Software and Documentation by the U.S.
Government shall be solely in accordance with the terms of this Agreement.
Symantec Corporation
350 Ellis Street
Mountain View, CA 94043
http://www.symantec.com
10 9 8 7 6 5 4 3 2 1
Technical Support
Symantec Technical Support maintains support centers globally. Technical Support’s
primary role is to respond to specific queries about product features and functionality.
The Technical Support group also creates content for our online Knowledge Base.
The Technical Support group works collaboratively with the other functional areas
within Symantec to answer your questions in a timely fashion. For example, the
Technical Support group works with Product Engineering and Symantec Security
Response to provide alerting services and virus definition updates.
Symantec’s support offerings include the following:
■ A range of support options that give you the flexibility to select the right amount
of service for any size organization
■ Telephone and/or Web-based support that provides rapid response and
up-to-the-minute information
■ Upgrade assurance that delivers software upgrades
■ Global support purchased on a regional business hours or 24 hours a day, 7
days a week basis
■ Premium service offerings that include Account Management Services
For information about Symantec’s support offerings, you can visit our website at
the following URL:
http://support.symantec.com
All support services will be delivered in accordance with your support agreement
and the then-current enterprise technical support policy.
Customer service
Customer service information is available at the following URL:
www.symantec.com/business/support/
Customer Service is available to assist with non-technical questions, such as the
following types of issues:
■ Questions regarding product licensing or serialization
■ Product registration updates, such as address or name changes
■ General product information (features, language availability, local dealers)
■ Latest information about product updates and upgrades
■ Information about upgrade assurance and support contracts
■ Information about the Symantec Buying Programs
■ Advice about Symantec's technical support options
■ Nontechnical presales questions
■ Issues that are related to CD-ROMs, DVDs, or manuals
Support agreement resources
If you want to contact Symantec regarding an existing support agreement, please
contact the support agreement administration team for your region as follows:
Table 1-1
Task Description
Number
The nbdeployutil utility gathers data remotely for multiple master servers
from a central location, provided the master servers granted the initiating server
access. The utility supports remotely collecting data from back-level master
servers. You must load the engineering binary that is associated with this utility
onto all master servers for which you want to gather information.
After the gather process finishes, run the --report option to generate the
traditional license report.
Gathering data
The nbdeployutil utility contains the following options for collecting traditional
data:
Example 3: Gather information for a subset of clients that the local master server
protects.
or
Note: When you use the --client or the --clientlist option, some media servers
may show up as not connectable in the report even though the utility can connect
to them. This problem should not affect the summary information.
This variation creates a report for a smaller set of master servers and specifies a
different directory for the output.
# mkdir UK-masters
# nbdeployutil --report --traditional EMEA-domains/master1dir
EMEA-domains/master2dir --output=UK-masters
Traditional licensing 16
About the traditional licensing report
Under the Options section, confirm that the list of master servers is correct. If there
are missing or extra master servers, you need to rerun the report.
When you finish your review of the entire report, all the values in the Unknown row
under Tiering should be zero. As you reconcile the other tabs in the report, these
values should automatically update to zero.
When that finishes, use the following command to recreate the report.
nbdeployutil --report <all_previously_specified_options>
<all_previously_specified_gather_directories>
2 Check the Tier column for any hosts that are listed as UNKNOWN. You must
replace these with the appropriate tier number between one and four. Please
work with your Symantec Sales Engineer to determine the correct tier
information.
The Platform and Processors values help determine the host’s tier. These
columns do not calculate the tier, but by knowing this information you can
determine the appropriate value to enter in the Tier column.
3 Review the MSEO Key Server column and verify all the listed information is
correct. Yes indicates that the host is an MSEO key server. No indicates that
the host is not an MSEO key server. The N/A value indicates that the host is
not a media server.
Traditional licensing 19
How to reconcile the traditional licensing report
4 Check the Enterprise Client column and verify that the information is correct.
Yes indicates that the host is an enterprise client and was backed up. No
indicates that the host is not an enterprise client. The N/A value indicates that
no backups were performed on the host during the report period.
5 Review the SAN Media Server column and correct any hosts where the value
is UNKNOWN. Confirm that all other values are correct. A value of N/A for a
host indicates that the host is either a client server or a master server.
Be aware the only column which contributes to the final information on the Summary
tab is the Tier column. So values of UNKNOWN in other columns other than Tier
indicate unknown information. All data aside from the Tier column is for informational
purposes only.
Final steps
Once you reconcile the report, correct the errors, and enter the missing information,
compare the results to the install base report. The install base report is provided to
you by Symantec or your reseller. Confirm that everything in the report matches
Traditional licensing 20
How to reconcile the traditional licensing report
with the content in the install base report. If there are discrepancies, consult with
your Symantec sales representative to correct problems.
Chapter 2
Capacity licensing
This chapter includes the following topics:
client/policy combination that the analyzer examines. The utility measures the actual
data protected. It does not measure the capacity of the storage where the data
resides or the total amount of data that is stored on the device.
Consider the following:
■ Assume a device with 100 TB of total storage capacity.
■ A total of 65 TB of the total capacity is in use.
■ NetBackup protects a total of 60 TB of the used data through multiple backup
storage units.
■ That is measured as 60 TB of front-end capacity.
The total terabytes of front-end capacity are independent of the number of copies
NetBackup makes. A backup of 200 TB to basic disk with two copies to tape is still
only 200TB of front-end capacity.
To run the capacity licensing utility, the master server must have a
tool for reading .xls files. Symantec tested the utility with Microsoft
Excel, but any tool for reading and editing .xls files should work.
Symantec posts the most recent information about the nbdeployutil utility on the
following website:
http://www.symantec.com/docs/TECH145972
Task Description
Number
The nbdeployutil utility can gather data remotely for multiple master
servers from a central location, provided the remote master servers have
granted the initiating server access. The utility supports remotely collecting
capacity data from back-level master servers (NetBackup 6.5.6 and later).
# nbdeployutil --gather
NetBackup Deployment Utility, version 7.1.0000.0000
Gathering license deployment information...
Discovered master server marybl2g1
Output for marybl2g1 at: D:\Program Files\VERITAS\netbackup\
var\global\reports\20101029_170534_marybl2g1
Gather DONE
Execution time: 1 min
To create a report for this master server, run the following:
nbdeployutil.exe --report "D:\Program Files\VERITAS\netbackup\
var\global\reports\20101029_170534_marybl2g1"
Example 3: Gather capacity information for a subset of clients that the local master
server protects
or
■ A specific subset of clients. For example, a report that contains capacity usage
for business unit billing.
More information about this option is available.
See “Business unit reporting” on page 25.
Example 1: Generate a report using data that is collected for the local master server
This example is a continuation of Example 1 from the previous topic.
This variation creates a report for a smaller set of master servers and specifies a
different directory for the output.
# mkdir UK-masters
# nbdeployutil --report EMEA-domains/master1dir EMEA-domains/master2dir
--output=UK-masters
Examine the Itemization tab in the capacity licensing report for flagged
conditions in the Accuracy column
The report’s Itemization tab shows the calculated capacity for each client/policy
combination. The report flag conditions that have the potential to over count or to
under count capacity. These conditions are identified in the Accuracy and Accuracy
Comment columns.
The catalog has only incremental backups for the range analyzed. That error
may indicate that a full backup falls outside the report's range or that a full backup
does not exist.
See “Locate policy full backup in the capacity licensing report” on page 31.
■ Compressed Image
The client's data was sent to NetBackup in compressed form. The actual size
cannot be determined with certainty. For all compressed backup images, the
analyzer multiplies the final backup image size by a fixed value (the compression
ratio). The value of the compression ratio is listed on the Summary tab.
See “Review compressed image information in the capacity licensing report”
on page 31.
■ Size unavailable – Only snapshot is present
The catalog has only snapshots for the range analyzed. The analyzer requires
a backup image of the snapshot to have an accurate figure for the client's
protected capacity.
See “Locate full backup for snapshot image in the capacity licensing report”
on page 33.
■ Possible multistream backup detected
The size of the clients that are protected by multistream backups is the total of
all backup images created by all streams.
See “Determine affect of multistreamed backups in the capacity licensing report”
on page 32.
Note: If OpsCenter generated the report, the log file is found on the OpsCenter
server. The email with the report results contains a link to the log file location. The
log file name is in the format nbdeployutil-report-timestamp-log.
In the log file, find the policy name for the policy in question and look at the
corresponding MAX value. The excerpt from a log file that is shown highlights the
information discussed.
Confirm that this information is correct for the policy. If the information is inaccurate,
change the Charged Size column, and add a note to the Enter a Reason here
when modifying the Charged Size column explaining the change.
Locate full backup for snapshot image in the capacity licensing report
Examine the backup policy attributes to determine if a backup image is ever created
from the snapshot. If it is, rerun the analyzer with specific options to restrict the
collection and reporting to the specific client with a longer date range to find a full
backup of the snapshot. If a backup image is never created from the snapshot,
manually examine the snapshot or the client system to determine the size of the
data.
Note: The log file that is associated with this report shows snapshot information.
Chapter 3
Additional configuration
This chapter includes the following topics:
Workstations
Network A1
NetBackup Workstations
Mass master server A
storage
Network A2
Mass NetBackup
storage master server B
Network B1
Workstations
Router
Workstations
Network B2
Image database
Information in
NetBackup Storage relational databases Administration
Client Device (about devices, Interface*
volumes)
NetBackup
Storage NetBackup
Media Server Storage
Device Media Server Device
* You can also use the Backup, Archive, and Restore user
interface from a Windows client that has the Remote
Administration Console installed.
install_path\VERITAS\NetBackup\db\config\
SIZE_DATA_BUFFERS_DISK
install_path\VERITAS\NetBackup\db\config\
SIZE_DATA_BUFFERS
For a data buffer of this size (kilobytes) Enter this touch file value
32 32768
64 65536
96 98304
128 131072
Additional configuration 39
About dynamic host name and IP addressing
For a data buffer of this size (kilobytes) Enter this touch file value
160 163840
192 196608
224 229376
256 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>."
install_path\VERITAS\NetBackup\bin\DISABLE_DIRECT_IO
Configure the network to use a dynamic IP NetBackup requires that IP addresses of clients have a network
addressing protocol like DHCP. host name.
Determine the NetBackup client names for the These NetBackup client names are used in other steps. Each
computers that have dynamic IP addresses and NetBackup client must have a unique NetBackup client name.
network host names. The NetBackup client name that is assigned to a client is
permanent.
Make changes on the master server, as described. ■ Create NetBackup policies with client lists that include the
new names.
■ Create entries in the NetBackup client database for the new
client names. Use the bpclient command to create the
entries.
Make changes on each dynamic NetBackup In the NetBackup Administration Console, in the left pane,
Windows client, as described. click NetBackup Management. On the File menu, click Backup,
Archive, and Restore. On the File menu, click NetBackup Client
Properties. In the NetBackup Client Properties dialog box,
select the General tab. Enter the correct NetBackup client name
for the computer in the Client Name text box.
On the master server, enable the Announce DHCP In the NetBackup Administration Console, in the left pane,
Interval option, as described. expand NetBackup Management > Host Properties > Clients.
Double-click on the Windows client(s) in the right pane to open
the Client Properties window. In the Client Properties window,
in the left pane, expand Windows Client > Network. In the right
pane, check the Announce DHCP Interval check box.
Additional configuration 41
About dynamic host name and IP addressing
Make changes on each dynamic NetBackup UNIX ■ Modify the bp.conf file to include a CLIENT_NAME entry
clients, as described. with the correct NetBackup client name for the computer.
■ Configure the system to notify the master server of the
computer'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 computer's NetBackup client name and current network
host name.
123.123.123.70 dynamic00
123.123.123.71 dynamic01
123.123.123.72 dynamic02
123.123.123.73 dynamic03
.
.
.
123.123.123.79 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 the network. If the NetBackup client names are changed
or are not unique, backup and restore results are unpredictable.
Additional configuration 42
About dynamic host name and IP addressing
nbclient01
nbclient02
nbclient03
nbclient04
.
.
.
nbclient20
install_path\NetBackup\db\client
On UNIX/Linux:
/usr/openv/netbackup/db/client
Additional configuration 43
About dynamic host name and IP addressing
3 Create, update, list, and delete client entries with the bpclient command.
The bpclient command is in the following directory:
On Windows:
install_path\NetBackup\bin\admincmd
On UNIX/Linux:
/usr/openv/netbackup/bin/admincmd
cd install_path\NetBackup\bin\admincmd
On UNIX/Linux:
cd /usr/openv/netbackup/bin/admincmd
bpclient -add -client nbclient01 -dynamic_address 1
bpclient -add -client nbclient02 -dynamic_address 1
bpclient -add -client nbclient03 -dynamic_address 1
bpclient -add -client nbclient04 -dynamic_address 1
.
.
.
bpclient -add -client nbclient20 -dynamic_address 1
Additional configuration 44
About dynamic host name and IP addressing
install_path\NetBackup\bin\admincmd\bpclient -L -All
On UNIX/Linux:
/usr/openv/netbackup/bin/admincmd/bpclient -L -All
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.
Action Command
On UNIX/Linux:
On UNIX/Linux:
On UNIX/Linux:
bpclient.exe -L -All
On UNIX/Linux:
bpclient -L -All
CLIENT_NAME = nbclient00
Additional configuration 47
About dynamic host name and IP addressing
3 Run the bpdynamicclient command once when the system first starts up.
bpdynamicclient notifies the NetBackup server of the computer's NetBackup
client name and current network host name. The bpdynamicclient command
is in the directory:
/usr/openv/netbackup/bin
rm /usr/openv/netbackup/last_successful_hostname
/usr/openv/netbackup/bin/bpdynamicclient
-last_successful_hostname \
/usr/openv/netbackup/last_successful_hostname
EOF
# chmod 544 /etc/rc2.d/S99nbdynamicclient
Ensure that the dynamic client startup script is called after the computer obtains
its IP address.
Additional configuration 48
About busy file processing on UNIX clients
4 You must also create a root crontab entry to call the bpdynamicclient
command periodically.
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
NetBackup creates several files and directories when it processes busy files. Initially,
a working directory named busy_files is created under /usr/openv/netbackup.
NetBackup then creates the /actions directory under busy_files and places
action files in that directory. An action file contains the information that NetBackup
uses to control the processing of busy files.
By default, the contents of the action file are derived from the BUSY_FILE_ACTION
options in bp.conf. A user can also create an action file to control a specific backup
policy and schedule. NetBackup creates a logs directory under busy_files for
storing busy file status and diagnostic information.
/usr/openv/netbackup/bin/goodies/bpend_notify_busy
/usr/openv/netbackup/bin/bpend_notify
Be sure to set the file access permissions to allow groups and others to run
bpend_notify.
(This step is also performed when configuring busy file processing in the Busy
File Settings host properties.)
3 Configure a policy with a user backup schedule for the busy file backups.
This policy services the backup requests that the repeat option in the actions
file generates. The policy name is significant. By default, NetBackup
alphabetically searches (upper-case characters first) for the first available policy
with a user backup schedule and an open backup window. For example, a
policy name of AAA_busy_files is selected ahead of B_policy.
(This step is also performed when configuring busy file processing in the Busy
File Settings host properties.)
Additional configuration 50
About busy file processing on UNIX clients
■ BUSY_FILE_DIRECTORY
■ BUSY_FILE_ACTION
Entry Description
BUSY_FILE_PROCESSING Enables the NetBackup busy file-processing feature. By default, this entry
is not present in the client’s /usr/openv/netbackup/bp.conf file.
BUSY_FILE_DIRECTORY Specifies an alternate path to the busy files working directory. This entry is
not required. By default, this entry is not present in the client’s
/usr/openv/netbackup/bp.conf or $HOME/bp.conf file. By default,
NetBackup creates the busy_files directory in /usr/openv/netbackup or
the user’s home directory.
Additional configuration 51
About busy file processing on UNIX clients
Entry Description
BUSY_FILE_ACTION Directs the action that NetBackup performs on busy files. By default, this
entry is not present in the client’s /usr/openv/netbackup/bp.conf or
$HOME/bp.conf file.
BUSY_FILE_ACTION =
filename_template action_template
Where
MAIL | mail
Directs NetBackup to retry the backup on the specified busy file. A repeat
count can be specified to control the number of backup attempts. The
default repeat count is 1.
IGNORE | ignore
Directs NetBackup to exclude the busy file from busy file processing. The
file is backed up and a log entry that indicates that the file was busy
appears in the All Log Entries report.
BUSY_FILE_NOTIFY_USER
Example Description
actions.policy_name.schedule_name
actions.policy_name
Step Example
/usr/openv mail
/usr/* repeat 2
/usr/local ignore
Example 2:
actions.production_servers.full
/bin/* repeat
If yes, NetBackup repeats the backup for busy files in the /bin
directory.
Additional configuration 54
About busy file processing on UNIX clients
policy_name.schedule_name.PID
log.policy_name.schedule_name.PID
policy_name.schedule_name.PID.retry.retry_count
Where retry_count starts at zero and increases by one every time a backup is
repeated. Processing stops when retry_count is one less than the number that
is specified by the repeat option.
Example:
To service busy file backup requests, the administrator defined a policy named
AAA_busy_files that has a user backup schedule named user. A scheduled backup
is initiated with the policy named production_servers, schedule named full, and PID
of 1442.
If busy files are detected, NetBackup generates the following files in the
/usr/openv/netbackup/busy_files/logs directory:
production_servers.full.1442
log.production_servers.full.1442
If the actions file has the repeat count set to 2, NetBackup generates the following
files:
Additional configuration 55
About specifying the locale of the NetBackup installation
production_servers.full.1442.retry.0
AAA_busy_files.user.10639
log.AAA_busy_files.user.10639
production_servers.full.1442.retry.1
AAA_busy_files.user.15639
log.AAA_busy_files.user.15639
/bin/rm -f $LOG_FILE
■ After the call to the busy_files() function in main, add the following
commands:
/bin/rm -f $BUSYFILELOG
/bin/rm -f $RETRY_FILE
The .conf file and the LC.CONF file contain very specific instructions on how to add
or modify the list of supported locales and formats.
The .conf file and the LC.CONF file are 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.
Modify the existing formats to change the default output.
For example, the TL line for the C locale is the following:
TL 1 C :hh:mn:ss/mm/dd/yyyy
TL 1 C :hh:mn:ss -yyyy-mm-dd
Or:
TL 1 C :hh:mn:ss/dd/mm/yy
TL 1 C :hh:mn:ss /mm/dd/yyyy
TL 2 ov :hh:mn:ss/mm/dd/yyyy
TM 6 french 2 fr
To map French to C
TM 6 french 1 C
To add more TM lines, see the specific instructions in the .conf file.
Additional configuration 57
About the Shared Storage Option
If the .conf file is not accessible, no default TM lines exist as the default locale
is C (ov).
Master Server
Host A Device allocation host Host B
Scan host Robot control host
(avrd) (avrd)
(nbemm / DA)
(ltid) (ltid)
(vmd) (vmd)
HBA HBA
SAN
Data path Data path
Robot control
Hardware control path
DRV1 DRV2
The following items describe the NetBackup components for the Shared Storage
Option example in Figure 3-3.
■ The master server hosts the Enterprise Media Manager (EMM) service. It's the
device allocation host.
See About the device allocation host.
■ Host A:
■ Is a NetBackup media server that runs the Automatic Volume Recognition
(avrd) process, the NetBackup Device Manager service (ltid), and the
NetBackup Volume Manager (vmd) service.
■ Is connected to drives DRV1 and DRV2 through SAN hardware.
■ Is the first host in the environment to come online with a non-zero scan ability
factor. Therefore, it's the initial scan host for its drives.
See About scan hosts.
■ Host B:
■ Is a NetBackup media server that runs the Automatic Volume Recognition
(avrd) process, the NetBackup Device Manager service (ltid), and the
NetBackup Volume Manager (vmd) service.
■ Is connected to drives DRV1 and DRV2 through SAN hardware.
Additional configuration 59
About the Shared Storage Option
■ Controls the robotics. Except for ACS or TLM robot types, only one robot
control host exists for each robot.
For a process flow diagram of Shared Storage Option components, see the
NetBackup Troubleshooting Guide:
http://www.symantec.com/docs/DOC5332
How the scan host is EMM determines scan hosts; a scan host may be different
determined for each shared drive. The first host in the environment to
come online with a non-zero scan ability factor is the initial
scan host for its drives.
http://www.symantec.com/docs/DOC5332
The scan host can change A scan host is assigned for a shared drive until some
interruption occurs.
For example, if one of the following occurs, EMM chooses a
new scan host:
■ The socket connection, the host, the drive, the drive path,
or the network goes down.
■ The drive is logically placed in the Down mode.
Drive paths for the scan host If a drive has multiple paths that are configured on the
selected scan host, EMM selects a scan path as follows:
Shared tape drive polling For shared tape drives, only the scan host polls drives until
a mount request is received from NetBackup. During a mount
request, NetBackup uses the host that requests the mount
to poll the shared drive.
RESERVED The host on which the script is executed needs SCSI access to the
drive until it's released.
ASSIGNED Informational only. It does not change the fact that the host that
reserved the drive needs SCSI access.
RELEASED Only the scan host needs SCSI access to the drive.
SCANHOST The host that executes the script has become the scan host. A host
should not become a scan host while the drive is RESERVED.
Term Definition
Backup Exec Shared The NetBackup Shared Storage Option is not the same as the
Storage Option Symantec Backup Exec Shared Storage Option. The Backup Exec
SSO does not include support for UNIX servers and uses a different
method for drive arbitration.
SAN media servers A NetBackup SAN media server backs up its own data to shared
drives. It cannot back up data on other NetBackup hosts or clients.
Symantec licenses NetBackup SAN media servers.
Shared drive When the Shared Storage Option is installed, a tape drive that is
shared among hosts is termed a shared drive. For the drives that
are attached to NDMP hosts, each NDMP attach host is considered
an additional host.
Note: Enter the license key on the NetBackup master server. Also enter the license
key on each NetBackup media server that you use for the Shared Storage Option.
3 In the Add a New License Key dialog box, enter the license key and click Add
or OK.
4 Click Close.
5 Restart all the NetBackup services and daemons.
■ Install and configure the appropriate drivers. See your vendor documentation
for instructions.
■ On UNIX and Linux servers, create any device files that are needed. Depending
on the operating system, a reconfiguration system start (boot -r) may create
these files automatically.
Create the device files for each drive; use the Fibre Channel LUNs of the drives
and adapters in the device file names. Add the names of the device files to your
notes to complete the correlation between device files and physical drive location.
Use the NetBackup Device Configuration Guide and the man pages that are
available with the operating system.
See the NetBackup Device Configuration Guide, available at the following URL:
http://www.symantec.com/docs/DOC5332
■ On UNIX and Linux servers, customize the operating system by modifying the
appropriate system configuration files. This task requires knowledge of the
system files that use the Shared Storage Option environment and their formats.
For example, on Sun Solaris systems you may need to modify the sg, st, and
HBA driver files.
Modify the HBA driver files to bind Fibre Channel devices (WWN) to a specific
target ID. For procedures, see the operating system documentation.
■ For instructions on how to configure the HBA on Windows servers, see the HBA
documentation from the vendor.
■ Use any available hardware configuration interface to configure and ensure that
the configuration is what you expect. For example, on Windows servers you
can use the Hyperterminal interface to configure SCSI-to-fibre bridges.
Use the following order when you configure and verify the hardware:
■ Robot and shared drives
■ Bridges
■ Hub or switches
■ Hosts
■ If errors occur and you suspect the operating system, refer to the operating
system logs as described in your operating system documentation.
■ The start sequence is longer for some devices than others. To verify that the
hardware starts completely, examine indicator lights. A green light often indicates
a completed start sequence.
Configuring Shared Storage Option devices See “Configuring Shared Storage Option
in NetBackup devices in NetBackup” on page 68.
Additional configuration 68
About the Shared Storage Option
About adding Shared Storage Option See “Configuring Shared Storage Option
configuration options devices in NetBackup” on page 68.
About configuring NetBackup storage units See “About configuring NetBackup storage
and backup policies units and backup policies” on page 68.
Configuring storage units for In each storage unit definition, logically define the robot and
each media server the shared drives for that media server. For the Maximum
concurrent drives used for backup, specify the total number
of all shared drives in the robot. When you configure storage
units, select a single media server. Alternatively, you can
allow NetBackup to select the media server to use at the time
of the backup. For example, you can configure a single
storage unit that any media server that shares the storage
unit can use.
Configuring a backup policy How you define a policy for a media server depends on your
for each media server media server license, as follows:
For a policy for the clients that you want to back up anywhere
in your configuration, you can choose any available storage
unit. Alternatively, you can use storage unit groups (prioritized
storage units).
■ If you have serialized devices but you did not use the Device Configuration
Wizard, use the following procedure to verify your configuration.
The verification procedures use the following NetBackup commands:
■ On Windows:
install_path\VERITAS\Volmgr\bin\scan
install_path\VERITAS\Volmgr\bin\tpconfig
■ On UNIX/Linux:
usr/openv/volmgr/bin/scan
usr/openv/volmgr/bin/tpconfig
In the following example the ADIC robotic library has six drives, but only drives 5
and 6 are configured on this particular host.
Perform the verification on all of the NetBackup servers in your configuration. Ensure
that each shared drive has the same logical drive name and same drive number
ID on each media server that shares the drive.
Additional configuration 71
About the Shared Storage Option
The output from tpconfig shows the logical names NetBackup assigns to tape
drives. The following example shows drive number 5 is named
QUANTUM.DLT7000.000 and drive number 6 is named QUANTUM.DLT7000.001:
2 Execute the scan command. The scan output shows the robot and the drive
properties.
The following is example output:
*************************************************************
********************** SDT_TAPE **************************
********************** SDT_CHANGER **************************
*************************************************************
Device Name : "/dev/sg/h3c0t0l0"
Passthru Name: "/dev/sg/h3c0t0l0"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry : "ADIC Scalar 100 3.10"
Vendor ID : "ADIC "
Product ID : "Scalar 100 "
Product Rev: "3.10"
Serial Number: "ADIC009K0340314"
WWN : ""
WWN Id Type : 0
Device Identifier: ""
Device Type : SDT_CHANGER
NetBackup Robot Type: 6
Removable : Yes
Device Supports: SCSI-2
Number of Drives : 6
Number of Slots : 50
Number of Media Access Ports: 10
Drive 1 Serial Number : "PXB03S0979"
Drive 2 Serial Number : "PXB03S0913"
Drive 3 Serial Number : "CXA04S2051"
Drive 4 Serial Number : "PXA31S1787"
Drive 5 Serial Number : "PXA37S3261"
Drive 6 Serial Number : "PXA50S2276"
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name : "/dev/st/nh3c0t5l0"
Passthru Name: "/dev/sg/h3c0t5l0"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry : "QUANTUM DLT7000 2561"
Vendor ID : "QUANTUM "
Product ID : "DLT7000 "
Additional configuration 73
About the Shared Storage Option
■ Determine the serial number of the drive in the scan output. "Tape" in the
device type field identifies a tape drive.
Step 2 shows example scan output shows the following:
The drive /dev/st/nh3c0t5l0 serial number is PXA37S3261.
The drive /dev/st/nh3c0t1l0 serial number is PXA50S2276.
Additional configuration 74
About the Shared Storage Option
■ Verify that the serial number for the drive matches the serial number in the
output from the robot section of scan. "Changer" in the device type field
identifies a robot.
In the previous examples, the serial numbers match.
Action Information
Drive Status pane The Control and Device Host columns contain shared drive
information.
Changing the operating mode For a shared drive, the Change Mode dialog contains a list
for a shared drive of all paths to the selected drive. You can choose any number
of paths to which the mode change applies.
Adding or changing a For a shared drive, the Change Drive Comment dialog box
comment for a shared drive contains the following:
Performing drive cleaning The three available drive cleaning functions are used with
functions for a shared drive shared drives are as follows:
■ Clean Now
In the list of hosts that share the drive, you can choose
only one host on which the function applies.
■ Reset Mount Time
In the list of hosts that share the drive, you can choose
any number of hosts on which the function applies.
■ Set Cleaning Frequency
Supported for shared drives.
Additional configuration 75
About the Shared Storage Option
with all hosts that share the drives. The tpconfig utility may create inconsistent
configurations.
■ Verify that you selected the appropriate device hosts in the Device Configuration
Wizard , including the host with robotic control.
■ Fibre Channel connections to the drives and the robots cause increased
complexity in a NetBackup device configuration. On some operating systems,
SCSI-to-fibre bridges may result in inconsistencies in the device paths when
you restart a host. After a restart of the host, the device configuration should be
verified.
■ Verify that names across all systems that share the drives are consistent.
■ Test the drive paths on every media server.
■ Define NetBackup storage units for each media server. Do not select any
available media server in the storage units.
■ Verify that you did not interrupt a data path during a backup. If you do, the
NetBackup job fails. It can fail with media write errors or it may hang and have
to be terminated manually.
■ Verify that you do not use Berkeley-style close on the tape path (UNIX or Linux
servers only).
■ On Solaris systems, verify the following:
■ That you added tape configuration list entries in /kernel/drv/st.conf (if
needed).
■ That you defined configuration entries for expanded targets and LUNs in
sg.links and sg.conf files. If you see problems with the entries in the
/etc/devlink.tab file (created from sg.links), verify the following:
The first entry uses hexadecimal notation for the target and LUN. The second
entry uses decimal notation for the target and LUN.
Use a single tab character between the entries; do not use a space or a
space and a tab character.
■ That you configured the operating system to force load the sg/st/fcaw
drivers.
For more information, see the Solaris chapter of the NetBackup Device
Configuration Guide, available at the following URL:
http://www.symantec.com/docs/DOC5332
Additional configuration 78
About the vm.conf configuration file
ACS_mediatype = Media_Manager_mediatype
Additional configuration 79
About the vm.conf configuration file
If this entry is used in vm.conf, the ACS media type is mapped to the specified
Media Manager media type. More than one ACS_mediatype entry can be specified.
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.
A list of the valid ACS_mediatype entries is available.
See the NetBackup Administrator's Guide, Volume I:
http://www.symantec.com/docs/DOC5332
ACS_SEL_SOCKET = socket_name
By default, acssel listens on socket name 13740. If this entry is specified in vm.conf,
the default can be changed. This entry is read and interpreted on the host on which
acsd runs.
The valid value for ACS_library_software_hostname is the host name of the ACS
library host. Do not use the IP address of the ACS library host for this parameter.
The valid values for socket_name are 1024 - 65535 and 0. The value must match
the value on the ACSLS server for the port that the CSI uses for inbound packets.
If 0 (zero), NetBackup uses the previous behavior of CSI and acsssi (no specific
ports).
This entry specifies the port where the acsssi process sends its ACSLS requests
on the ACSLS server. The ACSLS CSI must use this port to accept inbound ACSLS
requests from acsssi processes.
This entry, the ACS_SSI_INET_PORT entry, and the ACS_TCP_RPCSERVICE entry are
commonly used with firewall implementations. With these three entries in the
vm.conf file, TCP connections use the designated destination ports. Note that TCP
source ports are not restricted.
See “ACS_SSI_INET_PORT entry in vm.conf (on UNIX)” on page 80.
Additional configuration 80
About the vm.conf configuration file
ACS_TCP_RPCSERVICE
ACS_CSI_HOSTPORT = ACSLS_1 30031
ACS_CSI_HOSTPORT = ACSLS_2 30031
ACS_SSI_INET_PORT = ACSLS_1 30032
ACS_SSI_INET_PORT = ACSLS_2 30033
Each acsssi process sends queries to the respective ACSLS server’s port 30031,
and the ACSLS server is configured to listen for queries on this port.
ACS_SSI_HOSTNAME = host
Use ACS_SSI_HOSTNAME to specify the host to which RPC return packets from ACS
library software are routed for ACS network communications. By default, the local
host name is used. This entry is read and interpreted on the host on which acsd
and acsssi run. Do not use the IP address of the host for this parameter.
The valid value for ACS_library_software_hostname is the host name of the ACS
library host. Do not use the IP address of the ACS library host for this parameter.
The socket_name entry specifies the port that acsssi uses for incoming ACSLS
responses. Valid values are 1024 - 65535 and 0. This value must be unique for
each acsssi process.
A value between 1024 - 65535 indicates the number to be used as the TCP port
on which acsssi accepts ACSLS responses.
0 (zero) indicates that the previous behavior (allow the port to be dynamically
allocated) should remain in effect.
Additional configuration 81
About the vm.conf configuration file
This entry, the ACS_CSI_HOSTPORT entry, and the ACS_TCP_RPCSERVICE entry are
commonly used with firewall implementations. With these three entries in the
vm.conf file, TCP connections use the designated destination ports. Note that TCP
source ports are not restricted.
See “ACS_CSI_HOSTPORT entry in vm.conf (on UNIX)” on page 79.
See “ACS_TCP_RPCSERVICE / ACS_UDP_RPCSERVICE entry in vm.conf (on
UNIX)” on page 81.
For example, a NetBackup media server has two ACSLS servers (ACSLS_1 and
ACSLS_2) behind firewalls. Ports 30032 and 300033 have been opened in the
firewall for acsssi to ACSLS server communication.
The entries would be as follows:
ACS_TCP_RPCSERVICE
ACS_SSI_INET_PORT = ACSLS_1 30032
ACS_SSI_INET_PORT = ACSLS_2 30033
ACS_CSI_HOSTPORT = ACSLS_1 30031
ACS_CSI_HOSTPORT = ACSLS_2 30031
The NetBackup media server starts two acsssi processes. One listens for ACSLS_1
responses on port 30032, and the other listens on port 30033 for responses from
ACSLS_2.
The valid value for ACS_library_software_hostname is the host name of the ACS
library host. Do not use the IP address of the ACS library host for this parameter.
By default, acsssi listens on unique, consecutive socket names; the names begin
with 13741. If this entry is specified in vm.conf, specify socket names on an ACS
library software host basis. This entry is read and interpreted on the host where
acsd and acsssi are running.
ACS_TCP_RPCSERVICE
ACS_UDP_RPCSERVICE
Additional configuration 82
About the vm.conf configuration file
These entries specify the method over which acsssi communicates with ACSLS
servers: TCP or UDP.
Only one entry should be entered into vm.conf. NetBackup uses UDP if both entries
are found or neither entry is found.
For acsssi firewall support, ACS_TCP_RPCSERVICE must be entered in vm.conf.
See “ACS_CSI_HOSTPORT entry in vm.conf (on UNIX)” on page 79.
See “ACS_SSI_INET_PORT entry in vm.conf (on UNIX)” on page 80.
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.
Figure 3-4 is a diagram of LSM interconnections that are described by the following
entries:
Additional configuration 83
About the vm.conf configuration file
0 2
5 3
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 by using different drive types
such as HCART or HCART2. Specify a barcode rule for a series of bar codes 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
Additional configuration 84
About the vm.conf configuration file
AUTHORIZATION_REQUIRED
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 = YES|NO
If the value is NO, the device configuration remains unchanged when the NetBackup
Device Manager (ltid) is started. Therefore, the saved device configuration may
be different than the actual configuration after devices are changed and the server
is restarted.
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.
This entry is read and interpreted on the host on which the NetBackup Device
Manager (ltid) runs.
Device path remapping is enabled by default on Windows and Linux servers. It is
disabled by default on all other servers.
Additional configuration 85
About the vm.conf configuration file
AUTO_UPDATE_ROBOT
This entry only operates with the TL8 or TLD robots that post a unit attention when
their MAP is 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
is opened.
AVRD_PEND_DELAY = number_of_seconds
AVRD_SCAN_DELAY = number_of_seconds
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
converts to one 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.
Additional configuration 86
About the vm.conf configuration file
CLEAN_REQUEST_TIMEOUT = minutes
The minutes can be from 1 to 144000 (100 days). The default value is 30 and a
value of zero converts to the default value of 30.
For example, the following entry permits ports from 4800 through 5000:
The operating system determines the non-reserved port to use in the following
cases:
■ A CLIENT_PORT_WINDOW entry is not specified.
■ A value of zero is specified for start.
CLUSTER_NAME = cluster_alias
Add this entry in vm.conf to specify the options that enhance firewall efficiency with
NetBackup. The server connection options can be any of the following: use vnetd
or the daemon’s port number, use only vnetd, or use only the daemon’s port number.
For UNIX, you can also use a similarly named entry in the NetBackup configuration
file (/usr/openv/netbackup/bp.conf).
See the NetBackup Administrator's Guide, Volume I:
http://www.symantec.com/docs/DOC5332
server_name is the name of the media server to connect to.
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 the
vnetd service 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.
The following example entry specifies to use either vnetd or the daemon’s port
number to connect to server shark:
CONNECT_OPTIONS = shark 0 0 0
The following example entry specifies to use vnetd only to connect to server
dolphin:
CONNECT_OPTIONS = dolphin 0 0 1
The following example entry specifies to use the daemons’s port number only to
connect to server perch:
CONNECT_OPTIONS = perch 0 0 2
DAS_CLIENT = client_name
Additional configuration 88
About the vm.conf configuration file
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
A value of zero means that the logs are not deleted. The default is zero. This entry
does not affect the debug logs that Unified Logging creates.
Information about Unified Logging is available.
See the NetBackup Troubleshooting Guide:
http://www.symantec.com/docs/DOC5332
EMM_RETRY_COUNT = number_of_retries
EMM_CONNECT_TIMOUT = number_of_seconds
Only change the value of this vm.conf file entry when directed to do so by a
NetBackup support representative. If this entry is added to the vm.conf file or if this
value is changed, restart the vmd daemon and the ltid daemon.
EMM_REQUEST_TIMOUT = number_of_seconds
Used to filter the robot inventory results in ACS or TLH robot types. Add this entry
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 with an STK Library Station. Newer versions of STK Library Station allow robot
inventory commands to function correctly so filters are not required.
Use this entry to configure the default media access port (MAP) to use to eject
media from the Automated Cartridge System (ACS) robots. This default is selected
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.
See “ADJ_LSM entry in vm.conf” on page 82.
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 = seconds
The default timeout value for seconds is 300 (5 minutes). seconds cannot be zero
and values greater than 1200 (20 minutes) can 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 the daemons
Additional configuration 91
About the vm.conf configuration file
wait for user reply after the user removes volumes from the media access port. If
a timeout occurs, NetBackup aborts the operation.
This entry is read and interpreted on the host on which the SCSI-controlled robotic
daemon or process runs.
Note: Non-mount activities such as a robotic inventory cannot occur during this
timeout period.
Note: To use this entry, the robot must support bar codes and the robot type cannot
be an API robot.
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, if the number 2 is in a field, NetBackup
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.
Additional configuration 92
About the vm.conf configuration file
The following is an example rule and the resulting generated media ID:
MEDIA_ID_PREFIX = media_id_prefix
The best way to add media to a robot is to use the Robot Inventory Update Volume
Configuration operation.
MM_SERVER_NAME = host_name
If this entry is specified in vm.conf, TL8 robots run 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 = YES|NO
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, and then tries the next highest, and so on until a port
is available.
On UNIX, if random ports are not specified in the NetBackup configuration, specify
RANDOM_PORTS = NO in the vm.conf file.
REQUIRED_INTERFACE = host_name
Additional configuration 94
About the vm.conf configuration file
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 name of
that network interface.
See “Host name precedence in the vm.conf file” on page 96.
SERVER = host_name
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 = minutes
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
Additional configuration 95
About the vm.conf configuration file
a drive scan the drive. This reregistration allows conditions such as a device allocator
restart to have minimal effect 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 = minutes
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.
The Device Manager ltid delays before if one of the following events occurs:
■ Problems during communications with EMM/DA.
■ Failure trying to reserve a shared drive.
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.
SSO_HOST_NAME = host_name
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 = Media_Manager_mediatype
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.
Additional configuration 96
About the vm.conf configuration file
TLM_mediatype = Media_Manager_mediatype
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.
SERVER = server1
SERVER = server2
MEDIA_ID_PREFIX = NV
MEDIA_ID_PREFIX = NETB
ACS_3490E = HCART2
■ Creating a hold
■ Releasing a hold
Creating a hold
You can create a hold on one or more backup images by using the nbholdutil
-create command.
Caution: Creating a hold on backup images may disrupt new backups from
completing. Storage may fill up if previous backups are not automatically expired.
Note: When you retry a failed Hold creation, an empty hold is created if the backup
images have expired between the initial hold and the retry.
To create a hold
The nbholdutil -create command lets you create a hold for a backup image.
On a command prompt on the NetBackup master server, enter nbholdutil -create
with appropriate options and elements. For example:
nbholdutil.exe -create -holdname legal_case1 -backupid
win81.sky.com_1307425938 -allcopy
nbholdutil.exe -list
When you upgrade NetBackup to version 7.7, the legal holds are converted to user
holds, which can be managed by using the nbholdutil command.
Holds Management 99
Adding a backup image to an existing hold
Note: In versions earlier than 7.7, OpsCenter allowed creating holds on backup
images. Such holds are known as legal holds.
If the hold name of a legal hold is same as a user hold, all the hold names are
renamed as follows:
■ The legal hold names are suffixed with _1. For example, hold_1. The number
1 in the hold name denotes that it was a legal hold before conversion.
■ The user hold names are suffixed with _3. For example, hold_3. The number 3
in the hold name denotes that it is a user hold.
For more information about related command options, see the Symantec NetBackup
Commands Reference Guide.
To display help information about the command and its options, enter nbholdutil
-help [-option]
Releasing a hold
You can release holds by using the nbholdutil -delete command.
Note: A backup image expires as per the expiry date when all the holds that include
that backup image are released.
Holds Management 100
Releasing a hold
To release a hold
On a command prompt on the NetBackup master server, enter the nbholdutil
-delete command with appropriate options and elements. For example:
This command releases a hold that is called legal_case1. For more information
about related command options, see the Symantec NetBackup Commands
Reference Guide
The command nbholdutil -delete lets you release a hold.
Chapter 5
Menu user interfaces on
UNIX
This chapter includes the following topics:
Note: Many NetBackup processes set an upper limit on the number of concurrently
open file descriptors allowed by the process. That limit is inherited by the notify
scripts run by the process. In the rare event that a command invoked by a notify
script requires many additional file descriptors, the script must increase the limit
appropriately before invoking the command.
Menu user interfaces on UNIX 102
About the tpconfig device configuration utility
■ When you add an ACS robot, enter the name of the host on which the ACS
Library Software resides instead of a robotic control path.
■ When you add a TLM robot, enter the DAS or Scalar DLC server name
instead of a robotic control path.
■ When you add one of the following robots that has robotic control on another
host, you are prompted for the name of that host: TL8, TLD, or TLH robot.
1) Drive Configuration
2) Robot Configuration
3) Credentials Configuration
4) Print Configuration
5) Help
6) Quit
Enter option:
Drive Configuration Opens a menu to add, delete, or update drive definitions; list
definitions of drives and robots; or configure drive paths.
Robot Configuration Opens a menu to add, delete, or update robot definitions or list
definitions of drives and robots
Credentials Opens a menu to add, delete, update, or list credentials for the
Configuration following:
■ NDMP filer
■ Disk array
■ OpenStorage server
■ Virtual machine
Print Configuration The List Configuration commands on subsequent menus let you
display the current configuration on the screen or write it to a file.
http://www.symantec.com/docs/DOC5332
Help Online Help is available on the main menu and most submenus.
Quit Terminates the utility and returns you to the UNIX prompt.
You can return to the main menu from anywhere in the utility by entering Ctrl C or
by using the Escape key.
Note: If the Media Manager device daemon is running, stop it by using the stopltid
command.
Menu user interfaces on UNIX 105
About the tpconfig device configuration utility
Adding robots
When you configure robots and drives, first add the robots by using the Robot
Configuration menu. Then add the drives by using the Drive Configuration menu.
To change standalone drives to robotic, use the Update option of the Drive
Configuration menu.
See “Updating a drive configuration” on page 107.
To add a robot
1 Select the Robot Configuration menu.
2 Select the Add option.
3 From the list of possible robot types, select the one you want to add.
4 Enter a robot number that you know is unused or accept the default robot
number.
5 Indicate where the robotic control for the library is by entering the device file
path or library name. The Help option on the Robot Configuration menu has
examples of typical path names.
6 ■ If robotic control is on another host, enter that host name.
For an ACS robot, enter the name of the ACS library software host. For a
TLM robot, enter the name of the DAS or Scalar DLC server.
■ If robotic control is on this host, enter the device file path or library name.
The Help option on the Robot Configuration menu has examples of typical
path names.
For an ACS robot, enter the name of the ACS library software host.
For a TLH robot on an AIX system, enter the LMCP Device File; otherwise,
enter the Automated Tape Library Name.
For a TLM robot, enter the name of the DAS or Scalar DLC server.
Adding drives
Use the following procedure to add a drive.
Menu user interfaces on UNIX 106
About the tpconfig device configuration utility
To add a drive
1 Select the Drive Configuration menu.
2 Select the Add option.
3 From the list of possible drive types, select the one you want to add.
4 Enter the no rewind on close device path as shown in the /dev directory.
The Help option on the Drive Configuration menu has examples of typical
path names.
5 Enter the drive status (Up or Down).
6 If a robot exists to which you can add the drive, specify whether to add the
drive to the robot. Alternatively, you can configure the drives as a standalone
drive.
If there are no robots to which you can add the drive, tpconfig automatically
adds the drive as a standalone drive.
If you add a drive to a robot and more than one possible robot exists, enter the
number of the robot that controls the drive.
Depending on the type of robot, you may also be prompted to add the robot
drive number.
7 For a drive in an ACS robot, you are prompted for four drive identifiers.
More information on ACS robots is available.
See the NetBackup Device Configuration Guide, available at the following URL:
http://www.symantec.com/docs/DOC5332
For a drive in a TLH robot, you are prompted for an IBM device number.
For a drive in a TLM robot, you are prompted for a DAS or Scalar DLC drive
name.
More information is available.
See the NetBackup Device Configuration Guide, available at the following URL:
http://www.symantec.com/docs/DOC5332
8 Type a drive name or press the Enter key to use the default drive name.
If you use the shared drives option, all hosts that share the same physical drive
must use the same name for the drive. Descriptive drive names are
recommended.
Menu user interfaces on UNIX 107
About the tpconfig device configuration utility
Are you sure you want to UPDATE drive name xxxxx? (y/n) n:
Deleting a robot
Use the following procedure to delete a robot.
To delete a robot
1 On the main menu, select Robot Configuration.
If only one robot is configured, you do not have to select Update or enter the
robot number. If only one robot is configured, skip to step 4.
2 On the Robot Configuration menu, choose Delete.
3 If more than one robot is configured, enter the number of the robot to delete.
4 Enter y to delete the robot.
If you respond with n, press any key to return to the Drive Configuration
menu.
Deleting a drive
Use the following procedure to delete a drive.
To delete a drive
1 On the main menu, select Drive Configuration.
2 In the Drive Configuration menu, select Delete.
3 Enter the name of the drive you want to delete:
4 Enter y to delete the drive.
If you respond with n, press any key to return to the Drive Configuration
menu.
1) (N)dmp Filer
2) (D)isk Array Management Server
3) (O)penStorage Server
4) (V)irtual Machine
3 Select an option at the specific credentials menu and follow the prompts.
h) Help
q) Quit Menu
ENTER CHOICE:
2 Select a menu option and follow the prompts to configure and manage
OpenStorage.
h) Help
q) Quit Menu
ENTER CHOICE:
2 Select a menu option and follow the prompts to configure and manage
attributes.
Chapter 6
Reference topics
This chapter includes the following topics:
■ About TapeAlert
■ Media formats
Note: (On Windows) Do not change the host name of a NetBackup server. This
practice is not recommended. You may need to import all previously used media
to the server before you can use it under the new host name.
The following table discusses the topics that address how NetBackup stores and
uses host names.
Reference topics 115
Host name rules
Topic Description
Server and client names on On both UNIX servers and clients, the SERVER entries in the bp.conf file define the
UNIX servers and clients NetBackup servers that are allowed access. The first SERVER entry identifies the
master server. The first SERVER entry indicates the server to which client requests are
made. For this reason, the SERVER name must be one by which all clients can connect
to the server.
If more than one SERVER entry exists, the additional entries identify other NetBackup
servers that can initiate scheduled backups on the client. The bp.conf file must have
multiple SERVER entries if you configure remote media servers. The NetBackup Request
daemon (bprd) and NetBackup Database Manager daemon (bpdbm) do not run on
any server other than a master.
When a client makes a list or restore request to the server, the NetBackup client name
is used to determine whether to allow the operation. (The client name as specified on
the client.) The client name that is used is usually the CLIENT_NAME from the bp.conf
file of the client. Or, the client name can be the actual host name of the client if not in
the bp.conf file. Alternate client restores can use the name that is specified through
the user interface or with a parameter on the bprestore command.
For a successful request, the client name must match the name that is specified for
the client in the NetBackup configuration on the server. The only exception to this rule
is if the server is configured to allow alternate client restores.
Host names on Windows Windows NetBackup servers and clients also have SERVER and CLIENT_NAME settings.
servers and PC clients On these systems, specify server and client settings in the NetBackup Administration
Console.
Policy configuration (On Windows) The configured name for a client is the host name as it's added to a
policy. This name is how the client is identified in the NetBackup configuration.
(On UNIX) The configured name for a client is the host name as it's added to a policy.
This name is how the client is identified in the NetBackup configuration. NetBackup
also adds a CLIENT_NAME entry to a UNIX client’s bp.conf file when software is first
installed on the client.
The server uses the client’s 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 client’s 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 action and
administrator action is required to restore from some of the backups.
Reference topics 116
Host name rules
Table 6-1 How NetBackup stores and uses host names (continued)
Topic Description
Image catalog A subdirectory in the image catalog is created for a client when a backup is first created
for that client. The subdirectory’s name is the client’s 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 the entries in the error catalog for generating reports. These entries
contain the host name of the server that generates the entry and the client’s configured
name, if applicable. The server host name is normally the server’s short host name.
(For example, servername instead of servername.null.com.)
Catalog backup information If you include a media server’s catalog files in the NetBackup catalog, qualify the host
name of the media server in the file path. Qualified names are necessary because
they allow the master server to connect to the media server.
To update NetBackup after a master See “To update NetBackup after a master server
server name change name change” on page 116.
To update NetBackup after a client name See “To update NetBackup after a client name
change change” on page 117.
cd /usr/openv/netbackup/db/images ln -s
old_client_name new_client_name
Reference topics 117
Host name rules
3 (On Windows) 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
4 (On Windows) Create a directory for the new client2 in the \images directory:
Install_path\VERITAS\NetBackup\db\images\client2
5 (On Windows) 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
install_path\NetBackup\db\altnames\host.xlate
On UNIX/Linux:
/usr/openv/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 client’s gethostname (on Windows)
or gethostname(2) (on UNIX/Linux). 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 server’s
network services.
Consider the following example:
0 xxxx xxxx.eng.aaa.com
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 (on Windows) or gethostname(2)(on UNIX/Linux) is run
on the client, it returns xxxx.
■ The master server’s network services gethostbyname library function (on
Windows) or gethostbyname(2) library function (on UNIX/Linux) 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.
Reference topics 119
About reading backup images with tar
■ 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.
Where the e at the beginning of line one indicates that the backup is encrypted.
(Additional messages appear during recovery.)
■ The file restoration procedure with a non-NetBackup tar does not work on the
Solaris platform. You cannot use /usr/sbin/tar on Solaris to read NetBackup
backups. The Solaris tar command uses the ctime and the atime fields
differently than other tar commands.
When /usr/sbin/tar is used to restore backups, directories with large numbers
are created at the top level. These directories are from the ctime and the atime
fields being read as pathnames.
You can use /usr/openv/netbackup/bin/tar or GNU tar to read the backups
on Solaris platforms.
■ Steps 1 and 6 from the file restoration procedure with a non-NetBackup tar are
optional in a standalone environment. If step 1 is skipped, DOWN the drive and
then substitute the /dev path of the drive in place of /tmp/tape in the other
steps. Remember to UP the drive when you are done.
See “To restore files with a non-NetBackup tar” on page 120.
The following example was successful on an HP9000-800 with a downed 4mm
standalone drive and the NetBackup tar.
mt -t /dev/rmt/0hncb rew
mt -t /dev/rmt/0hncb fsf 1
mt -t /dev/rmt/0hncb fsr 1
/usr/openv/netbackup/bin/tar tvfb /dev/rmt/0hncb 64
Some platforms require other options on the tar command. The following is
required on Solaris 2.4:
/usr/openv/netbackup/bin/tar -t -v -f /dev/rmt/0hncb -b 64
Reference topics 122
Factors that affect backup time
File Description
@@MaNgLeD.nnnn_Symlink For long names of symbolic links, tar generates the files that are
named @@MaNgLeD.nnnn_Symlink. These files contain
descriptions of the symbolic links that must be made to return a link
to the correct file.
For cross-platform VxFS extent attribute restores, The files can either be deleted or read and the extent attributes
tar creates and stores extent attributes in regenerated by hand to the corresponding files.
.ExTeNt.nnnn files in the root directory
Transfer rate
The transfer rate depends on the following factors.
Factor Description
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 a transfer rate of
400 kilobytes. (Assume that other factors allow for the faster
transfer rate.)
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.
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 20 files, 1 megabyte each, is faster than a
backup for 20,000 files that are 1 kilobyte each.
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.
Reference topics 124
Methods for determining the NetBackup transfer rate
Factor Description
Network configuration can affect performance For example, when some computers run full-duplex and some run
half-duplex in an Ethernet environment, the throughput is
significantly reduced.
Compression (on UNIX/Linux) Software compression often multiplies the backup time by a factor
of two or three for a given set of data.
These delays can vary widely and depend on the devices and the
computing environments.
Network transfer rate The network transfer rate is the rate provided in the All Log
Entries report.
Network transfer plus This rate ignores the time it takes to load and to position media
end-of-backup processing before a backup. However, the rate does include the
rate end-of-backup processing that is ignored in the network transfer
rate. To determine this rate, use the All Log Entries report and
calculate the time from the message:
To calculate the transfer rate, divide this time (in seconds) into
the total bytes that are transferred. (The total bytes that are
transferred are recorded in the All Log Entries report.)
Total transfer rate This transfer rate includes the time it takes to load and position
the media as well as the end-of-backup processing. Use the
List Client Backups report to calculate the transfer rate by
dividing Kilobytes by Elapsed Time (converted to seconds).
On Windows, the Microsoft Windows System Monitor also displays the NetBackup
transfer rate.
Client: giskard
Backup ID: giskard_0767592458
Policy: production_servers
Reference topics 126
NetBackup notify scripts
The following three rates were compiled with the backup data from the sample
reports:
Network transfer rate:
1161824 KB at 230.325 KB per second
Network transfer plus end-of-backup processing rate:
23:10:30 - 00:35:07 = 01:24:30 = 5070 seconds
1161824 KB/5070 = 229.157 KB per second
Total transfer rate:
Elapsed time = 01:27:32 = 5252 seconds
1161824 Kbytes/5252 = 221.216 KB per second
backup_notify script
The backup_notify.cmd script (on Windows) and the backup_notify script (on
UNIX) runs on the NetBackup server where the storage unit is located. It's called
each time a backup is successfully written to media.
The scripts are located in the following directories:
On Windows: Install_path\VERITAS\NetBackup\bin\backup_notify.cmd
On UNIX: /usr/openv/netbackup/bin/backup_notify
NetBackup passes the following parameters to this script:
■ The name of the program performing the backup
■ The backup-image name or path
See the following Windows example:
backup_exit_notify script
The backup_exit_notify.cmd script (on Windows) and the backup_exit_notify
script (on UNIX) run on the master server. It's called to perform site-specific
processing when an individual backup completes.
Reference topics 128
NetBackup notify scripts
clientname Specifies the name of the client from the NetBackup catalog.
exitstatus Specifies the exit code for the entire backup job.
Note: Ensure that others can run this script on the client before it's used. To do so,
run chmod ugo+rx script_name, where script_name is the name of the script.
Reference topics 129
NetBackup notify scripts
To use this script, copy the following file from the server:
/usr/openv/netbackup/bin/goodies/bpstart_notify
Then place the script in the following location on the UNIX client:
/usr/openv/netbackup/bin/
Modify the script and ensure that you have permission to run the script.
The bpstart_notify script runs each time a backup or an archive starts and
initialization is completed. The script runs before the tape is positioned. This script
must exit with a status of 0 for the calling program to continue and for the backup
or archive to proceed. A nonzero status causes the client backup or archive to exit
with a status of bpstart_notify failed.
If the /usr/openv/netbackup/bin/bpstart_notify script exists, it runs in the
foreground and the bpbkar process on the client waits for it to complete before
continuing. Any commands in the script that do not end with an ampersand character
(&) run serially.
The server expects the client to respond with a continue message within the time
that the BPSTART_TIMEOUT option specifies on the server. The default for
BPSTART_TIMEOUT is 300 seconds. If the script needs more time than 300 seconds,
increase the value to allow more time. (The BPSTART_TIMEOUT option corresponds
to the Backup start notify timeout on the Timeouts host properties.)
clientname Specifies the name of the client from the NetBackup catalog.
Note: The bpstart_notify script also runs for NetBackup catalog backups if a
.policyname[.schedule] is not specified.
Reference topics 130
NetBackup notify scripts
For example:
/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.
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=client1_0857340526
UNIXBACKUPTIME=0857340526
BACKUPTIME=Sun Mar 2 16:08:46 2009
STREAM_NUMBER Specifies the stream number. The first stream from a policy, client, and schedule is 1. A 0
value indicates that multiple data streams are not enabled.
STREAM_COUNT Specifies the total number of streams to be generated from this policy, client, and schedule.
RESTARTED Specifies the 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.
Install_path\VERITAS\NetBackup\bin\goodies\bpstart_notify.bat
Then place the file on the client in the same directory as the NetBackup client
binaries:
Install_path\NetBackup\bin\
install_path\netbackup\bin\bpstart_notify.days.bat
■ The following script applies only to a schedule that is named fulls in a policy
named days:
Reference topics 132
NetBackup notify scripts
install_path\netbackup\bin\bpstart_notify.days.fulls.bat
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
bpstart_notify.bat
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.
%6 Specifies the 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 BPSTART_TIMEOUT option specifies on the server. The default for
BPSTART_TIMEOUT is 300 seconds. If the script needs more time than 300 seconds,
increase the value to allow more time. (The BPSTART_TIMEOUT option corresponds
to the Backup start notify timeout on the Timeouts host properties.)
For Windows 2000 clients, bpstart_notify script can use the following
environment variables for the support of multiple data streams.
STREAM_NUMBER Specifies the stream number. The first stream from a policy, client, and schedule is 1.
A 0 value indicates that multiple data streams are not enabled.
STREAM_COUNT Specifies the total number of streams to be generated from this policy, client, and
schedule.
Reference topics 134
NetBackup notify scripts
Install_path\VERITAS\NetBackup\bin\goodies\bpend_notify
On UNIX:
/usr/openv/netbackup/bin/goodies/bpend_notify
Then place the file in 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.
Note: The bpend_notify script is run when the client is finished sending data, but
the server has not yet completed writing to media.
Note: Ensure that other administrators can run the notify scripts after they are
modified. To do so, run chmod ugo+rx script_name, where script_name is the
name of 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 ampersand 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 script:
Reference topics 135
NetBackup notify scripts
clientname Specifies the name of the client from the NetBackup catalog.
exitstatus Specifies the exit code from bpbkar. The status is the client status and
does not indicate that the backup is complete and successful.
The client can display a status 0 when, due to a failure on the server,
the All Log Entries report displays a status 84.
Note: The bpend_notify script also runs for NetBackup catalog backups if a
.policyname[.schedule] is not specified.
For example:
/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.
BACKUPID
UNIXBACKUPTIME
BACKUPTIME
Reference topics 136
NetBackup notify scripts
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=client1_0857340526
UNIXBACKUPTIME=0857340526
BACKUPTIME=Sun Mar 2 16:08:46 2011
The following environment variables can be used for the support of multiple data
streams.
Table 6-7 Environment variables used for support of multiple data streams
STREAM_NUMBER Specifies the stream number. The first stream from a policy, client, and schedule is 1.
A 0 value indicates that multiple data streams are not enabled.
STREAM_COUNT Specifies the total number of streams to be generated from this policy, client, and
schedule.
FINISHED Specifies the status of the 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 of the data.
Install_path\NetBackup\bin\bpend_notify.bat
To create a script that applies only to a specific policy or policy and schedule
combination, add a .policyname or .policyname.schedulename suffix to the script
name as follows:
■ The following script applies only to a policy named days:
Reference topics 137
NetBackup notify scripts
Install_path\netbackup\bin\bpend_notify.days.bat
■ The following script applies only to a schedule that is named fulls in a policy
named days:
Install_path\netbackup\bin\bpend_notify.days.fulls.bat
Note: 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
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.
NetBackup passes the following parameters to the script when the backup
completes:
%5 Specifies the status of the operation. It is the same status as is 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.
Reference topics 138
NetBackup notify scripts
%6 Specifies the 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 Specifies the stream number. The first stream from a policy, client, and
schedule is 1. A 0 value indicates that multiple data streams are not enabled.
STREAM_COUNT Specifies the total number of streams to be generated from this policy, client,
and schedule.
Busy file processing can also be configured in the Busy File Settings host properties
of the NetBackup Administration Console.
diskfull_notify script
The diskfull_notify.cmd script (on Windows) and the diskfull_notify script
(on UNIX) run 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 scripts are located in the following directories:
On Windows: Install_path\VERITAS\NetBackup\bin\diskfull_notify.cmd
On UNIX: /usr/openv/netbackup/bin/diskfull_notify
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 the script:
For example:
/disk1/images/host_08193531_c1_F1
diskfull_notify.cmd bpdm
After the script runs, control is then returned to NetBackup to resume processing.
This script is located in the following directory:
/usr/openv/volmgr/bin/goodies
To use this script, activate it and place it into the /usr/openv/volmgr/bin directory.
See the script for instructions about how to activate it and how to modify it.
To use this script, activate it and place it into the /usr/openv/volmgr/bin directory.
See the script for instructions about how to activate it and how to modify it.
mail_dr_info script
Use the mail_dr_info.cmd script (on Windows) and the mail_dr_info.sh script
(on UNIX) to send NetBackup disaster recovery information to specified recipients
after running an online, hot catalog backup.
On Windows: 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.
/usr/openv/netbackup/bin/mail_dr_info.sh
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.
media_deassign_notify script
The NetBackup Media Manager calls the media_deassign_notify script after
media is deassigned. To send an email notification when media is deassigned,
include an email address in the script where indicated. (The script must be run as
the root user.)
On Windows: Copy
Install_path\NetBackup\bin\goodies\media_deassign_notify.cmd into
Install_path\NetBackup\bin\ on the master server.
Windows systems also require that you install the Simple Mail Transfer Protocol
application to transfer messages 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\goodies\nbmail.cmd from the master
server into Install_path\NetBackup\bin of each client that is to receive the
notification.
NetBackup passes the following parameters to the script:
%1 Specifies the address of the recipient. For multiple addresses, enter email1,email2
%3 Specifies the file that is sent in the body of the email. This is generated by another
script.
parent_end_notify script
NetBackup calls the parent_end_notify.cmd script (on Windows) and the
parent_end_notify script (on UNIX) each time a parent job ends.
clientname Specifies the name of the client from the NetBackup catalog.
status Specifies the exit code for the entire backup job.
stream_count Specifies that if the job starts normally, the stream count indicates
how may streams were started.
parent_start_notify script
NetBackup calls the parent_start_notify.cmd script (on Windows) or the
parent_start_notify script (on UNIX) each time a parent job starts.
clientname Specifies the name of the client from the NetBackup catalog.
status Specifies the exit code for the entire backup job.
streamnumber Specifies the stream number; for a parent job it's always -1.
pending_request_notify script
The NetBackup Media Manager calls the pending_request_notify script after a
pending request is issued for a media resource (tape volume). To send an email
notification when a pending request is initiated, include an email address in the
script where indicated. (A root user must run the script.)
On Windows: Copy
Install_path\NetBackup\bin\goodies\pending_request_notify.cmd into
Install_path\NetBackup\bin\ on the master server.
restore_notify script
The restore_notify.cmd script (on Windows) and the restore_notify script (on
UNIX) run on the server that contains the storage unit. The NetBackup tape or disk
manager (bptm or bpdm) calls the script when it finishes sending data to the client
during a restore. The script is called regardless of whether data is sent.
The scripts are located in the following directories:
On Windows: Install_path\VERITAS\NetBackup\bin\restore_notify.cmd
Reference topics 144
NetBackup notify scripts
On UNIX: /usr/openv/netbackup/bin/restore_notify
NetBackup passes the following parameters to the script:
programname Specifies the name of the program doing the restore or other read
operation.
session_notify script
The session_notify.cmd script (on Windows) and the session_notify script (on
UNIX) run on the master server. It's called at the end of a backup session if at least
one scheduled backup succeeded. NetBackup passes no parameters to this script.
Scheduling is suspended until this script completes, so no other backups can start
until that time.
The scripts are located in the following directories:
On Windows: Install_path\VERITAS\NetBackup\bin\session_notify.cmd
On UNIX: /usr/openv/netbackup/bin/session_notify
session_start_notify script
The session_start_notify.cmd script (on Windows) and the
session_start_notify script (on UNIX) run 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.
The scripts are located in the following directories:
On Windows: Install_path\VERITAS\NetBackup\bin\session_start_notify.cmd
On UNIX: /usr/openv/netbackup/bin/session_start_notify
shared_drive_notify script
NetBackup runs the shared_drive_notify.cmd script (on Windows) and the
shared_drive_notify script (on UNIX) when a shared drive is reserved or released.
RESERVED Specifies that the host on which the script is executed needs SCSI
access to the drive until it's released.
ASSIGNED Informational only. Specifies that the host that reserved the drive
needs SCSI access.
RELEASED Specifies that only the scan host needs SCSI access to the drive.
SCANHOST Specifies that the host that executes the script has become the
scan host. A host should not become a scan host while the drive
is RESERVED.
userreq_notify script
The userreq_notify.cmd script (on Windows) and the userreq_notify script (on
UNIX) run on the master server.
The scripts are located in the following directories:
On Windows: Install_path\VERITAS\NetBackup\bin\userreq_notify.cmd
On UNIX: /usr/openv/netbackup/bin/userreq_notify
NetBackup calls the script each time a request is made to either of the following:
■ List files that are in backups or archives
■ Start a backup, archive, or restore
You can change this script to gather information about user requests to NetBackup.
NetBackup passes the following parameters to the script:
action Specifies the action and can have the following values: backup,
archive, manual_backup, restore, list
■ When you restore the NetBackup catalog (for example, master server databases
and the EMM database), use backups from the same point in time.
■ Ensure that all names and numbers for devices and all media IDs and barcodes
are unique across the entire enterprise.
■ On UNIX hosts: To use the devices that NetBackup controls but are used with
other applications, do the following to avoid the potential loss of data:
■ Use the NetBackup tpreq command to mount media on a drive and
tpunmount to remove media from the drive. If you use these commands,
another application can control a device when NetBackup is finished with
the device.
Reference topics 147
Media and device management best practices
■ On Windows hosts: To use the devices that NetBackup controls but are used
with other applications, down the drive if the drive is in the UP state.
■ 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.
Reference topics 149
About TapeAlert
About 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.
For the drives that do not support TapeAlert, configure and use frequency-based
cleaning.
See “About frequency-based cleaning” on page 154.
■ The value for the mount time is greater than the cleaning frequency.
■ The TapeAlert CLEAN_NOW or CLEAN_PERIODIC flag is set.
And either of the following conditions must be true:
■ The drive is a standalone drive and a cleaning tape is not defined.
■ The drive is a standalone drive and no cleaning tape has any cleanings that
remain.
NetBackup displays NEEDS CLEANING as follows:
■ 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.
Note: NetBackup does not control the cleaning tapes that library-based cleaning
uses.
Symantec suggests following the recommendations from cleaning tape vendors for
the amount of tape usage. If you clean a tape past its recommended life, cleaning
delays can occur (due to excessive tape position operations) and drives can be
downed.
Alternatively, the new SCSI persistent reserve method may be more effective in
either of the following environments because it provides device status detection
and correction:
■ NetBackup media servers are 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.)
■ Environments where high drive availability is important
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, analyze the environment to ensure
that all of the hardware supports SCSI persistent reserve correctly.
NetBackup lets you configure either SCSI persistent reserve or SPC-2 SCSI
reserve.
The following table describes the protection options.
Option Description
SCSI persistent Provides SCSI persistent reserve protection for SCSI devices. The
reserve devices must conform to the SCSI Primary Commands - 3 (SPC-3)
standard.
SPC-2 SCSI reserve Provides SPC-2 SCSI reserve protection for SCSI devices. The
(default) devices must conform to the reserve method 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. The media server setting
for any drive path can be overridden.
SCSI reservations provide protection for NetBackup Shared Storage Option
environments or any other multiple-initiator environment in which drives are shared.
Reference topics 158
How NetBackup reserves drives
commands that cannot interfere with the reservation, such as Inquiry or Request
Sense.
A device stays reserved until one of the following events occurs on the device:
■ 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 can 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 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, one of the following actions must break the reservation:
■ SCSI reset
■ Bus device reset
■ 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 can 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. 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:
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 master server. Alternatively issue the command
on a media server and use the -h option of the command to specify the master
server. The NetBackup EMM service allocates devices (that is, the DA host or
device allocation host).
Note: Use this command after a PEND status appears in the NetBackup
Administration Console Device Monitor. However, do not issue this command
during backups.
Breaking a reservation
If you cannot release an SPC-2 SCSI reservation, 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.
Reference topics 162
How NetBackup reserves drives
Note: The reset operation can reset other devices in the configuration. Loss of data
is also possible. Try alternate methods first to break the reservation on a device
(by using switch and bridge hardware).
Lastly, if the following operating system commands cannot break the reservation,
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 Issue mt -f drive_path_name forcereserve.
2 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
◆ Issue st -f drive_path_name -r.
See the st(1m) man page for more information.
To break an SPC-2 reservation on AIX
◆ Issue tctl -f drive_path_name reset.
See the tctl man page (in the IBM AIX Commands Reference) for more
information.
See the NetBackup Device Configuration Guide, available at the following URL:
http://www.symantec.com/docs/DOC5332
The backup data may be usable. If so, import the image by using the NetBackup
bpimport command so the data is available for restores.
Order Description
1. 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 the backup job requires.
■ Not in a FULL, FROZEN, IMPORTED, or SUSPENDED state.
■ Of the same density that the backup job requested, and in the robot that the backup job requested.
■ Not currently in use by another backup or a restore.
■ Not written in a protected format. NetBackup detects the tape format after the volume is mounted. If the
volume is in a protected format, NetBackup unmounts the volume and resumes the search.
Order Description
2. 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 standalone drive, NetBackup automatically mounts and
assigns it. No manual intervention is required.
■ If a suitable volume is not in a robot or a standalone drive and the request is media-specific, NetBackup
may pend a mount request. A media-specific mount request is one for a restore, for an import, or from
the tpreq command.
■ If a suitable volume is not in a robot or a standalone drive, NetBackup may attempt to use another
volume only as follows: For backup jobs for which any other media can be used.
3. If a suitable volume does not exist or if a suitable volume is at end of media (EOM), NetBackup assigns a
new volume. 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:
4. 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.
5. If there are no unassigned volumes of the requested type, the backup terminates with an error message
that no media were available.
NetBackuptakes no action.
See “About spanning media with automatic media selection” on page 167.
■ 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 the media Allow backups to span media
property 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.
NetBackup selects unlabeled media only if the existing volumes that meet the
appropriate criteria do not have available space to contain the new backup images.
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 unlabeled, label it by using the bplabel command. Specify
the -u parameter to force assignment of a specific drive index, which eliminates
the need to assign the drive manually.
NetBackup searches for other media or generates a pending mount request. You
can configure a wait period for standalone drives. The wait period is helpful when
a gravity feed tape stacker takes a long time to load the next media in the drive.
To configure 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. After the wait period expires,
NetBackup searches for another drive. NetBackup also waits to generate a pending
mount request during tape span operations. The Media request delay property
applies only when standalone drive extensions are enabled.
Standalone
NB_pool
Robotic Off-site 1
Group 1 Group 2
Group 3 Group 4
Off-site 2
See Figure 6-3 on page 172. for examples of how 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).You also can configure a scratch pool from
which NetBackup can transfer volumes when a volume pool has no media available.
Reference topics 172
Volume pool and volume group examples
Robot A Standalone
Group Standalone Group
rob_A Group off-site
standalone1
NB_pool
_dept_1
NB_pool
_dept_2
Robot B
Group
rob_B
NB_pool
_dept_3
See Figure 6-4 on page 173. for an example where the scratch pool is named
Scratch_pool. The three robots contain volumes from that pool in addition to those
from other pools.
Assume the following sequence of events:
■ A backup job requires a DLT volume, so NetBackup 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.
■ 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.
Reference topics 173
Media formats
NB_pool_dept_1
Scratch_pool
Robot B - TL8
Group
rob_B
NB_pool_dept_2
Media formats
NetBackup writes media in a format that allows the position to be verified before
NetBackup appends new backups.
The following table shows the symbols that are used in the media format
descriptions.
Symbol Description
* Tape mark.
Symbol Description
BH1 ... BHn Backup headers (1024 bytes). One for each job that is part of the set of the
jobs that are multiplexed.
The following table provides more information about how the media formats are
used in different situations.
Format Description
Standard tape format For all tape media except quarter-inch cartridge (QIC) and WORM, the format for the
backups that are not multiplexed is as follows:
When a new backup image is added, the tape is positioned to the EH and the position
is verified. The EH is overwritten by a BH and the backup proceeds. When complete,
a new EH is written for future position validation.
When NetBackup encounters the end of media during a write operation, it terminates
the tape with two tape marks and does not write an EH.
QIC and WORM tape format This format is used for quarter-inch cartridge (QIC) and WORM media. Unlike the
standard tape format, NetBackup does not write empty backup headers (EH). The
format is as follows:
To append backup images to QIC media, NetBackup positions to the end of data (EOD)
and then starts the next backup.
Reference topics 175
Media formats
Format Description
Fragmented backup format 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
are specified when the storage unit is configured.
Fragmentation is intended primarily for storing large backup images on a disk type
storage unit.
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. NetBackup then starts multiplexing the revised set of jobs.
MH * BH1 BH2 BH3 Image* BH2 BH3 Image* BH2 BH3 BH4 Image
Spanning tape format 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) * *
UNIX /usr/openv/volmgr/bin
Windows install_path\VERITAS\Volmgr\bin
Command Description
acsd The Automated Cartridge System robotic process. The Device Manager
ltid starts this process.
ltid Starts the NetBackup Device Manager service. Starting the Device
Manager also starts the robotic, robotic control, Media Manager volume,
and automatic volume recognition daemons.
tl4d The tape library 4MM robotic process. The Device Manager ltid starts
this process.
tl8cd Starts the tape library 8MM robotic-control process. The Device Manager
ltid starts this process.
tl8d The tape library 8MM robotic process. The Device Manager ltid starts
this process.
To stop the tape library 8MM robotic-control process, use tl8cd -t.
tldcd Starts the tape library DLT robotic-control process. The Device Manager
ltid starts this process.
To stop the tape library DLT robotic-control process, use tldcd -t.
Reference topics 177
About Tape I/O commands on UNIX
Command Description
tldd The tape library DLT robotic process. The Device Manager ltid starts
this process.
tlhcd Starts the tape library Half-inch robotic-control process. The Device
Manager ltid starts this process.
tlhd The tape library Half-inch robotic process. The Device Manager ltid
starts this process.
tlmd The tape library Multimedia process. The Device Manager ltid starts
this process.
vmd The NetBackup Volume Manager service. The Device Manager ltid
starts this process.
On UNIX, you can use the kill pid command to stop the process for the daemon
with the specified pid (process ID).
On Windows, you can start and stop services by using the Services tool available
in Administrative Tools in the Microsoft Windows Control Panel. If they are started
from the command line, some services occupy that NetBackup Console session
until they are stopped.
For detailed information about most of the commands that are in the following tables,
see the NetBackup Commands Reference Guide, available at the following URL:
http://www.symantec.com/docs/DOC5332
is through this file name. Users do not have to be concerned with the full path to a
specific device file.
For all types of tapes, the tape is mounted and assigned when you enter the tpreq
command.
By default, NetBackup assigns drives that support DLT cartridge tapes. You can
use the density option on tpreq to request a drive that supports another density.
For a list of supported densities and drive types, see the tpreq man page.
The density for the physical write is not selected automatically on drives. It's
requested, so an operator can satisfy the correct drive. One of two methods is used
to determine the drive density: the /dev device name that was used when the drive
was configured or by how the drive is configured physically.
A tpreq command must include a media ID and a file name. If the tape volume is
associated with a volume pool, the name of the volume pool can also be specified
by using the -p parameter. If you specify the pool name, the name is validated
against the pool name that is associated with the media in the EMM database.
The NetBackup tpreq command runs the drive_mount_notify script (if it exists)
immediately after media is mounted in a pre-selected, robotic drive.
See “drive_mount_notify script (on UNIX)” on page 139.
See the NetBackup Commands Reference Guide, available at the following URL:
http://www.symantec.com/docs/DOC5332
Positioning tape files The mt command positions tape files by skipping forward or backward according to
tape marks.
The following options are available on the mt command for positioning tapes:
■ eof, weof
Writes an end-of-file tape mark at the current position on the tape according to the
count option on mt.
■ fsf, bsf
Spaces forward or backward the number of tape marks on the count option.
■ fsr, bsr
Spaces forward and backward the number of records according to the count option
on mt. bsr is only supported for the undefined record type.
The following example uses the mt command to skip forward three files on a tape:
mt -f tape1 fsf 3
Rewinding tape files When a file is rewound, it is positioned to the beginning of the data. To rewind a tape
file, you can use the mt command.
tape1 is positioned to the beginning of the tape volume that is associated with the file.
mt -f tape1 rewind
The count option is not used for the rewind operation. If you specify a count, mt ignores
it.
Symbols B
.ExTeNt.nnnn files 122 Backup Exec 63
@@MaNgLeD.nnnn files 122 backup_exit_notify script 127
@@MaNgLeD.nnnn_Rename files 122 backup_notify script 127
@@MaNgLeD.nnnn_Symlink files 122 backups
backup_exit_notify script 127
A backup_notify script 127
bpend_notify script
ACS or TLM robot types 59
UNIX client 134
ACS_ vm.conf entry 78
Windows client 136
ACS_CSI_HOSTPORT
bpstart_notify script
vm.conf entry 79
UNIX client 128
ACS_SEL_SOCKET
Windows client 131
vm.conf entry 79
compressed 119
ACS_SSI_HOSTNAME
diskfull_notify script 139
vm.conf entry 80
estimating time required 122
ACS_SSI_INET_PORT
multiplexed 119
vm.conf entry 80
session_notify script 144
ACS_SSI_SOCKET
session_start_notify script 144
vm.conf entry 81
blat mail 141
ADJ_LSM
bpclient commands 44
vm.conf entry 82
bpclntcmd utility 67
All Log Entries report 125
bpdynamicclient 47
Allow backups to span media 168
bpend_notify script
alternate client restores
UNIX client 134
host.xlate file 117
Windows client 136
Announce DHCP interval property 40
bpend_notify_busy script 139
API_BARCODE_RULES
bpstart_notify script 129, 133
vm.conf entry 83
UNIX client 128
Arbitrated Loop Physical Address (ALPA) 66
Windows client 131
AUTHORIZATION_REQUIRED
BPSTART_TIMEOUT 129, 133
vm.conf entry 84
busy file processing
AUTO_PATH_CORRECTION
bp.conf entries 50
vm.conf entry 84
Busy file settings property 48, 50
AUTO_UPDATE_ROBOT
configuration overview 48
vm.conf entry 85
configuring on UNIX 49
AVRD_PEND_DELAY
creating action files 52
vm.conf entry 85, 164
logs directory 54
AVRD_SCAN_DELAY
modifying bpend_notify_busy 55
vm.conf entry 85
BUSY_FILE_ACTION bp.conf entry 51
BUSY_FILE_DIRECTORY bp.conf entry 50
Index 181
D
DAS_CLIENT
E
EMM_REQUEST_TIMOUT
vm.conf entry 87
vm.conf entry 89
DAYS_TO_KEEP_LOGS
EMM_RETRY_COUNT
vm.conf entry 88
vm.conf entry 88
device
ENABLE_ROBOT_AUTH
configuration wizard 68
vm.conf entry 89
delays 124
encrypted backups 121
file
extended attribute files 119
robotic 105
ExTeNt.nnnn files 122
using with other applications 146–147
device allocation host 58–59
Index 182
F licensing (continued)
files reconciling report results 17, 31
.ExTeNt.nnnn 122 reporting 16, 24, 26–29
@@MaNgLeD.nnnn 122 traditional 12
@@MaNgLeD.nnnn_Rename 122 locale, configuring 55
@@MaNgLeD.nnnn_Symlink 122
goodies scripts 126 M
name on tpreq 178 mail_dr_info.cmd 140
positioning on tape 179 mail_dr_info.sh 140
firmware levels 64, 66 MAP_CONTINUE_TIMEOUT
FlashBackup 119 vm.conf entry 90
frequency-based drive cleaning 154 MAP_ID, vm.conf entry 90
Front-End Terabyte (FETB) Calculation 21 Maximum concurrent drives for backup 69
media
G best practices 147
GNU tar 119 formats 173
goodies directory 126 selection algorithm 166, 168
spanning 168–169
media and device management
H best practices 146
hold performance and troubleshooting 148
releasing 99 Media Manager
viewing hold details 98 best practices 146
holds configuration file 78
creating 98 security 94
host names media_deassign_notify script 141
changing client name 116 MEDIA_ID_BARCODE_CHARS
changing server name 114, 116 vm.conf entry 91
client peername 115 MEDIA_ID_PREFIX
correct use 114 vm.conf entry 92
robotic control selection 102, 105 MM_SERVER_NAME
short 116 vm.conf entry 92
host.xlate file and alternate client restores 117 multiple servers 34
HyperTerminal 65 multiplexing (MPX)
backups 175
I recovering backups 119
IBM tape format 175
device number 106 multistreamed backups 32
INVENTORY_FILTER
vm.conf entry 88–89 N
named data streams 119
L nbdeployutil 12–13, 22–24
library-based cleaning 153 nbdeployutil utility 27
licensing nbemm 57
about 12, 21 nbemm/DA
analyzing gathered data 14 definition 57
for Shared Storage Option 57, 63 nbholdutil -create 98
nbdeployutil 12–13, 22–23 nbmail.cmd 141
Index 183
servers (continued) T
NetBackup tape configuration utility. See tpconfig
multiple 34 tape drives, cleaning 153
SAN media server 61 tape formats 174
session_notify script 144 tape spanning 168–169
session_start_notify script 144 TapeAlert
shared drives. See SSO about 149
definition 63 cleaning flags 155
shared library support 62 frequency-based cleaning 149
shared robots log codes 150
without SSO 62 reactive cleaning 149
Shared Storage Option requirements 150
license key for 63 tapes and tape files
Shared storage option density 178
key 57 positioning tape file 179
shared_drive_notify script 61 reading and writing 178
Simple Mail Transfer Protocol 142 removing tape files 179
Solaris requesting tapes 178
extended attributes 119 rewinding 179
spanning media 167–169, 175 volume pool assignment 178
SSO tar used to read backup images 119
definition 57 tested SAN components 78
device allocation host 59 Timeouts host properties 129, 133
Device Allocation Host Summary 75 TLH_ vm.conf entry 95
hardware requirements 57 TLM_ vm.conf entry 96
scan host 58–59 tpconfig
Shared Drive Summary 75 about 102
supported SAN hardware 78 adding a drive 106
terminology 63 adding a robot 105
vm.conf entries 95 adding NDMP host credentials 109
SSO components configuration deleting a drive 108
examples 57 deleting robots 108
SSO_DA_REREGISTER_INTERVAL menus 103
vm.conf entry 94 Online Help 104
SSO_DA_RETRY_TIMEOUT printing device configuration 109
vm.conf entry 95 starting 104
SSO_HOST_NAME stopping 104
vm.conf entry 95 update drive configuration 107
standalone drive update robot configuration 107
extensions tpreq
disabling 169 requesting tapes 178
tpconfig 106 tpunmount
Storage area network (SAN) 57, 63–65 removing tape files 179
storage servers traditional licensing
creating 110 about 12
supported analyzing gathered data 14
SAN hardware 78 nbdeployutil 12–13
Symantec Backup Exec 63 reconciling report results 17
transfer rate 123–124
Index 185
U volume pools
userreq_notify script 145 examples 170
using devices with other applications 146–147 VxFS
extent attributes 122
named data streams 119
V
VERBOSE, vm.conf entry 96
veritas_pbx port 86 W
vm.conf file Windows, direct I/O 38
ACS_ entries 78 wizards
ACS_CSI_HOSTPORT entries 79 device configuration 68
ACS_SEL_SOCKET entries 79 shared drive configuration 68
ACS_SSI_HOSTNAME entries 80 writing tape files 178
ACS_SSI_INET_PORT entries 80
ACS_SSI_SOCKET entries 81
ADJ_LSM entries 82
API_BARCODE_RULES entries 83
AUTHORIZATION_REQUIRED entries 84
AUTO_PATH_CORRECTION entries 84
AUTO_UPDATE_ROBOTentries 85
AVRD_PEND_DELAY entries 85
AVRD_SCAN_DELAY entries 85
CLEAN_REQUEST_TIMEOUT entries 86
CLIENT_PORT_WINDOW entries 86
CLUSTER_NAME entry 86
CONNECT_OPTIONS entries 86
DAS_CLIENT entries 87
DAYS_TO_KEEP_LOGS entries 88
ENABLE_ROBOT_AUTH entries 89
INVENTORY_FILTER entries 88–89
MAP_CONTINUE_TIMEOUT entries 90
MAP_ID entries 90
MEDIA_ID_BARCODE_CHARS entries 91
MEDIA_ID_PREFIX entries 92
MM_SERVER_NAME entry 92
overview 78
PREFERRED_GROUP entries 92
PREVENT_MEDIA_REMOVAL entries 92
RANDOM_PORTS entries 93
REQUIRED_INTERFACE entry 93
SERVER entries 94
SSO_DA_REREGISTER_INTERVAL entries 94
SSO_DA_RETRY_TIMEOUT entries 95
SSO_HOST_NAME entries 95
TLH_ entries 95
TLM_ entries 96
VERBOSE entries 96
volume groups
examples 170
volume header device 106