You're absolutely right that anything over the "raw" capacity is a
matter of luck, and that discounting marginal media.

However, there are a couple of rules of thumb that I find useful:
- for the average client, a net compression ratio of about 1.5:1 is
fairly normal.  2:1 or higher is rare.
- the "compressed" rating is actually a fairly good sizing indicator of
tape vs disk capacity.  When you allow for not running hard drives over
80% full, and reasonable expectation of compression, the upper value is
about the size of the disk space you can plan to protect with it,
assuming full backups.

/kenw

> -----Original Message-----
> From: Ben Scott [mailto:[EMAIL PROTECTED]
> Sent: February-15-08 12:32 PM
> To: NT System Admin Issues
> Subject: Re: Backupexec and compression
> 
> On Fri, Feb 15, 2008 at 1:25 PM, Joseph L. Casale
> <[EMAIL PROTECTED]> wrote:
> > Exactly? They are 200/400 tapes.
> 
>   I ignore "compressed capacity" claims; they are a marketing gimmick
> and always have been.  Compression rates vary tremendously.  You might
> get no compression gain, or 1.5:1, or 3:1.  So I just avoid quoting
> "compressed capacity" entirely.
> 
>   By "200/400 tape", I surmise you LTO-2.  Those do have a nominal,
> native capacity of 200 GB.  But in the land of disks and tapes, "200
> GB" means "200 billion bytes".  In the land of software and operating
> systems, "200 GB" means "200 * 2^30 bytes".  This is sometimes
> explicitly written as "200 GiB".  Compare:
> 
> 200 GB  = 200,000,000,000 bytes
> 200 GiB = 214,748,364,800 bytes
>  14 GiB =  14,748,364,800 bytes (difference)
> 
>   So right away, you're only going to get 93% of that "200 GB" you
> thought you had.
> 
>   Then there is overhead for metadata.  Is this a large number of
> small files?  If so, the metadata for each file may be becoming
> significant.  I don't know anything about BUE's on-tape format, but I
> would guess they are likely storing a header at the start of each file
> (with name, datestamps, size, NTFS ACL, etc.).  Or maybe in a catalog
> at the start/end of the tape.  Either way, it consumes tape space.
> 
>   You also loose some tape capacity to bad blocks.  Any big tape is
> going to have some number of bad blocks.  Nominally, the drive
> automatically detects and corrects for them, so the backup software
> (and you) are not aware it is even happening.  But it can eat into the
> nominal capacity of the tape.  Is it an old tape?
> 
>   Finally, yes, a bad or simplistic compression algorithm may well
> make the "compressed" data larger for already-compressed input.  A
> smart compression implementation will detect this and just store the
> straight input data, but tape drives are not known for using smart
> implementations.  So turning off hardware compression may well gain
> you some tape space back.  But perhaps not as much as you think.
> 
> -- Ben
> 
> ~ Upgrade to Next Generation Antispam/Antivirus with Ninja!    ~
> ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!    ~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

Reply via email to