/usr/openv 100% 1

[rdapilmoto]

Netbackup Gurus!

Aside from cycling the Netbackup processes, what else can be done if the /usr/openv directory starts filling up close to 100%? This has happened to us in the past and has caused NB to come to a halt! We've recently added 30 extra gig to our Unix Master Server (Solaris 8, SUN 280R)

Any help is appreciated!

 

[Stumpr]

Document ID: 254377

http://support.veritas.com/docs/254377

E-Mail this document to a colleague
How to relocate or change the location of the VERITAS NetBackup (tm) catalog
--------------------------------------------------------------------------------
Details:
There are only two supported methods of relocating or changing the location of the NetBackup catalog files. The first method involves the use of ALTPATH files. It is the preferred method and is described in detail in the NetBackup DataCenter System Administrator's Guide on pages 180-182 (link in the Related Documents section below).

If for some reason, the NetBackup catalog needs to be relocated, but the method in the Administrator's Guide is not desirable, there is one other supported method.


Manually back up the NetBackup catalogs. This is to ensure that the catalogs can be restored via a bprecover command in event of a problem.
Ensure that there are no active backups or restores in progress. If there are, wait for them to finish or cancel them manually.
Shut down all NetBackup services either through the activity monitor or from the command line
Copy the directory %install_path%\Veritas\NetBackup\db to a temporary location
Copy the directory %install_path%\Veritas\NetBackup\var to a temporary location
Copy the directory %install_path%\Veritas\Volmgr\database to a temporary location
Uninstall NetBackup
Reboot
Install NetBackup in the new location where you wish the catalog to be located i.e. D:\Veritas\NetBackup
After the install finishes, do not start the services
Copy the old catalog information from the temporary location to the appropriate new install path, i.e. D:\Veritas\NetBackup\db

Once all catalog directories have been copied, start the services and all job, images, and media information should be intact. The catalogs will now write to the desired location. Do not forget to patch the NetBackup server to its previous patch level.


Related Documents:

246843: NetBackup DataCenter 4.5 System Administrator's Guide for Windows

http://support.veritas.com/docs/246843

Another idea.
Turn off verbose logging and remove any directory/logfiles under ...netbackup\logs\

Bob Stump
Incorrigible punster -- Do not incorrige

 

[Stumpr]

What to do when the VERITAS NetBackup Image Catalog becomes too large and there is insufficient diskspace
--------------------------------------------------------------------------------
Details:
There are two ways to manage this situation:

1. Compressing the Image Catalog
2. Moving the Image Catalog

see technote:

http://seer.support.veritas.com/docs/238066.htm

Bob Stump
Incorrigible punster -- Do not incorrige

 

[rynardo]

delete your logs or reduce verbosity

 

[Vela]

we've had problems with this recently. My problem is that we run 24-7 and there's no window for the process
CLEAN_IN_BACKGROUND to run- The last we manually ran clean_in_background it reduced the catlaog by 50% of 320GIG

Clean in background get rids of old expired images- this will run automatically if there is a short window of inactivity-Just remember that if your retention isn't set right for some backups you could lose the data forever

Compressing the catalog is a good idea and one we will be doing soon-

 

[creakyjoe]

Without moving stuff out of /var, there is a helluva lot of space to be gained from 1) keeping logging to a minumum and 2) compressing logfiles. I have various houskeeping in place (have done for many years so know it works). This is h/keeping for master server -

30 16 * * * find /usr/openv/netbackup/logs/*/log* -mtime +14 -exec rm {} \; > /dev/null 2>&1
30 16 * * * find /usr/openv/netbackup/logs/*/obk* -mtime +14 -exec rm {} \; > /dev/null 2>&1
40 16 * * * find /usr/openv/netbackup/logs/*/log* -mtime +7 -exec gzip {} \; > /dev/null 2>&1
40 16 * * * find /usr/openv/netbackup/logs/*/obk* -mtime +7 -exec gzip {} \; > /dev/null 2>&1
50 16 * * * find /usr/openv/netbackup/logs/bpdbm/log* -mtime +2 -exec gzip {} \; > /dev/null 2>&1
50 16 * * * find /usr/openv/netbackup/logs/bpbkar/log* -mtime +2 -exec gzip {} \; > /dev/null 2>&1
50 16 * * * find /usr/openv/netbackup/logs/bpsched/log* -mtime +2 -exec gzip {} \; > /dev/null 2>&1
50 16 * * * find /usr/openv/netbackup/logs/bprd/log* -mtime +2 -exec gzip {} \; > /dev/null 2>&1
50 16 * * * find /usr/openv/netbackup/logs/bpbrm/log* -mtime +2 -exec gzip {} \; > /dev/null 2>&1
50 16 * * * find /usr/openv/netbackup/logs/bpcd/log* -mtime +2 -exec gzip {} \; > /dev/null 2>&1


I have similar scaled down h/keeping on all clients. Plus it's important that you only create logfile folders that you actually need, regardless of logging verbosity level.

Log directories on Master -

admin
bpbackup
bpbkar
bpbrm
bpcd
bpdbm
bphdb
bpjava-msvc
bpjava-usvc
bplist
bprd
bprestore
bpsched
bptm
daemon
dbclient
reqlib
tar
user_ops

Log directories on a given client -

bpbkar
bpcd
bphdb
dbclient
tar
user_ops


(we only backup RMAN stuff and flatfile stuff so logging directories should be fairly minimal)

Works v well

Rich