Fbackup question regarding blocks read and blocks written

[Ray Humpage]

We have an auditor onsite who is asking me why the file blocks read and file blocks written don't match on our fbackup. Was hoping someone could explain to me the difference. Thanks.

fbackup(3055): total file blocks read for backup: 39346730

fbackup(3056): total blocks written to output file /dev/rmt/3m: 39489386

[Dennis Handly · Accepted solution]

I assume that since you aren't copying just one file, you must output lots of metadata to the tape.

A better question the auditor can ask is can you restore the data and compare to the original?

[James R. Ferguson]

Hi Ray:

What's a few blocks among friends :-)

Seriously, though, I can think of one good reason for the higher output than input count.

Fbackup (by design) computes a checksum for a file taht is being backed up before it writes the file to tape. Once a copy of the file has been written to the tape, the checksum is recalculated. If the checksums don't match, the copy on tape is marked *bad* and a new copy is made. This mechanism of retries is governed by the 'maxretries' value in the 'fbackup' configuration file (default=5). It is intended to allow backing up inuse, changing files, or at least, attempting to make a valid (static) copy.

During a 'frecover' process, any file marked "bad" cannot (will not) be recovered.

Regards!

...JRF...

[Matti_Kurkela]

From the fbackup man page:
-----------
The general structure of an fbackup volume is the same, no matter what type of device is used. There are some small specific differences due to differing capabilities of devices. The general structure is as follows:

+ reserved space for ASCII tape label (1024 bytes)
+ fbackup volume header (2048 bytes)
+ session index (size in field of volume header)
+ data
------------------

The number of "file blocks" is just the sum of the sizes of data files read from the disk. The "total blocks written to output" includes the data in those files, plus tape label, session index and periodic checkpoints to limit damage if one spot on the tape becomes bad.

Without this extra information, your backup would be just a pile of disorganized data: the session index contains the names, locations, modification times, ownerships, permissions and other important information about your files.

And, by the way, the block size of the tape is not necessarily the same as the block size of the disk: some tape technologies work much better with huge block sizes.

MK

[James R. Ferguson]

Hi (again):

...and I always say read those manpages --- thanks, Matti !

Regards!

...JRF...

[Ray Humpage]

This all makes total sense. Thanks for the info.

[Ray Humpage]

Thanks again.