Netbackup FAQs
Netbackup FAQs
Netbackup FAQs
Veritas NetBackup is an enterprise level backup and recovery suite. It provides cross
platform backup functionality to Windows, Linux, OpenVMS, Solaris, HP-UX, AIX,
IRIX, Tru64 and Mac OS X. NetBackup has the capability of communicating with
various robotic libraries and tape drives.
It is set up with a central master server that manages both media servers
(containing the backup media) and clients. Multiple NetBackup environments can be
managed by Net-Backup Operations Manager (NOM) which is bundled with the
NetBackup 6.0 distribution, which replaces the Global Data Manager (GDM)
component used in previous versions.
NetBackup comes with support for many hardware devices like tape drives, tape
libraries, disk units and supports, amongst many others, hot backups for major
database products like Oracle, can use Network Data Management Protocol (NDMP),
and has tape vaulting. NetBackup also enables LAN-Free and server-free backups in
SAN fabric environments.
A Windows NetBackup server has equivalent files and directories that are located in
the directory where NetBackup is installed (C:\Program Files\VERITAS by default).
The table “NetBackup Directories and Files - Servers and UNIX Clients” describes the
files and directories that are of special interest.
Bin: Commands, scripts, programs, daemons and files required for NetBackup
Operation and Administration. On a server, there are two subdirectories under bin.
goodies: (UNIX only) Contains scripts and information that may be useful to the
administrator. These subdirectories are not present on clients.
bp.conf: Configuration file where you can specify various options for NetBackup
operation. On a Windows server, these options are set in the interface.
Client: NetBackup client software that is installed on the clients during the
installation process. Do not install this directory on a media server.
Db: NetBackup databases as described in the table “NetBackup Databases”.
exclude_list: On UNIX clients, this file contains a list of files and directories to
exclude from scheduled backups. The help, Help files used by NetBackup programs.
These files are in ASCII format.
include_list: On UNIX clients, this file contains a list where you can specify a subset
of the exclude list to add back into scheduled backups.
Logs: Detailed debug logs for NetBackup processes. You must create the necessary
Sub directories in order for these log files to be written.
The table below, “NetBackup Daemons and Programs”, describes the programs and
daemons that provide most of the control for backup, archive, and restore
operations. The explanations include what starts and stops the program or daemon
and the debug log subdirectory (if any) where it records its activities. (You must
create the subdirectory manually.)
Release notes: NetBackup release notes in ASCII format, so you can conveniently
view or print them.
bpcd On UNIX clients, bpcd is the NetBackup client daemon and lets NetBackup
start programs on remote hosts (can be UNIX clients or other
servers). For example, the server can connect to UNIX clients
without requiring /.rhosts entries on the remote host. The
program is used when bpsched starts bpbrm and when bpbrm
communicates with the client. (For a description of the
NetBackup client daemon on PC clients, see BPCDW32.EXE,
BPCD.NLM, and NetBackup BPCD later in this table.)
Started By: inetd.
Stopped By: Completion of operation.
Debug Log: bpcd.log on both client and server.
bpdm On master and media servers, bpdm is the disk-media manager and is used
when the storage unit type is a disk. This program manages the
transfer of images between the client and the operating-system
disk manager on the server to which the disk attaches.
Started By: For each backup or restore, bpbrm starts an
instance of bpdm, on the server with the storage unit.
Stopped By: Completion of operation.
Debug Log: bpdm.log on the server.
Bprd On master servers, the request daemon responds to client and administrative
requests for the following:
◆ Restores
◆ Backups (scheduled and user-directed)
◆ Archives
◆ List backed up or archived files
◆ Manual immediate backups (started through the NetBackup
administration interface manual backup option)
Started By: Initiate Request Daemon option on the Special
Actions menu in bpadm (also the
/usr/openv/netbackup/bin/initbprd command).
Stopped By: Terminate Request Daemon option on the Special
Actions menu in bpadm.
Debug Log: bprd.log on the server.
bplist On UNIX clients, this program communicates with bprd on the master server
when a user browses the database during a restore operation.
Started By: Starting a search of the image database by using
the client-user interface or executing The
/usr/openv/netbackup/bin/bplist command on the client.
Stopped By: Completion of operation
Debug Log: bplist.log on the client.
bptm On master and media servers, bptm is the tape-media manager and is used
when the storage unit type is Media Manager. This program
manages transfer of images between the client and the storage
device. It also handles communication between the backup and
Media Manager software. In addition, bptm manages the
NetBackup media database and provides information for the
media list report screen.
Started By: For each backup or restore, bpbrm starts an
instance of bptm on the server that has the storage unit.
Stopped By: Completion of operation.
Debug Log: bptm.log on the server.
jbpSA A Java-based program for performing backups, archives and restores of UNIX
clients.
Started By: On UNIX, the /usr/openv/netbackup/bin/jbpSA
command.
Debug Log: None, although the log for the bpbackup,
bparchive, bplist, and bprestore commands on the client can be
useful. Also, the logs for bpjava-msvc and bpjava-usvc can be
helpful. jnbSA A Java-based administration utility for managing
NetBackup and Media Manager on UNIX. In addition,
administration of supported UNIX systems can be performed by
using the NetBackup-Java Windows Display Console on a
Windows system.
Started By: On UNIX, the /usr/openv/netbackup/bin/jnbSA
command. On a NetBackup-Java Windows Display console, the
NetBackup - Java on host menu item on the
Programs/NetBackup menu.
Stopped By: Exit option in jnbSA.
Debug Log: None, although the logs for bpjava-msvc and
bpjava-usvc can be helpful.
NDMP Mover Agent On the NetBackup media server (Windows), this service acts as
an NDMP server in a type of three-way backup called Remote
NDMP.
Started By: Executing
install_path/netbackup/bin/InstallNdmpMoverAgent
path_of_NetBackup_binaries
Stopped By:Executing
install_path/netbackup/bin/InstallNdmpMoverAgent -r.
Debug Log: install_path/netbackup/logs/ndmpmoveragent
NBWIN.EXE For Windows clients, this is the executable file that starts the
client-user interface on Windows systems.
Started By: From the Windows Start menu, under
Programs/NetBackup.
Stopped By: Exiting the client-user interface.
Debug Log: mmddyy.log file in the NBWIN directory on the
client.
Tar On UNIX clients, the Tape Archive program is a special version of tar provided
with NetBackup and used to restore images.
Started By: For each restore, bpbrm starts an instance of tar on
the client.
Stopped By: Completion of restore operation.
Debug Log: tar.log on the client.
xbp Graphical display based client-user interface, on UNIX clients, with options for
starting user directed backups, restores, and archives.
Functionally, it is very similar to the menu version, bp.
Started By: /usr/openv/netbackup/bin/xbp command on the
client.
Stopped By: Quit option in xbp.
Debug Log: None, although the log for the bpbackup,
bparchive, bplist, and bprestore commands on the client may
also be useful for debugging problems with xbp.
NetBackup Databases
The below are the “NetBackup Databases”, describes the NetBackup databases.
These databases contain information that is used internally by NetBackup and reside
in the /usr/openv/netbackup/db directory on UNIX servers and in the
install_path\NetBackup\db directory on Windows NetBackup servers.
config Configuration information. This database resides on the master server and
has three parts:
policy: Contains information about each NetBackup policy.
config: Contains information about global attributes, storage
units, and database backups.
altnames: Contains information about client names for restores.
error Error and status information about NetBackup operations. This database
resides on the master server and has two parts:
error: Contains information recorded during backup operations
and used in the NetBackup reports. failure_history: Contains
daily history of backup errors.
images Information about the backup images and resides only on the
master server. One of the files in the images directory is the file
database. The file database is the one that NetBackup accesses
when a user browses for files to restore.
jobs Job information that is used by the NetBackup job monitor (UNIX NetBackup
server) and activity monitor (Windows NetBackup server). The
Jobs database is on the master server.
media Media related information used by bptm. Each master or media server has a
media database with media information for the images stored
on that server’s storage units. The media database also has an
errors file that contains error history information for media and
devices.
Bprd
Bpdbm
Ltid
Vmd
Avrd
On media server
Ltid
Vmd
Avrd
Security
Data Encryption
Access Control
Performance
Synthetic Backups
Disk Staging
Checkpoint restart
Multiplexed Backup
Multi-streamed Backup
Inline Copy
Online NetBackup catalog backup
Media Management
Enterprise Media Manager
Automatic robotic/tape drive configuration
Broad tape device support
Heterogeneous Support
Broad platform support
Support for leading networking topologies
Advanced software and hardware snapshot support
· In 1990, Control Data formed the Automated Workstation Backup System (AWBUS)
business unit. The first version of AWBUS supported two tape drives in a single
robotic carousel with the SGI IRIX operating system.
· In 1993, Control Data renamed the product Aria*Backup Plus 1.0. (This is why
many NetBackup commands have a 'bp' prefix.) Support for media Volume
Management and Server Migration/Hierarchical Storage Management was added.
· In the end of 1993, the product and Control Data’s Storage Management 12-person
team were acquired by Openvision. This is why, on UNIX platforms, NetBackup
installs into /usr/openv. During this time, Open Vision renamed Backup Plus to
NetBackup.
Disk staging - Backup data is written to hard disk rather than directly to tape
(usually a slower technology). Then the data stored in the disk staging area is
written to tape in a background process.
Checkpoint Restart
Minimum value of checkpoint in NetBackup is 5 minutes for backups, i.e. during
backups checkpoint will be placed every 5 minutes. Hence in case when system
recovers from a failure, the backup operation (which went into error due to failure)
can resume from a point which was at most 5 minutes prior failure. Minimum value
in case of restores is 1 minute.
A snapshot is a virtual copy of a device or a File system. Suppose you perform LAN
free backups but have an application for which there is no API or can’t afford the API
for an application. You are therefore required to shut down the application during
backups. You want something better bur aren’t yet ready for the cost of client-free
backups, not do you need all the functionality they provide. Therefore, you need the
type of snapshots that are available only from an advanced filesystem, a host-based
volume manager, or a backup software add-on product that emulates this
functionality. An enterprise storage array that can create snapshots (that are visible
from the host of which the snapshot was taken) also works fine in this situation, but
it isn’t necessary.
When you create a snapshot, the snapshot software records the time at which the
snapshot was taken. Once the snapshot is taken, it gives you and your backup utility
another name through which you may view the snapshot of the device or Filesystem.
It looks device or Filesystem, but it’s really a symbolic representation of the device.
Creating snapshot doesn’t actually copy data from disk a to disk a.snapshot, but it
appears as if that’s exactly what happened, if you look at diska.snapshot, you see
diska exactly as it looked at the moment diska.snapshot was created.
Creating the snapshot takes only a few seconds. Sometimes people have a hard time
grasping how the software can create a separate view of the device without copying
it. This is why it’s called a snapshot; it doesn’t actually copy the data, it merely took
a “picture” of it.
Once the snapshot has been created most snapshot software (or firmware in the
array) monitors the device for activity. When it sees that a block of data is going to
change, it records the “before” image or that block in a special logging area (often
called the snapshot device). Even if a particular block changes several times, it only
needs to record the way it looked before the first change occurred.
Recovery Speed: This is the only reason you are backing up, right? Many people fail
to take recovery speed into consideration when designing a backup and recovery
system when they should be doing almost the opposite. They should design a backup
and recovery system in such a way that it can recover the system within an
acceptable window. In almost every case, this also results in a system that can
backup the system within an acceptable window.
If your backup system is based on moving data from disk to tape, and your recovery
system is based on moving data from tape to disk, the recovery time is always a
factor of the question in the previous section. They boil down to two basic questions:
how much data do you have to move, and what resources are available to move it?
Calculate data rate of backup: In order to understand the speed of NetBackup, you
need to understand the hardware that you have.
To calculate what you expect to be the data rate for backups, take the following
calculation: Tape Drive MB/Sec x (Compression factor – Usually 1.5) x 3600 / 1024
to give you your rate per hour in Giga Bytes. e.g. A DLT7000 rated at 5MB/sec is:
5MB/sec x 1.5 x 3600 / 1024 = 26.4GB/hr. A LTO will be 79GB/hr.
RAID Levels:
Level Description
RAID: A disk array in which part of the physical storage capacity stores redundant
information about user data stored on the remainder of the storage capacity.
The redundant information enables regeneration of user data in the event that one of
the array’s member disk or the access data path to it fails.
RAID combinations
Raid 0+1: (Mirrored Stripes) The server sees only the virtual hard disk. Internally,
the RAID controller realizes the virtual disk in two states: in the first stage it brings
together every four physical hard disk into one virtual hard disk that is only visible
within the RAID controller by means of RAID ) (Striping). In the second stage it
consolidates these two virtual hard disk by means of RAID 1 (mirroring) to form the
hard disk that is visible to the server.
Raid 10: The server sees only the virtual hard disk. Internally the RAID controller
realizes the virtual disk in two stages: The RAID controller initially brings together
the physical hard disk in pairs by means of RAID 1 (mirroring) to form a total of four
virtual hard disks that are only visible within the RAID controller. In the second
stage, the RAID controller consolidates these four virtual hard disks into a virtual
hard disk by means of RAID 0 (striping) to form the hard disk that is visible to the
server.
Backup Types
a. Full Backup
Is the starting point for all backups, and contains all the data in the folders and files
that are selected to be backed up. Because the full backup stores all files and folders,
frequent full backups result in faster and simpler restore operations. When you
choose other backup types, restore jobs make take longer.
b. Differential Backup
Differential backup contains all files that have changed since the last full backup. The
advantage of a differential backup is that it shorts restore time compared to a full
backup or an incremental backup.
c. Incremental Backup
Incremental backup stores all files that have changed since the last Full, Differential
OR Incremental backup.
Advantages: Backing up is the fastest
The storage space requirements are the lowest.
Disadvantages: Restore is the slowest.
d. Synthetic Backup
A synthetic backup is a backup image created without using the client. Instead, a
synthetic backup process creates a full or a cumulative incremental image using only
previously created backup images, called component images.
Eg. An existing full image and subsequent differential incremental images may be
synthesized to create a new full image. The previous full image and the incrementals
are the component images. The new synthetic full image behaves like a backup
created through the traditional process. The new synthetic full image is a backup of
the client that is as current as the last incremental. The synthetic image is created
by copying the most current version of each file from the most recent component
image containing the file. A synthetic backup must be created in a policy with the
True Image Restore with Move Detection option selected. This option enables the
synthetic backup to exclude files that have been deleted from the client file system
from appearing in the synthetic backup.
Like a traditional backup, a synthetic backup is typically initiated by the scheduler,
bpsched. Bpsched starts bpsynth, and bpsynth starts bpcoord. Bpsynth controls the
creation of the synthetic backup image, and bpcoord controls the reading of the files
needed from the component images. Bpsynth and bpcoord executed on the master
server. If directories name bpsynth and bpcoord exist in the debug log directory,
additional debug log messages will be written to log files in those directories.
Bpsynth makes a synthetic image in three phases: (1) preparation, (2) data copy,
and (3) validation. In phase 1 bpsynth makes a synthetic backup request to the
database manager, bpdbm. Bpdbm uses the entries and the TIR information from
the catalogs of the earlier component images to build the catalog for the new
synthetic image and the extents to be copied from the component images to the
synthetic image. Bpdbm returns the list of extents to bpsynth. (An extent is the
starting block number and the number of contiguous blocks within a specific
component image.)
There will usually be a set of extents that need to be copied from each component
image onto the new synthetic image.
Bpsynth also “suspends” tape volumes containing the component images so that
they will not be chosen for the output image. (Input volumes are not suspended if
they are already frozen or suspended.) The tape volumes suspended in this step will
be un-suspended after the data copy phase completes.
In the data copy phase (2), bpsynth starts bpcoord. Bpsynth starts the writer bptm
(for tape) or bpdm (for disk) on the media server to write the new synthetic image.
The required extents for each component image are sent to bpcoord. Bpcoord starts
a reader bptm (for tape) or bpdm(for disk) process for each component image on the
media server where the component image was written. The reader process will read
all extents for the component image.
bpcoord will start bptm on the media server only if a tape drive is available in the
storage unit to be used to read the image. The storage unit used is the one on which
the component image was written. For instance, if there are three component images
to read and only one drive is available in the storage unit, then the first bptm reader
process will be started. The second reader process will be started after the first one
completes and the third reader process will be started after the second one
completes. However, if three drives are available in the storage unit, then all three
reader processes will be started simultaneously. Note that if the component images
reside on disk, then all bpdm readers will be started immediately since disk is not a
manageable resource.
Note that bpsynth/bpcoord only start the parent bptm/bpdm reader/writer process
on the media server. The parent in turn starts a child process. The parent and child
communicate via buffers in shared memory.
The bpsynth process sends the extents (starting block and count) for each
component image to the corresponding child bptm/bpdm reader process.
The parent bptm/bpdm reader process reads the data from the appropriate media
into the shared buffers. The child bptm/bpdm reader process sends the data in the
shared buffers to the child bptm/bpdm writer process over a socket. The child
bptm/bpdm writer process writes the data into the shared buffers. The parent
bptm/bpdm writer process copies the data from the shared buffers to the media.
The parent bptm/bpdm writer process notifies bpsynth when the synthetic image is
complete. The bpsynth process then validates the image. The new image is now
visible to NetBackup and can be used like any other full or cumulative incremental
backup.
◆ That the component images are made with NBU 5.0 or later clients, or that they
are synthetic images.
◆ That the component images use the binary catalog format, not the ASCII catalog
format.
a. Media Manager Storage Units: A Media Manager storage unit uses tape robots,
standalone tape drives, or optical disk devices, that are under control of Media
Manager. Media Manager controls the allocation and mounting of media (called
volumes) in the storage devices.
b. Disk Storage Units: A disk type storage unit consists of a directory on a hard
disk that stores the backup or archive data. NetBackup permits an unlimited number
of disk storage units.
c. NDMP Storage Units: NDMP storage units are controlled by Media Manager but
attach to NDMP hosts and require that you have the NetBackup for NDMP option
installed.
Differences Between
A regular backup can backup and restore individual files. A "True Image" backup is a
snapshot of files done at the directory level at a certain point in time. Additionally,
when a "True Image" backup is restored, the directory restored will be brought to
the same state as when it was backed up. Any files or sub-directories that did not
exist at the time of backup will be deleted when the restore occurs if it is restored to
the same location.
Turn on Move Detection when using True Image Recovery. Without Move Detection,
TIR restores will not notice files that have moved within the filesystem (because they
don't change their modification time).
When a backup is made, a copy of the file is written to media. When an archive is
made, a copy of the file is written to media and then the original file is deleted.
A cumulative incremental backup is the backup of all files that have changed since
the last full backup.
A differential incremental backup is the backup of all files that have changed since
the last backup.
Multiplexing sends data from multiple sources to a single tape or disk device. This is
useful if you have a tape or disk device that writes faster than a single system can
send data, which (at this point) is just about every tape device.
Multistreaming establishes multiple connections, or threads, from a single system to
the backup server. This is useful if you have a large system with multiple I/O devices
and large amounts of data that need backing up.
LAN – FREE BACKUPS: LAN free backups occur when several servers share a single
tape / optical library and the drives within it. Each server connected to the SAN can
backup to tape drives it believes are locally attached. The data is transferred via the
SAN using the SCSI-3 protocol and thus doesn’t use the LAN> All that is needed is
software that will act as a “traffic cop.”
CLIENT FREE BACKUPS: The backup data is sent via the SAN to the backup server
and doesn’t travel through the client at all. Which is why it is referred to as client-
free backup. In order to implement a client free backup there has to be a SAN
connected storage that is available to at least two systems: the data server and the
backup server. The storage consist of a primary disk set and the backup mirror,
which is simply and additional copy of the primary disk set.
SERVER FREE BACKUPS: A truly server-free backup has a data path that doesn’t
include a server. It uses a server, of course, to control the process, but the data
moves directly from disk to tape without going through any server’s CPU including
the backup server. There are 3 essential requirements of server-free backups. You
must be able to:
1. Present the backup application with a static view of the disk set.
2. Map the blocks of data on the disk set to the files to which they belong.
3. Move the data directly from disk to tape.
CATALOG:
Use Catalog to create and configure a special type of backup NetBackup requires for
its own internal databases—a catalog backup. These databases, called catalogs, are
on the NetBackup server's disk and have setup information as well as critical
information on client backups. The catalog backups are set up and tracked
separately from other backups to ensure recovery in case of a server crash.
Catalog is also used to search for a backup image in order to verify the contents of
media with what is recorded in the NetBackup catalog, to duplicate a backup image,
to promote a backup image from a copy to the primary backup copy, to expire
backup images, or to import expired backup images or images from another
NetBackup server.
a. Catalog Files
Masterserver: /usr/openv/netbackup/db/
Masterserver: /usr/openv/netbackup/db/images/masterserver
Masterserver: /usr/openv/var
Masterserver: /usr/openv/netbackup/db/media
Masterserver: /usr/openv/volmgr/database
Netbackup Logs
UNIX: /usr/openv/netbackup/logs
Windows: install_path\NetBackup\logs
The table below lists the debug log directories that apply to servers. When these
directories exist, NetBackup creates log files in the directory for the associated
process.
Debug Log
Directory Associated Process
admin Administrative commands.
vnetd The VERITAS network daemon, used to create “firewall friendly” socket
connections. Started by the inetd(1M) process.
The following is a list of facts to be familiar with before using debug logs:
◆ On UNIX systems, NetBackup retains debug logs for the number of days you
specify with the Keep Logs for global attribute (28 days by default) and then deletes
them.
On Windows systems, NetBackup retains debug logs for the number of days you
specify with the Duration to Retain Logs global attribute (28 days by default) and
then deletes them.
◆ Debug logs can grow very large. Enable them only if unexplained problems exist
and delete both the logs and the associated directory when they are no longer
needed.
◆ A debug log file is created when the process begins. Therefore, you must create
the directory for a debug log before the process starts.
◆ On Windows systems, set the Global Logging Level to a higher level, in the
Logging dialog/tab under Master Server properties.
Caution: High verbose values can cause debug logs to become extremely large.
◆ Also note: You can use the Logging dialog/tab under Master Server Properties to
set the logging level for individual processes.
To enable debug logging on UNIX clients, create the appropriate directories under:
/usr/openv/netbackup/logs
bplist Program that lists backed up and archived files. This debug log is also useful
for debugging xbp and bp processes.
The following table lists the debug log directories that apply to the above clients:
PC Client Debug Logs.
Debug Log
Directory NetBackup Client Associated Process
Note: You must enable system logging to troubleshoot ltid or robotic software. See
the syslogd(8) man page for information on setting up system logs. If a problem
requires more information, enable debug logging to the system logs by including the
verbose option (-v) on the command that you use to start a daemon. This command
can be:
◆ The ltid command that started the device management processes. If the -v option
is included on the ltid command, all daemons started as a result also have the –v
option in effect.
or
◆ A command to start a specific daemon (for example, acsd -v). Alternatively, put a
VERBOSE entry in the Media Manager configuration file, /usr/openv/volmgr/vm.conf,
and restart ltid (create the vm.conf file if necessary).
To enable debug logging for the Media Manager Volume daemon (vmd), create the
following directories before starting vmd (or stop and restart vmd after creating
them):
/usr/openv/volmgr/debug/daemon
(Debug information on the daemon)
/usr/openv/volmgr/debug/reqlib
(Debug information on the process requesting the daemon)
/usr/openv/volmgr/debug/tpcommand
(Debug information on the tpconfig and tpautoconf commands)
/usr/openv/volmgr/debug/ltid
(Debug information on ltid)
/usr/openv/volmgr/debug/acssi
(Debug information on transactions between NBU and the Storage Tek ACSLS
server)
Media Manager creates one log per day in each of the debug directories with file
names of the form:
log.mmddyy
For example: log.110894
install_path\Volmgr\vm.conf
In addition, you can enable debug logging for the NetBackup Volume Manager
service by creating the following directories:
install_path\Volmgr\debug\daemon
(Debug information on the service)
install_path\Volmgr\debug\reqlib
(Debug information on the process requesting the service)
install_path\Volmgr\debug\tpcommand
(Debug information on the tpconfig and tpautoconf commands)
install_path\Volmgr\debug\ltid
(Debug information on ltid)
NetBackup creates one log per day in each of the above debug directories with file
names of the form:
mmddyy.log
For example: 110894.log
To disable debug logging for the NetBackup Volume Manager service, either delete or
rename the directories.
Media Manager retains debug logs for the number of days you specify with the
DAYS_TO_KEEP_LOGS = entry in the vm.conf file. (The default is infinite retention.)
Error Code 40
The connection between the client and the server was broken. This status code can
also appear if the connection is broken between the master and media server during
a backup.
Trouble-shoot:
1. Try pinging the client from the server. If this is not possible, check for loose
connections or other network problems.
2. Verify that the server list settings are correct on both the client and the server. If
the backup involves a media server, verify that these entries are correct on both the
master and media server. For example, if a media server does not have a server list
entry for the master, it does not accept connections from the master.
* On Windows, the master server is designated on the Servers tab in the Master
Server Properties dialog. To display this dialog, see "Using the Host Properties
Window" in the Troubleshooting Guide.
* On UNIX, and Macintosh systems, the master server is the first SERVER entry in
the bp.conf file.
If you change the server list on a UNIX master server, you must stop and then
restart the NetBackup Request daemon (bprd) and NetBackup database manager
daemon (bpdbm) for the changes to take effect. On Windows, stop and restart the
NetBackup Request Manager and NetBackup Database Manager services.
3. Status code 40 can also be due to the operator denying a mount request.
Run the NetBackup Configuration Validation Utility (NCVU) -conf <media server
option> and -conf <client option> checks for the associated NetBackup nodes.
Note the ping checks in section seven.
Error Code 13
A read of a file or socket failed. Possible causes include:
* I/O error reading from the file system.
* Read of an incomplete or corrupt file.
* Socket read failing. A socket read failure can be caused by a network problem or a
problem with the process that is writing to the socket.
* A problem specific to NetBackup Advanced Client (see recommended actions).
Trouble-shoot:
1. Check the NetBackup Problems report for clues on where and why the problem
occurred.
2. For a FlashBackup client, check the /var/adm/messages log for errors like the
following:
Mar 24 01:35:58 bison unix: WARNING: sn_alloccache: cache
/dev/rdsk/c0t2d0s3 full - all snaps using this cache are now unusable
This indicates that the cache partition is not large enough. If possible, increase the
size of the cache partition. Or, if multiple backups are using the same cache, either
reduce the number of concurrent backups by rescheduling some of them or
reschedule the entire backup to a time when the file system is less active.
3. For detailed troubleshooting information, create a debug log directory for the
process that returned this status code, retry the operation, and check the resulting
debug log.
If the disk is an IDE drive, you may see the following in the /usr/openv/
netbackup/logs/online_util log:
* The files to back up exist on a file system that is not mounted. The file system
specified as the snapshot source must be mounted. If the snapshot source is not
mounted but the mount point is present, NetBackup may try to take a snapshot of
the directory above the directory that was specified as the snapshot source.
Error Code: 50
The client backup aborted. One instance when this code appears is if a NetBackup
master or media server is shut down or rebooted when a backup or restore is in
process.
Trouble-shoot:
Try the following:
4. On UNIX clients, check the system log (/usr/adm/messages on Solaris) for system
problems.
1. Verify that the schedule specifies the correct storage unit and the storage unit
exists.
2. Verify that the Media Manager device daemon (ltid) is running (if the server is
UNIX) or the NetBackup Device Manager service is running (if the server is a
Windows system).
Use bpps on UNIX and the Activity Monitor on Windows or the Services application in
the Windows Control Panel.
3. Verify that the Maximum concurrent jobs attribute is not set to 0 (for a disk
storage unit) and the Maximum concurrent drives attribute is not set to 0 (for a
Media Manager storage unit).
4. If the storage unit is a tape or optical disk, verify that at least one of the drives is
in the UP state. Use the Device Monitor.
5. Verify that the robot number and host in the storage unit configuration matches
what is specified in the Media Manager device configuration.
6. Verify that the master server can communicate with the bpcd process on the
server that has the storage unit.
a. Verify that bpcd is listening on the port for connections.
b. If bpcd seems to be operating correctly, create bpsched and bpcd debug log
Directories and retry the operation. Check the resulting debug logs for records of an
earlier failure.
After each backup, the scheduler checks the storage unit to see how many drives are
available (in case the backup caused a drive to be automatically downed). If bpsched
cannot communicate with bpcd, it sets the number of available drives in that storage
unit to 0 and further backups to that storage unit during this backup session will fail.
The number of available drives remains at 0 until the scheduler is initialized again.
c. If the cause of the problem is not obvious, perform some of the steps in
"Resolving Network Communication Problems" in the Troubleshooting Guide.
7. Run the NetBackup Configuration Validation Utility (NCVU) -conf <media server
option> on the master server for the associated NetBackup media servers. Note the
policy, storage unit, and tpconfig checks in section five, and the bpcd checks in
section one.
Error Code: 55
The UNIX client does not have the server's name in its /.rhosts file.
Trouble-shoot:
Add the server name to the /.rhosts file on the UNIX client.
Error Code: 56
An error was returned that the host was unreachable by the client
(WSAENETUNREACH on Windows systems, or ENETUNREACH on UNIX systems)
when performing a system call.
Trouble-shoot:
Try to ping the client from the server. Check the IP address for the client. If you still
have problems, talk to your network administrator. Run the NetBackup Configuration
Validation Utility (NCVU) -conf <media_server option> and -conf <client option>
checks for the associated NetBackup nodes. Note the ping checks in section seven.
Error Code: 72
The policy type attribute in the policy configuration indicates that the client is one
type, but the installed software is for another type.
Trouble-shoot:
Verify that the policy type attribute for the policy is correct. Run the NetBackup
Configuration Validation Utility (NCVU) for the associated NetBackup clients. Note the
client software checks in section two.
Error Code: 92
When performing a restore, the tape manager (bptm) or disk manager (bpdm) could
not find a tar header at the offset it expected.
Trouble-shoot:
2. Check the NetBackup Problems report for additional information about the error.
3. Verify the Media Manager and system configuration for the drive.
For example, on some UNIX systems, for example, if you do not configure the drive
for variable-mode block size writes, backup images written to the media produce this
error when an attempt is made to restore the image. For example, you see the
following sequence of events:
* Backup succeeds
* Verify succeeds
* Restore fails
The bptm debug log shows an error similar to
00:58:54[2304]<16>write_data: write of 32768 bytes indicated only 29696 bytes
were written, errno=0
In this case, configure the drive for variable-mode block sizes and suspend media
written on that device. See the NetBackup Device Configuration Guide.
The images written to those media may be restorable (this is platform dependent),
but single file restores are almost guaranteed to fail. You can choose to expire these
media and regenerate the backups, or you can attempt to duplicate the images on
these media to another device and then expire the original copy.
4. Error code 92 has been encountered on some relabeled and value-added 8-mm
tape drives where the drive's microcode incorrectly processes a "forward space
record" SCSI command.
5. If the problem is not one of the above, create a debug log directory for either
bpdm or bptm and retry the operation. Check the resulting debug log file.
Add the media IDs to the catalog backup configuration. Verify that the media IDs are
in the NetBackup volume pool. Run the NetBackup Configuration Validation Utility
(NCVU) on the master server. Note the NetBackup database configuration checks in
section six.
Trouble-shoot:
Trouble-shoot:
The 134 code is an informational message only and is not considered an error. It can
occur for a number of reasons in normal operation.
The 134 status code can occur more frequently in an SSO environment. No action is
necessary.
A 134 status is not logged in the error logs (as of versions 3.4 MP4 and 4.5 MP2).
A 134 status will cause a new try to show up in the Activity Monitor, but will not
increment the retry count associated with the number of retries allowed.
Trouble-shoot:
* If volume is in a DOWN drive, remove it and place it in its designated slot. Then,
retry the restore.
* If the volume is in the wrong slot, use a robot inventory option to reconcile the
contents of the robot with the Media Manager volume configuration.
BP.CONF Entries:
· Use BPBACKUP_SCHED to set the default schedule used for client initiated
backups.
· Use BPEND_TIMEOUT to increase the amount of time bpend scripts have to finish
(don~Rt forget CLIENT_READ_TIMEOUT must be greater than or equal to
BPEND_TIMEOUT).
· Use BUSY_FILE_ACTION to send email notification, try again, or ignore files that
cannot be accessed.
· BUSY_FILE_DIRECTORY sets the working temp directory when using busy file
processing.
· CLIENT_NAME specifies the exact name that the client is known as to the Net-
Backup server(s) it is served by.
· Use SERVER to specify the NetBackup server(s) the client should use.
What are the client type values, as used in bpbackup -t client type?
standard = 0
apollo = 3
auspex = 12
afs = 22
msnt = 13
netware = 10
os2 = 14
SAP = 17
MS-SQL = 15
SQL-Backtrack = 11
Sybase = 7
DB2 = 18
Oracle = 4
MS-Exchange = 16
Informix = 6.
NDMP: The Network Data Management Protocol (NDMP) defines a mechanism and
protocol for controlling backup and recovery between primary and secondary
storage. The purpose of NDMP is to allow a network backup application to control the
backup and recovery of an NDMP-compliant server without installing third-party
software on the server.
NDMP SERVICES
The daemon or server on the NDMP host that is controlled using the NDMP protocol.
There are three types of NDMP Services: Data Service, Tape Service, and SCSI
service.
A NDMP Service that transfers data between primary storage and the Data
Connection. Data services provide and abstracted interface to the filesystem or
primary storage on the NDMP server.
A data service is the source of data during backup operations and the destination
during recovery operations.
B. TAPE SERVICES (TRANFERS DATA BETWEEN SEC STORAGE AND NDMP SERVERS)
A NDMP service that transfers data between secondary storage and the Data
Connection and allows the DMA to manipulate and access secondary storage. Tape
services provide an abstracted interface to tape devices or other types of secondary
storage attached tot he NDMP server. A tape library may implement its own NDMP
server and associated tape service or may be connected through an external NDMP
server. A tape service is the source of data during recovery operations and the data
destination during backup operations. The tape service also provides a mechanism
for tape positioning and I/O on behalf of the DMA.
A NDMP Service that passes low-level SCSI commands to a SCSI device typically
used by the DMA to manipulate a SCSI or Fibre Channel attached Media Changer.
This answer assumes the hostname of your NDMP box is "HPNAS" and the hostname
of your Master Server is "HPMASTER".
Do the following:
4) Connect HPNAS to one of the drives in your Jukebox, and reboot it so it can
recognize the drive.
Check to make sure the drive is recognized after reboot:
HPNAS % sysconfig –t
This will show you the drive, and all device files you can use with it.
Use the norewind device nrst0a. (or b.. whatever comes up in sysconfig's output)
6) Come back to master server (HPMASTER), and add the NDMP drive:
Pull up xdevadm, select DRIVES -> ADD DRIVE.
This will pull up the ADD DRIVE window. In that window, select/provide the following
information:
DRIVE TYPE: DLT (or whatever type your drive is)
DRIVE INDEX: 0 (or any number of your choice)
DRIVE NAME: HPNAS_jukeboxname_drive# (or what ever you like)
NO REWIND DEVICE: HPNAS:nrst0a
DRIVE STATUS: UP
CLEANING FREQUENCY: 300 (or what ever you like)
ROBOTIC DRIVE: YES
ROBOT TYPE: TLD (or what ever type your Jukebox is)
ROBOT NUMBER: <your robot's number>
ROBOT DRIVE: <drive number of the drive thats connected to HPNAS>
At this point, you're ready to test NDMP backups. Use xbpadm to create a class of
type NDMP, and include HPNAS as client, and a sample directory under file list.
Create a schedule "manual_backup" dont put any regular dates on it, and start a
manual backup of that NDMP class for HPNAS and see how it goes.
You do not have to install any software on HPNAS. All you need to do is start ndmpd.
You want to put that in its rc file so its started every time its rebooted.
A. FILER TO SELF
If the data service and tape service are both running within a single filer, this is
referred to as filer to self. Even if you have multiple filers sharing a tape library via a
SAN, this is referred to as Filer to Self.
B. FILER TO FILER
If the data service is on one filer, and the tape service is on another filer, this is
referred to as Filer to Filer.
C. FILER TO LIBRARY
A variation on Filer to Filer is when the tape service is running on an NDMP-
compatible tape library. Each tape drive within such a tape library has a small
computer running the NDMP tape service. Since the tape drives appear as a filer to
the DMA, this might be referred to as Filer to Filer. However, I'd like to use the term
Filer to Library.
D. FILER TO SERVER
If the data service is on filer, and the tape service is running on a non-filer server
controlled by the DMA, this is referred to as Filer to Server. Eg. If a filer was being
backed up via a NDMP to a Unix of NT Backup server running a commercial backup
product, it's called Filer to Server.
E. SERVER TO FILER
If the DMA-routed backup data coming for a non-NDMP backup client is routed to an
NDMP tape server, it's referred to as server to filer. This configuration is extremely
rare.