fbackup log

[Ricky_2]

Hi, I use fbackup -vf /dev/rmt/0mn -i / for my system backup. The standard out and standard error are redirected to a log file. What affirmative message should my operator look out for to be sure of a successful backup.
Thanks.

[harry d brown jr]

Ricky,

You should never have an operator scanning logs for success or failure messages. You need to put that ERROR checking into your scripts and send EMAIL's, PAGES, and even VOICE MAIL's, when a process fails.

That's my story, and I'm sticking to it :-))


live free or die
harry

[S.K. Chan]

Typically you'll see something like ..

fbackup(3024): writing volume 1 to the output file test
1: check-abars.10072 1
fbackup(1005): run time: 4 seconds
fbackup(3055): total file blocks read for backup: 1
fbackup(3056): total blocks written to output file test: 16

The above is just 1 file backup to a file "test". As you can see you can't really conclude in a single line if the backup is successful or not. The whole file should be scanned and look for "errors", looking the nd of the log file is not sufficient.

[Michael Tully]

The best way to have the results of backups is to make sure that you email the results to yourself of the outcome. Having operators is great in the middle of the night, by having coloured notifications through SNMP traps, but there is no substitute for seeing the results yourself.

[S.K. Chan]

..sorry my typo SUCKS ... "looking at the end of the log file is not sufficient".

[James R. Ferguson]

Hi Ricky:

I look at a couple of indicators.

First, the return code from 'fbackup' has value. 'fbackup' returns <0> if successful; <1> if interrupted (but restartable); <2> if errors occured; and <4> if warnings have been issued.

The most common reason for a return code of <4> is the normal copy-retry action for a file that has changed since the time its transfer to tape started. Remember that the number of retries is controlled by 'maxretries' (see 'man fbackup'). Another common reason for a return codeof <4> is the inability to 'stat' a file. This occurs when a file is removed from the system sometime between the time 'fbackup' queries the filesystems and when it actually begins to transfer the file to tape.

Another useful "marker" for a successful/unsuccessful backup is to run 'fbackup' with the '-V ' option to collect the volume header information. The presence or absence of the volume_header_information file at the end of the 'fbackup' session serves to signify success or failure.

Regards!

...JRF...

[Michael Tully]

The following command will allow you to see all 'fbackup' numbered messages.

# strings /usr/lib/nls/C/fbackup.cat

~Michael~