new fbackup error ....

[Thi Vu]

Sorry, I hit ENTER too quickly.
Hi everyone,

Again I need your assistant with the fbackup I'm testing. I've tested fbackup on 3 systems at different time over the course of the week. Sys1 - OK but have anyone ever encounter this kind of problem that I have with my other Sys2 and Sys3 my /usr file system is 100%. I was there in front of the screen for the entire time when I tested fbackup and there was no error/complain (except for "volume header"). Since I'm the only one on that 3 systems over the course of 1 week when /usr become 100% is there any document anywhere I can read to find out the cause of this (whether it's from fbackup or not). I have to prove or disprove that it's from fbackup. It's killing me that I did not think of having this in a log file (except for the "date" and the "index" files) to go over to see if there is any error message that I might have miss.

Again thank you for any help.
Thi

[Thierry Poels_1]

hi,

fbackup itself should not fill up any disks. If any filesystem get filled up during fbackup you are probably redirecting output to a log file, or worse, putting your entire backup on disk instead of on tape (or whatever).

Showing your fbackup instruction would help us to help you :)

good luck,
Thierry.

[Thi Vu]

BKUPDIR=/var/adm/fbackupfiles
BKUPLOG=/reports/logfiles/backups

GRAPHFL=$BKUPDIR/NWTNbkup
LOGFILE=$BKUPLOG/bkuplog.$dat
INDEXFL=$BKUPLOG/indexfile.$dat

fbackup -n -f $tape -c $CONFIGFL -u0g $GRAPHFL -d $LOGFILE -I $INDEXFL


where $CONFIGFL is:

blocksperrecord 128
records 32
checkpointfreq 256
readerprocesses 4
maxretries 1
retrylimit 0
maxvoluses 500

Thanks

[Philip Chan_1]

Take a look at what files were being opened while fbackup runs by using either

glance /* zoom into process open files screen */
lsof /* lsof -p */

Check sizes of each open files.

~Philip