[prev in list] [next in list] [prev in thread] [next in thread]
List: veritas-bu
Subject: Re: [Veritas-bu] LTO-3 throughput expectations
From: "bob944" <bob944 () attglobal ! net>
Date: 2006-12-22 4:42:25
Message-ID: 001001c72583$977a0bd0$693415ac () enterprise ! veritas ! com
[Download RAW message or body]
> Anyone else have an idea of why I can only seem to drive the
> tape drives at 12.5MB/sec when duplicating tapes on the
> master server? The server itself is not loaded during this
Buffer wait/delay times in bptm are your friend. Consult the _Backup
Planning and Performance Tuning Guide_ for a logical plan to isolate the
cause(s) of the poor performance you're seeing on backups as well as
dups.
> Also, what about the bpduplicate performance when duplicating
> multiplexed tapes?
For multiplex level N, it's N passes of the tape to duplicate--unless
you use the -mpx option to leave the tape multiplexed. See the Commands
manual or man page for bpduplicate.
> How about restores from the same? Am I
> just moving the bottleneck from one place to another?
In a DR scenario, multiplexed restores, where you want to restore
much/all of the data to multiple destinations, is generally faster than,
say, restoring one non-mux backup, then the next non-mux backup, ... If
recovery time is critical, it can be worth crafting the backup scheme to
take advantage of multiplexed restores.
If you're restoring a single box from muxed backups, the book (can't
provide a cite) says that NetBackup's ability to skip over the "other"
data on current, fast tape drives makes restore from reasonable
multiplex levels makes 1-of-N restores on a par with non-muxed restores.
I haven't tested this, but think it's reasonable. This, from someone
whose first 3.1 NetBackup experience was recovering The Finance Server
from my predecessor's heavily multiplexed backups. Most painful.
_______________________________________________
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic