topic Re: fbackup size in Operating System - HP-UX

fbackup size

Greta Blamire — Thu, 08 Jun 2000 14:43:44 GMT

I'm trying to determine the size of my fbackup tape, it's reporting writing 43,309,549 blocks, which if I'm reading this white paper right means it's writing 43 G. But that doesn't make sense because it fits on one DDS2 tape. Here is the section of the white paper I'm refering to:

Understanding Fbackup/Frecover and Optimizing Backup
Performance

Records and Blocks

The commercial world is accustomed to logical records being combined into blocks, and blocks physically
written to tape or disk. Typically these records are about 80 bytes, as in a document. If a blocking factor
of 100 were used, then a block size of about 8K bytes would be written to tape, followed by an
interrecord gap.

Terminology can get a little confusing when trying to adapt this to fbackup. Fbackup has its own notion of
records and blocks. Its starting point is a block which it assumes consists of an unknown amount of raw
data (known in the commercial world as logical records). Its block size currently is 1024 bytes. Fbackup
combines these blocks into its own grouping, which hereafter is referred to as an fbackup record. It uses
the blocksperrecord option to specify the number of logical blocks which define a fbackup record. Using
the default blocksperrecord of 16, an fbackup record would be 16k bytes, and would be internally
structured as 16 logical 1k blocks. These 16k fbackup records would each be written to the output device
as individual 16k write(2) calls.

Beyond this level, how the output device handles the fbackup-record sized output is device dependent, and
relatively transparent to fbackup; if fbackup writes a 16k record to a file on an 8k-block filesystem, the
space on the disk would occupy two complete 8k HFS (High Speed File System) blocks. If fbackup
writes a 16k record to a half-inch magnetic tape or DDS, the space occupied on the tape would be 16k
contiguous bytes followed by an interrecord gap, considered one tape record, plus low-level tape format
overhead.

Re: fbackup size

CHRIS_ANORUO — Thu, 08 Jun 2000 15:08:45 GMT

try using this command on the tape:
frecover -f /dev/rmt/0m -V-

Re: fbackup size

Thomas G. Tudrej — Thu, 08 Jun 2000 18:36:52 GMT

read up on "tapeinfo" (not standart) utility http://hpchs.cup.hp.com/tools/tapetools/tapeinfo.html
. I have the 10.20 version if you want it. It provides some tape stats you may be interested in.

Re: fbackup size

Carlos Fernandez Riera — Fri, 09 Jun 2000 09:58:57 GMT

Nominal capacity for DDS2 and 120m tapes is 4Gb. With a tipycal compresion factor of 2:1 it is 8Gb.

But compresion depends much of data type, among other things. I have put 20Gb in a 120M tape.

I think 43 Gb is too high, but maybe.

Try to frecover and compare data with original.

Try the tapeinfo utility to get full status of compresion and capacity of your media.

I.ve try visit this page ,but i get timeout.

I have my own utility, so if you are interesed, just respond on forum.

Re: fbackup size

Andy Monks — Fri, 09 Jun 2000 12:10:21 GMT

Hi Greta,

You may have a 'sparse' file or files that your backing up. A sparse file is a file with holes in it (no data ever written to it). As far as any backup command is concerned it's just a block of nulls. If your tape drive does compression (as most do), nulls compress really well.

The 'tapeinfo' program is on an internal hp site so you can't get hold of that. If you can you could set the tape drives compression statistics to zero, then do your backup. After that you could check how much compression you go.

Also, there is an unsupported tool called 'fanalyze' which examines fbackup tapes. It also reports on the total data backed up and how much could be sparse.

I'm attaching fanalyze.

Re: fbackup size

Vince Laurent — Tue, 10 Oct 2000 17:37:41 GMT

I am game to get ANY tool which can help me with my tape library! I am unable to get tapeinfo from the above mentioned link. I have a SureStoreE 2/20 and am unable to get any hardware compression.

Vince Laurent