fbackup succesfull- frecover wants second tape

[edwin hamers]

I found something strange happening on our production server.
I use to backup the server with fbackup. This is fairly straightforward, and fbackup does not return any error. (It doesnt ask for a second tape).

But when i try to frecover a file which is mentioned on the last place in de online Index file, that i get the following message :

frecover(5401): Volume 1 completed.
frecover(5404): Press return when the next volume is ready on /dev/rmt/0m:

frecover(5423): incorrect volume mounted;
frecover(5424): expected volume 2, and got 1
frecover(5433): Do you wish to continue using this volume? (^[yY]/^[nN]) n
frecover(5412): Do you wish to try to salvage this volume? (^[yY]/^[nN]) n
frecover(5411): Do you wish to try a different volume? (^[yY]/^[nN]) n
frecover(5414): abort selected

This is strange because the index file states that the recoverd file should be on volume 1, and fbackup does not ask for volume 2.

I use HPUX 11.0 and installed the latest patch PHCO_29197.
my fbackup command is like this :
${FBACKUP} -0uyc ${CFG} -g ${GRAPH} -I ${INDEX} -V ${HEAD} -f ${DEVICE}

Does anybody have an idea?
Or else i will get support from HP i guess.

[Bill Hassell]

The backup required at least two tapes. fbackup places a list (index) of the entire backup on every tape but since there is no way to guess how much tape is available or to predict tape usage, fbackup will write until the end of the tape, then request another tape. When you insert a second tape, the index will again be written at the front but this time a maker is placed at the beginning indicating all the files that were recorded on the previous tape.

You need to look at the output of the fbackup command to see where it asked for another tape and see if the operator actually inserted a tape or just cancelled the job. If the above fbackup command is being run from cron, there is no one to change tapes so you only have a partial backup. Run the fbackup command from a login and see what happens. It will probably ask for another tape.

[edwin hamers]

Sorry, but my logging is as follows :

fbackup(1004): session begins on Tue Jul 6 01:00:00 2004
fbackup(1517): /net not backed up - 'n' option (NFS) not specified
fbackup(3205): WARNING: unable to read a volume header
fbackup(3024): writing volume 1 to the output file /dev/rmt/c4t5d0BESTnb
fbackup(1102): WARNING: unable to stat file /var/opt/dce/rpc/local/02217/c-0/9571
fbackup(3005): WARNING: file number 914546 was NOT backed up
fbackup(1030): warnings encountered during backup
fbackup(3055): total file blocks read for backup: 186150127
fbackup(3056): total blocks written to output file /dev/rmt/c4t5d0BESTnb: 190205945

No question of asking for a new tape.
That why it is so strange.
I know i have the -y option in my fbackup command. I wil run the backup of tonight without this option.

[edwin hamers]

Indeed i run this from the cron.

But i alwyas run from the cron, and whenever the tape would be full, fbackup would complain, and ask for a new tape.
The cron would automatically cancel it, but thats another thing.

And according to the amount of data written (around 90 GB), the tape of 40 GB compressed, should not be full. (Mainly Oracle data is being backupped)

[Darren Prior · Accepted solution]

Hi Edwin,

Your latest response showing fbackup errors looked like you used a no-rewind device file. This is not supported, and could possibly lead to the behaviour that you've seen.

regards,

Darren.

[edwin hamers]

So i noticed.....
I removed the nb from the device name.
Lets see for now.

Back on monday. (points will be awarded then)

[Bill Hassell]

Regardless of what the manufacturer says about compression, you are only guarenteed to backup 90Gb on a 100Gb tape. If the Oracle database was just created and the initial values inside the database are either sparse or all zeros, then you can probably backup 500Gb to 2000Gb on your 40Gb tape. But if the database is quite full with essentially random data in most of the records, you can probably squeeze 50Gb on your 40Gb tape.

Marketing (for all manufacturers of tape drives) has always quoted the 'compressed' value and put the 'real' value in fine print. Now if you have the time and disk space to compress all your data into a big file, then see how much is actually needed, you can predict the actual tape usage (minus tape retries and fast searchmarks).

fbackup is quite sophisticated and does not use the device file defaults for no-rewind. It does pay attention to compression (ie, BEST) but the majority of all tape device files are BEST anyways (see: lssf /dev/rmt/*)

I would add a separate logfile to your cronjob that captures stdout and stderr and of course, turn off the -y option. You want fbackup to fail if operator assitance is required in a cronjob.

[edwin hamers]

That did it.
I deleted the -y option, and now fbackup complaints about a second tape.
I guess it was overwriting the first tape, and did not log this.

Thanks everybody