Full Backup problem

[karen_poon]

Could anyone assist me in analyzing the following error found in /var/adm/log/br_log when I scheduled a full system backup. Thanks.

Full backup started on cnms : Sat Sep 30 16:00:00 SST 2000 (Scheduled Backup)
{ fbackup -0 -u -g /etc/sam/br/graphPCAa04397 -I /var/sam/log/br_index.full -
c /etc/sam/br/fbackup_config -d /var/adm/fbackupfiles/dates -f /dev/rmt/0m } 2>&
1
Full backup failed on cnms : Sat Sep 30 16:44:17 SST 2000 .
Exit code = 4

[John Palmer]

An exit status of 4 from fbackup means that there have been warnings issued. This is almost bound to happen as certain OS files will be in use when fbackup tries to copy them to tape.

Try adding the -v (verbose) flag to fbackup so that you can see what the errors were.

They are probably log files that you need not worry about.

[Alex Glennie · Accepted solution]

The issue with fbackup failures is that the new exit code of '4' is not
correctly recognized by SAM as a completion code. Fbackup introduced the exit
code of 4 with HP-UX release 11.0. This exit code was also introduced at 10.20
via an fbackup patch of PHCO_18135.
According to the man fbackup(1M) page, the four valid exit codes are:


RETURN VALUE
------------

fbackup returns one of the following values:

0 upon normal completion.
1 if it is interrupted but allowed to save its state for possible restart.
2 if any error conditions prevent the session from completing.
4 if any warning conditions are encountered.

If warnings occur, the operator should verify the fbackup logs to justify the
sanity of the backup taken.



With an exit code of 4, the backup completes but the fbackup logs should be
checked for errors.

This issue will be corrected in the next HP-UX 11.0 SAM patch due to be released
around 02/00. A workaround is also available at this time. It requires editing
the /usr/sam/lbin/br_backup script to recognize exit code 4 correctly. The
steps to edit this script are:


1. cd /usr/sam/lbin
2. cp br_backup br_backup.bak
3. vi br_backup
4. :se_nu *** This allows you to see the line numbers. ***
5. Move down to line #329
6. Edit the code from:

329 if [ "$exit_code" = "0" ]

to:

329 if [ "$exit_code" = "0" -o "$exit_code" = "4" ]

7. :qw!

Then try the backup again and see if it completes.


HOW TO VERIFY THE BACKUP IS COMPLETE:
------------------------------------

To verify that the backup was successful, either create an index of the tape
with the frecover command:


frecover -Nrosv -f /dev/rmt/0m > /tmp/index 2>&1

This command reads the whole tape and creates alist of all the files
successfully backed up on the tape using device file /dev/rmt/0m, creating the
list in the file called 'index' in the /tmp directory.

Or, you can use the -vN options with the frecover command. The '-v' option is
verbose mode, so it prints everything to the screen. '-N' prevents frecover
from recovering any files to disk. It simply goes through the motions as if it
is. The command is:

frecover -vN /dev/rmt/0m

The most common cause of an exit code of 4 is the use of a new tape or a tape
that does not contain an fbackup header from a previous backup. When fbackup
begins on a new tape, it recognizes this and gives a warning as it generates the
proper tape headers. In this case, the exit code 4 can generally be assumed to
be a success.

[James R. Ferguson]

Hi:

This is indeed an annoying problem.

The way I prefer to circumvent this is to setup my own script for fbackup (rather than using SAM). The script runs fbackup using the verbose (-v) mode to generate status messages. Messages from fbackup (one for each file backed up) are redirected into a log file. At the end of the backup, the script does a grep on the log, mailing the grep results to root for quick examination. This grep is as follows:

# grep -e "WARNING:" -e "was active" -e "was not" -e "unable to stat" > $WARNINGS

...JRF...