Agreed on the shoeshine thing.  But mux'd backups do hurt large restore
performance.  

Four servers equally mux'd together would increase your restore time by four
since three out of every four 
fragments would have to be ignored.  I discovered this when I was making
offsite duplicates from mux'd backups.  I had these huge duplication times
until I demux'd my originals.

Storage unit creation defaults to *No* fragments so I was suggesting that,
if not being used, they should be.  After that, it's a balancing act between
fragment size & restore speed & catalog size (since very fragment gets its
own catalog entry).

If performance in a DR setting is everything with very short
Return-to-Business times, then tape is out.  You should look to other
technologies, ie VVR, SRDF, etc.

-M

-----Original Message-----
From: Ed Wilts [mailto:ewilts AT ewilts DOT org]
Sent: Thursday, October 20, 2005 2:20 PM
To: Mark.Donaldson AT cexp DOT com
Cc: Bill_Jorgensen AT csgsystems DOT com; veritas-bu AT mailman.eng.auburn DOT 
edu
Subject: Re: [Veritas-bu] Expert advice


On Thu, Oct 20, 2005 at 12:09:35PM -0600, Mark.Donaldson AT cexp DOT com wrote:
> To optimize for restorals, I'd:
>  
> 1. Turn off multiplexing - mpx doesn't hurt you for single-file restore
but
> it can cost big on whole server/filesystem restores.

Turning multiplexing off can really hurt your backups - if you can't
drive the tape drive at full speed, you'll shoeshine.

> 2. Use fragments on your storage units.  I use 4096M per fragment for my
> tapes.  This allows faster search-to-file ability at the cost of a larger
> catalog.

The larger the fragment size, the faster your *FULL* restores will be.
However, your individual file restores will be slower - on average,
they'll need to read 2GB of data off the tape instead of 1GB.

To optimize for restores, though, I'd do all my backups to disk or at
least disk staging.  

Use FlashBackup if you can since your restores will be significantly
faster - we see at least double the throughput with FlashBackups than
walking the file system if you have lots of small files.

-- 
Ed Wilts, Mounds View, MN, USA
mailto:ewilts AT ewilts DOT org