What is Veritas NetBackup?

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.

NetBackup Directories and Files

The figure below, “NetBackup Directories and Files - UNIX Servers and Clients”
shows the NetBackup files and directory structure on UNIX servers and clients. If a
host is only a client and not a server, then only the files in the lower part of the
graphic “NetBackup Directories and Files - UNIX Servers and Clients” are present. If
a host is both a client and a server, the client component shares files as necessary
from those in the upper part of the graphic “NetBackup Directories and Files - UNIX
Servers and Clients”.

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.

NetBackup Directory Structure -- UNIX

NetBackup Directories and Files - UNIX Servers and Clients
NetBackup Directories and Files - Servers and UNIX Clients

File or Directory Contents

Bin: Commands, scripts, programs, daemons and files required for NetBackup
Operation and Administration. On a server, there are two subdirectories under bin.

admincmd: Contains various commands used internally by NetBackup. Use these

commands ONLY if they are documented. Most of these commands are not
documented and should not be used directly.

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.

release_notes: NetBackup release notes in ASCII format, so you can conveniently

view or print them.

Version: Version and release date of the software.

NetBackup Programs and Daemons

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.

version Version and release date of the software.

bp On UNIX clients, this menu-driven, character-based interface program has
options for starting user- directed backups, restores, and
archives.
Started By: /usr/openv/netbackup/bin/bp command on the
client.
Stopped By: Exiting the interface program.
Debug Log: /usr/openv/netbackup/logs/bp on the client. The
debug logs for bpbackup, bparchive, bprestore, and bplist also
have information about bp activities.

bpadm On a UNIX master server, this administrator utility has a menu-

driven, character-based, interface with options for configuring
and managing NetBackup.
Started By: /usr/openv/netbackup/bin/bpadm command on the
master server.
Stopped By: Quit option from within bpadm.
Debug Log: admin.log on the server.

bparchive On UNIX clients, this program communicates with bprd on the

master server when a user starts an archive.
Started By: Starting an archive by using the client-user
interface or executing the /usr/openv/netbackup/bin/bparchive
command on the client.
Stopped By: Completion of operation.
 Debug Log: bparchive.log on the client.

bpbackup On UNIX clients, this program communicates with bprd on the

master server when a user starts a backup.
Started By: Starting a backup by using the client-user interface
or executing the /usr/openv/netbackup/bin/bpbackup command
on the client.
Stopped By: Completion of operation
Debug Log: bpbackup.log on the client.

bpbrm On master and media servers, the Backup/Restore Manager

manages the client and media manager processes and uses
error status from both to determine the final status of backup
or restore operations.
Started By: For each backup or restore, bpsched starts an
instance of bpbrm on the server with the appropriate storage
unit.
Stopped By: Completion of operation.
Debug Log: bpbrm.log on the server. bpbkar On UNIX clients
the Backup/Archive Manager generates the backup images.
Started By: bpbrm on the server with the storage unit.
Stopped By: Completion of operation.
Debug Log: bpbkar.log on the client.

BPBKAR32 On Windows clients, the Backup/Archive Manager generates the

backup images.
Started By: BPCDW32 on the client.
Stopped By: Completion of operation.
Debug Log: BPBKAR.LOG file in the NetBackup logs directory on
the client.

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.

BPCDW32.EXE On Windows 95 and NT/2000, XP and Windows Server 2003

clients, this is the executable file that starts the NetBackup
client daemon.
Started By: When Windows starts if the daemon is in the
Startup group. Otherwise, by double clicking on its icon.
Stopped By: On Windows NT/2000, XP and 2003, you can stop
it through the Services application in the Control Panel. On
Windows 95, you can stop it by clicking on its icon and choosing
Close.
 Debug Log: BPCD.LOG file in the NetBackup logs directory on
the client.

bpdbjobs On UNIX master servers, this program is used to clean up the

NetBackup jobs database.
Started By: /usr/openv/netbackup/bin/admincmd/bpdbjobs.
When bprd starts, it runs this command automatically. The
administrator can also execute it manually or with a cron job.
Stopped By: There is no terminate option for this command
outside of using kill.
Debug Log: bpdbjobs.log on the server.

bpdbm On master servers, the NetBackup database manager program

that manages the configuration, error, and file databases.
Started By: bprd (also by /usr/openv/netbackup/bin/initbpdbm
on UNIX)
Stopped By: /usr/openv/netbackup/bin/bpdbm -terminate
command on UNIX and by stopping the NetBackup Database
Manager service on Windows.
Debug Log: bpdbm.log on the 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.

bphdb On UNIX database-extension clients, bphdb starts the NetBackup hot-

database-backup program.
Started By: Client-user interface when the user starts a
database backup or restore operation.
Stopped By: Completion of operation.
Debug Log: bphdb.log on the client. With NetBackup for Oracle,
bphdb also writes to /usr/openv/netbackup/logs/obackup_tape.

bpjava-msvc NetBackup-Java master server application program. This

program runs on all NetBackup UNIX Systems and
authenticates users that start the NetBackup-Java interface
programs.
Started By: inetd during startup of the NetBackup Java
interfaces.
Stopped By: When authentication is complete.
Debug Log: /usr/openv/netbackup/logs/bpjava-msvc bpjava-
usvc NetBackup-Java user server application program. This
program services all requests from the NetBackup-Java user
and Administration interfaces.
Started By: bpjava-msvc upon successful login through the
Login dialog box that is presented when a NetBackup-Java
interface is started.
Stopped By: When the interface program is terminated.
 Debug Log: /usr/openv/netbackup/logs/bpjava-usvc

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.

bprestore On UNIX clients, this program communicates with bprd on the

master server when a user starts a restore.
Started By: Starting restore by using the client-user interface
(or by executing the /usr/openv/netbackup/bin/bprestore
command on the client).
Stopped By: Completion of operation
Debug Log: bprestore.log on the client.

bpsched On master servers, the Scheduler uses policy information from

the NetBackup configuration databases to determine:
◆ Clients to start and when to start them.
◆ Storage units to use for backups and archives.
Started By: bprd for the following operations:
◆ User-directed backups and archives
◆ Immediate manual backups (started through the option that
is available in the NetBackup administrator interface)
◆ Scheduled automatic incremental or full backups. In this
case, bprd starts the scheduler at intervals determined by the
wakeup interval global attribute.
Stopped By: Completion of all backups that are due.
Debug Log: bpsched.log on the server.

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.

BPSYS.EXE On Windows NT/2000, XP and Windows Server 2003 clients,

this is the NetBackup System Registry Replacement utility.
Started By: NetBackup as required.
Stopped By: Completion of operation.
Debug Log: BPSYS.LOG file in the NetBackup LOGS directory on
the client.

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.

ndmpmoveragent On the NetBackup media server (UNIX), this daemon acts as an

NDMP server in a type of three-way backup called Remote
NDMP.
Started By: Executing
/usr/openv/volmgr/bin/ndmpmoveragent.start.
Stopped By: Executing
/usr/openv/volmgr/bin/ndmpmoveragent.stop.
Debug Log: /usr/openv/netbackup/logs/ndmpmoveragent

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.

TAR32 On Windows clients, the TAR32 program is a special version of

tar provided with NetBackup and used to restore images.
Started By: For each restore, NetBackup starts an instance of
TAR32 on the client.
Stopped By: Completion of restore operation.
Debug Log: TAR.LOG in the NetBackup logs directory 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.

Default NetBackup Processes:

Default processes which must be running on NetBackup server are:

Bprd
Bpdbm
Ltid
Vmd
Avrd

On media server
Ltid
Vmd
Avrd

Major features of NetBackup

Security
Data Encryption
Access Control

Performance
Synthetic Backups
Disk Staging
Checkpoint restart
Multiplexed Backup
Multi-streamed Backup
Inline Copy
Online NetBackup catalog backup

Management and Reporting

Web-based management reporting (VERITAS NetBackup Operations Manager)
Tape volume, drive and library viewing
Error message identification, categorization and troubleshooting

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

Major releases of Veritas Netbackup

6.5 was releases in 2007

6.4 was releases in 2007
6.0 was released in 2005
5.0 was released in 2003
4.5 was released in 2002
3.4 was released in 2000
3.0 was released in 1997
2.0 was released in 1996
1.6 was released in 1994 and the NetBackup name was coined

History of Veritas NetBackup

· In 1987, a backup software solution was written by a small group of engineers at

Control Data for Chrysler Corporation, and later adopted by other customers of
Control Data.

· 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.

· On May 6, 1997 Veritas acquired Openvision, NetBackup formally became a Veritas

product.

· In 2005 Symantec acquired Veritas and NetBackup became a Symantec product.

Also in this year, the 30th version of NetBackup was released as NetBackup 6.0.

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?

Snapshots are an alternate way to provide instantaneous recoveries. However,

snapshots (that have not been backed up to tape) only protect against logical
corruption, and the loss of too many drives on the primary disk set results in a
worthless snapshot. Therefore, client-free backups that use a backup mirror are the
only backup and recovery design that offers instantaneous recovery after the loss of
multiple drives on the primary disk set.

Speed of tape drives

• DDS2 rated as being able to write 1.6GB/hour native and 3.2GB/hour compressed.
• DDS3 3.5GB/7GB per hour
• DDS4 10GB/20GB per hour
• DLT4000 5GB/10GB per hour
• DLT7000 18GB/36GB per hour
• DLT8000 21GB/42GB per hour
• SDLT 38GB/76GB per hour
• LTO 53GB/106GB per hour
• LTO (Gen1) 100GB/200GB per hour
• LTO (Gen2) 200GB/400GB per hour
• LTO (Gen3) 400GB/800GB per hour
• LTO (Gen4) 800GB/1600GB per hour

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.

Level 0: Disk striping without data protection.

Level 1: Mirroring. All data is replicated on a number of separate disks.
Level 2: Data is protected by Hamming code. Uses extra drives to detect 2-bit errors
and correct 1-bit errors on the fly. Interleaves by bit or block.
Level 3: Each virtual disk block is distributed as with disk striping. Parity check is
stored in one disk.
Level 4: Data blocks are distributed as with disk striping. Parity check is stored in
one disk.
Level 5: Data blocks are distributed as with disk striping Parity check data is
distributed across all members of the array.
Level 6: Like RAID 5 but with additional independently computed check data.

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.

Advantages: Restore is the fastest.

Disadvantages: Backing up is the slowest.

The storage space requirements are the highest compared to incremental or

differential backups.

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.

Advantages: Restore is faster than restoring from incremental backup.

Backing up is faster than a full backup.
The storage space requirements are lower than for full backup.
Disadvantages: Restore is slower than restoring from full backup.
Backing up is slower than incremental backup.
The storage space requirements are higher than for 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.

Synthetic backup requires:

◆ That True Image Restore (TIR) with move detection be selected for each
component image.

◆ 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.

Types of Storage Units

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.

d. Disk Staging Storage Units:

A disk staging storage unit provides the first storage location in a two-stage process
called Disk Staging. In this process, client data is backed up to a disk staging storage
unit, then, in the second stage, the data is relocated to another storage unit.

Differences Between

A backup and A "True Image" backup:

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).

A backup and an Archive:

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 and A differential incremental backup:

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 and Multistreaming:

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

Debug Logs on Servers

Debug logs directory

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.

On UNIX systems, also refer to the README file in the /usr/openv/netbackup/logs

directory. On a Windows server, you can create all of the NetBackup debug log
directories at once on a master or media server by running the following batch file:
install_path\NetBackup\Logs\mklogdir.bat

Debug Log Directories & Associated Processes:

Debug Log
Directory Associated Process
admin Administrative commands.

bpbrm Net backup and restore manager.

bpcd NetBackup client daemon/manager. This process is started by the NetBackup

Client service.

bpcoord NetBackup process started by bpsynth to start and

monitor the bptm/bpdm processes on the media servers
to read the component images to be synthesized.
bpcoord runs on the master server.

bpdbjobs NetBackup jobs database manager program.

bpdm NetBackup disk manager.
bpdbm NetBackup DB manager. This process runs only on
Masterserver. On Windows systems, it is the NetBackup
Database Manager service.

bpjava-msvc NetBackup-Java application server authentication service

started by inetd on UNIX servers and by the Client
Services service on Windows servers during startup of
the NetBackup Java interface applications.
This program authenticates the user that started the
application.

bpjava-susvc NetBackup program started by bpjava-msvc upon

successful login through the Login dialog box that is
presented when a NetBackup-Java interface is started.
This program services all requests from the Java user
interfaces on the NetBackup master or media server
 host where bpjava-msvc is running.(On all Windows
platforms except 95/98)

bprd NetBackup request daemon/manager. On Windows systems, this process is

called the NetBackup Request Manager service.

bpsched NetBackup backup scheduler. This process runs only on

master servers.

bpsynth NetBackup process started by bpsched for synthetic

backup. This process runs on the master server.

bptm NetBackup tape or optical media management process.

symlogs System log.

user_ops The user_ops directory is created during the install of

NetBackup on all servers and clients. The NetBackup
Java interface programs use it for temporary files and
for job and progress log files generated by the user
backup, archive, and restore program (jbpSA). This
directory must exist for successful operation of any of
the Java programs and must have public read, write and
execute permissions. user_ops will contain a directory
for every user that is using the Java programs.

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.

◆ Each debug log is kept in a separate subdirectory under:

UNIX: /usr/openv/netbackup/logs
Windows: install_path\NetBackup\Logs
Debug logging takes place only if you create the subdirectory where the process can
store its logs.

◆ A process creates one debug log file per day.

On UNIX, the file names created are of the form:
log.mmddyy
For example: log.140898

On Windows, the file names created are of the form:

mmddyy.log
For example: 040198.log

◆ A debug log file is created when the process begins. Therefore, you must create
the directory for a debug log before the process starts.

◆ To increase the amount of information that processes write in the logs.

◆ On Windows systems, set the Global Logging Level to a higher level, in the
Logging dialog/tab under Master Server properties.

◆ On UNIX systems, define the string VERBOSE in the /usr/openv/netbackup/bp.conf

file.
VERBOSE by itself sets the verbose value to 1.
To get more logging detail, enter VERBOSE = 2 or a higher value.

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.

Debug Logs on UNIX Clients

To enable debug logging on UNIX clients, create the appropriate directories under:
/usr/openv/netbackup/logs

UNIX Client Debug Logs

Directory Associated Process
bp Menu driven client-user interface program.

bparchive Archive program. These debug logs are also

useful for debugging xbp and bp processes.

bpbackup Backup program. These debug logs are also

useful for debugging xbp and bp processes.

bpbkar Program used to generate backup images.

bpcd NetBackup client daemon/manager.

bphdb Program that starts a script to back up a database on a NetBackup database

agent client.

bpjava-msvc NetBackup-Java application server authentication

service started by inetd during startup of the
NetBackup Java interface applications.
This program authenticates the user that started
the application.
bpjava-usvc NetBackup program started by bpjava-msvc upon
successful login through the Login dialog box that
is presented when a NetBackup- Java interface is
started. This program services all requests from
the Java administration and user interfaces on
the host where bpjava-msvc is running.

bplist Program that lists backed up and archived files. This debug log is also useful
for debugging xbp and bp processes.

bpmount Program that determines local mount points and

wildcard expansion for Multiple Data Streams.

bporaexp Command-line program on clients to export

Oracle data in XML format. Communicates with
bprd on server.

bprestore Restore program. These debug logs are also

useful for debugging xbp and bp processes.

Debug Logs on Windows and Netware Clients

To enable detailed debug logging on Microsoft Windows or NetWare target clients,

create the appropriate directories in the following locations:

◆ Windows clients - C:\Program Files\VERITAS\NetBackup\Logs\

◆ NetWare clients - SYS:\OPENV\NETBACK\LOGS\

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

bpinetd WindowsNT/2000/2003 Client service logs.

These logs have information
on the bpinetd32 process.

bparchive Windows NT/2000/2003, 98, 95 Archive program that is run

from the command line.

bpbackup Windows NT/2000/2003, 98, 95 Backup program that is run

from the command line.

bpbkar WindowsNT/2000/2003 Backup and archive

manager. These logs have
information on the
bpbkar32 process.

bpcd All Windows n NetWare clients NetBackup client

daemon/manager. These
 logs have information on
communications between
the server and client. On
NetWare and Windows 98
and 95 clients, these logs
also contain the log
information for the backup
and restore processes.

bplist WindowsNT/2000/2003, 98, 95 List program that is run

from the command line.

bpmount Windows NT/2000/2003, 98, 95 Program used to collect

drive names on the client
for multistreaming clients.

bprestore Windows NT/2000/2003, 98, 95 Restore program that is run

from the command line.

nbwin Windows 98, 95 Client-user interface

program for Windows
98/95/NT/2000/2K3.

tar Windows NT/2000/2003 tar process. These logs

have information about the
tar32 process.

Media Manager Logs

Media Manager logging is different on UNIX than on Windows.

Media Manager Logs On UNIX: Media Manager on a UNIX system automatically

records robotic and network errors in the system logs by using syslogd. System log
entries are also made when robotically controlled drives change between UP and
DOWN states.

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

To disable vmd debug logging, either delete the /usr/openv/volmgr/debug/daemon

directory or rename it. This directory continues to accumulate information until you
either rename or delete it. 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.)

Media Manager Logs On Windows: On Windows, Media Manager records robotic

and drive errors in the Event Viewer Application log. Log entries are also made when
drives change between the UP and DOWN states. If a problem requires more
information, increase the level of logging to the Event Viewer Application log by
adding a VERBOSE entry to the following file:

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.)

SOME COMMON ERROR CODES:

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:

Try the following:

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.

4. For NetBackup Advanced Client only:

Status code 13 may appear in the /usr/openv/netbackup/logs/bpbkar log, and can
indicate the following:
* The files to back up reside on an IDE drive as opposed to SCSI, and the offhost
backup method was set to either NetBackup Media Server or Third-Party Copy
Device. If you are using offhost backup, the disk containing the client files must be a
SCSI or Fibre Channel device.

If the disk is an IDE drive, you may see the following in the /usr/openv/
netbackup/logs/online_util log:

get_disk_info: FTL - /var/tmp/caa026fEU disk_inquiry failed.

Errno = 25: Inappropriate ioctl for device and the following may appear in the
/usr/openv/netbackup/logs/bpbkar log:
bpbkar: INF - Processing /var
bpbkar: ERR - get_disk_info() failed, status 13
bpbkar: ERR - tpc_get_disk_info() failed: err 13
bpbkar: ERR - bpbkar FATAL exit status = 13: file read failed
bpbkar: INF - EXIT STATUS 13: file read failed

* 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:

1. Enable detailed debug logging:

* Create a bpbkar debug log directory (UNIX or Windows only).
* Create a bpcd debug log directory (this log is created automatically on Macintosh
clients.)
* On UNIX clients, add the VERBOSE option to the /usr/openv/netbackup/bp.conf
file.
* On PC clients, increase the debug or log level.

2. Retry the operation and examine the resulting logs.

3. On UNIX clients, check for core files in the / directory.

4. On UNIX clients, check the system log (/usr/adm/messages on Solaris) for system
problems.

5. This problem can sometimes be due to a corrupt binary.

On UNIX clients, use the UNIX sum command to check the bpcd, bpbkar, and tar
binaries, located in /usr/openv/netbackup/bin on the client. Reinstall them if they are
not the same as in the client directory under /usr/openv/netbackup/client on the
server.
Run the NetBackup Configuration Validation Utility (NCVU) for the associated
NetBackup clients. Note the client software checks in section two.

On a Windows client, check the bpinetd.exe, bpcd.exe, bpbkar32.exe, and tar32.exe

executables located in the install_path\NetBackup\bin folder on the client. Reinstall
the client if these executables are not the same size as on other Windows clients or
are not at the same release level or do not have the same NetBackup patches
applied as other Windows clients.

Error Code: 219

The policy or schedule for the backup requires a specific storage unit, which is
currently unavailable. This error also occurs for other attempts to use the storage
unit within the current backup session.

Trouble-shoot: Try the following:

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.

On a UNIX server, executing: netstat -a | grep bpcd

should return something similar to the following: *.bpcd *.* 0 0 0 0 LISTEN
Do this on the server where the storage unit is connected.

On a Windows NetBackup server, executing: netstat -a

prints out several lines of output. If bpcd is listening, one of those lines is similar to
the following: TCP myhost:bpcd 0.0.0.0:0 LISTENING
Do this on the server where the storage unit is connected.

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:

1. Perform a bpverify of the affected image to determine if it is written correctly.

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.

Error Code: 121

NetBackup attempted to back up its internal catalogs and there were no media IDs
defined in the catalog backup configuration.
Trouble-shoot:

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.

Error Code: 127

The bprecover command was issued and the media ID specified does not have valid
catalog backup data.

Trouble-shoot:

Validate that the correct media ID is being used.

Error Code: 134

Status code 134 is an informational message indicating that all drives in the storage
unit are currently in use. If this occurs, NetBackup automatically tries another
storage unit; if one is not available, NetBackup requeues the job with a status of 134
and retries it later.

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.

Error Code: 164

A restore was attempted and the volume required for the restore was in a DOWN
drive in a robot. Or, the slot that should contain the volume is empty.

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:

· ALLOW_MEDIA_OVERWRITE should be used on the server if you wish to

overwrite previously used non-NetBackup media without prompting.

· ALLOW_MULTIPLE_RETENTIONS_PER_MEDIA should be used if you have a

limited supply of media and a large number of retention periods.

· ALLOW_NON_RESERVED_PORTS will allow ports 1025 through 5000 to be used

for data streams instead of 512 through 1024.
· Use BPBACKUP_CLASS to set the default class used for client initiated backups.

· 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 BPSTART_TIMEOUT to increase the amount of time bpstart scripts have to

finish (don~Rt forget CLIENT_READ_TIMEOUT must be greater than or equal to
BPSTART_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.

· BUSY_FILE_NOTIFY_USER tells NetBackup whom to notify when busy file email

is sent.

· BUSY_FILE_PROCESSING turns on 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 CLIENT_READ_TIMEOUT to give bpstart and bpend scripts enough time to

finish.

· Use DISALLOW_CLIENT_LIST_RESTORE to prevent clients from listing and

restoring files backed up on their systems.

· Use DISALLOW_CLIENT_RESTORE to prevent clients from restoring files backed

up on their systems.

· Use DISALLOW_SERVER_FILE_WRITES to prevent server initiated restores or

server initiated updates to bp.conf.

· DO_NOT_RESET_FILE_ACCESS_TIME can be used if you do not care about

atime but do not want your ctime messed with.

· INITIAL_BROWSE_SEARCH_LIMIT is used to set the default number of days

that NetBackup will search to find files for restore.

· Use KEEP_LOGS_DAYS to specify the number of days to keep client logs.

· Use LIMIT_BANDWIDTH to throttle network saturation to a specified number of

KB per client.

· Use LOCKED_FILE_ACTION to skip files that have mandatory locking.

· Use REQUIRED_INTERFACE to override the operating systems choice of network
interface for server to client communications.

· Use SERVER to specify the NetBackup server(s) the client should use.

· Use the VERBOSE option to log additional information in NetBackup~Rs logs.

· USEMAIL will specify the user to notify for NetBackup events.

· USE_CTIME_FOR_INCREMENTALS will cause NetBackup to check both the ctime

and the mtime when determining which files should be backed up for incrementals.
You MUST also enable DO_NOT_RESET_FILE_ACCESS_TIME when using
this option.

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. DATA SERVICES (SOURCE OF DATA DURING BACKUP AND DESTINATION

RECOVERY OPERATION)

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.

C. SCSI SERVICES (MANIPULATE SCSI OR FC ATTACHED MEDIA CHANGER)

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.

Configuring NetBackup to work with NDMP

This answer assumes the hostname of your NDMP box is "HPNAS" and the hostname
of your Master Server is "HPMASTER".

Do the following:

1) Login to HPMASTER as root, and install the NDMP packages (SUNWnbdmp).

2) Set your NDMP authorization: HPMASTER# /usr/openv/volmgr/bin/set_ndmp_attr

-auth HPNAS root It will ask you for a Password, and enter HYDNAS password.

3) Put the following line in /usr/openv/netbackup/bp.conf: ALLOW_NDMP

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)

5) On HPNAS, start the ndmpd daemon.

To start ndmpd, do HPNAS % ndmpd on
To see the usage of ndmpd, just enter ndmpd.

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.

THE TYPES OF NDMP BACKUPS

There are 5 types of NDMP Backups:

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.