fbackup output --- can it be trusted?

[Charles Holland]

Greeting gurus,

Platform: rp7410 running 11.11 with Vpar software

As an interum, keep this one on site backup, we were using fbackup to read the mount points on Vpar2 and back it up on Vpar1. Vpar1 is the one that has the tape drive. We are utilizing a 1000MB private lan to transfer data.

When we ran the process and backed up VG00 last week the process took 6 hrs 9 minutes.... WAY to long. Searched around in the forms and found many referances suggesting the use of an configuration file to modify parameters. The config file has the following parameters....

blocksperrecord 256
records 32
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 100
filesperfsm 2000

I scheduled it to run at 0300 on last Saturday and took out the standard "-v" option we normally have. It began at 0300, just as planned, and finished at 0327..... yeah 27 minutes. Problem is that in the emailed message were the lines

fbackup(3055): total file blocks read for backup: 8565536
fbackup(3056): total blocks written to output file private_r3_prd:/dev/rmt/0mn: 0

That last line of course didn't look right. So this morning I put the "-v" option back in and ran it from a prompt. Output is below.

116360: /var/yp/ypxfr_2perday 1
fbackup(1005): run time: 1606 seconds
fbackup(3055): total file blocks read for backup: 8566145
fbackup(3056): total blocks written to output file private_r3_prd:/dev/rmt/0mn:
0

Again still doesn't look right even though you could visually verify that there was tape activity. But it still doesn't make sense.

Please NOTE: I am writing out to /dev/rmt/0mn even though man on fbackup indicated that you shouldn't use a 0mn device because control of the device may be lost if the fbackup process is killed or something like that.

Needless to say, it looks like it worked beautifully......it accessed the tape on the remote machine, the file count incremented, we had tape activity and appeared to terminate normally. That last line saying 0 really bugs me though.

Any thoughts?
Regards

[john korterman]

Hi,
fbackup requires use of the rewinding device. This is necessary as every session includes a rewinding of the tape before writing anything on it. If the tape cannot rewind, the outcome of the operation will be unclear. Try using the rewinding device. Please show us the command used.

regards,
John K.

[Bill Hassell]

private_r3_prd:/dev/rmt/0mn

This is a tape on another HP-UX machine, not local to the current box. The problem is that there is not a sophisticated interaction possible with the remote tape--fbackup simply sends the data to a remote tape writer process (man rmt). The use of 0mn on the remote system won't make any difference since the tape is always rewound at the beginning of the backup. However, remote backups (with fbackup) are a send-and-pray system. fbackup can't recover from any tape problems because the communication is one-way so there is no way to know what the tape actually wrote or to obtain detailed status. Similarly, fbackup can't write setmarks on the tape so recovering individual files or directories will be very slow. fbackup is using code internally that is basically the same as writing to a simple file and not a tape.

[Steven E. Protter]

I would not trust this setup.

You'd be better off backup up via NFS or making a tar file and transferring it via scp to the machine that has the tape drive.

Then at least you'll have full communication between the tape drive and the process.

Interestingly enough if your tape drive box happens to have a Veritas media manager software installation, then it becomes possible to have normal communications with the tape drive.

Under that expensive scenario you may be able to detect problems and rely on the return codes.

SEP

[Charles Holland]

John - the command is :
/usr/sbin/fbackup -f private_r3_prd:/dev/rmt/0mn -0 -v -c /homeroot/fbackup_config \

-i / \
-e /tmp \
-e /dvdrom

Bill - yes this is on another machine. Local machine doesn't have a tape drive. I can understand the "send-and-pray" statement, but generally we have an individual running the process interactively.

SEP - I dont' think the NFS thing is an option... I'd have to NFS /, /var, /opt, /etc, and all the "standard" filesystems from the source onto the target. What is scp? A man scp indicates "No manual entry for scp." No Veritas media manager software.

[Steve Lewis]

scp is the secure copy version of ssh.

Anyway, if you are unsure about your backup, then the obvious thing to do is to try to read it. Start with the index which sits at the start of the tape.
frecover -I /tmp/index.txt -f host:devicefile

That command reads the index off the tape and puts it into /tmp/index.txt

Then see if you can recover a file further down the tape, such as something in /usr or /var. Make a local copy of it if you don't want to overwrite something, using -F parameter. I suggest you carefully read the frecover man page.

[Steve Lewis]

By the way, that frecover command to read the index had a capital i, it looks like an l on my PC which could be confusing.

A slight terminological inexectitude, scp is the secure copy part of the ssh suite of utilities, not version. All bits of ssh are encrypted. It is unrelated to fbackup.

[Steve Lewis]

terminological inexactitude - I can't type this morning, more coffee required.

[Charles Holland]

thanks to all who responded. I gained a better understanding of fbackup along the way. After listening to Steve's sugestion, and doing some testing (had to relearn how to do a frecover) I think I will go with the confiuration of using fbackup to back up the information to a tape on another machine.

[Charles Holland]

See above