fbackup: how is end of successful execution signaled?

[Ralph Grothe]

Hi,

I haven't used the HP-UX utilities fbackup/frestore yet (at least not conciously), so forgive my silly question.

Just to give it a try I had stated this command line through batch to do some backup on a DLT tape:

/usr/sbin/fbackup -f /dev/rmt/1m -i /oracle -i /sapmnt/B09 -i /usr/sap/B09 -0 -v -I /ROOT/fbackup_20021125.idx 2>&1 | tee /ROOT/fbackup_20021125.out


When I have a look in the process table right now I can still see a lingering fbackup process (with some spawned children):


# ps -ef|grep fback|grep -v grep
root 1549 1548 0 17:52:47 ? 0:06 /usr/sbin/fbackup -f /dev/rmt/1m
-i /oracle -i /sapmnt/B09 -
root 1553 1549 0 17:52:47 ? 0:00 /usr/sbin/fbackupwrtr 32773 2621
44 4 C 0 0 /dev/rmt/1m
root 1552 1549 0 17:52:47 ? 0:00 /usr/sbin/fbackuprdr 32773 1 262
144 C 0 0
root 1550 1548 0 17:52:47 ? 0:00 tee /ROOT/fbackup_20021125.out
root 1551 1549 0 17:52:47 ? 0:00 /usr/sbin/fbackuprdr 32773 0 262
144 C 0 0

The mtime stamps and the tails of the index file and my dumped output are such:

# ll /ROOT/fbackup_20021125.*
-rw------- 1 root sys 4127752 Nov 25 22:13 /ROOT/fbackup_20021125
.idx
-rw-r--r-- 1 root sys 3333105 Nov 25 22:13 /ROOT/fbackup_20021125
.out

# tail -5 /ROOT/fbackup_20021125.out
51166: /usr/sap/B09/lost+found 1
fbackup(1005): run time: 15221 seconds
fbackup(3055): total file blocks read for backup: 77885912
fbackup(3056): total blocks written to output file /dev/rmt/1m: 78132948
fbackup(1030): warnings encountered during backup
# tail -5 /ROOT/fbackup_20021125.idx
96 0 /usr/sap/B09/SYS/gen/opt
18 0 /usr/sap/B09/SYS/global
19 0 /usr/sap/B09/SYS/profile
96 0 /usr/sap/B09/SYS/src
96 0 /usr/sap/B09/lost+found


My question is, how can I be sure that the fbackup has completed successfully since the job is still in the process table?
I found no clues for additional files to look for in the manpage of fbackup.

Regards
Ralph

[Chuck J]

You could do an frestore as a test to see if the file backed up ok.

Chuck J

[BFA6]

Hi,

You could check the return code from the fbackup command.

Regards,

Hilary

[Robert Thorneycroft]

The fbackup processes will all terminate after the backup has completed. It sometimes seems to take a long time after the last file as the DLT can take a while to rewind in the tape drive.
I would definitely avoid the temptation to kill off any processes as you could potentially end up with an incomplete backup, which on an SAP system will probably result in an unrecoverable system.

You should also find something similar to the following at the bottom of your log:
fbackup(1005): run time: 25588 seconds
fbackup(3055): total file blocks read for backup: 335544414
fbackup(3056): total blocks written to output file /dev/rmt/tape2: 335549781


Kind regards,

Robert Thorneycroft

[Ralph Grothe]

Robert,

the totals were already sent to stdout from fbackup, that was the tail of my log (repeated here again):

# tail -5 /ROOT/fbackup_20021125.out
51166: /usr/sap/B09/lost+found 1
fbackup(1005): run time: 15221 seconds
fbackup(3055): total file blocks read for backup: 77885912
fbackup(3056): total blocks written to output file /dev/rmt/1m: 78132948
fbackup(1030): warnings encountered during backup


I definetly wouldn't want to send a SIGTERM or even SIGKILL to the process because I also fear (as you said) to such render my backup useless.

Unfortunately I cannot see what the tape drive is doing (e.g. rewinding) since the machine is at a located at a far away place.

Do you think that fbackup would prompt to stdout for change of media in case if the backup didn't fit on a single tape?
Would it continue the backup upon insertion of the follow on tape?

[Chris Wilshaw]

With reference to Hilarys' comment about the exit code.

The "normal" exit codes from a successful backup are 0 and 4 (4 signifies that non-critical warnings were encountered - files open durring backup, temporary files deleted and such like).

A detailed list of fbackup errors (including the details shown in brackets from the fbackup output - eg fbackup(1005))

can be found using

dumpmsg /usr/lib/nls/C/fbackup.cat | more

[Chris Wilshaw · Accepted solution]

As far as the second tape issue goes, the message is written to standard error (nothing will display into the logs unless you've got this redirected).

Sadly it won't auto-continue when the new tape is put in - a confirmation is required from the user before it checks the new tape (to verify that it is indeed a new tape, and not just the previous one again).

[Ralph Grothe]

Chris,

though it doesn't help me now, your hint with regard to the commands dumpmsg, findmsg, gencat is very valuable to me (I havn't come accross these before).
When I actually do a dumpmsg on the catalog file of fbackup I can see exactly the same messages that were written to stdout, respectively my log file.

[Ralph Grothe]

Steve,

thanks for the recipe with the named pipe to do the IPC to the fbackup proc in case of required interaction.
But this is for my current purpose far too much fuss.
If I wanted to invest more in a clever fbackup solution I would have read the fbackup manpage more carefully, or more probably, have written my own Perl based backup solution (where I could do IPC through fifos, signals, semaphores, unix sockets or even inet sockets ad lib ;-)
We do have a sophisticated regular backup scheme with TSM and OmniBack.
It was more or less just a test to have a look at fbackup.