ADSM-L

Re: Restores--multiple threads vs. collocated

2003-04-19 06:17:48
Subject: Re: Restores--multiple threads vs. collocated
From: Remco Post <r.post AT SARA DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sat, 19 Apr 2003 12:17:06 +0200
On Fri, 18 Apr 2003 15:02:51 -0500
"Stapleton, Mark" <stapleto AT BERBEE DOT COM> wrote:

> From: Nancy R. Brizuela [mailto:Brizuela AT UWYO DOT EDU]
> > We are considering the pros and cons of using collocation at
> > our site. Has anyone done any experiments with restoring
> > using collocation (with a single thread using one tape drive)
> > vs. restoring using multiple threads, (multiple tape drives,
> > no collocation)?  We are using 3590 tapes with a capacity of
> > 40 gb's, so most of our machines would have their backup data
> > on one or, at most two tapes, if we collocated.  So, if we
> > collocated, we would usually not be able to use multiple
> > threads. It seems like we might actually have faster restores
> > by not collocating, therefore have data on multiple tapes,
> > thus be able to restore using multiple threads.  Anyone have
> > any advice, results from experiments, thoughts on this?
>
> Strong empirical evidence from the dozens of threads this mailing list
> has seen on this subject indicates that collocated data restores much
> faster than non-collocated data, particularly in the cases of Windows
> and Netware clients.
>


If you'd manage things in such a way that data of one client is only
spread across a few tapes, you might gain speed on non-colocated
storagepools. Then again, a 3590 is about as fast as a single disk, so
you might actually not gain anything, I guess This is only an issue on
_large_ fileservers, with lots of filesystems in the case you only need
to restore one of those, but you do have a disk-performance that could
keep up with multiple 3590's streaming at full speed (and a matching
network...)

> --
> Mark Stapleton (mark.stapleton AT berbee DOT com)
> Berbee Information Networks
> Office 262.521.5627


--

Gr, Remco

<Prev in Thread] Current Thread [Next in Thread>