On the master server do the following to find the Netbackup daemons that are running
# /usr/openv/netbackup/bin/bpps -a
Usually the daemons for which one should be looking on the Master server are bprd, bpdbm and vmd. The Netbackup request daemon "bprd" starts the schedulerdaemon bpsched if backups are initiated on the master server.
To kill all the daemons run the following script on the Master server
# /usr/openv/netbackup/bin/goodies/bp.kill_all
To restart the Netbackup daemons run the following script on the
# /etc/rc.veritas.aix
Active Jobs
To find all the jobs that are completed or active or incomplete jobs do the following on the Master server
# /usr/openv/netbackup/bin/admincmd/bpdbjobs -report -header -M
The output will be like this:
Job ID Job Type Job State Job Status Class Schedule Client Media Server
11453 Backup Done 0 ecfs04_Friday ecfs04_Fri_Dly ecfs04 ecfs0411454 Backup Done 0 ecfs05_Friday ecfs05_Fri_Dly ecfs05 ecfs0511455 Backup Done 0 ecfs04_Friday ecfs04_Fri_Dly ecfs04 ecfs0411456 Backup Done 0 ecfs06_Friday ecfs06_Fri_Dly ecfs06 ecfs06
· To find the active jobs (i.e backups that are currently running) do the following
# /usr/openv/netbackup/bin/admincmd/bpdbjobs -report -header -M
For example if we want to find active jobs that are running on the master server "ecbs01"
# /usr/openv/netbackup/bin/admincmd/bpdbjobs -report -header -M ecbs01 grep Active
To kill a particular active job
# /usr/openv/netbackup/bin/admincmd/bpdbjobs -kill
To kill all active jobs
# /usr/openv/netbackup/bin/admincmd/bpdbjobs -kill_all -M
To delete an already completed job
# /usr/openv/netbackup/bin/admincmd/bpdbjobs -delete
Like this there are many options. If you do a "bpdbjobs -h" you can find all the options.
Status of Backup jobs
To find the status of all the backups that are done in the last 24 hours do the following :
# /usr/openv/netbackup/bin/admincmd/bperror -server
OR
you can run the script /usr/openv/netbackup/scripts/get_status on the master server
If the "STATUS" is 0 it means a successful backup was done. For the meaning of each status code go to the status code section. For the details of the various options do a man on bperror
DRIVES
We can find drive status by using either vmoprcmd or tpconfig commands. Below both the commands are discussed.
Using vmoprcmd
vmoprcmd performs opeartor functions on drives.
To find the status of drives.
# /usr/openv/volmgr/bin/vmoprcmd -d ds.
The above command is fine if you run the command on the media server for which you want to find the drive status. If you are running the command from master server then do the following
# /usr/openv/volmgr/bin/vmoprcmd -h
For example if you want to find status of the drives attached to media server ecfs09 then do the following on the master server: # /usr/openv/volmgr/bin/vmoprcmd -h ecfs09 -d ds.
To change the drive status from DOWN to UP or viceversa
If we executed vmoprcmd on ecfs09 as
# /usr/openv/volmgr/bin/vmoprcmd -d ds The output will be like shown below
Drv Type Control User Label RVSN EVSN Ready Wr.Enbl. ReqId8 dlt TLD - No - - 9 dlt TLD - No - - 10 dlt TLD - No - - 11 dlt TLD - No - - 12 dlt TLD - No - - 13 dlt TLD - No - -
If a particular drive is DOWN it will be shown in Control column. Let's say drive with drive index 8 is DOWN, then in the Control column it will be like DOWN-TLD instead of TLD. So if you want to change the status from DOWN to UP of the drive with drive index 8 then do the following:
# /usr/openv/volmgr/vmoprcmd -up
To find any pending requests do
# /usr/openv/volmgr/bin/vmoprcmd -d pr (on the media server)
/usr/openv/volmgr/bin/vmoprcmd -h
If you want other options do vmoprcmd -h
Using tpconfig
To find the status of the drives and also the robotic host on a media server ( note that here two media servers are sharing one ATL) do the following:
Log on to the media server for which you want to find the drive status and execute the following command
# /usr/openv/volmgr/bin/tpconfig -d
The above command gives the status of the drives (whether they are up or down), the drive device path, drive index, robot number, robot host.
For example let's take ecfs09 and ecfs10 which are media servers. Both these machines are sharing one ATL. Here ecfs10 is having the control of the robot (so it is the robotic host ). If you execute the tpconfig -d command on ecfs10 the output will be like this:
ECFS10! / -> /usr/openv/volmgr/bin/tpconfig -dIndex DriveName DrivePath Type Multihost Status0 ecfs10-drive0 /dev/rmt1.1 dlt No UP TLD(2) Definition DRIVE=1 1 ecfs10-drive1 /dev/rmt2.1 dlt No UP TLD(2) Definition DRIVE=2 2 ecfs10-drive2 /dev/rmt3.1 dlt No UP TLD(2) Definition DRIVE=3 3 ecfs10-drive3 /dev/rmt4.1 dlt No UP TLD(2) Definition DRIVE=4 4 ecfs10-drive4 /dev/rmt5.1 dlt No UP TLD(2) Definition DRIVE=5 5 ecfs10-drive5 /dev/rmt6.1 dlt No UP TLD(2) Definition DRIVE=6 6 ecfs10-drive6 /dev/rmt7.1 dlt No UP TLD(2) Definition DRIVE=7 7 ecfs10-drive7 /dev/rmt8.1 dlt No UP TLD(2) Definition DRIVE=8 Currently defined robotics are:TLD(2) robotic path = /dev/ovpass0, volume database host = ecbs01
Note: In the above statement TLD(2) is the robot number with respect to the master server ecbs01. Since ecfs10 is the robotic host it gives the path for robotic device.
Now if you run the tpconfig -d on ecfs09 the output will be like this
ECFS09! / -> /usr/openv/volmgr/bin/tpconfig -dIndex DriveName DrivePath Type Multihost Status8 ecfs09-drive8 /dev/rmt1.1 dlt No UP TLD(2) Definition DRIVE=9 9 ecfs09-drive9 /dev/rmt2.1 dlt No UP TLD(2) Definition DRIVE=10 10 ecfs09-drive10 /dev/rmt3.1 dlt No UP TLD(2) Definition DRIVE=11 11 ecfs09-drive11 /dev/rmt4.1 dlt No UP TLD(2) Definition DRIVE=12 12 ecfs09-drive12 /dev/rmt5.1 dlt No UP TLD(2) Definition DRIVE=13 13 ecfs09-drive13 /dev/rmt6.1 dlt No UP TLD(2) Definition DRIVE=14 Currently defined robotics are:TLD(2) robot host = ecfs10, volume database host = ecbs01
Note: In the above since ecfs10 is having robot control, it shows that robot host is ecfs10 ( and doesn't give any device path to robotic device). The volume database host is the master server for all the media severs. Here volume datbase host means the host that contains the tape database.
How to Change a Master Server
Developed for Chandler Site April, 2001
Transition Details:
Need to remove chbkup01, Solaris 2.6 on Sun E220R, as the Master server, and add chmstr1, AIX 4.3.3 on H80 with EMC disk array, as the New Master server.
Need to then rename chbkup01 to chmed01, as per new naming policies, and keep it as a media server.
The new Master server will not have any media attached. The new Media (old master) will keep its media.
NOTE: The following processes should be interpreted as a guide, not necessarily a step-by-step process.
Steps for transition:
Before beginning, have a list of all media servers and clients to transition!
Stop all backups
Kill bprd on current mastera. bpps -ab. Kill
Manually backup NetBackup database
Run /usr/openv/netbackup/bin/.xvmadm and print volume detail report
Save a copy of bp.conf from current master
Run /usr/openv/netbackup/bin/admincmd/bpsyncinfo -L and printout/save for new master server
Move all tapes associated with current master server to non-robotica. Highlight all volumes and select: action - move - if "vol is in robotic Lib" is unselected then click OK
Kill all NetBackup daemons on the Old Master servera. bp.kill_allb. Edit startup files to make sure the master server daemons do not startup on reboot
Install NetBackup on the New Master server
Copy (tar) files from these directories over to new master server:a. /usr/openv/netbackup/dbb. …/netbackup/db/mediac. …/volmgr/database
Move/Update bp.conf on new Master server (don't forget to change first line indicating new Master server, and remove any media references)a. Add new media server
Update all Media server bp.conf files to indicate new Master server
Update all clients (bp.conf)
Rename old master to new Media server name (make appropriate NIS changes)
Update the media images to reflect new media server (name changed)a. On master run: bpimage -newserver
Rename all "db" areas previously copied over from old master (see step 10 above) - suggest copying all to .old extensionsa. Definitely keep structure!
Restart daemons on all Media servers and New Master server
Configure new media server with new robot number
All existing media servers need to reflect the new master server as the VolMgr Hosta. Media & Device mgmtb. Highlight devicec. Actiond. Changee. Vol Database Host to New Master server
Re-inventory robot on new media server
Test backups and troubleshoot as necessary
No comments:
Post a Comment