Fbackup hanging/looping

[Matt Livingston]

This is odd!

fbackup suddenly stopped working two nights ago.

Platform: d380/2
OS: HPUX 10.20
Tape: HP DLT7000
Media : DLT III

Historically, our backup has been taking 6 hrs 15 min to back up 21 GB, but last night and the night before, it was still running after 8 hours and had not written any files to tape. Nothing has been logged to
/var/adm/syslog/syslog.log or
/var/adm/messages

I tested the tape by tarring /etc to it, and the media and drive are both OK.

Suspecting possible filesystem problems, I ran "find / -print > /dev/null" expecting to see something on STDERR... nothing. (On this box, I do not have the liberty of casually unmounting and fsck'ing the FS's)

I then tried:
"fbackup -f /dev/rmt/3m -v -i /dev/rmt/3m"
fbackup was still running after 5 minutes and no files written to tape.

I tried the same thing again, except backing up only /stand/vmunix, and got exactly the same results.

top consistently reports fbackup using very high cpu (up to 95%), and cpu time equal to elapsed runtime. This can't be normal.

Here's what ps reports while fbackup is trying /stand/vmunix:

# ps -ef | grep back
root 24191 24190 0 10:00:13 ? 0:00 /usr/sbin/fbackuprdr 660609 0 262144 C 0 0
root 26158 19642 1 10:31:17 -c 0:00 grep back
root 24192 24190 0 10:00:13 ? 0:00 /usr/sbin/fbackuprdr 660609 1 262144 C 0 0
root 24193 24190 0 10:00:13 ? 0:00 /usr/sbin/fbackupwrtr 660609 262144 4 C 0 0 /dev/rmt/3m
root 24190 24189 254 10:00:13 ? 25:47 /usr/sbin/fbackup -f /dev/rmt/3m -v -i /stand/vmunix

Coincidentally, (or perhaps not?) the problem first manifested one year to the day after the last reboot.

[David Allen]

Hi Matt,

Is the tape unit a stand alone unit? If so, I have experienced something similar to this on a DLT4000 stand alone unit. After a scheduled outage at a customers site, the onsite support had powered on the Unix Server and peripherals, except the tape unit. The onsite support realised the mistake and powered on the tape unit after the server had booted. The next overnight backup (using fbackup) failed.

I tried running frecover commands to get an index and a header from the tape, but with no luck. I then tried backing up a small filesystem using fbackup, which failed. Then tried tar, which worked. From memory I think ioscan reported the tape unit as being ok.

The end result was (after I had found out how the server was restarted) to shutdown and power off the server and peripherals and then get the onsite support to power everything back on (server last). Not always a great way to fix a problem, but it worked.

It is probably a long shot, but maybe someone has power cycled your tape unit by mistake?! I can't remember if we experienced the same problems with fbackup hanging or if it simply failed with an error.

Regards,
Dave

[Animesh Chakraborty]

Hi,
Is it due to too many retries that fbackup does ?Have you tried with new tape?

fbackup was designed to allow backups while the system is in use by providing the capability to retry an active file. When absolute consistency on a full backup is important, the system should probably
be in single-user mode. However, incremental backups can be made while the system is in normal use, thus improving system up-time.
Thanks
Animesh

[Frank Slootweg · Accepted solution]

Probably a known problem. Make sure that you have installed fbackup/frecover patch PHCO_9228 or later, currently PHCO_23861, especially if you recently added or changed user or group names.

Please let us know which fbackup/frecover patch you had, if any.

[Matt Livingston]

Thanks Frank, that was it.

There had been some users added with userid's > 8 characters, causing that particular bug to manifest.