-----------------------------------------------------------------------
pkg: VRTSnetbp
version of NBU: /usr/openv/netbackup/version, /usr/openv/netbackup/bin/version
-----------------------------------------------------------------------
windows admin GUI- **** only one user in it at a time (writes out the last
users view when then exit and clobbers all other changes by others when they
exited). Use vi on text files, CLI, or Java when doing admin changes.
-----------------------------------------------------------------------
catalog
MASTER
/usr/openv
netbackup/db
volmgr/database
var
db - manual add
MEDIA
/usr/openv
db/media
volmgr/database
var
-----------------------------------------------------------------------
bp.conf - make sure master is the first entry
-----------------------------------------------------------------------
backup performance
#Drive speed
bperror -hoursago 24 |grep "Kbytes at"
#OR
grep "Kbytes/sec" /usr/openv/netbackup/logs/bptm/log.`date +%m%d%y` \
#THEN
| sed 's/[a-zA-Z/]//g'\
| awk '{print $NF}' \
| /usr/local/bin/mam
#Amount of data
grep "Kbytes/sec" /usr/openv/netbackup/logs/bptm/log.`date +%m%d%y` \
| awk -F, '{print $2}' \
| awk '{sum+=$1} END {print sum}'
#Buffers
grep "Kbytes/sec" /usr/openv/netbackup/logs/bptm/log.`date +%m%d%y` \
| grep buffers
backup status
/usr/openv/netbackup/bin/admincmd
bperror -S<Statuscode#> -r
================================================================
-----------------------------------------------------------------------
ALL_LOCAL_DRIVES
backup the entire client but splits each drive volume/filesystem into its
own backup stream
NEW_STREAM
if first entry in the file list, each occurance of this directive results
in a new backup job being initiated to backup the files following the
directive in a separate stream
NEW_STREAM
set destpath=/etc/home
/tmp
/usr
NEW_STREAM
/export
NEW_STREAM
UNSET_ALL
/var
-----------------------------------------------------------------------
~netbackup/db/altnames
touch No.Restrictions (get rid of hostname checking)
or cat server files in this dir and see if client exists
-----------------------------------------------------------------------
/usr/openv/netbackup/bin/bpbackup -i -c NT_FILE_VIRTUAL -s Full -w -S netbackup-server
-----------------------------------------------------------------------
/usr/openv/volmgr/bin/vmchange -res -multi_eject -w -verbose -rn <robot number> -rt <robot type> -
-----------------------------------------------------------------------
#list dir contents on client
bpdir -M [client|mediasrv] /somedir
-----------------------------------------------------------------------
Update client s/w
ALPHA OSF1_V4
ALPHA OSF1_V5
DataGeneral UNIX
HP9000-700 HP-UX11.00
HP9000-800 HP-UX11.00
INTEL FreeBSD
Linux RedHat2.2
Linux RedHat2.4
MACINTOSH MacOSXS1.2
MACINTOSH MacOSX
NCR UNIX
RS6000 AIX4.3.3
RS6000 AIX5
SCO UnixWare
Sequent DYNIX420
SGI IRIX65
Solaris Solaris2.6
Solaris Solaris7
Solaris Solaris8
Solaris Solaris9
Solaris Solaris_x86_2.6
Solaris Solaris_x86_7
Solaris Solaris_x86_8
-----------------------------------------------------------------------
Here is the full pathname and command you should use for cleanups if you are
running your catalog backups through cron or some other scheduler other than
NBU.
Also, I recommend you touch this file so that the process runs in
touch /usr/openv/netbackup/bin/CLEAN_IN_BACKGROUND
While you can run a complete catalog backup from the command line,
the easier way is to configure it through the gui, then just execute
'/usr/openv/netbackup/bin/bpbackupdb' from the command line or via
cron. It pulls in the configuration you defined in the gui. It
has to be executed on the system that will be doing the writing, in
your case a media server, not the master.
The configuration is defined in the 4.5 Sys Admin Guide for Unix on
page 155 (of the book). Search for 'Configuring Catalog Backups' if
using the pdf. I recommend defining two tapes so that they rotate
back and forth and you would always have one good backup tape. The
tapes that you choose must be in the NetBackup pool and must be
unassigned. Catalog backups don't append, they overwrite the tape
each time it runs.
-----------------------------------------------------------------------
TROUBLESHOOTING PORTS/CONNECTIONS
ping node
*OR*
telnet node bpcd
*THEN*
telnet node 13782
/etc/services (or applicable NIS file) does not have the correct bpcd entry.
The correct /etc services entry is:
bpcd 13782/tcp bpcd
rpcinfo -p /etc/inetd.conf (or applicable NIS or DNS file) does not have the
correct bpcd entry. The correct /etc/inetd.conf entry is:
bpcd stream tcp nowait root /usr/openv/netbackup/bin/bpcd bpcd
PORTS/Sockets
ping
bprd 13720 (NBU Request Service Port)
vnetd 13724 main port if in DMZ
bpcd 12782 (NBU Client Service Port)
portmapper 111 acsls libattach (windows)
acscsi 13740 acsls
13741 acsls
30031 acsls
30032 acsls
44110 acsls
visd 9284
vmd 13701
acsd 13702
tl8cd 13705
odld 13706
ts8d 13709
tldcd 13711
tl4d 13713
tsdd 13714
tshd 13715
tlmd 13716
tlhcd 13717
lmfcd 13718
rsmd 13719
bprd 13720 *
bpdbm 13721
bpjobd 13723
bpcd 13782 *
vopied 13783
nbdbd 13784
Level Period
----- -----------
0 1 week
1 2 weeks
2 3 weeks
3 1 month
4 2 months
5 3 months
6 6 months
7 9 months
8 1 year
9 infinity
10 6 weeks
11 10 years
12 8 days
13 5 weeks
14 13 months
15 7 years
16 infinity
17 infinity
18 infinity
19 infinity
20 infinity
21 infinity
22 infinity
23 infinity
-----------------------------------------------------------------------
OPENVBIN=/usr/openv/netbackup/bin
/etc/rc3.d/S77netbackup
initbprd
itid
jnbSA [-lc]
-----------------------------------------------------------------------
bgetconfig -M (pull list)
#list pools
vmpool -listall
vmpool -listall -b
#import a tape
bpimport -create_db_info -id XXXXXX -server genmsbu2 -L "/var/matt"
#new GUI
xbpadm is replaced by jnbSA
/usr/openv/netbackup/bin
cd /usr/openv (/opt/openv)
./netbackup/bin
./xbpadm
./bpps -a #status
ps -ef | grep bpsched
/usr/openv/volmgr/bin/vmps
./netbackup/bin/goodies
./bp.kill -all
./S77netbackup start
/usr/openv/netbackup/bin/goodies/bp.kill_all
#Up a drive
vmoprcmd -up 0 #use the drive index
I have tapes whose physical expiration date is shorter than I'd like. How do I change that date? T
The command will tell media manager that the tape should never expire.
#reread schedule
bprdreq -rereadconfig
bpschedreq -read_stunits
bpschedreq -read_stu_config
bpschedreq -predict DATE
bpsched -predict 09/11/2004 -client someclient
#
# Header for bpdbjobs
#
# JobID Type State Status Policy Schedule Client Dest Media Svr
# Started Ended Try Kilobytes Elapsed Operation Files KB Per Se
# Dest M Active E
#
# processes
bpps -a
#list clients
bpplclients
# list policies
bpcllist -U
bpcllist -U -allpolicies
bppllist
bppllist -L
bppllist -U -byclient CLIENTNAME
bppllist -U -allpolicies
bppllist -hwos
#licnenses
bpminlicense
bpminlicense -verbose
get_license_key -L keys
get_license_key -L features
#media lists
bpmedialist
bpmedialist -l
bpmedialist -L
bpmedialist -summary
bpmedialist -mcontents -m MEDIA
bpimmedia
bpimmedia -U
bpimagelist -A
bpimagelist -A -media
bpimagelist -media
# what media per BackupIDs per job (lists each copies media)
bpimagelist -L -d 01/20/2006 -e 01/23/2006 -client amrxm2101 | egrep -e "Backup ID|ID:"
bpimagelist -U -rl 0
bpimagelist -U -rl 1 ...
--------------------------------------------------------------------------------
How can I tell which tapes will be needed for a particular restore?
1. If you are using the Java GUI, start the restore, and click "Preview Media Required".
2. You can also perform the restore (either via the GUI or command line), and have messages wri
Or you can avoid the GUI (and avoid having to kick off a restore) with the bpimagelist command.
Let's assume you want to restore from a backup of CLIENTA that happened on August 1st.
### Next you use the -media flag to see what volume(s) were used for that
backup:
--------------------------------------------------------------------------------
http://seer.support.veritas.com/docs/271637.htm
http://seer.support.veritas.com/docs/264924.htm
http://ftp.support.veritas.com/pub/support/products/NetBackup_Enterprise_Server/269932.pdf
--------------------------------------------------------------------------------
Cause Veritas communicates to ACSLS using RPC and uses both UDP and TCP communications. The
Fix
Change the default communication protocol of NetBackup to TCP in the /usr/openv/volmgr/vm.conf...
Note
These messages are logged in the Netbackup acssi event log:
--------------------------------------------------------------------------------
1. Because it has exceeded the configured number of tries
- Delete(or move/rename) the log files under /usr/openv/netbackup/db/error/ and re-run the scheduled
- rm *.* ./netbackup/db/failures_history
- rm *.* ./netbackup/db/jobs except joblock ,jobid and done directory
- The problem occurs when a Windows 2000 Media Server is demoted to a Windows 2000 Client and the
Corrective Action:
a. On the master server, open the NetBackup Administration Console.
b. Open "Storage Unit Management".
c. Delete the storage unit that belongs to the Windows 2000 Client.
3. recv_runQ_msg: msgrcv(nodelay) stat -1 errno 35 (The specified message type does not exist on
- Appears to be a resource problem - message queue errors
- Perhaps a performance problem on Master - too much activity
This file will disable overcommit checking for drives on the master server. If environment is not
5. set_drives_down: set drive <Silo1P9_Drive5> to down state, bptm did not report drive
- It may be a possible bug in drive counting - get_num_avail_drives
- Once the NetBackup daemons are killed, backups run fine.
The sys admin had changed the shm parameters. AIX doesn't need any tuning for shm, but not sure wh
6. start_bptm: remap errcode 46 to 206 -- access to server backup restore manager denied
start_bptm: bpcd exit: server not allowed access (46) get_stunits: get_num_avail_dr
-Please check Host Properties under Media Servers and verify that a connection is established to e
Corrective Action:
For this instance, the issue was resolved by changing the registry on the media server. The follow
Message: EC_resource_busy
When using shared drives, or if NetBackup is spanning backups across tapes, you may see a status c
-----------------------------------------------------------------------
#devices
bpstulist -U
cd c:\Prog*\Veritas\Net*\bin
cd c:\Prog*\Veritas\Vol*\bin
tpconfig -l
tpconfig -d
tpconfig -ld
tpconfig -data
scan
vmoprcmd -d
vmadreq
vmglob -listall
#unfreeze tape
#check state
bpmedialist -U -m ID
#unfreeze
bpmedia -unfreeze -m ID
-----------------------------------------------------------------------
NDMP
OS and filer Passwords are 8 chars MAX or this will not work (4.x), 64 in 5.x.
/usr/openv/volmgr/bin
****
remove the number of drives from the storage unit's useable number
for netbackup as these are dedicated drives to NDMP
policy
use the NDMP STU
type NDMP
client
type NDMP
-----------------------------------------------------------------------
clean drives:
stats
/usr/openv/netbackup/bin/goodies/cleanstats
-----------------------------------------------------------------------
BLIB
/usr/openv/netbackup/scripts/setup_bli_script.sh
-----------------------------------------------------------------------
vmcheckxxx -rt acs -rn 0 -full -list
vmupdate -rt acs -rn 0 -interactive
-----------------------------------------------------------------------
Verifying that rpc is running on the Media Server.
# rpcinfo
program version netid address service owner
100000 4 ticots hotdog.rpc rpcbind superuser
100000 3 ticots hotdog.rpc rpcbind superuser
100000 4 ticotsord hotdog.rpc rpcbind superuser
100000 3 ticotsord hotdog.rpc rpcbind superuser
100000 4 ticlts hotdog.rpc rpcbind superuser
100000 3 ticlts hotdog.rpc rpcbind superuser
100000 4 tcp 0.0.0.0.0.111 rpcbind superuser
100000 3 tcp 0.0.0.0.0.111 rpcbind superuser
100000 2 tcp 0.0.0.0.0.111 rpcbind superuser
100000 4 udp 0.0.0.0.0.111 rpcbind superuser
100000 3 udp 0.0.0.0.0.111 rpcbind superuser
100000 2 udp 0.0.0.0.0.111 rpcbind superuser
You should get a response from both programs, but you only need a response
from the version that you are using (2 = udp or 3 = tcp). The Netbackup
default for this communications service is udp.
-----------------------------------------------------------------------
Support:
The number for Veritas support of Netbackup is 800-342-0652
ftp://ftp.support.veritas.com/pub/support/outgoing/nbsupport.201.windows.tar.gz
Unzip to c:\program files\nbsupport From the command prompt,
Run c:\program files\nbsupport\windows\nbsupport -media (use this on the media server only)
If you fail to select the appropriate switch, it will run as a client machine which will NOT provi
Send me the cab file that will be found under c:\program files\nbsupport\windows\output folder
email is to "support@veritas.com"
web ticket logging: support.veritas.com, see icons on bottom of the page
Patches
ftp://ftp.support.veritas.com/pub/support/products/NetBackup_DataCenter/258310.p
df
ftp.support.veritas.com
user: ftp
ftp> cd /pub/support/incoming
ftp> bin
ftp> hash
ftp> put CASENUMBER.support.out
ftp> quit
-----------------------------------------------------------------------
/usr/openv/netbackup/bin/goodies/
untar NCVU.tar
cd SOLARIS
./NCVU -help
Modification:
The following arguments can be passed to the NetBackup Configuration
Validation Utility (NCVU).
To get the latest version of NCVU go to:
http://support.veritas.com/menu_ddProduct_NBUESVR.htm
Select the Downloads tab, select File type: Utility, and press Go>>.
The TechNote that contains the latest version of NCVU will be displayed in
the listing.
NCVU requires at least two arguments. The most frequently used are
"-host_node" and "-conf". The possibilities include:
Argument Meaning
./NCVU -host_node master -conf all NCVU will validate Master, Media Server and Client configura
./NCVU -host_node master -conf master NCVU will perform Master Server configuration checks only.
./NCVU -host_node master -conf media_server NCVU will validate all Media Servers (no Clients).
./NCVU -host_node master -conf all_clients NCVU will validate all configured clients (that me
./NCVU -host_node master -conf media_server_clients NCVU will validate only the Media Server a
./NCVU -host_node master -conf class_clients NCVU will validate the clients configured in the cla
./NCVU -host_node master -conf single_client NCVU will validate the specified client.
NCVU will need to be run from the master server to generate the input file
before you can run it from the media server. Ftp the
<hostname>.ncvu_media_config_input.<date> file from the master to the media
server:
#/usr/openv/netbackup/bin/goodies/NCVU_media_server -if
<hostname>.ncvu_media_config_input.<date>
This will generate an NCVU_media.out.<date> file.
NCVU will need to be run from the master server to generate the input file
before you can run it from the client. Ftp the
<hostname>.ncvu_client_config_input.<date> file from the master to the
client:
#/usr/openv/netbackup/bin/goodies/NCVU_client -if
<hostname>.ncvu_client_config_input.<date>
This will generate an NCVU_client.out.<date> file.
-----------------------------------------------------------------------
Unix server fails to backup
/etc/services
bprd (required)
bpcd
vopied
/etc/inetd.conf
bpcd
bpjava-msvc
vopied
/etc/hosts
media master/server (if no DNS)
------------------------------------------------------------------------
Install backup software on a client
Copy the list of files not to backup from the shared source
cp $NBUHOME/exclude_list /usr/openv/netbackup
================================================================
How to configure the sg (Solaris scsi pass-thru driver) so that sgscan will
tape drives that have a scsi id (target) that is greater than 15.
TechNote ID: 236104 Last Updated: June 08 2001 05:35 PM GMT
E-Mail this document to a colleague
Subscribe to this document
Symptom:
How to configure the sg (Solaris scsi pass-thru driver) so that sgscan will
tape drives that have a scsi id (target) that is greater than 15.
Solution:
Problem:
With the invention of "native fibre" tape drives like the STK 9840 it is
now possible to have scsi ids (or scsi targets) that are greater than the old
limit of 15. With fibre channel devices it is possible to have scsi target
values up to 127.
The NetBackup procedure in the NetBackup 3.4 Media Manager Device
Configuration Guide pp.58-62 tells how to create scsi targets up to 15 with
the /usr/openv/volmgr/bin/sg.build command. However, this command does not
allow the creation of scsi targets that are greater than 15.
Solution:
The work-around for this is to manually edit the sg driver's configuration
files.
1) The first step is to ensure the operating system (OS) can see the tape
drives.
Check the /dev/rmt/ directory with this command ls -al /dev/rmt/*cbn.
The output should look something like this:
lrwxrwxrwx 1 root other 45 Apr 10 12:25 0cbn ->
../../devices/pci@1f,4000/scsi@4,1/st@2,0:cbn
lrwxrwxrwx 1 root other 45 Apr 10 12:25 1cbn ->
../../devices/pci@1f,4000/scsi@4,1/st@3,0:cbn
lrwxrwxrwx 1 root other 45 Apr 10 12:25 2cbn ->
../../devices/pci@1f,4000/scsi@4,1/st@13,1:cbn
lrwxrwxrwx 1 root other 45 Apr 10 12:25 3cbn ->
../../devices/pci@1f,4000/scsi@4,1/st@20,0:cbn
Note: The strings st@2,0 st@3,0 st@13,1 and st@20,0 at the end of the
device paths. These are the scsi target and lun values.
Also Note: The target and lun values for "st@?,?" are in hexadecimal
format, NOT decimal.
/dev/rmt/0cbn has target 2 and lun 0 (st@2,0).
/dev/rmt/1cbn has target 3 and lun 0 (st@3,0).
/dev/rmt/2cbn has target 19 and lun 1 (st@13,0).
/dev/rmt/3cbn has target 32 and lun 0 (st@20,0).
Go through the list of tape drives that the server sees and write down
the target and lun values for each /dev/rmt/*cbn device.
2) If there are tape drives missing from the /dev/rmt/ device files then the
/kernel/drv/st.conf file needs to be edited.
The first step is to determine what scsi target and luns the tape drives
are set for.
The next step is to edit the st.conf file so that it has a listing for
each target and lun combination that the tape drives have.
For example: if there is a tape drive with target 19 and lun 0 then this
line needs to be in the st.conf file name="st" class="scsi" target=19
lun=0;
Another example: if there is a tape drive with target 58 and lun 1 then
this line needs to be in the st.conf file name="st" class="scsi"
target=58 lun=1;
After all the updates are made to the /kernel/drv/st.conf file the device
trees need to be rebuilt. Do this with the command reboot -- -r.
3) Once the scsi target and lun values are know for each tape drive then it's
time to edit the sg driver configuration files.
First edit the /usr/openv/volmgr/bin/driver/sg.conf file to add the
needed target and lun entries.
For example: if there is a tape drive with target 19 and lun 0 then this
line needs to be in the st.conf file name="sg" class="scsi" target=19
lun=0;
For example: if there is a tape drive with target 58 and lun 1 then this
line needs to be in the st.conf file name="sg" class="scsi" target=58
lun=1;
4) After the sg.conf and sg.links files are edited, they need to be moved
into place with the /usr/openv/volmgr/bin/sg.install script.
The sg.install script will reload the sg driver. It was also copy
/usr/openv/volmgr/bin/driver/sg.conf to /kernel/drv/sg.conf.
If there is an existing /kernel/drv/sg.conf file, sg.install will not
copy the new file out there.
Thus it is important to remove or rename the existing
/kernel/drv/sg.conf file before running sg.install.
type=ddi_pseudo;name=sg;addr=3E,0; sg/c\N0t62l0
Conclusion:
Currently there are only a few native-fibre tape drives (including the STK
9840FC and the LTO tape drives like the IBM 3580-LTO and the HP SureStore
Ultrium 230-LTO).
These native-fibre device can support scsi target values that are greater
than the scsi target limit of 15.
To take advantage of this extended scsi target limit it is necessary to
configure the st (scsi tape) driver, the sg (scsi pass-thru) driver, and the
device links files so that the sg driver will see these devices with the
higher scsi targets.
--------------------------------------------------------------------------------
TechNote Summary:
TechNote Title: How to configure the sg (Solaris scsi pass-thru driver) so
that sgscan will tape drives that have a scsi id (target) that is greater
than 15.
TechNote ID: 236104
Last Updated: June 08 2001 05:35 PM GMT
Products: NetBackup DataCenter 3.4, 3.4.1
NetBackup v3.2 and prior (UNIX Platforms) 3.2
Update failed: could not add new media ID '0006L1' into slot 18 Insert media
failed: Media ID not unique to database (34)
Solution:
The LTO barcode format consists of eight characters nnnnnnLx, where nnnnnn
ranges from 0-999999 and x varies from 1-9. VERITAS NetBackup 3.4 generates
media ID based on the last six characters of the media barcode. Using LTO
barcodes will limit the media IDs generated since the Lx is common for
numerous barcodes. A problem can occur when a robotic library contains
multiple media with barcodes that have the same last six characters.
For example, a library has media with barcodes "S00006L1" and "120006L1". The
media ID generated for both pieces of media is identical, and when a robot
inventory update is performed, the following error occurs:
Update failed: could not add new media ID '0006L1' into slot 18
Insert media failed:
Media ID not unique to database (34)
Media ID generation rules can be added to the vm.conf file to specify the
robot number and barcode length with multiple configuration entries for each
robot or for each barcode format. With NetBackup 4.5, media ID generation
rules can also be added to the vm.conf file via the "Inventory Robot"
function of the NetBackup administration console graphical user interface.
c1-c6 can specify a character from the media barcode or specify a fixed
character by prefixing the character with a "#".
MEDIA_ID_BARCODE_CHARS 0 8 #N:1:3:4:5:6
****MEDIA_ID_BARCODE_CHARS 0 8 1:2:3:4:5:6
generates media IDs for robot 0 using the character N and the 1st, 3rd,
4th-6th characters of the 8 character barcode, and for the barcode, 123456L1
generates media ID N13456.
The rule:
MEDIA_ID_BARCODE_CHARS 0 8 1:2:3:4:5:6
generates media IDs for robot 0 using the 1st-6th characters of the 8
character barcode, and for the barcode 006498L2 generates media ID 006498.
================================================================
======================
Veritas Technote:
First, figure out the fragment number and the block size needed.
Ex:
File number 1
Backup id = xxxxx_0937941543
Creation date = 09/21/99 14:19:
Expiration date = 10/05/99 14:19:
Retention level = 1
Copy number = 1
Fragment number = 1
Block size (in bytes) = 32768
This issues a tpreq for media id D0004, the " r " is for read, the " -d " is
density, " -p " is pool and " -f " is mount point.
PENDING REQUESTS
DRIVE STATUS
Drv Type Control User Label RVSN EVSN Ready Wr.Enbl. ReqId
0 dlt TLD - No - -
1 dlt TLD root Yes D0004 D0004 Yes Yes 0
2 dlt AVR Yes D0004 Yes Yes -
ficus# tpconfig -d (to get the device file name for commands):
Since the tar command didn't work in the above scenario, run the stat command
to see what file the tape is positioned at:
ficus# mt -f /tmp/mytape stat
Vendor 'QUANTUM ' Product 'DLT7000 ' tape drive:
sense key(0x0)= No Additional Sense residual= 0 retries= 0
file no= 1 block no= 2
The following will move the data from one host to another host:
Run this at the target host (client). In the below example tape_host is the
server with the tape mounted.
------------------------------------------------------------------------
ACSLS Automated Cartridge System Library Software
-----------------------------------------------------
start acsls
su acsss
rc.acsss || rc.acsss idle
stop acsls
su acsss
cmd_proc
idle
logoff
kill.acsss
db_command stop
-----------------------------------------------------
1) How do I take acsls offline?
Login to stimpy
su - acsss || su - acssa
cd bin
open window full length
./cmd_proc
---------ACSLS 5.4.0----------
ACSSA> query server
2001-11-08 09:11:34 Server Status
Identifier State Free Cell Audit Mount Dismount Enter Eject
Count C/P C/P C/P C/P C/P
run 3079 0/0 0/0 0/0 0/0 0/0
ACSSA> vary acs 0 offline
Vary: ACS 0 varied offline.
ACSSA> logout
-----------------------------------------------------
How to clean drive through acsls?
>q clean all --- to find cleaning tapes
>mount CLN#### 0,0,10,#
example:
>set clean 100 CLN024
===========================================
3) Install acsls from CDROM
mount cdrom
as root
vi /etc/cron.d/cron.allow
add acsss
vi /etc/nsswitch.conf
on passwd and group, remove nis for now
*if
create 2Gb /export/backup filesystem
create 1Gb /export/home filesystem
cd /cdrom/cdrom0
./install.sh
accept defaults
say yes to auto restart (startup scripts)
say no to SCSI drivers
say no to modem on ttya
put nis back in /etc/nsswitch.conf
reboot for kernel changes
Otherwise, if you have to dump tranlogs and get a level zero backup, do the following procedure with
-----Original Message-----
From: Dotson, Julia [mailto:DotsoJ@LOUISVILLE.STORTEK.COM]
Sent: Wednesday, August 28, 2002 12:11 PM
To: 'Chris Biggins'
Subject: Berzerk
Importance: High
first thing is we must offload the logical logs...did you follow the instructions below (your onst
2) You will need to edit the onconfig file, defining an online disk file to be used for the backup.
# cd $INFORMIXDIR/etc
# vi onconfig
Find the variable
LTAPEDEV /dev/rmt/0mn
and change to
LTAPEDEV /export/backup/<filename>
note: <filename> is the name of the device that we are backing up to. The name
can be whatever you choose.
4) Run the ontape command. This will back up the current logical logs
freeing the used logical logs.
# ontape -a
5) After the ontape finishes, attempt to use onbar to backup the database
# onbar -b
If this echo returns a "0", you know that your backup was successful. If this is
the case, your problem with backups was caused by a long transaction holding
the logical logs open. By backing up the logical logs using ontape, you freed up
logical log space to allow the long transaction to be committed and everything
will work properly again. If a non zero was returned, you have avoided the problem
of logical logs filling up but you still need to determine the problem with backups. You will
need to monitor the logical logs with the "onstat -l" command and clear the logical logs with
ontape until you have determined the cause of the problem.
then do
db_command ism_start
============================================
Had drive in use, but no volume series id. ran following:
ACSSA> q dr all
2002-11-05 13:24:37 Drive Status
Identifier State Status Volume Type
0, 0, 1, 0 online available 9840
0, 0, 1, 1 online available 9840
0, 0, 1, 2 online available 9840
============================================================
Restore tapes from an alternate site.
============================================================
NOTE: *** select the write protect tab on the tape(s) ***
NOTE: Make sure that the tapes are not duplicates with any tapes that
internal. If so, you must eject out the duplicate tape(s).
NOTE: Keep note of the tape IDS for future use in this process.
3. Update library
/usr/openv/volmgr/bin/vmadm
s (special actions)
r (Inventory a Robot and Update Volume Configuration)
1 (select appropriate library)
u (Inventory Robot and Update Volume Configuration)
5. Import tape(s) one at a time, start with the primary volume first (if
known)
Follow documentation see following diagrams and steps.
7. Do the restore.
Select proper server, client and restore client. Pay attention to the date
selections.
Run ~netbackup/bin/goodies/MEDIA/EJECT.ksh
9. Update library.
/usr/openv/volmgr/bin/vmadm
s (special actions)
r (Inventory a Robot and Update Volume Configuration)
1 (select appropriate library)
u (Inventory Robot and Update Volume Configuration)
The expiration date for the imported items is the current date plus the
retention period. For example, if a backup is imported November 14, 2001 and
its retention period is one week, the new expiration date is November 21,
2001.
To avoid this problem in the future, use unique prefix characters for media
IDs on all servers.
You cannot import a backup if an unexpired copy of it already exists on
the server where you are trying to import it.
You cannot import data from disk-image.
1. Add the media IDs that have the backups to Media Manager on the server
where you are going to import the backups.
2. In the NetBackup Administration Console, expand Master Server > NetBackup
Management > Catalog.
3. Select Actions > Initiate Import. A dialog appears titled
Step 1: Read Catalog from Media.
The Master Server field indicates the master server to which you are
importing the images.
In the Media Host field, specify the name of the host that contains the
volume you are going to import.
In the Media ID (to import) field, type the Media ID of the volume that
contains the backups you are importing.
If youre importing Backup Exec images, check Password, then enter the
password.
Click OK. The Confirm Initiate Import dialog appears.
4. Click OK to start the process of reading the catalog information from the
source volume.
5. Click on the Catalog Results tab to see NetBackup look at each image on
the tape and determine whether or not it has expired and can be imported. The
job also displays in Activity Monitor as an Import type. Select the import
job log just created to view the job results.
Note Since it is necessary to mount and read the tape at this phase, reading
the catalog and building the list can take some time to complete.
Note When importing backups that have fragments on more than one tape, do not
start
the import until you have read the catalog for all the tapes containing
fragments.
Otherwise, the import will fail with a message similar to: Import of backupid
failed, fragments are not consecutive.
Import Phase II view
-----------------------------------------------------
After much searching, I found what the CU was looking for on an Internet
http://mailman.eng.auburn.edu/pipermail/veritas-bu/2003-June/017347.html
* My Environment *
Sun 220R w/two 450MHz Ultra Sparc II Procs, 2048MB Ram
two QLA2200 Fibre Channel HBA
Sun L40 (with two Quantum DLT8000 drives) attached via HVD SCSI Card
Qualstar 8236 (with two IBM LTO-2 (Ultrium TD-2) Drives) attached via
Fibre Channel.
Install Qlogic SANblade Control FX. This software allows you to use
the gui to set persistent binding for each adapter. One adapter has
disk drives attached (SAN Raid Array), the other has the the Qualstar
8236 unit bound to it.
Go through the wizard and setup persistent binding for each adapter -
Disk Subsystem on one adapter, Tape Subsystem on the other adapter.
# Quantum DLT8000
DLT8k-data = 1, 0x36, 0, 0x0D639, 4, 0x84, 0x85, 0x88, 0x89, 2;
* Veritas Setup *
Veritas uses the ST driver, but need the SG devices created correctly.
and
Next run the following commands to build the correct dev files:
The IBM drives should be auto configured, if not, specify both drives as
HCART2.
/backup/home
/
NEW_STREAM
/backup/h2
/backup/disk2
This will spawn one stream to one drive, and the other stream to the
remaining drive.
How do I see the hex values that the driver put into the kernel? I would like
to
verify this for Veritas Netbackup.
Example string:
CLASS_LTO2 = 1,0x24,0,0x45863d,2,0x00,0x01,0;
When you send me this command(s) to do this, you may close the case.
Thanks much.
Sun Engineer Mar 30, 2004 4:28:41 PM, Mountain Standard Time (MST GMT-07:00)
Hi Matthew,
For IBM LTO-2 tape drives, the settings are compiled into the newer drivers
by default. You can load the latest st driver patch 108725-16 (or at least
rev -13) after backing up your old one (for reference) and reboot, and the
driver will have native support. The patch can be obtained on
sunsolve.sun.com.
Please let me know if you have further questions. You can add a note which
will email me (I'm in M-F 8-5 MST) or call 877-786-0101 to speak to the next
engineer if it is outside my scheduled hours.
-----------------------------------------------------
The issue "Drive name is already in use by another drive" occurs if the
global device database already has an entry with the drive name you are
trying to create.
Firstly check on each media server that it is pointing to the master server
for the global database using
/usr/openv/volmgr/bin/vmglob -get_gdbhost which should return the name of
the master.
If the above is correct then from the master you can see the list of drives
and robots configured using
/usr/openv/volmgr/bin/vmglob -listall
You can also make use of the vmglob -delete -drive (see full syntax with
vmglob -?) to delete the drive and hopefully this will allow you to then add
the drive you want.
-----------------------------------------------------
Symptom:
The tape drive serial number or the firmware version is not correct in the
global database.
Solution:
You do not need to delete and re-add the drive to update the serial number
or firmware version in the global database when a drive is replaced. All you
have to do is update the drive device with the update parameters.
The drive information (serial number, firmware version, etc.) is kept in the
/usr/openv/volmgr/database/ltidevs file on each media server. When you
update a drive including the drive device (even if you do not change
anything), it re-reads the hardware and updates the
/usr/openv/volmgr/database/ltidevs file. That also updates the global
database (/usr/openv/volmgr/database/globDB) on the master.
Go to each media server to which the drive is attached and do the following:
cd /usr/openv/volmgr/bin
./tpconfig
Stop and restart media manager after you have updated all the drives that
you desire to change:
/usr/openv/volmgr/bin/stopltid
/usr/openv/volmgr/bin/ltid -v
/usr/openv/volmgr/bin/tpautoconf -sync
Verify that the drive serial number or firmware version has been updated in
the global database:
You can also do the drive update for each media server from the master with
the following commands. Run these commands for each media server to be
updated.
cd /usr/openv/volmgr
./vmoprcmd -h {hostname} -stopltid
./vmoprcmd -h {hostname} -devconfig "-update -drive {index_number} -path
{drive_device}"
./vmoprcmd -h {hostname} -startltid
./vmoprcmd -h (hostname) -autoconfig -sync
If you are unable to synchronize the global database, you can clear and
rebuild the global database with the following commands on the master
server. Run the 'sync' command for each media server.
cd /usr/openv/volmgr/database
cp globDB globDB.{date}
vmglob -delete
-----------------------------------------------------
reset the globDB
(due to bad memory of deleted devices)
cp /usr/openv/volmgr/database/globDB /var/tmp/globDB
vmglob -listall
-----------------------------------------------------
if vmglob is deleted from master, but not from media servers
media
vmglob -get_gdbhost #make sure it points to master
tpautoconf -sync #take a few
master
vmglob -listall #should have entires from the media server
-----------------------------------------------------
LH - library Half inch
stopltid
lmfcd -t (stops LMF robot control daemon)
tlhcd -t (stop tape half0-inch robot control daemon)
bmctrldbm -t (stop mm vol daemaon - vmd)
vmps - list active processes
$NBUHOME/volmgr/log/acsssi/event.log
-----------------------------------------------------
#vault
/usr/openv/volmgr/bin/vmchange -res -api_eject -map 0,0,0 -rn 2 -rt acs -rh mediaserver -vh master
cd /usr/openv/netbackup/vault/production
./bpvault.opsmenu dup_param_V100_full
vltadm
-----------------------------------------------------
/usr/openv/netbackup/bin/vltcore -jobid 459631 -dup_id 61 -function preview -profile 1/V1/LTO-Profil
vltrun 1/V1/LTO-Profile
-----------------------------------------------------
dups don't run
Vault Dir
/usr/openv/netbackup/vault
/usr/openv/netbackup/vltreports Contains Reports of all Vault Sessions
1. Daily Vaults all Production Database and Archive log backups. Runs Sun
Fri, starts 4:00 am
Policy Name vlt_daily_dup
Dir - /usr/openv/netbackup/vault/Daily_dup
Every Vault session has a session ID ( sid ) Directory e.g. sid219
Within each sid directory, are the details about that session. Some are
given below-
preview.list Contains the list of images to be vaulted/duplicated.
# wc l preview.list = Count of No. of images to be duplicated.
duped.images Contains the list of images successfully vaulted
# wc l duped.images = Count of No. of images successfully vaulted/duplicated.
detail.log contains logs of all vault processes, including mounting
Media, copying backup images, failures to successfully copy images etc.
Any failed to duplicate images should be picked up in the next Vault
session by default.
After the daily vault session is complete, it takes a backup of Netbackup
Catalog. Once NBUP Catalog backup is complete, it sends Report/Email
a) Summary of Vault session
b) Media Used for this session and to be offsited.
c) Media to be requested from Offsite ( This Report is Disabled for now,
since Automatic Ejection of Tapes is Disabled ).
2. Weekly Vaults all Production O/S backups. Runs Sat starts 4:00 am
Policy Name vlt_weekly_os
Dir - /usr/openv/netbackup/vault/Weekly_dup
NOTE Tapes should be ejected Daily after Vaulting completes, and should be
put in the East Shipping/Receiving Dock for Offsiting before 3:00 pm . Also,
Available Tapes should be requested from Offsite on a regular basis.
/usr/openv/netbackup/bin/vltopmenu
[q] Quit
Selection--> 1
Enter Profile (or Robot Num/Vault/Profile triplet):
vlt_daily_dup
[q] Quit
Selection--> 4
Starting the operation...
Beginning eject procedure. Please wait...
-----------------------------------------------------
get tapes from offsite or alternate datacenter
NOTE: *** select the write protect tab the tape(s) ***
Inject tape(s)
~netbackup/bin/goodies/MEDIA/INJECT.ksh
edit the 'mail' file and note the tape slots - they are in order and you
will take the first x number based on your quantity of tapes you are
inserting
Update library
/usr/openv/volmgr/bin/vmadm
s
r
1 (appropriate library)
u
Import tape(s) one at a time, start with the primary volume first (if known)
Follow documentation
import phase I
import phase II
add client
bpplclients POLICY -add CLIENT.domain HARDWARE OS
bpplclients addhoc_backups -add someserver Solaris Solaris8
Do the restore
select proper server, client and restore client
watch date selections
NOTE: set alternate restore directory if needed/desired
Update library
/usr/openv/volmgr/bin/vma
s
r
1 (appropriate library)
u
================================================================================
tpconfig - dev cfig
vmadm - media cfig
tpreq - mount & req for media
tpunmount - umount media
tpclean - clean media or list
vmadd
vmupdate
vmoprcmd
vmglob -listall
================================================================================
push out bp.conf on master to clients: add_slave_on_clients
================================================================================
Document ID: 230047
http://support.veritas.com/docs/230047 E-Mail this document to a colleague
De-commissioning a Media Server and removing it from the NetBackup
configuration.
--------------------------------------------------------------------------------
Details:
Before de-commissioning a Media Server, there are several steps that must be
accomplished. These steps are in several broad categories:
-updating the internal NetBackup database references to all tapes with active
images
-allowing restores from a media server other than the Media Server that
-performed the original backup
-un-configuring the Media Server from the system
-updating all references involving Storage Units, Classes, and Volume Groups and Pools
-changing the configuration so NetBackup will not recognize the old system as
a Media Server.
1) Determine which tapes on the Media Server that are being de-commissioned
have active images that have not expired. The easiest way to do this is to
run the bpmedialist command with the following options:
2) Select another Media Server or the Master Server to inherit the tapes
from the Media Server that is being de-commissioned and update the
appropriate NetBackup internal databases. This will update the mediaDB files
on both the old and new Media Servers and also update the images database on
the Master Server. Since the mediaDB files are binary files, they can only be
updated by this program, they cannot be updated manually. To update these
databases, the bpmedia command must be executed with the following options
for each tape identified by step 1:
3) Enable restores of the inherited images on the new Media Server (which
was determined in the previous step) by adding a line to the bp.conf file in
the Media Server that will be inheriting the media. Add the following line to
the bottom of the bp.conf file:
where fromhost is the Media Server that was used in the previous step for the
-oldserver parameter and tohost is the Media Server that was used in the
previous step for the -newserver parameter.
4) Move all tapes in all robots attached to the Media Server being
de-commissioned to non-robotic status (standalone). This is easiest if done
using the Media and Device Management GUI. Select each robot attached to the
Media Manager being decommissioned, highlight all tapes, and Move them to
Standalone.
5) After moving all tapes in all robots attached to the Media Manager being
decommissioned to Standalone, use the Media and Device Management GUI to
delete first the Tape Drives and then the Robots from the Media Server to be
de-commissioned. Once the Tape Drives and Robots are deleted from the Media
Server being de-commissioned, use the Storage Unit Management GUI to delete
all Storage Units associated with all robots associated with the Media Server
that is being de-commissioned.
6) If any Robots from the de-commissioned Media Server are being moved to
other Media Servers, power down the affected servers and make any cabling
changes required to physically attach the Robots to the new Media Servers.
Once the Robots are recognized by the operating systems on the new Media
Servers, add the Robot and Tape Drives to those Media Server with the Media
and Device Management GUI. Then, using the Storage Unit Management GUI,
create the appropriate Storage Units. Finally, Inventory the Robots for any
Robots attached to new Media Servers to cause the location of all tapes in
those robots to be known to NetBackup.
7) Modify any Classes that explicitly specified any of the Storage Units on
the Media Server that is being de-commissioned. These Classes must point to
any other defined Storage Units in the NetBackup configuration or to Any
Available as appropriate.
8) Update the bp.conf and vm.conf files (or their equivalent on NT) on the
Master Server and all Media Servers in the NetBackup configuration to remove
any reference to the Media Server that is being de-commissioned. Also update
the Server List on all Clients to no longer include a reference to the Media
Server being de-commissioned. Cycle the NetBackup daemons on any system
where these files are modified.
================================================================================
Document ID: 243593
http://support.veritas.com/docs/243593 E-Mail this document to a colleague
How to create a scratch pool
--------------------------------------------------------------------------------
Details:
A volume group is a logical grouping that identifies a set of volumes that
reside at the same physical location. Volume groups are an administration
convenience for logically moving multiple volumes (where a logical move means
to change the volume attributes to show the new location). Using a volume
group allows the System Administrator to move a set of volumes between a
robot and a standalone location or delete them from the configuration by
specifying the group name, rather than each individual media ID. Volume
groups are also convenient for tracking a location, such as when a group is
moved offsite.
The scratch pool is an optional volume pool that can be configured within
VERITAS NetBackup. If the scratch pool is configured, Media Manager moves
volumes from that pool to other pools that do not have volumes available.
In Figure 1, it can be seen that the scratch pool is named Scratch_pool and
the three robots contain volumes from that pool in addition to those from
other pools.
Media Manager searches the scratch pool for an unassigned DLT volume in Robot
C. If there is an available volume, Media Manager moves it to NB_pool_dept_1
and assigns it to NetBackup. Otherwise, a media unavailable status is logged.
Pool Name: Any name (pool_name), except NetBackup or None. The name can be 20
characters or less, but cannot contain any spaces or special characters.
Host Name: ANYHOST. (Do not use the check box to specify a specific host).
3. Add volumes for each robotic or standalone device that requires them.
Follow the steps as when adding other volumes, except in this case specify
the scratch pool as the volume pool.
SCRATCH_POOL = pool_name
To have Media Manager allocate all volumes to volume pools, do one of the
following:
- Create the scratch pool and add all volumes to it. Media Manager will move
volumes to the other pools as they are required.
NOTE: If the scratch pool does not already exist, Media Manager creates one
when the SCRATCH_POOL entry is added to the vm.conf file.
Notes
1. If the SCRATCH_POOL entry in the vm.conf file specifies a volume pool that
contains assigned volumes, then these volumes remain in the scratch pool.
Media Manager does not move assigned volumes to other pools as it does with
unassigned volumes.
2. Media Manager will not assign volumes while they are in the scratch pool.
For example, if a NetBackup class or schedule specifies the scratch pool, all
requests for those volumes are denied.
3. Volumes moved from the scratch pool to another pool remain in that new
pool. Media Manager does not automatically move it again for any reason,
though it is possible to manually reassign it to another volume pool.
================================================================================
A new Storage Unit is not recognized by the Scheduler until "bpsched
-mainempty" shuts down and restarts.
--------------------------------------------------------------------------------
Details:
The NetBackup scheduler application, known as "bpsched", is not a dynamic
process. Since bpsched is not dynamic, it is unable to recognize new Storage
Units until bpsched has been stopped and restarted. It is recommended that
all customers schedule the addition of new Storage Units at a time in which
the scheduler can be stopped and restarted to ensure Storage Unit recognition
by bpsched.
NOTE: It is possible for a bpsched process to run for a few days if the
NOTE: If a new media server entry is added to the bp.conf file, the bprd
daemon needs to be bounced to re-read the bp.conf file.
NOTE: If the media server already exists in the bp.conf file and a new
storage united is added, the bprd daemon does not need to be bounced.
When bpsched main is started by bprd, bpsched reads the storage unit
configuration and polls once for each stunit. If a media server goes down
while a main_empty is running, bpsched will continue to poll the media server
for available storage units.
When a new storage unit is added to a previously defined media server, the
storage unit will begin being polled when the next bpsched main_empty is
started by bprd. However, if bpsched main_empty is already active, the
storage unit will not be polled until after the bpsched main_empty
terminates. The termination of bpsched main_empty can happen 2 ways: 1)
bounce the active bpsched main_empty; or 2) wait until the bpsched main_empty
terminates after all jobs have completed.
There is polling done of specific stunits when jobs complete, if the stunit
goes down(all drives down), this polling stops. This polling
gets restarted by a -read_stunits if a drive is up. However, bpsched polls
the stunits(an internal -read_stunits call) every 5 minutes. The command
bpschedreq -read_stunits can be used to cause the storage unit poll to happen
sooner.
================================================================================
After changing the NetBackup master's /usr/openv/netbackup/bp.conf file, use
the following command to tell bprd to re-read its configuration:
Note that this command will only detect and incorporate some bp.conf
configuration changes. Many NetBackup configuration changes do require a
complete stop and start of the NetBackup daemons.
================================================================================
change a policies/class file list
cd /usr/openv/netbackup/db/class/POLICY/
vi includes
================================================================================
Document ID: 266673
http://support.veritas.com/docs/266673
Recovery without Import
--------------------------------------------------------------------------------
VERITAS now supports a method of recovering image information without having
to import from a tape. There are some very important caveats; please
carefully read the entire procedure before attempting it.
The goal of this document is to establish the procedure to allow for quicker
recovery of a system or VERITAS NetBackup (tm) domain for backup tapes
without importing the individual backup images. Implied in this procedure, is
that the receiving site has a fully functional master. If this is being done
as part of a disaster recovery plan, there are many other steps that are
required and which must be addressed. This procedure is only intended to
There are many different ways to recover data on a different master than the
one used for the original backups. Several of these methods are documented by
consulting, and one method -- catalog replication using VERITAS Volume
Replicator (tm) -- is being formalized in the near future. This document will
give a specific procedure to follow along with the restrictions and caveats.
This should allow customers to accomplish their goals in a manner that will
be safe, reliable, and supported.
If data is being moved from one active NetBackup domain to another for
recovery purposes only or being sent to a disaster recovery site, this
procedure can be used. You must follow all the restrictions and caveats.
Restrictions:
Procedure:
1. Perform a catalog backup on both masters. This will allow you to recover
from any errors that might occur during this process.
2. Configure a special volume pool at the new site that will never be used
for backups.
3. Setup barcode rules for the incoming tapes to put them in the special
volume pool.
4. Ensure there are no active backups for the desired clients. One way to
ensure this is to stop the NetBackup services/daemons on the master server.
5. Copy the desired client directories at the originating site. This would be
the contents of /usr/openv/netbackup/db/images/<client name> or \Program
Files\VERITAS\netbackup\db\images\<client name>.
7. You can now move the client data (tapes) and catalog data to the new site.
8. Merge the copied images into the catalog at the new location.
9. Put the tapes in the library at the new location.
10. To ensure none of the moved tapes can be overwritten, you might want to
write-protect them.
11. Inventory the robot containing the moved tapes.
12. Put the appropriate FORCE_RESTORE_MEDIA_SERVER entry or entries in
bp.conf. When you put this entry in bp.conf, you will need to recycle bprd.
13. If you moved primary copies of the tapes, then you are ready to restore.
If you moved non-primary tapes, then you will need to change the primary copy
for all the images being moved.
Caveats:
Since this procedure assumes you will not be using the moved tapes for
backups, it did not require moving the volume database or the media database.
If these tapes are to be returned to the original site, the image directory
will not be gracefully cleaned up. When the image or images expire, they will
be deleted from the image directory but there will be an error logged in the
bptm log that states: "Could not find media ID xxxxxx in database, nothing to
delete."
It would be advisable to delete the images from the catalog, preferably by
removing the data when the restores are finished and the tapes are removed
from the library. When you eject the tapes, you should also consider removing
the entries from the volume database. If you want to permanently move the
tapes and images, then you are looking at a master merge which is a
documented service offered by VERITAS Enterprise Consulting Services.
================================================================================
What does the message ' unable to lock media at offset ' mean?
In BPTM log: 11:08:35 [28132] <2> db_lock_media: unable to lock media at offset 76 (560010)
Details:
When browsing the /usr/openv/netbackup/log/bptm log to trouble shoot drive
problems a message similar to 11:08:35 [28132] <2> db_lock_media: unable to lock media at offset 76
During the course of a backup, NetBackup selects media which matches criteria
for use. In this instance, NetBackup has found a media suitable for use but
is unable to locate the media in its robotic slot.
The media is already mounted in a drive and is being used by another backup.
NetBackup will then skip that particular media and continue on its selection,
until the next suitable media is located.
================================================================================
How to configure robots for NDMP devices using the Master Server's command
prompt.
--------------------------------------------------------------------------------
Details:
Network Data Management Protocol (NDMP) is a protocol developed to allow the
backing up and restoring of data on a Network Attached Storage (NAS) device.
NetBackup for NDMP is an extension for NetBackup that must be purchased and
licensed separately. This extension, along with a tape device attached
locally or remotely to the NAS device, allows a NetBackup Master Server to
backup and restore files from a NAS device.
Configuring a robotic device and drives attached to a NAS device can be done
through the GUI interface on the Master Server. However, sometimes the
command line must be used from the Master Server in order to accurately
install a robotic device.
To configure the tape device from the Master Server's command prompt,
implement the following steps:
3. Create a telnet session to the NAS device using the root user. Inside
the telnet
session:
a. version
-This verifies the version level of the NAS device. It is usually
5.3.6R1 or 5.3.6R2.
Other versions are supported, but these work the best with NetBackup.
It is
possible to upgrade this version through the NAS device vendor.
b. sysconfig -m
-A return value of mc0 shows the robot is attached and recognized.
c. sysconfig -t
-This returns device names for robots and drives. Find and note the
NRST0A
values
NOTE: When issuing this command for NetApp Filers using OnTap versions prior
to
version 5.3.4, it is necessary to specify SP# and the controller, target, and
lun numbers.
NOTE: Refer to the Release Notes for the specific operating system versions
related to each NetBackup Product Version applied to this TechNote.
Following these steps should successfully configure the robotic device and
drives for use with an NDMP device for most configurations.
================================================================================
NCVU
================================================================================
Installation and necessary file information for the VERITAS NetBackup (tm)
Configuration Validation Utility binary executable version 5.0
--------------------------------------------------------------------------------
Details:
5. Link the directory associated with the appropriate operating system for
NCVU (Solaris, HP-UX, or AIX). For example, if running Solaris:
ln -s /usr/openv/netbackup/bin/goodies/support/SOLARIS/NCVU
/usr/openv/netbackup/bin/goodies/support/NCVU
6. If on the master server, run ./NCVU -host_node master -conf master under
the support directory /usr/openv/netbackup/bin/goodies/support. The results
of the NCVU command will be placed in the NCVU_master.out.mm_dd_yyyy_hh_mm
file.
For media server checks, run ./NCVU -host_node master -conf <media server
option>.
The results will be placed in the NCVU_media.out.mm_dd_yyyy_hh_mm file.
For client checks, run ./NCVU -host_node master -conf <client option>.
The results will be placed in the NCVU_client.out.mm_dd_yyyy_hh_mm file.
For more detailed operating instructions, consult the NCVU.README file
(reproduced below) or run:
./NCVU -help
--------------------------------------------------
NetBackup Configuration Validation Utility (NCVU) 5.0 README
Contents:
1. General information
2. Supported NetBackup versions
3. Supported platforms
4. What is new
5. Known NCVU issues
6. Installation information
7. Operation information
1. Space requirements
2. Command help information
8. Troubleshooting information
1. Installation troubleshooting
2. Operation troubleshooting
9. Legal disclaimer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
1. GENERAL INFORMATION:
"NCVU" is a VERITAS support utility written in the PERL programming language.
It is used to validate NetBackup and associated operating system
configurations and functionality.
The NCVU deliverable consists of two files, this NCVU.README file and the
NCVU.tar tar file.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
5. KNOWN NCVU ISSUES:
1. If the NetBackup Database backup paths configuration have links that are
not at the end of the path, NCVU will flag these paths with WARNINGS as not
having the correct path configured. Links in all but the lowest level are
valid in NetBackup 4.5 and 5.0.
2. If the NetBackup Database backup paths configuration has files listed in
the paths, these are not validated correctly in that NCVU attempts to do a
chdir into these files and posts a WARNING message.
3. On Solaris systems, the parsing of the LUNs in the /kernel/drv/st.conf
file will not take place if there are no tape devices or options configured.
4. Advanced client policies will not validate correctly. Change to bpbplist
-U -L is required.
5. Some WARNINGS in the NCVU summary section have the incorrect section
number noted on them.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
6. INSTALLATION INFORMATION:
The NCVU.tar file contains a directory structure based upon the platforms
supported by NCVU. Currently there are three directories, SOLARIS, AIX and
HP-UX. Each directory contains the NCVU program for that platform. Use:
# tar -xvf ./<platform name>
to extract these components in a directory of your choosing.
*************************************************************************
* NOTE: If a previous PERL version of NCVU is installed, you should *
* either move or remove all of the NCVU PERL script components: *
* *
* NCVU, NCVU_media_server, NCVU_client, bp_commands.pm, chk_nbu_conf.pm *
* chk_nbu_node.pm, chk_sys_nbu_req.pm, os_commands.pm, *
* print_commands.pm and vm.commands.pm *
* *
* on each NetBackup node being updated. For this binary version of *
* NCVU, the installation and referencing of PERL is not required. *
*************************************************************************
After untarring the NCVU programs, place a copy of the appropriate platform
NCVU program in the openv/netbackup/bin/goodies/support directory on each
NetBackup node to be validated.
*************************************************************************
* NOTE: On NetBackup nodes prior to NetBackup release 4.5, the script named
* support must be temporarily renamed, the support directory created and the
* support script moved into the new support directory. *
* If any other administration scripts call the support script, the path
* should be updated accordingly.
*************************************************************************
The minimum amount of free space required to run a single instance of NCVU
for master, media servers and clients can be estimated with the following
formula:
master server .out
media server .out
number of additional media servers X 102K
client .out
+ number of clients X 63K
-------------------------------------------
Total space required:
Using the above example for a site with three media servers and ten clients:
NCVU_master.out 30,000
NCVU_media.out 75,000
number of additional media servers X 102K 204,000
NCVU_client.out 45,000
number of additional clients X 63K 567,000
---------
total space required 921,000
Typical level 9 debug file sizes in bytes running on the master server with
minimal warnings are:
NCVU_master.debug = 275K
NCVU_media.debug = 275K with approximately @100K for each additional media
server.
Each media server generates a .output communication file.
<media server>.output = @100K
NCVU_client.debug = @235K with @35K for each additional client.
DESCRIPTION
"NCVU" is a VERITAS support utility used to validate NetBackup and associated
operating system configurations and functionality. Currently, validating
master, media server and client configurations are supported on the following
platforms:
Solaris 2.5.1, 2.6, 2.7, 2.8 and 2.9
HP-UX 10.20 and 11.00
AIX 4.15, 4.2, 4.3, 4.3.1, 4.3.2, 5.1 and 5.2
Other platforms may be supported in the future. The utility can be run in
different modes to control the amount of information output. The default mode
is to print all of the utilities observations and warnings in the output.
The utility is non-intrusive in that no NetBackup or operating system
configuration items are altered. NetBackup or operating system command output
or configuration files are parsed and examined. The NCVU utility must be
installed on the master server, each media server and each client in the
netbackup/bin/goodies/support directory.
The method utilized to transfer information between NetBackup nodes is remsh.
Therefore each NetBackup node that is to be tested needs to be configured as
a "trusted" host.
For NetBackup media servers and clients, there are two methods that the
utility can be run:
The first method is when the utility is run on the master server with either
the -conf <media server option> or -conf <client option> command line
options, if the associated media server(s) or client(s) are pingable, the
master server will invoke NCVU with either the -host_node media_server or
-host_node client command line option on the remote node via a remsh command.
Input will come from the input configuration file generated on the master
server. The input file will designate the name of the utility output file
that will be returned to the master server upon completion.
The second method that can be used is to run the utility from the command
line on the media server or client. A copy of the input file created on the
master server can be used along with the -if option. An output file will be
created on the media server or client.
[-help] [all, host_node, of, if, conf, net, quiet, wait, version]
Display help information
Default all
all This information
host_node Host node information
of Output file information
if Input file information
conf Configuration validation information
net Network communication validation
information
quiet Output quiet information
wait Output wait information
version Output NCVU version information
[-host_node] [master, media_servers or client]
[-conf] [all, master, all_media_servers,
group_media_servers <storage unit group>,
single_media_server <media server>, single_client <client name>,
class_clients <class name>, media_server_clients <media server name>,
policy_clients <policy name>, all_clients]
Run configuration validation
Default all master master server configuration checks including:
- Master server's operating system type and version.
- hostname and nodename.
- Master server's uptime information.
- Master server's boot time information.
- Master server's physical memory size information.
- Domain name.
- openv, openv/netbackup/db and openv/netbackup/logs disk partition usage.
- NetBackup version file check, this validates that the proper version level
and system platform is installed.
- the operating system's kernel parameter configuration file for the
appropriate NetBackup operating system kernel parameters.
- the operating system's active kernel parameters for the appropriate
NetBackup operating system kernel parameters.
- "ndd" tcp_close_wait_interval settings if available on that platform.
- Operating system services configuration file settings.
- Depending on the version of NetBackup, the bprd, bpdbm, bpcd vnetd, vopied
and bpjobd entries in the configured services.
- Depending on the version of NetBackup, the bpcd, vopied, bpjava-misc, vnetd
and bpjobd entries in /etc/inetd.conf file.
- Depending on the version of NetBackup, prints out the VERITAS license
information.
- Checks for NetBackup packs installed on master server. This reports pack
install processes aborted and packs installed out of sequence.
- NetBackup master server binaries in the netbackup/bin and
Reports pack install processes aborted and packs installed out of sequence.
- Compares the NetBackup packs installed on the media server with the packs
installed on the master server.
- Validates media server entries in the netbackup/bp.conf file.
- Reports on the configured operating system host services abilities to
resolve the configured media server SERVER names. Notes other NetBackup
node entries. Checks for invalid entries.
- Runs a tpconfig -d to obtain the NetBackup volume database hosts configured
on the master server.
- Checks that the configured storage unit host connections have bp.conf
SERVER entries in the master server's bp.conf file.
- Checks on the configured operating system host services abilities to
resolve the configured host connection names.
- Depending on the version of NetBackup, checks the configured storage unit
groups.
- Checks that the configured volume pool host entries exist in the master
server's bp.conf file.
- Depending on the version of NetBackup, checks the configured
classes/policies for the following:
That the class/policy and schedule storage units have a valid entry in the
master server's bp.conf file.
That the class/policy and schedule volume pools exist in the volume pool
database.
The active status of the class/policy.
That active classes/policies have clients.
That active classes/policies have include lists.
That active classes/policies have schedules.
That active classes/policies have schedule windows.
Checks for class/policy type specific rules for include list contents and
keyword usage and sequence.
Comments on various configuration settings and recommendations.
- Checks the NetBackup database backup configuration. Checks that the
configured storage units have the appropriate path settings based on which
server is the database backup server.
- Runs various bpclntcmd utilities to validate the media server names in the
netbackup/bp.conf file and any associated hostnames or IP addresses
returned by the configured operating system services.
- Checks on the master server's ability to ping the valid storage unit host
connections.
------> Based on the above information, an input configuration file is built
on the master server for each selected media server. The input file is
redirected into an remsh command which then executes the NCVU program on each
pingable media server. The master server then waits in a loop for the return
of an output file from each selected media server. The number of seconds that
the master server will wait is either the default 300 seconds or the number
of seconds input with the -wait parameter. As each media server executes
NCVU, it builds an output file which is returned to the master server.
Once all of the output files return from each media server or the wait
timeout expires, the master server then parses the output file information
into the output report.
On each selected media server, the following items are checked:
- Server operating system information. If storage unit name is the same as
the system's hostname or nodename. If the media server's domain name is the
same as the master server's.
- Media server's uptime information.
- Media server's boot time information.
- Media server's physical memory size information.
- openv, openv/netbackup/db, openv/netbackup/logs and openv/volmgr/database
disk partition size and usage.
- NetBackup version file check. Validates that the proper NetBackup software
for the system platform is installed.
- If on the appropriate system, checks that an sg driver is loaded.
- ndd tcp_close_wait_interval setting.
- Depending on the version of NetBackup, the bpcd, vopied and bpjava-msvc
entries in /etc/inetd.conf file.
is either the default 300 seconds or the number of seconds input with the
-wait parameter. As each client executes NCVU, it builds an output file which
is returned to the master server. Once all of the output files return from
each client or the wait timeout expires, the master server then parses the
output file information into the output report.
On each client, the following items are checked:
- Server operating system information. If the client's hostname is the same
as the system's hostname or nodename. If the client's domain name is the
same as the master server's.
- client's uptime information.
- client's boot time information.
- client's physical memory size information.
- openv and openv/netbackup/logs disk partition size and usage.
- NetBackup version file check. Validates that the proper NetBackup software
for the system platform is installed. Checks if a NetBackup pack is listed
in the version file and if it is, checks to see if it is in the list of
installed NetBackup packs from the master server.
- ndd tcp_close_wait_interval setting.
- NetBackup bpcd entries in /etc/inetd.conf file.
- Operating system host services configuration file settings.
- Depending on the version of NetBackup, validates that the bprd, bpdbm, bpcd
and vnetd port entries in services are the same as the master server's port
entries.
- Depending on the version of NetBackup, prints out the VERITAS license
information.
- NetBackup client binaries in the openv/netbackup/bin are checked for
existence, if they are the same size as listed in the netbackup/client
software repository on the master server, are non-zero size, executable, are
owned by root.
- UNIX sum output is provided for each NetBackup client binary in the
netbackup/bin directory.
- NetBackup client libraries in the openv/lib directory are listed and a UNIX
sum performed on the ones found.
- NetBackup startup and shutdown scripts in appropriate locations and
validates that the proper client startup and shutdown commands are present.
Also validates that no master server commands for bprd or bpdbm are present.
- Checks that the bpcd process is listening on it's port.
- Validates client entries in the netbackup/bp.conf file.
Any valid bp.conf entries involving hostnames, the hostnames are validated
against the configured operating system host services ability to resolve the
configured hostname.
- Checks for the existence of any non-standard NetBackup files in the
netbackup directory.
- Lists any NetBackup logging that is turned on in the openv/netbackup/logs
directory.
- Reports on configured operating system services ability to resolve the
master server hostname.
- Reports on configured operating system services ability to resolve the
media server hostnames.
- Runs various bpclntcmd utilities to validate the SERVER and CLIENT_NAME
hostnames in the netbackup/bp.conf file and any associated hostnames or IP
addresses returned by the configured operating system services.
- Runs various bpclntcmd utilities to validate the master server hostnames
and any associated hostnames or IP addresses returned by the configured
operating system services.
- Runs various bpclntcmd utilities to validate the media server hostname and
any associated hostnames or IP addresses returned by the configured
operating system services.
- Checks on the client's ability to ping the master server.
- Checks on the client's ability to ping the media servers.
EXAMPLES
User Commands:
Report on NetBackup master server and the associated operating system
configuration. Run on the master server.
example# ./NCVU -host_node master -conf master
Report on NetBackup master server and the associated operating system
configuration, generate a debug file and not report any observations, only
warnings. Run on the master server.
example# ./NCVU -host_node master -conf master -debug 9 -quiet
Report on NetBackup master server and the associated operating system
configuration designating the named output file for the report to go to. Run
on the master server.
example# ./NCVU -host_node master -conf master -of report.out
Report on NetBackup media server(s) and the associated operating system. Run
on the master server.
example# ./NCVU -host_node master -conf all_media_servers
Report on NetBackup media server(s) and the associated operating system. Show
no observations, only warnings. Run on the master server.
example# ./NCVU -host_node master -conf all_media_servers -quiet
Report on NetBackup media server(s) in the storage unit group sample_group
and the associated operating system. Run on the master server.
example# ./NCVU -host_node master -conf group_media_servers sample_group
output file returned to the master server from each client. Each file must be
removed prior to rerunning the utility.
SPACE REQUIREMENTS
The current version of NCVU takes approximately 26.8 megabytes of space to
install. 13.7 megabytes of this space is for the NCVU.tar file and the
remaining space is for the actual NCVU programs. There are many items that
contribute to the size of files that NCVU creates per instance. Each
installation has a different number of configuration items to be validated.
This can include such items as the number of NetBackup nodes, packs
installed, bp.conf and vm.conf entries, storage units configured, and
classes/policies configured. As the number of configuration items increase,
so does the amount of items reported in the NCVU output report.
Running NCVU in debug mode (especially debug level 8 and higher) can create
sizable debug files. This is primarily due to the listing of the output from
the various system and NetBackup commands that NCVU parses through. The
number of hostnames contained in the NetBackup configuration and the various
operating system hostname resolution systems also has a large impact on the
size of the NCVU debug files. The number of observations and warnings
messages generated by NCVU also has a large bearing on the size of NCVU
output and debug files as well.
Typical file sizes in bytes running on the master server with minimal
warnings are:
NCVU_master.out.<date> for a master server = 30-50K
NCVU_media.out.<date> for a media server = 75K with approximately @30-50K for
each additional media server.
Each media server generates a .input and a .output communication file.
<media server>.input = 1.4-2K
<media server>.output = 30-50K
NCVU_client.out.<date> for a client = 45K with @30K for each additional
client.
Each client generates a .input and a .output communication file.
<client>.input = @3K
<client>.output = @30K
The minimum amount of free space required to run a single instance of NCVU
for master, media servers, and clients can be estimated with the following
formula:
master server .out
media server .out
number of additional media servers X 102K
client .out
+ number of clients X 63K
-------------------------------------------
total space required
Using the above example for a site with three media servers and ten clients:
NCVU_master.out.<date> 30,000
NCVU_media.out.<date> 75,000
number of additional media servers X 102K 204,000
NCVU_client.out.<date> 45,000
number of additional clients X 63K 567,000
-------
total space required 921,000
Typical level 9 debug file sizes in bytes running on the master server with
minimal warnings are:
NCVU_master.debug for a master server = 275K
NCVU_media .debug for a media server = 275K with approximately
@100K for each additional media server.
Each media server generates a .output communication file.
<media server>.output = @100K
NCVU_client.debug for a client = @235K with @35K for each additional client.
NOTES:
This utility is currently under development. As such, the media server or
client input and output files are not deleted on the master server after
completion. Any problems reported should be accompanied with copies of the
media server input and output files along with the utility output and debug
files.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
8. TROUBLESHOOTING INFORMATION:
1. INSTALLATION TROUBLESHOOTING:
Problems pertaining to the proper installation of NCVU can be caused by but
are not limited to:
1. Corrupt tar or individual files due to file transfer problems.
2. Incorrect file ownership or execution permissions due to installation
methods.
2. OPERATION TROUBLESHOOTING:
Problems pertaining to the proper operation of NCVU can be caused by but are
not limited to:
1. Incomplete deployment of NCVU utility components to all NetBackup nodes
being tested.
3. Incomplete configuration of the "trusted host" environment on each
NetBackup node being tested.
4. NCVU utility components not being installed in or linked to the
netbackup/goodies/support directory on each NetBackup node being tested.
5. Erratic behavior on command line commands and utilities not returning
information to the NCVU program. Use debug modes to output information to the
debug file for verification.
6. Utility execution times greater then the wait timeout period. This could
be caused by commands or utilities that get hung or do not return information
================================================================================
Backups directed to a particular media server always queue in the job monitor
and never run.
--------------------------------------------------------------------------------
Details:
If a backup job is queueing and never going to active even when it should,
there is a quick possible fix. Sometimes due to an improper shutdown or a
system crash, bpsched can leave stale worklist information that will
interrupt with the activation of backup jobs. To check for this problem,
shutdown NetBackup, then cd into the directory
/usr/openv/netbackup/bin/bpsched.d. The contents of the directory should
look like the below example, with only four files in it.
If there are any other files such as worklist.23749; try moving them out of
the directory. Then start NetBackup and see if the problem has been resolved.
================================================================================
Exact Error Message
requested media id was not found in NB media database and/or MM volume
database
Details:
A recommended way to expire a tape is to use bpexpdate -ev <MEDIAID> -d 0,
but this can fail if any entries in any of the three VERITAS NetBackup
The database can be checked and any entries can be manually removed using the
following procedures:
I. Media database
To check: available_media
To remove: bpexpdate -ev <MEDIAID> -d 0 -justmedia -force
WARNING: This procedure will delete the tape from the VERITAS NetBackup
catalog and the tape will become available for backups again. The only way to
back track this procedure is to manually import the tape.
================================================================================
Document ID: 266314
http://support.veritas.com/docs/266314 E-Mail this document to a colleague
Formatting the output from the bpdbjobs command in NetBackup 4.5
--------------------------------------------------------------------------------
Details:
The method in which the format of the bpdbjobs report is controlled changed
in VERITAS NetBackup (tm) 4.5. This is now controlled by adding
BPDBJOBS_COLDEFS entries to the /usr/openv/netbackup/bp.conf file on the
master server.
Add a BPDBJOBS_COLDEFS entry for every column you wish to include in the
output using the following format:
where:
"COLDEFS_ENTRY" is the name of the column to include in the output. See the
table below for valid BPDBJOBS_COLDEFS entries.
"true" indicates that the column should expand as needed. If not specified,
true is the default.
"false" indicates that the column should not expand beyond the minimum_size,
if required entries in this field will be truncated.
The order of the entries determines the order that the column headings will
appear. The NetBackup daemons do not need to be restarted for these options
to take effect.
Please note that these are the default columns for NetBackup 4.5. Also note
that if there is only one BPDBJOBS_COLDEFS entry in the bp.conf file, there
will only be one column in the output from bpdbjobs. Thus, adding at least
one entry to bp.conf will remove all defaults in favor of the bp.conf list.
Therefore, you must specify all the columns you require.
root@firefly:/> bpdbjobs
JobID Type State Status Policy Schedule Client Dest Media Svr Active PID
1 Backup Done 0 test1 full firefly firefly 15965
root@firefly:/> bpdbjobs
JobID Type
1 Backup
COLDEFS_ENTRY DESCRIPTION
ACTIVEELAPSED Active Elapsed (elapsed active time)
ACTPID Active PID (PID of job)
BACKUPTYPE Backup Type
CLIENT Client
COMPLETION Completion (percent complete)
COMPRESSION Compression (yes or no)
DSTMEDIA_SERVER Dest Media Svr (writing media server)
DSTMEDIAID Dest Media ID (writing media ID)
DSTSTORAGE_UNIT Dest StUnit (writing storage unit)
ELAPSED Elapsed (elapsed time)
ENDED Ended
ESTFILE Est File (estimated number of files)
ESTKB Est KB (estimated number of kilobytes)
FILES Files
GROUP Group
JOBID JobID
JOBSTVERSION Job Strucuture Version
KBPERSEC KB Per Sec
KILOBYTES Kilobytes
LASTBACKUP Last Backup (date and time)
MAINPID Main PID (PID spawning job, if applicable)
NUMTAPESEJECT Media to Eject (number of tapes to eject; Vault only)
OPERATION Operation (current operation)
OWNER Owner
PARENTJOBID Parent JobID
PATHNAME Pathname
POLICY Policy
POLICYTYPE Policy Type
PRIORITY Priority
PRODUCT Product
PROFILE Profile (Vault only)
RETENTION Retention (retention period)
ROBOT Robot (Vault only)
RQSTPID Request PID (PID requesting job, if applicable)
SCHEDULE Schedule
SCHEDULETYPE Schedule Type
SESSIONID Session ID (Vault only)
SRCMEDIA_SERVER Src Media Svr
SRCMEDIAID Src Media ID
SRCSTORAGE_UNIT Src StUnit
STARTED Started
STATE State
STATUS Status
STREAMNUMBER Stream Number
TRY Attempt
TYPE Type (job type)
VAULT Vault (Vault only)
Related Documents:
After creating the above folders run the backup job that has been running
slow. You will want to check in the bptm log for waits or delays of either
full or empty buffers. (See the example below)
22:08:12.782 [24469] <2> write_data: waited for full buffer 8947 times,
delayed 43713 times
If waits or delays of FULL buffers are taking place, then this will point to
the network as the slow down. If waiting for full buffers, that means the
bptm is waiting for the buffer to become full to write to the tape device.
The following are recommended actions:
Note: This will allow the backup to write directly from the NIC to the drive,
without using shared memory.
Note: This file should be removed as soon as step 6 has been completed.
6. Run a test backup on the client using the command: bpbkar32 -nocont C:\
1>nul 2>nul
Note: This will test the ability of the NetBackup 'bpbkar' process to READ
data from the hard drive. Enter the entire drive where the slow throughput
issues are occurring (ex: C:\ or D:\). This will give us the highest READ
rate of the client. After running the "NUL" backup; you can then check the
'bpbkar' debug log for the throughput of the "NUL" backup job.
If the waits or delays are for EMPTY buffers, this then points to the bptm
writing slower than the network is sending data to the bpcd. In this case
adding more buffers should help. Here are some recommended test procedures:
First step for both the master and media servers: [NORMALLY NOT RECOMMENDED]
1. Open windows explorer to install_path\veritas\netbackup
2. Create a file named NET_BUFFER_SZ (no file extension)
3. Edit the file using notepad and add the entry: 65536
Third step for the media server: [THIS FILE IS THE ONLY TOUCH FILE
RECOMMENDED UNDER NORMAL CIRCUMSTANCES]
1. Open windows explorer to install_path\veritas\netbackup\db\config
2. Create a file named NUMBER_DATA_BUFFERS (no file extension)
3. Edit the file using notepad and add the entry: 32
The NET_BUFFER_SZ file will set the tcp block size to be used. This will be
set to 64k (65536). This value can be changed to either 128k (131072) or 96k
(98304). During testing you may want to change the value.
The SIZE_DATA_BUFFERS file will set the tape block size. This will be set to
64k. This value should not be changed to anything higher then 64k. Windows
will not be able to reliably read anything higher then 64k block sizes.
The NUMBER_DATA_BUFFERS file will set the number of buffers to be used. The
tcp block will write data to this buffer, which in turn will write to the
tape drive. This is the one value we can change the most. You will want to
start with 32 buffers. Then increment up by 8, going to 40, then 48 and so
on.
While changing the NUMBER_DATA_BUFFERS once you see the performance go down,
backup the number of buffers to the last setting that you saw an increase.
Once you have that, then change the NET_BUFFER_SZ to 96k to see if you see
another increase or decrease. Then change NET_BUFFER_SZ to 128k and take
note. If the speed again increased with the NET_BUFFER_SZ then change the
NUMBER_DATA_BUFFERS once more by 8 to see if the performance again increases.
By this time you should have found the maximum speed of the local backup. The
only thing left will be to add the file NET_BUFFER_SZ to all of the clients.
This file will be located in the same place: install_path\veritas\netbackup
and you will want to add the value to match what is on the media server that
you finally settled on.
If the waits or delays are for full buffers, this then points to a client or
network issue as the buffers are waiting for data from the client.
--------------------------------------------------------------------------------------
Maximum BUFFER settings for SCSI-attached robot
NET_BUFFER_SZ = 65536
SIZE_DATA_BUFFERS = 65536 (64 x 1024)
NUMBER_DATA_BUFFERS = 32 (can increase in increments of 8)
NET_BUFFER_SZ = 65536
SIZE_DATA_BUFFERS = 131072 (128 x 1024)
NUMBER_DATA_BUFFERS = 32 (can increase in increments of 8)
================================================================================
Automatic Volume Recognition (AVR) control mode (the drive is a standalone drive or is a drive in
================================================================================
Advanced reporter
To access NBAR 4.5 installed on a UNIX system, use the following URL from your web browser: http:
To access NBAR 4.5 installed on a Windows system, use the following URL from your browser: http:/
================================================================================
nbar export database - faster than browser
VRTSnbaro
/opt/VRTSnbaro/bin/arconfig.sh -c
4.5 /opt/VRTSnbaro/bin
5.X /usr/openv/nbar/bin
nbardbex -H -d , -S MASTER_SERVER -s 11/01/2005 00:00:00 -e 11/30/2005 23:59:59
nbardbex -H -d , -S MASTER_SERVER -hoursago 48
To access NBAR 4.5 installed on a UNIX system, use the following URL from your web browser: http:
To access NBAR 4.5 installed on a Windows system, use the following URL from your browser: http:/
================================================================================
Document ID: 256790
http://support.veritas.com/docs/256790 E-Mail Colleague IconE-Mail this
document to a colleague
VERITAS NetBackup (tm) Advanced Reporter browser will not open when the SUN
Java Plug-In is enabled.
Details:
The SUN Java Plug-in is not supported for NetBackup Advanced Reporter
(NBAR) 4.5 in any version of Internet Explorer or Netscape.
In order to open Advanced Reporter using your browser, the SUN Java plug-in
must not be in use on your workstation's browser. To disable the SUN Java
plug-in for Internet Explorer, click Tools | Internet Options | Advanced.
Pull your scroll bar down to SUN Java and verify that this option is not
enabled. To disable the SUN Java plug-in for NetScape, click Edit |
Preferences | Advanced. Verify that SUN Java is not enabled.
With either browser, you will then need to open a new browser session to
activate this change. The NBAR product should then be available to view
again.
OR
(only certain clients are supported - XP is not)
================================================================================
Add new drives (or create media server):
Solaris
edit lpfc or qlc files
drvconfig
AIX
cfgmgr
sgscan
add drives on media server: tpconfig
create storage unit
================================================================================
How to set up a client that is behind a firewall, filtering by destination
port using VNETD
Details:
Configuring VERITAS NetBackup (tm) to use vnetd for a client:
NOTE:
* This process is done from the master and is the only configuration that
* needs to be done in NetBackup to use VNETD. bp.conf does not need to be
* updated manually. Ports will still need to be opened on the firewall,
* see below.
* The process is different for setting up a media server that is on the
* other side of the firewall, see TechNote 251631 (link in Related
* Documents section of this TechNote). VNETD holds the originating IP and
* does not work with NAT.
If using the ALL_LOCAL_DRIVES directive when setting up the policy for the
client behind the firewall, then the following port will also need to be
opened:
Master >> Client 13782 (bpcd)
Client >> Master 13724 (vnetd)
If the client needs to run user backups/restores, then the following port
will also need to be opened:
Client >> Master
13720 (bprd)
If database backups are done from the client, then the following ports will
also need to be opened:
Client >> Master
13720 (bprd)
13724 (vnetd)
Related Documents:
251631: How to configure VNETD for a firewall between a master and media
server in NetBackup 4.5
http://support.veritas.com/docs/251631
Resolution:
Under the master server's Host Properties, add the client in question to the
Firewall tab. Select Use reserved ports, VNETD Only and clear any check boxes
for "connect back" (Figure 2). For clients behind a firewall, VNETD should
be selected whenever possible. The client must also still be listed under
the master server's Client Attributes tab with No Callback in order to still
take advantage of VNETD backups through a firewall.
================================================================================
Administrative Tools
Local Security Settings
Local Policies
Security Options
Devices: Unsigned driver installation behavior
SET:: Silently succeed'
================================================================================
SSO
Tape cleaning must be handled on a host with SSO, or via the library. Automated cleaning
================================================================================
Windows Restore of System State
Normally you will get the inaccessible boot device if hardware or the drive configuration on a ser
1. install OS
2. rename current boot.ini
3. run w2koption -restore -same_hardware 0
4. do full NBU restore of the system
5. compare boot.ini files (the original one and the one just got recovered)
6. reboot the system and see if it is getting blue-screened
================================================================================
Page: N/A
Modification:
Troubleshooting all NetBackup issues requires a certain knowledge of the
servers involved with the backup or restore. At a minimum, the following
information should be known:
* The operating system and OS patch level of the master server, along
with the NetBackup version and maintenance pack (MP) or feature pack (FP)
level
* The operating system and OS patch level of the media server, along
with the NetBackup version and MP or FP level. If the master server is
also the media server, this needs to be noted.
* The operating system and OS patch level of the client server, along
with the NetBackup version and MP or FP level
For database backups and restores, knowledge of the version of the database
as well as any patches is also necessary. To determine the version of
Microsoft Exchange (5.5, 2000, or 2003), open the Exchange administrator
console, and review the information under Help | About. This will show the
version of Exchange.
Next, be sure to enable the correct logging. For Exchange, enable bpbkar
for backups, and tar for restores. Go to the
<install_path>\veritas\netbackup\logs directory and create the necessary
logging folder. Additionally, it helps to have a policy list, and copies of
the Microsoft Application Event Log.
Status 1:
Status 12:
Status 13:
* Confirm the directives are correct for the version of Exchange. For
Exchange 5.5, the directives are Microsoft Exchange Server:\Information
Store and Microsoft Exchange Server:\Directory. For Exchange 2000/2003
server is Microsoft Information Store:\* or Microsoft Information
Store:\<storage_group_name>. Please note that for the files list Microsoft
Information Store:\* to work correctly, Allow multiple data streams must be
enabled.
* Confirm that the servers list correctly lists the Exchange server
name. Do not use a NetBackup name, the name of a backup interface, or a
fully qualified domain name. If the server is listed in the Exchange
administrative console as Exchange_server_1, confirm that is how it is
listed in the policy. If the policy shows Exchange_server_1_backup or
Exchange_server_1.domain.com, the backups will fail.
* If the backup makes use of the directive NEW_STREAM, be sure the
Allow multiple data streams option is selected.
NOTE:
Because of the design of Exchange 2000 and 2003 servers, the files list
must be either Microsoft Information Store:\* (with Allow multiple data
streams enabled) or Microsoft Information Store:\<storage_group_name>.
Listing only Microsoft Information Store:\ without the asterisk results in
the backup failing. Additionally, if the recovery storage group is present
on an Exchange 2003 server, and the files list is Microsoft Information
Store:\*, the backup also fails. Remove the recovery storage group and
re-run the backup.
NOTE:
Due to the nature of mailbox backups (for 5.5, 2000, and 2003) and public
folder backups (for 2000 and 2003), VERITAS highly recommends placing
mailbox and public folder backups into their own class, and not include
them with database backups.
================================================================================
Windows cluster:
bpclusterutil
-c #install
-a [option] #run on active node
================================================================================
PATH=$PATH:/usr/openv/netbackup/bin:/usr/openv/netbackup/bin/goodies/support:/usr/openv/ne
if [[ ! -d $CFIG_DIR/$NODE/VNBU/Files ]]
then
mkdir -p $CFIG_DIR/$NODE/VNBU/Files
fi
NBU_FILES="
/usr/openv/var/license.txt
/usr/openv/volmgr/vm.conf
/usr/openv/netbackup/bp.conf
/usr/openv/java/auth.conf
/usr/openv/java/nbj.conf
/usr/openv/netbackup/db/jobs/job.conf
/usr/openv/netbackup/db/media/errors
/usr/openv/netbackup/bin/version
/usr/openv/netbackup/db/config/behavior
/usr/openv/netbackup/db/vault/vault.xml
/usr/openv/netbackup/vault/sessions/vlteject.mstr
"
#support taken out because it can hang and eat up process time
#support > $CFIG_DIR/$NODE/VNBU/$NODE.support.out
# processes
bpps > $CFIG_DIR/$NODE/VNBU/$NODE.bpps
bpps -a > $CFIG_DIR/$NODE/VNBU/$NODE.bpps_a
vmps -a > $CFIG_DIR/$NODE/VNBU/$NODE.vmps_a
#errors
bperror > $CFIG_DIR/$NODE/VNBU/$NODE.bperror
bperror -U > $CFIG_DIR/$NODE/VNBU/$NODE.bperror_U
bperror -U -backstat > $CFIG_DIR/$NODE/VNBU/$NODE.bperror_U_backstat
bperror -U -backstat -by_statcode > \
$CFIG_DIR/$NODE/VNBU/$NODE.bperror_U_backstat_by_statcode
bperror -media -U > $CFIG_DIR/$NODE/VNBU/$NODE.bperror_media_U
#licnenses
bpminlicense > $CFIG_DIR/$NODE/VNBU/$NODE.bpminlicense
bpminlicense -verbose > $CFIG_DIR/$NODE/VNBU/$NODE.bpminlicense_verbose
get_license_key -L keys > $CFIG_DIR/$NODE/VNBU/$NODE.get_license_key_L_keys
get_license_key -L features > \
$CFIG_DIR/$NODE/VNBU/$NODE.get_license_key_L_features
#media lists
available_media > $CFIG_DIR/$NODE/VNBU/$NODE.available_media
bpmedialist > $CFIG_DIR/$NODE/VNBU/$NODE.bpmedialist
bpmedialist -l > $CFIG_DIR/$NODE/VNBU/$NODE.bpmedialist_l
bpmedialist -L > $CFIG_DIR/$NODE/VNBU/$NODE.bpmedialist_L
bpmedialist -summary > $CFIG_DIR/$NODE/VNBU/$NODE.bpmedialist_summary
#ndmp
set_ndmp_attr -list > $CFIG_DIR/$NODE/VNBU/$NODE.set_ndmp_attr_list
#vault
#devices
bpstulist -U > $CFIG_DIR/$NODE/VNBU/$NODE.bpstulist_U
bpstulist -g > $CFIG_DIR/$NODE/VNBU/$NODE.bpstulist_g
bpstulist -go > $CFIG_DIR/$NODE/VNBU/$NODE.bpstulist_go
fi
================================================================================
Ensure that the robot number matches the one on the control host.
If there are drives in the robot that have not been configured, add them now.
The following command configures the drive with the system name of Tape0
under control of the robot configured in step 1. (Tape0 has been attached
and recognized by the Windows server.)
tpconfig -add -drive -type dlt -name Tape0 -comment DEC DLT2000 8414 -index
3 -drstatus up -robot 9 -robtype tld -robdrnum 3 -asciiname DLT2000_D3
tpconfig -add -drive -type dlt -name Tape0 -comment DEC DLT2000 8414 -index
6 -asciiname DLT2000_standalone
#list windows tape drives, match with master (vmglob -listall OR tpautoconf -t
tpautoconf -t
================================================================================
tape copy to VTL
# i.e.
IMAGE amrxm1111 0 0 7 amrxm1111_1135853202 ACC_PROD_EXCH_AMRXM1111_SG4 16 *NULL* root Daily 0 0 1
#Which is amrxm1111_1135853202
#copy tape to vtl (minimum required, can use more options - LOTS available)
#backupid - the job number used for orignal image, if you don't use this
then you must supply lots of other options
#dstunit - STU where the duplication will go
#dp - pool where the duplication will go
bpduplicate -v -client amrxm1111 -dstunit ictcvnb01-CDL1-ST -backupid\
amrxm1111_1135853202 -dp CDL1_VirtualTapes
================================================================================
SSO drives
/usr/openv/volmgr/bin/vmdareq -display
scanhost
================================================================================
LibAttach
need rpcportmapper
useLocalIP
c:/Program Files/STK/libattach/bin/CLI-query-server
================================================================================
Exchange:
if c:/temp fills up, when doing restore,
select different drive and path for
"Temporary location for log and patch files:"
================================================================================
Disk based backups
Files: clientname_backupid_container_file#
================================================================================
How long has netbackup been up, or when was it restarted.
================================================================================
databases from files into your current setup. May need to remove database
directory contents first. -l instead of -r will list
* bpplinfo <policy> -modify -inactive - Will change a policy to
inactive
* bpduplicate -dp <pool to use> -dstunit <storage unit to use>
-hoursago n -sl <Sched name> -mpx (-PM / -L /var/log/logfile) - This will
duplicate images of sched name done in hoursago and use storage unit and
pool specified. mpx Does mpx duplications of mpx backups but can be
ommitted. -PM is to view -L is output log. There are -client and policy
flags too
* vmdareq -h <glob da host> -display - Shows the device scanning host
when have media servers and SSO
* tpautoconf -get_gdbhost - Lists the global device scan host
* bprdreq -rereadconfig - Very useful as it re-reads configs eg bp.conf
without restarting daemons. Useful when doing FORCE_RESTORE_MEDIA_SERVER =
<oldserver> <newserver> on the Master server in bp.conf
* bpgetconfig -M clientname | grep -i "^exclude" - Lists exclude lists
on windows boxes from the master server. Can probably set with bpsetconfig
* jnbSA -lc - This will log all commands the console uses if possible
to the a log file
* bpchangeprimary -copy 2 -sl <schedule> -cl <client> -sd mm/dd/yyyy (
-ed mm/dd/yyyy ) - This changes copy 2 (i.e the offsite copy from an ITC
job) to be the primary copy. The primary copy is what netbackup uses to do
its restores from. this e.g is for a client and has start date and end date
and schedule shown.
* bpchangeprimary -pool Offiste_Cinc -sd mm/dd/yyyy - As above, but
this changes all images which were written to a tape pool to be the primary
copy. This may be beneficial in DR scenarios.
* bpverify -PD -M <master server> -X -s <start date> -e <end date> -cn
2 -client <client> - This will give the output as the gui does for showing
info on a client between dates of an image which is copy number 2. The last
field on the output is 0 or 1. 0 = not the primary copy. 1 = is set to
primary copy. Can use this to check before and after you use
bpchangeprimary. Other options can be used such as -sl <schedule> instead
of/aswell as -client
* /usr/openv/netbackup/bin/admincmd/bpconfig -tries 0 - Change the
number of schedules tries to 0 so no backup jobs are performed but running
jobs finish. Useful for maintenance or other actions. To list current
setting use bpconfig -L. This is done on master server
* bpretlevel -l - shows retention levels set and time in seconds
* bplist -C <client> -k <Policy> -R -l -s 04/28/2005 -e 04/29/2005
/path/to/files | awk '$NF = /\.log/ && $4 != "0" {print $NF}' > /tmp/list -
This lists all files Recursivly (-R) which have .log in them and are NOT 0
bytes between the dates, and puts them in a file. -l = long listing ( to
get file size ).
* bprestore -C <client> -D <destination client> -s 04/28/2005 -e
04/29/2005 -L /tmp/progress -R /tmp/rename -f /tmp/list - This restores
files from client to destination using images between the dates and the
files in /tmp/list( -f ). -L logs progress and -R /tmp/rename is for
alternate path restores. /tmp/rename contains :- change /path/a/b/c to
/path/new/a/c/
When system memory gets low, Solaris unloads unused drivers from memory and
reloads drivers as needed. Tape drivers are a frequent candidate for
unloading, since they tend to be less heavily used than disk drivers.
Depending on the timing of these unload and load events for the st (Sun),
sg (VERITAS), and fibre channel drivers, various problems may result. These
problems can range from devices "disappearing" from a SCSI bus to system
panics.
forceload: drv/st
forceload: drv/sg
/usr/sbin/modinfo | grep sg
Version 5.0
ALPHA OSF1_V5
HP9000-700 HP-UX11.00
HP9000-800 HP-UX11.00
HP9000-700 HP-UX11.11
HP9000-800 HP-UX11.11
IBMSerieslinux2.4
INTEL Freebsd4.5
Linux Redhat2.4
MACINTOSH MACOSXS10.2
RS6000 AIX4.3.3
RS6000 AIX5
SCO Unixware7.1
SGI IRIX65
Solaris Solaris7
Solaris Solaris8
Solaris Solaris9
Solaris Solaris_x86_7
Solaris Solaris_x86_8
Need to run
/usr/openv/netbackup/bin/admincmd/bpclient -client <client> -add
Check in /usr/openv/netbackup/db/client/<client>/host_info
Useful URLS
* http://www.NetBackupcentral.com
* http://sourceforge.net/projects/nbux
================================================================================