----------------------------------------------------------------------- pkg: VRTSnetbp version of NBU: /usr/openv/netbackup/version, /usr/openv/netbackup/bin/version conf dev: jnbSA, xdevadm, tpconfig conf media: jnbSA, xvmadm, vmadm conf dev: jnbSA, xdevadm, vmoprcmd bp (backup and restore) bpadm vltadm jnbSA [-lc] #log command line equivilents /usr/openv/java/[auth.conf, nbj.conf, Debug.properties] Also add hostname in bp.conf as SERVER=xxx xbpadm (old Moif - pre jnbSA) ----------------------------------------------------------------------- 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 # see if waiting for full or empty buffers # see performance advice later in file backup status /usr/openv/netbackup/bin/admincmd bperror -S -r bperror -U -backstat -hoursago 24 bperror -U -problems -hoursago 24 bperror -U -backstat -d 3/22/2004 -e 3/28/2004 -by_statcode bperror -U -client somename -L -hoursago 24 bperror -problems -v -client somename -L bperror -problems -client somename -U -d 07/25/2002 -e 08/02/2002 bperror -hoursago 48 -backstat -U \ | awk '{if ($1 !=0 && $1 != 1 && NFS == 7) print $0}' | sort -n bperror -U -backstat -hoursago 24 \ | awk '{if ($1 == 0 || $1 == 1 ) print $0}' | sort -n ================================================================ ----------------------------------------------------------------------- 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 SYSTEM_STATE:\ [note underscore] (< win 2003 server) used to backup the registry Shadow Copy Components:\ [note spaces] (>= win 2003 server) used to backup the registry Veritas tech article 275931 UNSET & UNSET_ALL reset or set Drive letter (windows: i.e C:\) Mount path (unix: /home ) 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/netbackup/bin/bpbackup -i -w -h $CLIENT -p $POLICY -s $SCHEDULE ----------------------------------------------------------------------- /usr/openv/volmgr/bin/vmchange -res -multi_eject -w -verbose -rn -rt -rh -ml /usr/openv/volmgr/bin/vmchange -h mediaserver -verify_eject -map 0,0,0 -rn 0 -r h mediaserver -ml H00011 -rt acs -res #move between pools /usr/openv/volmgr/bin/vmchange -p -m \ -h -M ----------------------------------------------------------------------- #list dir contents on client bpdir -M [client|mediasrv] /somedir ----------------------------------------------------------------------- Update client s/w /usr/openv/netbackup/bin/update_clients 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 Remember to include the master server's type. Note: The /usr/openv/netbackup/bin/update_clients command without any parameters will update all the UNIX clients. ----------------------------------------------------------------------- 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. /usr/openv/netbackup/bin/admincmd/bpimage -cleanup -allclients Also, I recommend you touch this file so that the process runs in background and does not interfere with other backups. 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 netstat -a | grep bpcd netstat -a | grep 13782 rpcinfo -p | grep 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 NDMP 10000 for comm 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 bp.conf and general settings bpgetconfig -M ctcbs1500 # list OS and NBU version bpgetconfig -L -s sctcvnb31 *** WARNING: be very careful **** bsetconfig -h (push list) #push std exclude list (unix) bpgp #list pools vmpool -listall vmpool -listall -b #see global settings bpconfig -U #see the config file /usr/openv/netbackup/db/config/behavior #check overall policies and get client hardware inventory $NBUHOME/bin/goodies/check_coverage -coverage -hardware -hosts /etc/hosts $NBUHOME/bin/goodies/check_coverage -host ictcvnb11 $NBUHOME/bin/admincmd/bpcoverage -coverage -hardware $NBUHOME/bin/admincmd/bpcoverage -c ictcvnb11 #update robot inventory - rescan volumes vmupdate -rt acs -rn 0 /usr/openv/volmgr/bin/vmupdate -x -rn 2 -rt acs \ -rh mediaserver -vh master \ -interactive -use_barcode_rules #empty/get tapes/import tapes from CAP door The vmupdate command is used to achive this. The most basic form of the command to empty the inport is: vmupdate -rn 0 -rt acs -interactive -empty_ie #import a tape bpimport -create_db_info -id XXXXXX -server genmsbu2 -L "/var/matt" #rename policy name bppolicynew -renameto #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 #To shutdown all Netbackup Daemons /usr/openv/netbackup/bin/netbackup stop /usr/openv/netbackup/bin/goodies/bp.kill_all #To startup Netbackup Daemons /etc/rc2.d/S77netbackup /usr/openv/netbackup/bin/netbackup start /etc/init.d/nbar start #To startup only Media Manager Daemons /usr/openv/volmgr/bin/ltid #To startup Netbackup Advanced Reporter Daemons /etc/init.d/nbar start #Top stop Windows netbackup bpdown -f -v #may have to run twice to stop inetd #Top start Windows netbackup bpup -v -s output you should see from bpps: tracker vmd NdmpMoverListen bpinetd bpjava-msvc bpps #To check the Status of Tape Drives vmoprcmd -d vmoprcmd -d ds vmoprcmd -h MEDIA_SERVER #Up a drive vmoprcmd -up 0 #use the drive index #To check the Netbackup Daemons /usr/openv/netbackup/bin/bpps -a /usr/openv/volmgr/bin/vmps bprestore -L /tmp/backup.txt -C someserver -D someserver -t 19 -s 05/18/2004 -e 05/20/2004 /vol/vol7/somedir #Location of Logs - /usr/openv/netbackup/logs #To check the status of Media vmquery -m bpmedialist -U bpmedialist -U -m 200437 bpmedialist -U -ev 200437 #List all vols vmquery -h hostname -b -a #Delete media from vol/media database #first >= 4.5 # bpexpdate -m H00011 -d 0 vmdelete -m H00011 #first - pre 4.5# bpexpdate -ev H00011 -d 0 GET message: WHICH is OK - meant it worked requested media id was not found in NB media database and/or MM volume database I have tapes whose physical expiration date is shorter than I'd like. How do I change that date? The date to which we are referring is the date that you see in vmquery, and is the date that the volume itself should be expired, and no longer used. This is not related to the expiration date of the images on the tape. The command will tell media manager that the tape should never expire. vmchange -M master -h volhost -exp 0 -m mediaid vmchange -M master -h volhost -exp mm/dd/yy -m mediaid bpmedia -unfreeze -m bpmedia -unfreeze -ev #new label on the tape media bplabel #reread schedule bprdreq -rereadconfig bpschedreq -read_stunits bpschedreq -read_stu_config bpschedreq -predict DATE bpsched -predict 09/11/2004 -client someclient See on master: /opt/openv/netbackup/bin/bpsched.d if backups don't run, move the worklist.???? to another dir and start netbackup #Command to find out the Active Backup Jobs bpdbjobs -report | grep Active bpdbjobs -report | grep Queue bpdbjobs -report | grep $JOBID bpdbjobs -report | grep -v Done bpdbjobs -report -all_columns # # 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 # #List the files that were backed up between time in /some/dir bplist -R -s 04/24/2004 [-e 04/24/2004] /some/dir/* bplist -R -l -s 04/24/2004 [-e 04/24/2004] /some/dir/* bplist -A -b -l /oraclus1p/arch01/prdgpdb/0000001664_prdgpdb.arc #To freeze a media bpmedia -freeze -m # processes bpps -a #list clients bpplclients #troubleshoot/test and get names and IP of client, run from client bpclntcmd -pn bpclntcmd -self bpclntcmd -hn $HOSTNAME bpclntcmd -ip $IP # 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 backup images do we have? bpimagelist -U -d 01/20/2006 -e 01/23/2006 -client amrxm2101 # what are the BackupIDs per job bpimagelist -L -d 01/20/2006 -e 01/23/2006 -client amrxm2101 | grep "Backup ID" # what media was written to for a backup image bpimagelist -media -backupid pocxm1001_1137105611 # 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:" # list overview on a backupid bpimagelist -U -backupid pocxm1001_1137105611 # list details on a backupid bpimagelist -L -backupid pocxm1001_1137105611 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 written to a log file. The beginning of the log will contain a list of tapes needed for the restore. 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. (these commands would be run on your NBU master server) ### First you need to find the exact start time of the backup you want: nbumaster# bpimagelist -U -client CLIENTA -d 08/01/2001 -e /08/01/2001 Backed Up Expires Files KB C Sched Type Class ---------------- ---------- -------- -------- - ------------ ------------ 08/01/2001 05:05 08/15/2001 729846 52624096 N Full Backup CLIENTA_OS 08/01/2001 02:05 11/02/2001 58233 5029312 N Full Backup CLIENTA_DATA ### Next you use the -media flag to see what volume(s) were used for that backup: nbumaster# bpimagelist -media -U -client CLIENTA -d 08/01/2001 05:05 -e 08/01/2001 05:05 Media ID Last Written Server -------- ---------------- ---------- 602595 08/01/2001 05:05 nbumaster 603084 08/01/2001 05:05 nbumaster -------------------------------------------------------------------------------- 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 Exchange 2000/2003 Alternate Server Recovery http://seer.support.veritas.com/docs/264924.htm Restoring Exchange 2003 Information Store to Recovery Storage Group http://seer.support.veritas.com/docs/269933.htm Exchange 2003 Information Store to Recovery Storage Group on Alternate Client http://support.veritas.com/docs/269932 Recovery Storage Group Mailbox Recovery Feature http://www.microsoft.com/technet/prodtechnol/exchange/2003/rmd.mspx -------------------------------------------------------------------------------- Cause Veritas communicates to ACSLS using RPC and uses both UDP and TCP communications. The default communication protocol used by NetBackup is UDP. Fix Change the default communication protocol of NetBackup to TCP in the /usr/openv/volmgr/vm.conf... 1. ACS_TCP_RPCSERVICE ####Make sure this entry is present. 2. ACS_UCP_RPCSERVICE ####Make sure this entry is not present. Note These messages are logged in the Netbackup acssi event log: 11-11-03 20:13:54 SSI[0]: ONC RPC: csi_rpccall(): status:STATUS_NI_FAILURE; failed: clntudp_create() RPC UDP client connection failed, RPC: Port mapper failure Remote Internet address:204.130.33.70, Port: 0; 11-11-03 20:14:24 SSI[0]: cl_ipc_write: Sending message to socket 51658 failed on "Connection refused" 11-11-03 20:14:24 SSI[0]: ONC RPC: csi_ipc_send(): status:STATUS_IPC_FAILURE; Cannot send message To Client:discarded; -------------------------------------------------------------------------------- 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 backup. - rm *.* ./netbackup/db/failures_history - rm *.* ./netbackup/db/jobs except joblock ,jobid and done directory 2. get_num_avail_drives: bptm exit status = 80 - This error is the result of the schedule not being able to connect to bptm on the media servers. Ensure that has none of them are down or offline. - The problem occurs when a Windows 2000 Media Server is demoted to a Windows 2000 Client and the old media server storage unit exists on the master server. 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 a message queue.). sigcld=1 sigalrm=0 sigusr1=0 sigusr2=0 - Appears to be a resource problem - message queue errors - Perhaps a performance problem on Master - too much activity 4. run_backups: run_any_ret_level(3) returned -3(Something maxed out) - In some cases a large number of these messages are repeating in the bpsched log. When this happens enable the oc_check_disable touch file. # touch /usr/openv/netbackup/oc_check_disable This file will disable overcommit checking for drives on the master server. If environment is not using Shared Storage Option (SSO), then adding this file should not cause any problems with backups. In an SSO environment, backups can periodically receive a Status 134 due to the fact that the drives are actually over committed. In this case the jobs will requeue and try again. 5. set_drives_down: set drive 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 what he did. There were "." (period) characters in device names, which might have confused OS. Later customer confirmed that the issue was actually with OS tuning. 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_drives failed with stat 46 -Please check Host Properties under Media Servers and verify that a connection is established to each of the media servers and the master servers. If there is an error then identify the error code Corrective Action: For this instance, the issue was resolved by changing the registry on the media server. The following registry key: HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\Config\Server, had incorrectly listed the media server first and then the master server. The key was modified to have the master server listed first in the list and then the configuration worked properly 7. readstring: EXIT STATUS 134 - The definition for the error code is as follows: Message: EC_resource_busy When using shared drives, or if NetBackup is spanning backups across tapes, you may see a status code 134. This status indicates that all drives in the storage unit are currently in use. If this occurs, NetBackup automatically tries another storage unit; if one is not available, NetBackup re-queues the job and retries it later. 8. get_stunits: get_num_avail_drives failed with stat 80 log_in_errorDB: backup of client pocxm1101 exited with status 150 (termination requested by administrator) - Termination requested by administrator. The process is terminating (or has terminated) as a direct result of a request from an authorized user or process. 9. run_backups: run_any_ret_level(3) returned -1(NO WORK) - There are numerous bpsched engineering bugs, backline need to identify which one is applicable in this case(if at all) ----------------------------------------------------------------------- #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. Add NDMP license to master and mediaserver Add NDMP options package VRTSnbdmp to master and mediaserver Add NDMP needed/neccessary MP/FP for your current release password keys for filers and mediaservers are stored in: #you can edit this file to change/delete names #you can copy from another node as well if you don't know the # password to a filer /usr/openv/volmgr/database/.namespace.chksum /usr/openv/volmgr/bin #root is the username "root" set_ndmp_attr -auth FILER root #filer/datamover/NAS hostname set_ndmp_attr -auth MEDISERVER root #media server w/ NDMP drives set_ndmp_attr -verify FILER #see if password worked set_ndmp_attr -verify MEDISERVER #see if password worked set_ndmp_attr -list #see contents of file (/usr/openv/volmgr/database/.namespace.chksum) start NDMP process on mediaserver (check to see if rc or inittab) /usr/openv/volmgr/bin/ndmpmoveragent.start **** remove the number of drives from the storage unit's useable number for netbackup as these are dedicated drives to NDMP bpadm - storage unit **** setup drives w/ tpconfig - to make the ndmp drives tpconfig #add drives #replace MEDIASERVER w/ mediaserver's hostname for drive path: "MEDIASERVER:/dev/rmt/Xcbn" run tpconfig -d, ndmp drive will be seen as: "/ndmp//dev/rmt/Xcbn" Where "ndmp" shows up in place of the mediaserver hostname. Nothing you can do about this, the ms hostname is forever hidden in tpconfig. Make sure you type it in correctly. The GUI will show the hostname again when viewing the device. add the following to vm.conf DISALLOW_NONNDMP_ON_NDMP_DRIVE setup NDMP STU *** we use *** remote NDMP (tape drive on media server) type NDMP mediaserver, mediaserver direct NDMP (tape drive on filer) type NDMP mediaserver, filername policy use the NDMP STU type NDMP client type NDMP uses port 10000 for comm ----------------------------------------------------------------------- clean drives: to see current mount time: /usr/openv/volmgr/bin/tpclean -l to see last clean time: /usr/openv/volmgr/bin/tpclean -L to set the cleaning flag: /usr/openv/volmgr/bin/tpclean -m 4 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 vmupdate -x -rt tl8 -rn 0 -rh MASTER -vh MASTER -interactive /usr/openv/netbackup/bin/goodies/available_media bperror -media -U bpmedialist -U -mcontents bpmedialist -U -m TAPEID bpmedialist -U -ev TAPEID bpmedialist -summary /usr/sbin/lucreate /var/sadm/system/logs/upgrade_logs /usr/openv/netbackup/bin/admincmd/bpexdate -m media_id -d 0 ----------------------------------------------------------------------- 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 Verifying the ACSSS program registration. # rpcinfo -t {acsls_hostname} 30031 2 program 300031 version 2 ready and waiting # rpcinfo -t {acsls_hostname} 30031 1 program 300031 version 1 ready and waiting 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 provide the appropriate diagnostic info. 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 Run /usr/openv/netbackup/bin/goodies/support/support > /tmp/CASENUMBER.support.out ftp.support.veritas.com user: ftp ftp> cd /pub/support/incoming ftp> bin ftp> hash ftp> put CASENUMBER.support.out ftp> quit StorageTek Hotline: 800-525-0369 acsls is OpenSystems Software, phone queue: 1,2,3 http://www.storagetek.com Tape Recall - Iron Mountain 800-899-IRON ----------------------------------------------------------------------- /usr/openv/netbackup/bin/goodies/ untar NCVU.tar cd SOLARIS ./NCVU -help Manual: NCVU.README installed with the NetBackup Configuration Validation Utility NCVU 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 configurations. ./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 meet the NCVU OS requirements). ./NCVU -host_node master -conf media_server_clients NCVU will validate only the Media Server and Client configuration (no Master Server). ./NCVU -host_node master -conf class_clients NCVU will validate the clients configured in the class specified. ./NCVU -host_node master -conf single_client NCVU will validate the specified client. NCVU Command Line Arguments: NCVU Command Line Argument Significance -host_node Specifies the NetBackup node where you are running NCVU from. Options are master, media_servers or client -conf Specifies the configuration you want it to validate. Run NCVU -help for a full list of configuration types. -debug Generate a file useful for troubleshooting NCVU. -help Display help information for the NCVU utility. -if Specify an input file. -nbu_db_time Specify the number of seconds to wait between prompts for checking the NetBackup catalog. Default: (600 seconds) -net This option is currently not supported. -no_nbu_db Skip (lengthy) NetBackup database checking. -of Specify an output file. -quiet Suppress the majority of observations in NCVU.out that precede the summary. Only WARNING and FATAL messages will be included. -wait Change the delay for Media Server and Client output. Default: (300 seconds) II. Running NCVU from the master server # /usr/openv/netbackup/bin/goodies/NCVU -host_node master -conf master This will create an NCVU_master.out. file. The word master is not to be replaced by a host name. The command should be typed just as it is stated above. # /usr/openv/netbackup/bin/goodies/NCVU -host_node master -conf # all_media_servers This will create an NCVU_media.out. file. The word master is not to be replaced by a host name. The command should be typed just as it is stated above. This will also create .ncvu_media_server_config_input. and .ncvu_media_server_config_output. files for each media server selected by NCVU from the NetBackup storage unit configuration. #/usr/openv/netbackup/bin/goodies/NCVU -host_node master -conf single_client or #/usr/openv/netbackup/bin/goodies/NCVU -host_node master -conf -all_clients This will create an NCVU_client.out. file. The word master is not to be replaced by a host name. The command should be typed just as it is stated above. This will also create .ncvu_client_config_input. and .ncvu_client_config_output. files for each client selected by NCVU from the NetBackup policy configuration. III. Running NCVU from the media server: 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 .ncvu_media_config_input. file from the master to the media server: #/usr/openv/netbackup/bin/goodies/NCVU_media_server -if .ncvu_media_config_input. This will generate an NCVU_media.out. file. IV. Running NCVU from the client: 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 .ncvu_client_config_input. file from the master to the client: #/usr/openv/netbackup/bin/goodies/NCVU_client -if .ncvu_client_config_input. This will generate an NCVU_client.out. 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 Note: "newhost" it the hostname of the client you are installing Add client to a schedule Send required files to the Client Creates a dir in /tmp/bp on the client #NBUHOME/netbackup/bin/install_client_files ftp newhostname root > Client newhostname -- Sun4 hardware running Solaris 2.8 > Installing NetBackup software on newhostname as user root > Password: > Ftp completed successfully. Log into "newhostname" and .... Installs the client configuration files on "newhostname" Log into newhost cd /tmp chmod 755 /tmp/bp/bin/client_config sh /tmp/bp/bin/client_config 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 Caution! The information in this TechNote is based upon certain assumptions, including product, operating system and platform versions. You can review this information in the TechNote Summary portion of this document. This document ( 236104 ) is provided subject to the disclaimer at the end of 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; Next edit the /usr/openv/volmgr/bin/driver/sg.links 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 type=ddi_pseudo;name=sg;addr=13,0; sg/c\N0t19l0 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 type=ddi_pseudo;name=sg;addr=3A,1; sg/c\N0t58l1 Note: The values for the addr= string are in hexadecimal, but the values for sg/c\N0t19l0 are in decimal. Note2: The format of this line if very important. The two parts of this line need to be separated by a tab, not spaces (i.e. type=ddi_pseudo;name=sg;addr=3A,1;sg/c\N0t58l1). 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. The script sg.install also concatenates the entries in /usr/openv/volmgr/bin/driver/sg.links to the end of the Solaris device links file /etc/devlink.tab. It is recommended to remove any previous sg device link entries in the /etc/devlink.tab file before running sg.install. 5) If setting up persistent binding for tape drives in /kernel/drv/st.conf then it is also necessary to setup entries for the persistent binding of the tape drives to the world wide names (wwn) in the /kernel/drv/sg.conf file too. For example: If you have some native-fibre tape drives with targets 60-62 do this: A. Make sure the /kernel/drv/st.conf file has persistent binding setup for the tape drives. name="st" class="scsi" hba="fcaw0" wwn="500104F000426D0A" target=60 lun=0; name="st" class="scsi" hba="fcaw0" wwn="500104F00043E20C" target=61 lun=0; name="st" class="scsi" hba="fcaw0" wwn="500104F00043A45C" target=62 lun=0; B. Edit the /kernel/drv/sg.conf file to setup persistent device binding for these tape drives. name="sg" class="scsi" hba="fcaw0" wwn="500104F000426D0A" target=60 lun=0; name="sg" class="scsi" hba="fcaw0" wwn="500104F00043E20C" target=61 lun=0; name="sg" class="scsi" hba="fcaw0" wwn="500104F00043A45C" target=62 lun=0; C. Make sure the /etc/devlink.tab file is setup correctly. type=ddi_pseudo;name=sg;addr=3C,0; sg/c\N0t60l0 type=ddi_pseudo;name=sg;addr=3D,0; sg/c\N0t61l0 type=ddi_pseudo;name=sg;addr=3E,0; sg/c\N0t62l0 D. If any changes are made to these three files then it is necessary to rebuild the device tree with a reboot -- -r or rm /dev/rmt/*; rm /dev/sg/*; drvconfig; tapes; devlinks. When sg.install is run, it reloads the sg driver and puts the new sg configuration files in place. The key to make any configuration changes to sg.conf or devlink.tab permanent is to edit the files /usr/openv/volmgr/bin/driver/sg.conf and /usr/openv/volmgr/bin/driver/sg.links so that they will be copied into place whenever sg.install is run. 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 Subject: NetBackup DataCenter - Application - Configuration NetBackup DataCenter - Application - Device Management NetBackup DataCenter - Application - Documentation NetBackup DataCenter - Application - How To NetBackup v3.2 and prior (UNIX Platforms) - Application - Configuration NetBackup v3.2 and prior (UNIX Platforms) - Application - Device Management NetBackup v3.2 and prior (UNIX Platforms) - Application - Documentation NetBackup v3.2 and prior (UNIX Platforms) - Application - How To Languages: English (US) Operating Systems: Solaris 2.6, 7.0 (32-bit), 8.0 (32-bit) ================================================================ Symptom: How to use the new configurable media ID generation vm.conf rules for LTO barcodes Exact Error Message: 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) With NetBackup 3.4 patch NB_34_1 or (NB_341_1 on NT) or NetBackup 4.5 installed on all NetBackup media servers and master server, how media IDs are generated is now configurable. 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. The media ID generation rule has the following syntax: MEDIA_ID_BARCODE_CHARS ::::: where robot_number is the robot number, barcode_length is the number of characters in the media's barcode format, c1 is the first character of the Media ID c2 is the second character of the Media ID c3 is the third character of the Media ID c4 is the fourth character of the Media ID c5 is the fifth character of the Media ID c6 is the sixth character of the Media ID c1-c6 can specify a character from the media barcode or specify a fixed character by prefixing the character with a "#". For example, the rule: 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: Note: This is not a recommended procedure. It should be used only in extreme situations and as a last step in attempting to restore data. This procedure has been used on numerous occasions with success. First, figure out the fragment number and the block size needed. Ex: # ./bpmedialist -mcontents -m D0004 # ./bpmedialist -mcontents -ev D0004 media id = D0004, allocated 09/21/99 14:19:, retention level = 1 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 Then work the tape: ficus# tpreq -m D0004 -a r -d dlt -p NetBackup -f /tmp/mytape ficus# tpreq -ev D0004 -a r -d dlt -p NetBackup -f /tmp/mytape 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. ficus# /usr/openv/volmgr/bin/vmoprcmd -d (to verify the media is mounted) PENDING REQUESTS < NONE > 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 - ADDITIONAL DRIVE STATUS Drv DriveName Multihost Assigned Comment 0 Drive0 No - 1 Drive1 No ficus 2 Drive2 No - ficus# ficus# tpconfig -d (to get the device file name for commands): Index DriveName DrivePath Type Multihost Status ***** ********* ********** **** ********* ****** 0 Drive0 /dev/rmt/0cbn dlt No UP TLD(0) Definition DRIVE=1 1 Drive1 /dev/rmt/1cbn dlt No UP TLD(0) Definition DRIVE=2 2 Drive2 /dev/rmt/1lbn dlt No UP Currently defined robotics are: TLD(0) robotic path = /dev/sg/c0t6l0, volume database host = ficus Standalone drive volume database host = saturn ficus# mt -f /tmp/mytape rew (goes to beginning of tape) ficus# mt -f /tmp/mytape stat (verify at beginning of tape) Vendor 'QUANTUM ' Product 'DLT7000 ' tape drive: sense key(0x0)= No Additional Sense residual= 0 retries= 0 file no= 0 block no= 0 ficus# mt -f /tmp/mytape fsf (position to file #1) ficus# mt -f /tmp/mytape stat (verify) Vendor 'QUANTUM ' Product 'DLT7000 ' tape drive: sense key(0x0)= No Additional Sense residual= 0 retries= 0 file no= 1 block no= 0 ficus# mt -f /tmp/mytape fsr (position to record 1) ficus# mt -f /tmp/mytape stat (verify) Vendor 'QUANTUM ' Product 'DLT7000 ' tape drive: sense key(0x0)= No Additional Sense residual= 0 retries= 0 file no= 1 block no= 1 ficus# /usr/openv/netbackup/bin/tar -tvf /tmp/mytape (run tar command) Blocksize = 2 records Hmm, this doesn't look like a tar archive. Skipping to next file header... 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 ficus# /usr/openv/netbackup/bin/tar -tvf /tmp/mytape Blocksize = 126 records Hmm, this doesn't look like a tar archive. Skipping to next file header... drwxr-xr-x root/other Jul 27 09:51 1999 / drwxr-xr-x root/sys Jul 27 07:36 1999 /etc/ drwxrwxr-x root/sys Mar 8 14:27 1999 /etc/default/ -r--r--r-- root/sys Oct 30 16:58 1996 /etc/default/sys-suspend -r-xr-xr-x bin/bin Mar 5 12:45 1999 /etc/default/cron -r--r--r-- bin/bin Mar 5 12:45 1999 /etc/default/fs -r--r--r-- root/sys Mar 5 12:45 1999 /etc/default/inetinit -r--r--r-- root/sys Mar 5 12:45 1999 /etc/default/kbd -r--r--r-- root/sys Mar 5 12:45 1999 /etc/default/passwd -r--r--r-- root/sys Mar 5 12:45 1999 /etc/default/tar To get the information off of the tape execute: /usr/openv/netbackup/bin/tar -xvf /tmp/mytape -b [BYTESIZE/512] In this example [BYTESIZE/512] is 32768 / 512, which equals 64. 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. rsh tape_host dd if=/tmp/mytape bs=[BLOCKSIZE] \ | /usr/openv/netbackup/bin/tar -xvf - -b [BYTESIZE/512] In this example [BLOCKSIZE] equals 32768 and [BYTESIZE/512] equals 64. To unmount the media run /usr/openv/volmgr/bin/tpunmount /tmp/mytape ------------------------------------------------------------------------ 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,# *** to set cleaning mounts: >set clean volume(tapeNumber) example: >set clean 100 CLN024 or give a range of volumes: >set clean 100 CLN025-CLN050 =========================================== 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 database wasn't up after install, you have to configure it: run as acsss, acsss_config ================================ How to audit the L5500/9310 from acsls: ACSSA> audit 0,0,0 ser =============================== logical logs filled on informix, had to flush them. nsr procs must be running inorder to handle them. should be 8 at all times. if not 8, then as acsss run: db_command ism_start Otherwise, if you have to dump tranlogs and get a level zero backup, do the following procedure with STK's help: -----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 onstat file did not show the onconfig file changed ) To configure the ontape utility, do the following; 1) Login as 'root' and then source the ACSLS environment. # . /export/home/ACSSS/.acsss_env 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/ note: is the name of the device that we are backing up to. The name can be whatever you choose. 3) Create the backup device # cd /export/backup # touch # chmod 666 # chown informix # chgrp informix 4) Run the ontape command. This will back up the current logical logs freeing the used logical logs. # ontape -a You will see the following interactive output; Performing automatic backup of logical logs. Please mount tape 1 on /export/backup[/file and press Return to continue ... Do you want to back up the current logical log? (y/n) y Please label this tape as number 1 in the log tape sequence. This tape contains the following logical logs: 6 Program over 5) After the ontape finishes, attempt to use onbar to backup the database # onbar -b 6) When the prompt returns, check the return code # echo $? 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 0, 0, 1, 3 online available 9840 0, 0, 1, 4 online available 9840 0, 0, 1, 5 online available 9840 0, 0, 1, 6 online available 9840 0, 0, 1, 7 online available 9840 0, 0, 1, 8 online in use T9840B 0, 0, 1, 9 online available T9840B 0, 0, 1,10 online available T9840B 0, 0, 1,11 online available T9840B 0, 0, 1,12 online available T9840B 0, 0, 1,13 online available T9840B 0, 0, 1,14 online available T9840B 0, 0, 1,15 online available T9840B 0, 0,10, 0 online available T9940A 0, 0,10, 1 online available T9940A 0, 0,10, 2 online available T9940A 0, 0,10, 3 online available T9940A 0, 0,10, 4 online available T9940A 0, 0,10, 5 online available T9940A 0, 0,10, 6 online available T9940A 0, 0,10, 7 online available T9940A ACSSA> dis X 0,0,1,8 f ----------------------------------------------------- ============================================================ Restore tapes from an alternate site. ============================================================ 1. Get tapes from offsite or alternate datacenter. 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. 2. Inject tape(s) into the library. Edit the '~netbackup/bin/goodies/MEDIA/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. IF ADIC: Run ~netbackup/bin/goodies/MEDIA/INJECT.ksh 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) 4. If tapes were suspended, then unfreeze them: (The state should be 'IMPORTED') bpmedialist -U -m ID bpmedia -unfreeze -m ID 5. Import tape(s) one at a time, start with the primary volume first (if known) Follow documentation see following diagrams and steps. import for phase I import for phase II 6. Add host that needs restore as a client list policies bppllists add client (following is an example) bpplclients POLICY -add CLIENT.domain HARDWARE OS bpplclients addhoc_backups -add someclient Solaris Solaris8 7. Do the restore. Select proper server, client and restore client. Pay attention to the date selections. NOTE: set alternate restore directory if needed/desired 8. When finished, eject the tape(s). Edit the '~netbackup/bin/goodies/MEDIA/slots' file and put in the slots that were noted from the injecting process. 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) 10. Unselect the write protect tab the tape(s). 11. Send the tape(s) back. Importing Backup Images NetBackup can import backups that have expired, or are from another NetBackup server. During an import operation, NetBackup recreates NetBackup catalog entries for the backups that are on the imported volume. This option is useful for moving volumes from one site to another and for recreating NetBackup catalog entries for expired backups. 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. Notes About Importing Backup Images You cannot import images generated for clients in Apollo wbak policies. NetBackup does not direct backups to imported volumes. To import from a volume that has the same media ID as an existing volume (for example A00001) on this server, first duplicate the existing volume to another media ID (for example, B00001). Then, remove information about the existing media ID that is causing the problem (in this example, A00001) from the NetBackup catalog by running the following command: /usr/openv/NetBackup/admincmd/bin/bpexpdate -d 0 -ev media ID Next, delete the existing media ID that is causing the problem (in this example, A00001) from Media Manager on this server. Finally, add the volume you are importing (the other A00001) to Media Manager on this server. The Media Manager System Administrators Guide contains instructions for deleting and adding volumes. 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. To initiate an import Phase I The result of initiating an import is to create a list of expired images from which you can select images to import. However, no importing occurs at this stage. 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. Import Phase I view To import backup images Phase II 1. In the NetBackup Administration Console, expand Master Server > NetBackup Management > Catalog. 2. Set up the search criteria to find imported images by setting the search action to Import. 3. Select the image(s) you wish to import and Select Actions > Import. The Confirm Import dialog appears. 4. To view the log, click the Results tab, then select the import job log just created. 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 message board page: http://mailman.eng.auburn.edu/pipermail/veritas-bu/2003-June/017347.html What is listed below is basically a walkthrough on how to get a Qualstar 8236 robot with two IBM-LTO2 (ULTRIUM-TD2) drives to work under Solaris 9 with Netbackup 4.5FP3 (or GA with MP4). This also contains an st.conf line for the Sun L40 Unit (for those that are interested). * 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 Solaris from the 04/03 Release. Download and install the Latest Patch Cluster from 5/30/03. Download patch 113277-11 from Sun (Adds IBM LTO-2 Native Support). You can verify IBM Ultrium-TD2 support by typing: strings /kernel/drv/st | grep -i lto It should return: [root@tape /]$ strings /kernel/drv/st | grep -i lto HP Ultrium LTO 2 HP Ultrium LTO Seagate Ultrium LTO IBM Ultrium Gen 2 LTO IBM Ultrium Gen 2 LTO IBM Ultrium LTO IBM Ultrium LTO [root@tape /]$ Install Qlogic 4.08 Drive for qla2200 HBAs. 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. Start SANblade Control fx /opt/QLogic_Corporation/SANblade/Control_FX/scfx Go through the wizard and setup persistent binding for each adapter - Disk Subsystem on one adapter, Tape Subsystem on the other adapter. Add these entries to the /kernel/drv/st.conf # Quantum DLT8000 Support "QUANTUM DLT8000", "Quantum DLT8000", "DLT8k-data", # IBM LTO-2 (Ultrium-TD2) Support "IBM ULTRIUM-TD2", "IBM Ultrium-2", "CLASS_LTO2", "IBM ULT3580-TD2", "IBM 3580 Ultrium-2", "CLASS_LTO2"; # Quantum DLT8000 DLT8k-data = 1, 0x36, 0, 0x0D639, 4, 0x84, 0x85, 0x88, 0x89, 2; # LTO-2 (Ultrium-TD2) Support CLASS_LTO2 = 2,0x3B,0,0x45863d,2,0x40,0x42,0,60,0,540,9060,720,720,9060; Reboot with: reboot -- -r (to rebuild the kernel). Put a test LTO-2 tape in each drive and test the new devices with ufsdump (ufsdump 0f /dev/rmt/(tape dev) /) Example: ufsdump 0f /dev/rmt/3cbn / * Veritas Setup * Veritas uses the ST driver, but need the SG devices created correctly. Edit /etc/devlink.tab and remove the entries between: # begin SCSA Generic devlinks file - creates nodes in /dev/sg and # end SCSA devlinks Next run the following commands to build the correct dev files: # Remove existing sg devices rm /dev/sg/* # Remove current driver /usr/sbin/rem_drv sg # Remove the config file rm -f /kernel/drv/sg.conf # The qualstar unit sets each drive on its own lun # Max Targets 15, Max Luns 2 - rebuild both cd /usr/openv/volmgr/bin/driver ; /usr/openv/volmgr/bin/sg.build sg.links -mt 15 -ml 2 -sl ./sg.links cd /usr/openv/volmgr/bin/driver ; /usr/openv/volmgr/bin/sg.build sg.conf -mt 15 -ml 2 -sc ./sg.conf cd /usr/openv/volmgr/bin/driver ; ./sg.install Then run /usr/openv/volmgr/bin/sgscan You should see the new devices. For example: * Test drive support under Veritas * Install latest MP or FP+fixes. Install Latest Mappings (April 7th mappings includes support for Ultrium2 drives). The Qualstar 8236 is not recognized through configuration, so it needs to be setup manually. Setup the Qualstar unit as a TLD (DLT Tape Library) device. The IBM drives should be auto configured, if not, specify both drives as HCART2. Create a new policy. Click "Allow Multiple Streams" under the files section create entries with "NEW_STREAM" directives. Example: NEW_STREAM /backup/home / NEW_STREAM /backup/h2 /backup/disk2 This will spawn one stream to one drive, and the other stream to the remaining drive. Configure Multiplexing (If needed). Start a manual backup. I am receiving around 30MB/sec on each IBM LTO-2 drive. ------------------ I did this and everything looks fine. Thanks. 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. The global device database is found in /usr/openv/volmgr/database/globDB, which is held on the master server. 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. Exact Error Message: Cannot synchronize global device 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 Select Drive Configuration | Update. Enter the name of the changed drive. Press Enter to keep all the existing values until it asks if you are sure you want to update. Enter 'y' to update. 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: /usr/openv/volmgr/bin/vmglob -listall -java | grep {hostname} 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 vmglob -set_gdbhost {master} -h {master} vmoprcmd -h {media_server} -autoconfig -sync vmglob -listall -java #for each media server vmglob -set_gdbhost {master} -h {media_server} vmoprcmd -h {media_server} -autoconfig -sync vmglob -listall -java ----------------------------------------------------- reset the globDB (due to bad memory of deleted devices) #on the master vmglob -listall > /var/tmp/vmglob-listall cp /usr/openv/volmgr/database/globDB /var/tmp/globDB # the following deletes all entries # run on the master vmglob -delete #on each media server vmglob -set_gdbhost MASTER tpautoconf -upgrade vmglob -listall ----------------------------------------------------- if vmglob is deleted from master, but not from media servers (do NOT do a vmglob -delete *** BAD - removed globDB entries) 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 tpautoconf -sync #fails - cannot sync database To determine the cause of the syncnronization failure: 1. Create a log folder on the media server which is failing: \volmgr\debug\tpcommand\ 2. Rerun the Global Device Database synchronization (as described above) 3. Examine the log in the folder \volmgr\database\tpcommand\ for the failure ----------------------------------------------------- #vault /usr/openv/volmgr/bin/vmchange -res -api_eject -map 0,0,0 -rn 2 -rt acs -rh mediaserver -vh master -v Offsite3 -ml H02238:H02239:H02240:H02242 cd /usr/openv/netbackup/vault/production ./bpvault.opsmenu dup_param_V100_full vltadm vlteject -eject -report ----------------------------------------------------- /usr/openv/netbackup/bin/vltcore -jobid 459631 -dup_id 61 -function preview -profile 1/V1/LTO-Profile -xmlfile vault.xml vltrun 1/V1/LTO-Profile ----------------------------------------------------- dups don't run see if there is a lock file /usr/openv/netbackup/vault/sessions/$POLICY_NAME/vault.lock ================================================================================ Vaulting at Tower Vault Dir /usr/openv/netbackup/vault /usr/openv/netbackup/vltreports Contains Reports of all Vault Sessions Two Types of Vaulting 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 Every Vault session has a session ID ( sid ) Directory e.g. sid35 Within each sid directory, are the details about that session. Some are given below- preview.list Contains the list of images to be vaulted # 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 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 ). Procedure to Eject Tapes Manually for Vault Sessions 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. Profile for Daily Vault - vlt_daily_dup Profile for Weekly Vault - vlt_weekly_os /usr/openv/netbackup/bin/vltopmenu NetBackup Vault Operator Menu Current Profile: None Current Session: 0 Current Report Destinations - Print command: /usr/ucb/lpr Email: Directory: [1] Select Profile [2] Select Session [3] Inject Media into Robot [4] Eject Media for This Session [5] Modify the Report Destinations... [6] Run Reports for This Session [7] Run Individual Reports... [8] Consolidate All Reports [9] Consolidate All Ejects [10] Consolidate All Reports and Ejects [q] Quit Selection--> 1 Enter Profile (or Robot Num/Vault/Profile triplet): vlt_daily_dup NetBackup Vault Operator Menu Current Profile: 0/Daily_dup/vlt_daily_dup Current Session: 202 Current Report Destinations - Print command: Directory: /usr/openv/netbackup/vltreports/ [1] Select Profile [2] Select Session [3] Inject Media into Robot [4] Eject Media for This Session [5] Modify the Report Destinations... [6] Run Reports for This Session [7] Run Individual Reports... [8] Consolidate All Reports [9] Consolidate All Ejects [10] Consolidate All Reports and Ejects [q] Quit Selection--> 4 Starting the operation... Beginning eject procedure. Please wait... Eject process complete. The operation has completed. Press [Return] to continue ----------------------------------------------------- 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 If tapes were suspended, then unfreeze them: (The state should be 'IMPORTED') bpmedialist -U -m ID bpmedia -unfreeze -m ID Import tape(s) one at a time, start with the primary volume first (if known) Follow documentation import phase I import phase II Add host that needs restore as a client list policies bppllist 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 When finished, eject tape(s) ~netbackup/bin/goodies/MEDIA/EJECT.ksh edit the 'slots' file and put in the slots that were noted from the injecting process Update library /usr/openv/volmgr/bin/vma s r 1 (appropriate library) u unselect the write protect tab the tape(s) send tape back ================================================================================ 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. If the images are not moved correctly or if the Media Server is de-commissioned before any of this takes place, any restores will have to be performed by importing the tapes, which is a much longer process. These are the steps required to decommission 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: Note: Use -l to get one line of output per tape. bpmedialist -mlist -l -h bpmedialist -mlist -L -h bpmedialist -mlist -U -h 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: bpmedia -movedb -m -oldserver \ old bpmedia -movedb -ev -oldserver \ \ -newserver 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: FORCE_RESTORE_MEDIA_SERVER = fromhost tohost 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. 1. NetBackup requires a Digital Linear Tape (DLT) volume, so Media Manager attempts to assign one from NB_pool_dept_1 in Robot C. 2. Robot C has no unassigned volumes available in the NB_pool_dept_1 pool. 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. To configure the scratch pool 1. Add a volume pool to be used as the scratch pool 2. Specify the attributes for the scratch pool as follows: 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). Description: Scratch Pool. 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. 4. Add a SCRATCH_POOL entry to the install_path\Volmgr\vm.conf file: SCRATCH_POOL = pool_name To have Media Manager allocate all volumes to volume pools, do one of the following: - Create other volume pools as required, but add no volumes to them. - 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. For more information, refer to the NetBackup Media Manager System Administrator's Guide. Related Documents: 232349: VERITAS NetBackup DataCenter 3.4, Media Manager System Administrator's Guide. Windows NT/2000 http://support.veritas.com/docs/232349 232350: VERITAS NetBackup DataCenter 3.4, Media Manager System Administrator's Guide. UNIX. http://support.veritas.com/docs/232350 ================================================================================ 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 schedule workload is that large and jobs are queued. 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. *bpsched storage unit polling process* 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: /usr/openv/netbackup/bin/admincmd/bprdreq -rereadconfig #bp.conf changes 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 allow tapes to be moved between master servers. 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: 1. All tapes being moved must have unique barcodes. 2. All client names must be unique. 3. None of the tapes being moved will be used for backups at the new location. 4. There exists a library at the new location to support the correct tape format. 5. Both masters must be running the same release of NetBackup. 6. Both masters must be of similar architecture (both UNIX or both Windows). 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/ or \Program Files\VERITAS\netbackup\db\images\. 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. To make this entire process more easily managed, it would be advisable to ensure that the polices are correctly configured on the originating master. Some things to consider are, having the target backups not multiplexed to ensure only the desired images are sent offsite. Also, directing the target backups to a specific unique volume pool should be done to make it easier to identify and track the required media. This will also ensure that only the desired images are taken offsite. If the originating site has multiple storage units, it would be easiest to define this special volume pool on one storage unit. Another way to achieve this would be to duplicate the images that are going to be sent to the new location using either Vault of bpduplicate and directing the duplicate images to a special volume pool. Careful planning in the configuration at the originating site can make this process work more smoothly. ================================================================================ 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 (560010) may be seen. 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. The message is purely informational in nature and no corrective action is required. ================================================================================ 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: 1. set_ndmp_attr -auth -Enter the NDMP device name as specified for the device and the root username for the NAS device. This will prompt twice for the root user password and connect to the NAS device. 2. set_ndmp_attr -verify -This verifies a connection can be made to the NAS device and returns some configuration information. 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 d. Quit the telnet session. 4. set_ndmp_attr -robot MC0 0 0 0 -This sets the robot for use with the NDMP device. 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. 5. tpconfig -add -robot -robtype -robpath -vdbhost -This adds the robot to the NetBackup configuration. 6. tpconfig -add -drive -type -name -drstates UP -robot -robtype -robdrnum <#> (all entered from a single command line) -It is imperative to perform this command on each drive to add it to the NetBackup configuration. 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: VERITAS NetBackup Configuration Validation Utility (NCVU) 5.0 quick startup guide 1. If using VERITAS NetBackup 3.4 or earlier, it is necessary to temporarily rename the support script in /usr/openv/netbackup/bin/goodies, then create a new /usr/openv/netbackup/bin/goodies/support directory. Move the support script to that directory. (See the following sample commands to do this.) cd /usr/openv/netbackup/bin/goodies mv support support.tmp mkdir support mv support.tmp support/support 2. Download the file NCVU_266158.tar to the /usr/openv/netbackup/bin/goodies/support directory. (See the Download Now link at the bottom of this page.) 3. Extract the NCVU.README and NCVU.tar files by running the following commands: cd /usr/openv/netbackup/bin/goodies/support tar xvf NCVU_266158.tar 4. Extract the platform-specific NCVU binaries by running the following commands: cd /usr/openv/netbackup/bin/goodies/support tar xvf NCVU.tar The following directories should be present after the tar process finishes: ls AIX HP-UX SOLARIS 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 . 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 . 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 ./ 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. ************************************************************************* This version of NCVU takes approximately 27.6 megabytes of space to install. 14.2 megabytes of this space is for the NCVU.tar file and the remaining space is for the actual NCVU programs associated to the platform. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7. OPERATION INFORMATION: 1. SPACE REQUIREMENTS: 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, patches installed, bp.conf and vm.conf entries, storage units configured, and classes 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 = 30-50K NCVU_media.out 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. .input = 1.4-2K .output = 30-50K NCVU_client.out = 45K with 30K for each additional client. Each client generates a .input and a .output communication file. .input = @3K .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 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. .output = @100K NCVU_client.debug = @235K with @35K for each additional client. Each client generates a .output communication file. .output = @85K The minimum amount of free space required to run a single instance of NCVU for master, media servers and clients with debug level 9 enabled can be determined with the following formula: Using the above example for a site with three media servers and ten clients: NCVU_master.out NCVU_master.debug NCVU_media.out NCVU_media.debug number of additional media servers X 200K client .out client .debug + number of clients X 120K ------------------------------------------- total space required Using the above example for a site with three media servers and ten clients: NCVU_master.out 30,000 NCVU_master.debug 275,000 NCVU_media.out 75,000 NCVU_media.debug 275,000 number of additional media servers X 200K 400,000 NCVU_client.out 45,000 NCVU_client.debug 235,000 number of additional clients X 120K 1,080,000 --------- total space required 2,415,000 Since each installation is different, the end user should formulate the typical sizes for the various NCVU files if free space is a concern. 2. COMMAND HELP INFORMATION: To obtain information on how to run "NCVU," issue the following help command which will output general information about the utility. # ./NCVU -help NAME NCVU SYNOPSIS NCVU [-help option] [-host_node node] [-conf option] [-if filename] [-of filename] [-net] [-debug level filename] [-quiet] [-no_nbu_db] [-wait seconds] 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 or -conf 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 , single_media_server , single_client , class_clients , media_server_clients , policy_clients , 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 netbackup/bin/admincmd directories are checked for existence, non-zero size, executable, are owned by root. - UNIX sum output is provided for each NetBackup master server binaries in the netbackup/bin and netbackup/bin/admincmd directories. - NetBackup startup and shutdown scripts in appropriate locations and validates startup and shutdown commands. - Runs a "bpps" command and validates the appropriate NetBackup master server minimum "bprd", "bpdbm" and "bpcd" (if standalone) processes are running. This detects more than one "bprd" or "bpdbm" main process running. This also detects orphaned "bprd" and "bpdbm" processes. - Depending on the version of NetBackup, checks that at least one "bprd", "bpdbm", "bpcd", "bpjobd", "vnetd" and "vopied" process is listening on it's port. - Validates master server entries in the netbackup/bp.conf file. Reports on configured operating system services ability to resolve the configured master server SERVER name. This notes other NetBackup node entries, and checks for invalid entries. - Checks the NetBackup global configuration settings, this analyzes the settings that affect disk utilization versus the associated disk partition usage. - Checks for the existence of the netbackup/db/altnames/No.Restrictions file. - Validates the configuration of the Jobs database. - Checks for the existence of any non-standard NetBackup files in the netbackup, netbackup/bin and netbackup/db/config directories. - Depending on the version of NetBackup, lists any NetBackup logging that is turned on in the openv/netbackup/logs, openv/volmgr/debug and openv/logs directories. - Runs a "tpconfig -d" to obtain the NetBackup volume database hosts configured on the master server and verifies that those configured exist in the netbackup/bp.conf file. - Checks the NetBackup database backup configuration versus the actual file systems on the master server that contain the databases. The file systems are traversed and a list of directory paths that should be part of the database backup is formulated. This list of directories is compared against the NetBackup database backup configuration. Recursive directories are also checked for. If the backup server to perform the database backup is the master server and if the backup media are of the disk type, checks are made to verify that the designated NetBackup database paths are not on the same disk partition as the media path. - Runs various bpclntcmd utilities to validate the master server name in the netbackup/bp.conf file and any associated hostnames or IP addresses returned by the configured operating system services. Conflict checks after the master server's summary of warnings, checks storage unit and tpconfig configuration conflicts. all_media_servers media server configuration checks group_media_servers including checks on the master server single_media_server and each selected media server. Media server checks done on the master server: - Master server's domain name. - NetBackup master server version file check. - Operating system host services configuration file settings. - Depending on the version of NetBackup, the bprd, bpdbm, vnetd, vopied and bpjobd port number entries in the /etc/services file. - Checks for NetBackup packs installed on media server. 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. - Operating system services configuration file settings. - Operating system host services configuration file settings. - Validates that the NetBackup bprd, bpdbm and bpcd 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. - Checks for NetBackup packs installed on media server. Reports pack install processes aborted and packs installed out of sequence. - NetBackup media server binaries in the openv/netbackup/bin and openv/volmgr/bin directories are checked for existence, non-zero size, executable, are owned by root. - Lists the NetBackup media server libraries in the openv/lib directory and performs a sum on those found. - NetBackup startup and shutdown scripts in appropriate locations and validates that the proper media server startup and shutdown commands are present. Also validates that no master server commands for bprd or bpdbm are present. - Runs a bpps command and validates that no bprd or bpdbm processes are running on the media server. - Depending on the version of NetBackup, checks that the bpcd and vopied processes are listening on their port. - Validates media server 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, netbackup/bin and volmgr/database directories. - Lists any NetBackup logging that is turned on in the openv/netbackup/logs and openv/volmgr/debug directories. - Checks for the existence of Shared Storage Option information. - Runs a tpconfig -d and validates that each applicable storage unit's configuration is valid. Checks the that any media server type of storage units are present. Checks for a valid number of drives, valid density of drives and that robots have robotics configured. Any drives or robotics found that are not associated to a storage unit are reported. Checks that the configured volume database hosts are contained in the list of volume database hosts from the master server. Checks for NDMP device types. - If on the appropriate system, checks that an SG driver is loaded. - Runs a sgscan all and confirms that any tape drives or robotics configured in tpconfig are contained in the output. Reports any NetBackup supported tape devices contained that are not configured in tpconfig. - If valid tape drives are configured in tpconfig, and sgscan all reports their existence, examines the operating system's tape driver configuration file. Checks for valid file syntax. Validates entries for NetBackup supported tape devices are validated for recommended values. - Validates all entries in the volmgr/vm.conf file. Reports on configured operating system services ability to resolve the configured volmgr/vm.conf files SERVER, KNOWN, DEVICE_HOST or MH_HOST_NAME hostnames entries. - If the media server is a NetBackup for NDMP server, validates the NDMP configuration and NDMP server responses. - Checks the NetBackup database backup configuration versus the actual file systems on the media server that contain the databases. The file systems are traversed and a list of directory paths that should be part of the database backup is formulated. This list of directories is compared against the NetBackup database backup configuration. Recursive directories are also checked for. If the NetBackup database media is a disk type, checks are made to verify that the designated NetBackup database paths are not on the same disk partition as the media path. If the NetBackup database media is a media type, does a vmquery check on the media ID and verifies that the media exists, is in the NetBackup volume pool, is of the correct type and the correct NetBackup status. - Reports on configured operating system services ability to resolve the client names configured in the classes/policies for storage units on the media server. - Reports on configured operating system services ability to resolve the configured NetBackup database hosts names. - 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. - Runs various bpclntcmd utilities to validate the client names configured in the classes/policies for storage units on the media server and any associated hostnames or IP addresses returned by the configured operating system services. - Runs various bpclntcmd utilities to validate the volmgr/vm.conf files SERVER, KNOWN, DEVICE_HOST or MH_HOST_NAME hostname entries and any associated hostnames or IP addresses returned by the configured operating system services. - Checks on the media server's ability to ping the master server. - Checks on the media server's ability to ping the clients configured in the classes/policies for storage units on the media server. - Checks on the media server's ability to ping any NetBackup database hosts that are to be backed up by this media server. single_client class_clients policy_clients media_server_clients all_clients Client configuration checks including checks on the master server and each selected client. Client checks done on the master server: - Domain name. - NetBackup master server version file check. - Operating system host services. - NetBackup bprd and bpdbm port number entries configured in each configured service service. - NetBackup master server installed NetBackup packs. - Validates client entries in the netbackup/bp.conf file. - Reports on the configured operating system host services abilities to resolve the configured SERVER and CLIENT_NAME hostnames. Notes other NetBackup node entries. Checks for invalid entries. - Lists the configured storage unit host connections. - Checks the configured policies based on the -conf parameter for the following: Client name, hardware type and Operating System version. Class name, type, residence and associated residence host connection. - Reports on the configured operating system host services abilities to resolve the selected client's hostnames. - Runs various bpclntcmd utilities to validate the selected client's hostnames. - Checks on the master server's ability to ping the selected client's unit host connections. - Checks for the existence of the selected client's NetBackup hardware and software binaries in the netbackup/client repository. Builds a list of the appropriate binaries and sizes. ------> Based on the above information, an input configuration file is built on the master server for each selected client. The input file is redirected into an remsh command which then executes the NCVU program on each pingable client. The master server then waits in a loop for the return of an output file from each client. 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 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. - Checks if the client is a NetBackup database extension client. Additional database extension checks are made for Informix, Lotus Notes and Oracle clients. [-if] [input file path/name] -if requires input file path/name. Currently not supported. [-of] [output file path/name] Without this option, the default utility output files are: ./NCVU_master.out. -conf master ./NCVU_media.out. -conf ./NCVU_client.out. -conf [-net] Analyze configured NetBackup node's network communication functionality. Currently not supported. [-debug] [level] [output file path/name] Output additional debug information to the designated debug file for -conf or -net options. Output debug information: Default level 1 NCVU ABORT errors level 2 Warnings level 3 Observations level 5 Subroutines level 8 Parse information level 9 VERBOSE Output file path/name Default = ./NCVU.debug [-quiet] Quiet mode prints out only WARNING or NCVU ABORT messages to the utility output file. [-no_nbu_db] Skips the checking of the NetBackup database backup configuration. Useful if this check takes a significant amount of time due to extensive file systems. [-wait] [seconds] The amount of time in seconds that the master server will wait when running -conf or -conf for the return of client output files. Once the time expires, any output files not received will be noted in the utility output report. The default value is 300 seconds. 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 Report on the NetBackup media server sample_media and the associated operating system. Run on the master server. example# ./NCVU -host_node master -conf single_media_server sample_media Report on NetBackup client sample_client and the associated operating system. Run on the master server. example# ./NCVU -host_node master -conf single_client sample_client Report on NetBackup clients that are members of the class/policy named sample_class and the associated operating system. Run on the master server. example# ./NCVU -host_node master -conf policy_clients sample_policy Report on NetBackup clients that are members of policies that utilize the media server named sample_media_server and the associated operating system. Run on the master server. example# ./NCVU -host_node master -conf media_server_clients sample_media_server Report on all NetBackup clients and the associated operating system. Run on the master server. example# ./NCVU -host_node master -conf all_clients Report on NetBackup media server and the associated operating system configuration. Run on the media server. example# ./NCVU -host_node media_server -if input_file_name Report on NetBackup media server and the associated operating system configuration, generate a debug file and not report any observations, only warnings. Run on the media server. example# ./NCVU -host_node media_server -if input_file_name -debug 9 -quiet Report on NetBackup media server and the associated operating system configuration designating the named output file for the report to go to. Run on the media server. example# ./NCVU -host_node media_server -if input_file_name -of report.out Report on NetBackup media server and the associated operating system system. Show no observations, only warnings. Run on the media server. example# ./NCVU -host_node media_server -if input_file_name -quiet Report on NetBackup client and the associated operating system configuration. Run on the client. example# ./NCVU -host_node client -if input_file_name Report on NetBackup client and the associated operating system configuration, generate a debug file and not report any observations, only warnings. Run on the client. example# ./NCVU -host_node client -if input_file_name -debug 9 -quiet Report on NetBackup client and the associated operating system configuration designating the named output file for the report to go to. Run on the client. example# ./NCVU -host_node client -if input_file_name -of report.out Report on NetBackup client and the associated operating system system. Show no observations, only warnings. Run on the client. example# ./NCVU -host_node client -if input_file_name -quiet FILES NCVU_master.out. default -conf master output file NCVU_media.out. default -conf output file NCVU_client.out. default -conf output file NCVU_master.debug default -conf master debug file NCVU_media.debug default -conf debug file NCVU_client.debug default -conf debug file .ncvu_media_server_config.input input configuration file for each media server .ncvu_media_server_config.output output file returned to the master server from each media server. Each file must be removed prior to rerunning the utility. .ncvu_client_config.input input configuration file for each client .ncvu_client_config.output 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. for a master server = 30-50K NCVU_media.out. 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. .input = 1.4-2K .output = 30-50K NCVU_client.out. for a client = 45K with @30K for each additional client. Each client generates a .input and a .output communication file. .input = @3K .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. 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 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. .output = @100K NCVU_client.debug for a client = @235K with @35K for each additional client. Each client generates a .output communication file. .output = @85K The minimum amount of free space required to run a single instance of NCVU for master, media servers and clients with debug level 9 enabled can be determined with the following formula: Using the above example for a site with three media servers and ten clients: NCVU_master.out. NCVU_master.debug NCVU_media.out. NCVU_media.debug number of additional media servers X 200K NCVU_client.out. NCVU_client.debug + number of clients X 120K ------------------------------------------- total space required Using the above example for a site with 3 media servers and 10 clients: NCVU_master.out. 30,000 NCVU_master.debug 275,000 NCVU_media.out. 75,000 NCVU_media.debug 275,000 number of additional media servers X 200K 400,000 NCVU_client.out. 45,000 NCVU_client.debug 235,000 number of additional clients X 120K 1,080,000 --------- total space required 2,415,000 Since each installation is different, the end user should formulate the typical sizes for the various NCVU files if free space is a concern. 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 in a reasonable amount of time. 7. Not removing the previous runs .ncvu_media_server_config.output or .ncvu_client_config.output output files from the master server's netbackup/bin/goodies/support (or linked location) directory. This will result in the utility "seeing" the old output files before the current runs output files return resulting in "old" information being included in the current runs report. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 9. LEGAL DISCLAIMER Copyright 2004 VERITAS Software Corporation. All Rights Reserved. VERITAS, VERITAS SOFTWARE, the VERITAS logo, Business Without Interruption, VERITAS The Data Availability Company, NetBackup, NetBackup DataCenter, NetBackup BusinesServer and VERITAS Storage Migrator for Unix are trademarks or registered trademarks of VERITAS Software Corporation in the US and/or other countries. Other product names mentioned herein may be trademarks or registered trademarks of their respective companies. Download Now - 13920 K File Name: NCVU_266158.tar File Type: Utility Click Below to Browse the FTP files by Product: ftp.support.veritas.com/pub/support/products ================================================================================ 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. drwx------ 2 root other 512 May 30 02:31 ./ drwxr-xr-x 10 root other 2048 May 30 02:31 ../ -rw------- 1 root other 10 May 30 02:01 last_time_expired_media -rw------- 1 root other 17 May 30 02:31 main_bpsched.lock -rw------- 1 root other 17 May 30 02:31 main_bpsched_busy.lock -rw------- 1 root other 17 May 30 11:02 reg_bpsched.lock 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 -d 0, but this can fail if any entries in any of the three VERITAS NetBackup databases are missing. 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 -d 0 -justmedia -force II. Volume database To check: vmquery -m To remove: vmquery -deassignbyid NOTE: can be found in the output of vmquery -m and is usually 0. III. Image database To check: bpimmedia -mediaid -U To remove: bpexpdate -ev -d 0 -justimage -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: BPDBJOBS_COLDEFS = COLDEFS_ENTRY [minimum_size [true | false]] where: "COLDEFS_ENTRY" is the name of the column to include in the output. See the table below for valid BPDBJOBS_COLDEFS entries. "minimum_size" is the minimum column width. If not specified, the default is a width of 5. "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. Sample entries in the bp.conf file: 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. BPDBJOBS_COLDEFS = JobID 5 true BPDBJOBS_COLDEFS = Type 4 true BPDBJOBS_COLDEFS = State 5 true BPDBJOBS_COLDEFS = Status 6 true BPDBJOBS_COLDEFS = Policy 6 true BPDBJOBS_COLDEFS = Schedule 8 true BPDBJOBS_COLDEFS = Client 6 true BPDBJOBS_COLDEFS = DstMedia_Server 12 true BPDBJOBS_COLDEFS = ActPID 10 true The default output will look like this: root@firefly:/> bpdbjobs JobID Type State Status Policy Schedule Client Dest Media Svr Active PID 1 Backup Done 0 test1 full firefly firefly 15965 A bp.conf file with the following entries: BPDBJOBS_COLDEFS = JobID 5 true BPDBJOBS_COLDEFS = Type 4 true will result in the output with only these two columns: root@firefly:/> bpdbjobs JobID Type 1 Backup Table of valid bp.conf entries: Note that these entries are case insensitive so "JobID" is the same as "JOBID." 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: 258949: In VERITAS NetBackup (tm) 4.5 Feature Pack 3, bpdbjobs -report does not display the Try or Attempt field. ================================================================================ Performance Tuning with NetBackup 1. Create the following folders in the path "%systemroot%\Program Files\Veritas\Netbackup\Logs" on the NetBackup servers as specified below: - On the Client server, create the folder: bpbkar - On the Media server, create the folder: bptm 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.771 [24475] <2> fill_buffer: [24469] socket is closed, waited for empty buffer 2 times, delayed 5975 times 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: 1. Add hosts file entries for all servers involved 2. Update the drivers for the NIC, on the client and media servers 3. Update the drivers for SCSI controllers, on the media server 4. Ensure all NICs and the Switch ports they are connected to are manually set to FULL or HALF duplex 5. Add the file: install_path\veritas\netbackup\NOSHM, on the Media server 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 Second step for the media server: [NORMALLY NOT RECOMMENDED] 1. Open windows explorer to install_path\veritas\netbackup\db\config 2. Create a file named SIZE_DATA_BUFFERS (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) BUFFER settings for Fibre-attached robot 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 a robot that is not working) as indicated by AVR state Reset the drive if the drive is OK. ================================================================================ Advanced reporter #To startup Netbackup Daemons /etc/rc2.d/S77netbackup /usr/openv/netbackup/bin/netbackup start /etc/init.d/nbar start To access NBAR 4.5 installed on a UNIX system, use the following URL from your web browser: http://.:8885/nbar.html To access NBAR 4.5 installed on a Windows system, use the following URL from your browser: http://.:80/nbar/nbar.html ================================================================================ 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://.:8885/nbar.html To access NBAR 4.5 installed on a Windows system, use the following URL from your browser: http://.:80/nbar/nbar.html ================================================================================ 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) Log into solaris master ksh export DISPLAY=x.x.x.x:0 /usr/dt/bin/netscape& http://localhost:8885/nbar.html ================================================================================ Add new drives (or create media server): Solaris edit lpfc or qlc files drvconfig AIX cfgmgr Load NBU s/w if not there alread (as a media server) edit sg.conf files sgscan add drives on media server: tpconfig create storage unit edit global to increase number of drives (master: bpadm) restart NBU on master do the same for each ms set blk variable to 0 set reserve to yes setup on master w/ storage unit restart master NBU processes ================================================================================ 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: On the master, go to the NetBackup administrative console: 1. Expand NetBackup Management | Host Properties. Highlight Master Servers. 2. In the right pane, double-click the master host name; this will bring up the master server properties. 3. Select the Client Attributes dialog box 4. Select New (UNIX) or Add (Windows). This will open a new client box; enter the client name the way it is configured in the policy. 5. Highlight the client you are configuring and check No connect-back (UNIX) or No call back (Windows) 6. Click OK 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. What ports need to be open on the firewall if filtering by destination port: Media >> Client 13782 (bpcd) Client >> Media 13724 (vnetd) 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) Master >> Client 13782 (bpcd) If using NetBackup enhanced authentication, you will also need to open: Master >> Client 13783 (vopied) 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' DOS shell - Run: gpupdate /force ================================================================================ SSO Tape cleaning must be handled on a host with SSO, or via the library. Automated cleaning cannot be done via SSO drives SSO and /etc/system If more than 16 tapes drives shared in SSO Add the following statements to the /etc/system file. # Increase the maximum number of messages that can be created set msgsys:msginfo_msgtql=512 # Increase message queue maximum number of bytes set msgsys:msginfo_msgmnb=65536 ================================================================================ Windows Restore of System State Normally you will get the inaccessible boot device if hardware or the drive configuration on a server has changed. In this type of situation you will run through the following steps when restoring. 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 ================================================================================ DOCUMENTATION: How to troubleshoot Microsoft Exchange database backup issues Details: Manual: NetBackup (tm) 4.5 for Microsoft Exchange Server System Administrator's Guide on Windows NT/2000 NetBackup 5.0 for Microsoft Exchange Server System Administrator's Guide for Windows NetBackup 5.1 for Microsoft Exchange Server System Administrator's Guide for Windows Page: N/A Modification Type: Addition. 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 \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. Exchange backups tend to exit with a limited number of status codes. In general, Exchange database backups will fail with status 1, 12, 13, 69, or 71. Status 1: * Check for a corrupt Exchange database. Go to the Microsoft Event Viewer, and look for a message "Failure reading file X." Then have the user contact Microsoft to assist in correcting the problem. * On an Exchange 2000/2003 server, check to see if the Recovery Storage Group is enabled. If it is, and the user has "Microsoft Information Store:\*" as the files list, the backup fails with a status 1 because it cannot back up the recovery storage group. Remove that storage group, or specify all the storage groups in the files list. Status 12: * Generally, a status 12 is associated with having a files list which reflects Exchange 5.5 directives, but the server is an Exchange 2000/2003 server. The files list for an Exchange 5.5 backup is Microsoft Exchange Server:\Information Store and Microsoft Exchange Server:\Directory. The files list for an Exchange 2000/2003 server is Microsoft Information Store:\* or Microsoft Information Store:\. Please note that for the files list Microsoft Information Store:\* to work correctly, Allow multiple data streams must be enabled. Status 13: * Check for a corrupt Exchange database. Go to the Microsoft Event Viewer, and look for a message "Failure reading file X." Then have the user contact Microsoft to assist in correcting the problem. Status 69 or Status 71: * 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:\. 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:\. 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/netbackup/bin/admincmd:/usr/openv/volmgr/bin:/usr/openv/volmgr/bin/goodies:/usr/openv/netbackup/bin/goodies:/usr/openv/nbar/bin:/opt/VRTSnbaro/bin print "...getting Veritas Netbackup\n" if [[ ! -d $CFIG_DIR/$NODE/VNBU/Files ]] then mkdir -p $CFIG_DIR/$NODE/VNBU/Files fi cd /usr/openv/netbackup;ls -l > $CFIG_DIR/$NODE/VNBU/$NODE.ls_l_usr_openv_netbackup #get performance files for DIR in /usr/openv/netbackup do cd $DIR for i in [A-Z]*[A-Z] do OUTFILE=`print $DIR | tr '/' '_' ` echo $i >> $CFIG_DIR/$NODE/VNBU/Files/$NODE.cat-files-in-$OUTFILE cat $i >> $CFIG_DIR/$NODE/VNBU/Files/$NODE.cat-files-in-$OUTFILE echo "" >> $CFIG_DIR/$NODE/VNBU/Files/$NODE.cat-files-in-$OUTFILE done done 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 " for FILE in $NBU_FILES do ################################## # change the / to _ for file name # /etc/fstab becomes: hostname._etc_fstab ################################## if [[ -f $FILE ]] then OUTFILE=`print $FILE | tr '/' '_' ` cp $FILE $CFIG_DIR/$NODE/VNBU/Files/$NODE.$OUTFILE fi done if [[ -n $(print $NBU_SERVERS | grep -w $NODE) ]] then print "...getting Veritas Netbackup server items\n" cd /usr/openv/volmgr;ls -l > $CFIG_DIR/$NODE/VNBU/$NODE.ls_l_usr_openv_volmgr #get performance files for DIR in /usr/openv/netbackup/db/config do cd $DIR for i in [A-Z]*[A-Z] do OUTFILE=`print $DIR | tr '/' '_' ` echo $i >> $CFIG_DIR/$NODE/VNBU/Files/$NODE.cat_files_in_$OUTFILE cat $i >> $CFIG_DIR/$NODE/VNBU/Files/$NODE.cat_files_in_$OUTFILE echo "" >> $CFIG_DIR/$NODE/VNBU/Files/$NODE.cat_files_in_$OUTFILE done done #support taken out because it can hang and eat up process time #support > $CFIG_DIR/$NODE/VNBU/$NODE.support.out netstat -ian > $CFIG_DIR/$NODE/VNBU/$NODE.netstat_ian ipcs -a > $CFIG_DIR/$NODE/VNBU/$NODE.ipcs_a df -k > $CFIG_DIR/$NODE/VNBU/$NODE.df_k env > $CFIG_DIR/$NODE/VNBU/$NODE.env # 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 bpdbjobs > $CFIG_DIR/$NODE/VNBU/$NODE.bpdbjobs bpdbjobs -report > $CFIG_DIR/$NODE/VNBU/$NODE.bpdbjobs_report bpconfig -U > $CFIG_DIR/$NODE/VNBU/$NODE.bpconfig -U #clients & classes bpplclients > $CFIG_DIR/$NODE/VNBU/$NODE.bpplclients bpclclients -allunique > $CFIG_DIR/$NODE/VNBU/$NODE.bpclclients_allunique bpcllist -U > $CFIG_DIR/$NODE/VNBU/$NODE.bpcllist_U bpclntcmd -pn > $CFIG_DIR/$NODE/VNBU/$NODE.bpclntcmd_pn bpclntcmd -self > $CFIG_DIR/$NODE/VNBU/$NODE.bpclntcmd_self bppllist > $CFIG_DIR/$NODE/VNBU/$NODE.bppllist bppllist -L > $CFIG_DIR/$NODE/VNBU/$NODE.bppllist_L bppllist -U -allpolicies > $CFIG_DIR/$NODE/VNBU/$NODE.bppllist_U_allpolicies bppllist -hwos > $CFIG_DIR/$NODE/VNBU/$NODE.bppllist_hwos for POLICY in $(bppllist) do bppllist $POLICY -U -L > $CFIG_DIR/$NODE/VNBU/$NODE.bppllist_${POLICY}_L_U done #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 bpimmedia > $CFIG_DIR/$NODE/VNBU/$NODE.bpimmedia bpimmedia -U > $CFIG_DIR/$NODE/VNBU/$NODE.bpimmedia_U bpimagelist -A > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_A bpimagelist -A -media > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_A_media bpimagelist -media > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_media bpimagelist -U -rl 0 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_0 bpimagelist -U -rl 1 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_1 bpimagelist -U -rl 2 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_2 bpimagelist -U -rl 3 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_3 bpimagelist -U -rl 4 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_4 bpimagelist -U -rl 5 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_5 bpimagelist -U -rl 6 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_6 bpimagelist -U -rl 7 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_7 bpimagelist -U -rl 8 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_8 bpimagelist -U -rl 9 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_9 bpimagelist -U -rl 10 > $CFIG_DIR/$NODE/VNBU/$NODE.bpimagelist_rl_10 #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 ltid -tables -f $CFIG_DIR/$NODE/VNBU/$NODE.ltid_tables_f tpconfig -l > $CFIG_DIR/$NODE/VNBU/$NODE.tpconfig_l tpconfig -d > $CFIG_DIR/$NODE/VNBU/$NODE.tpconfig_d tpconfig -dl > $CFIG_DIR/$NODE/VNBU/$NODE.tpconfig_dl tpconfig -data > $CFIG_DIR/$NODE/VNBU/$NODE.tpconfig_data vmadreq -display > $CFIG_DIR/$NODE/VNBU/$NODE.vmadreq_display tpautoconf -t > $CFIG_DIR/$NODE/VNBU/$NODE.tpautoconf_t tpautoconf -r > $CFIG_DIR/$NODE/VNBU/$NODE.tpautoconf_r bpgetconfig > $CFIG_DIR/$NODE/VNBU/$NODE.bpgetconfig scan > $CFIG_DIR/$NODE/VNBU/$NODE.scan if [[ -d /dev/sg ]] then sgscan conf -v > $CFIG_DIR/$NODE/VNBU/$NODE.sgscan_conf_v fi vmoprcmd -d > $CFIG_DIR/$NODE/VNBU/$NODE.vmoprcmd_d vmoprcmd -d ds > $CFIG_DIR/$NODE/VNBU/$NODE.vmoprcmd_d_ds vmpool -listall > $CFIG_DIR/$NODE/VNBU/$NODE.vmpool_listall vmpool -listall -b > $CFIG_DIR/$NODE/VNBU/$NODE.vmpool_listall_b vmglob -listall > $CFIG_DIR/$NODE/VNBU/$NODE.vmglob_listall vmglob -listall -b > $CFIG_DIR/$NODE/VNBU/$NODE.vmglob_listall_b vmglob -listall -java > $CFIG_DIR/$NODE/VNBU/$NODE.vmglob_listall_java vmquery -bx -a > $CFIG_DIR/$NODE/VNBU/$NODE.vmquery_bx_a # get a weeks worth of nbar report nbardbex -H -d , -S $NODE -hoursago 168 > \ $CFIG_DIR/$NODE/VNBU/$NODE.nbardbex_H_d_comma_S_$NODE_hoursago_168 fi ================================================================================ 1. Add the robot by executing the following command: tpconfig -add -robot 9 -robtype tld -cntlhost perch -vdbhost perch Ensure that the robot number matches the one on the control host. 2. If the robot contains drives that are currently configured as standalone, update the drive configuration to place them under robotic control. The following commands update the configuration for drives 1 and 2: tpconfig -update -drive 1 -type dlt -robot 9 -robtype tld -robdrnum 1 tpconfig -update -drive 2 -type dlt -robot 9 -robtype tld 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 Example 3: Configuring New Standalone Drives The following is an example of adding a standalone drive, after the drive is installed: tpconfig -add -drive -type dlt -name Tape0 -comment DEC DLT2000 8414 -index 6 -asciiname DLT2000_standalone tpconfig -add -robot 1 -robtype tld -cntlhost ictcvnb01 -vdbhost ictcvnb01 #list windows tape drives, match with master (vmglob -listall OR tpautoconf -t tpautoconf -t TPAC45 STK T9940B 1.30 1PGM000206 5 0 28 0 Tape28 - - TPAC45 STK T9940B 1.30 1PGM000207 5 0 28 1 Tape29 - - TPAC45 STK T9940B 1.30 1PGM000208 5 0 28 2 Tape30 - - TPAC45 STK T9940B 1.30 1PGM000209 5 0 28 3 Tape31 - - TPAC45 STK T9940B 1.30 1PGM00020A 5 0 28 4 Tape32 - - TPAC45 STK T9940B 1.30 1PGM00020B 5 0 28 5 Tape33 - - TPAC45 STK T9940B 1.30 1PGM00020C 5 0 28 6 Tape34 - - TPAC45 STK T9940B 1.30 1PGM00020D 5 0 28 7 Tape35 - - TPAC45 STK T9940B 1.30 1PGM00020E 5 0 28 8 Tape36 - - TPAC45 STK T9940B 1.30 1PGM00020F 5 0 28 9 Tape37 - - Index DriveName DeviceName Type Shared Status ***** ********* ********** **** ****** ****** 0 CDL1_Drive1 \\.\Tape28 hcart2 Yes UP TLD(1) Definition DRIVE=1 1 CDL1_Drive2 \\.\Tape29 hcart2 Yes UP TLD(1) Definition DRIVE=2 2 CDL1_Drive3 \\.\Tape30 hcart2 Yes UP TLD(1) Definition DRIVE=3 3 CDL1_Drive4 \\.\Tape31 hcart2 Yes UP TLD(1) Definition DRIVE=4 4 CDL1_Drive5 \\.\Tape32 hcart2 Yes UP TLD(1) Definition DRIVE=5 5 CDL1_Drive6 \\.\Tape33 hcart2 Yes UP TLD(1) Definition DRIVE=6 6 CDL1_Drive7 \\.\Tape34 hcart2 Yes UP TLD(1) Definition DRIVE=7 7 CDL1_Drive9 \\.\Tape35 hcart2 Yes UP TLD(1) Definition DRIVE=8 8 CDL1_Drive10 \\.\Tape37 hcart2 Yes UP TLD(1) Definition DRIVE=9 Currently defined robotics are: TLD(1) robot control host = ictcvnb01, volume database host = ictcvnb01 ================================================================================ tape copy to VTL #get quick list to see what is Full or Incr bpimagelist -hoursago 12 -U -client amrxm1111 | more #Get BPID from following bpimagelist -hoursago 12 -U -L -client amrxm1111 | more bpimagelist -hoursago 12 -client amrxm1111 | more # i.e. IMAGE amrxm1111 0 0 7 amrxm1111_1135853202 ACC_PROD_EXCH_AMRXM1111_SG4 16 *NULL* root Daily 0 0 1135857329 17920 1136462129 0 0 114367418 7 1 23 0 ACC_PROD_EXCH_AMRXM1111_SG4_1135857329_FULL.f *NULL* *NULL* 0 1 0 0 0 *NULL* 0 0 0 0 0 0 0 *N ULL* 0 0 0 *NULL* 253436 38 0 1336 0 0 #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 #set second copy to primary bpduplicate -npc 2 -backupid amrxm1111_1135853202 ================================================================================ 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. grep "Starting init process" /usr/openv/netbackup/logs/bpjobd/* ================================================================================ * bpimmedia -U -mediaid - will list images and fragments on a tape. Replace -U with -L * bpverify -p -sl -hoursago | awk '/^Media/ {print $4}' - gives which tapes were used for a schedule ago * vmquery -a - gives info on each tape * bpexpdate -ev -d 0 - expires a tape NOW (ver 3.2) * bpexpdate -m -d 07/24/2004 - expires a tape on a date, and changes all images on that tape (ver 4.5+) * bpexpdate -backupid -d 08/10/2005 - expires a certain backupid on * echo "s s" | tldtest -r /dev/sg/c3t0l0 - gives status of slots. ( s d - gives status of drives ) * vmpool -listall - gives pool number of all pools (-listscratch lists scratch pool) * vmchange -p -m - will move tape into scratch pool * /usr/openv/volmgr/bin/vmoprcmd - shows tape pending requests and mount info. You can kill pending requests with -deny * bpdbjobs - some nice options and status of jobs. Can kill with -kill or -kill_all * bpcllist -U -allclasses - Shows all class information * bpmedialist - gives info on media * bpmedialist -ev DBQ814 - for info on one tape * bpmedialist -summary - gives summary of media and expirys. Can use -p to give sumarry just for pool * bpmedia -unfreeze -ev DBQ844 - unfreeze a tape. Other options on bpmedia also * bpimport -create_db_info -id -L /tmp/bpimport1.ls - Recreats database info on tapes. Phase 1 * bpimport -l -L /tmp/bpimport.ls -client - imports phase2 for a client. * bpimagelist -A -media -d 04/17/01 15:53:00 -e 04/18/01 23:59:00 - gets tapes last written on date * bpimagelist -hoursago 14 | awk '$2==2 {print $9}' | sort | uniq - Very important. Gives tapes used for a second copy from an Inlinetapecopy ( multiple copies ). I use this for offsite * bpimagelist -media -client -d 04/10/2003 -e 04/11/2003 | awk '{print $1}' - same as above for a client. Can also add -class for a class * bpimagelist -l -hoursago $hoursago | grep IMAGE | awk '{ tot+=$19} END { printf "Data backed up in the last '$hoursago' hours: %9.0f MB\n",tot/1024 }' - List amount of data backed up in $hoursago specified as variable in a script. E.g 24, 48 * vmquery -pn scratch | grep "media ID" - lists all media in scratch pool * bperror -media -d -U - gives media errors * bplabel -ev CZJ241 -d dlt -o -p scratch - Can label a tape which had netbackup db info on. -d is tape density -o overwrites. -p may not be needed and is pool * /usr/openv/netbackup/db/altnames/No? .Restrictions - Is what to enable to let clients restore to each other * bpimmedia -client | awk '$1=="IMAGE" {print $4}' - Lists backup ids for a client. -L Gives more info * bpimage -oldserver -newserver - Look at to convert images from oldserver to newserver on netbackup server. * bpclclients -allunique - Lists all clients netbackup knows about * bprecover -r -dptah /path/to/saved/nbu/databases - Recovers netbackup databases from files into your current setup. May need to remove database directory contents first. -l instead of -r will list * bpplinfo -modify -inactive - Will change a policy to inactive * bpduplicate -dp -dstunit -hoursago n -sl -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 -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 = 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 -cl -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 -X -s -e -cn 2 -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 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 -k -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 -D -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. VERITAS recommends adding the following forceload statements to the /etc/system file. These statements prevent the st and sg drivers from being unloaded from memory. forceload: drv/st forceload: drv/sg 1. Determine if an sg driver is loaded by using the following command: /usr/sbin/modinfo | grep sg Version 5.0 * /usr/openv/netbackup/bin/update_clients Where is one of the following: 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 Can use -ClientList? /tmp/clients but /tmp/clients must be in form Solaris Solaris8 update_clients called on its own attempts to update all clients. Vnet Daemon Set up To use vnet need to do the following make sure its uncommented in /etc/inetd.conf on server and client make sure 13724 is the port in /etc/services Need to run /usr/openv/netbackup/bin/admincmd/bpclient -client -add /usr/openv/netbackup/bin/admincmd/bpclient -client -update -no_callback 1 Check in /usr/openv/netbackup/db/client//host_info option below is set. 'No call-back connections: yes' Useful URLS * http://www.NetBackupcentral.com * http://sourceforge.net/projects/nbux ================================================================================