Networker

Re: [Networker] Speed of recovers?

2005-03-10 07:14:49
Subject: Re: [Networker] Speed of recovers?
From: Howard Martin <howard.martin AT EDS DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Thu, 10 Mar 2005 07:12:33 -0500
On Wed, 9 Mar 2005 13:59:13 -0800, Darren Dunham <ddunham AT TAOS DOT COM> 
wrote:

>> 1. All network speed aside, does the number of files and sizes of the
>> files in the saveset affect the speed of recovery for the saveset or
>> just the amount of the data and the speed of the drives?
>
>Yes, it does.  Recovery of small files is usually dominated by the speed
>with which the client can create files in the filesystem.  This may
>reduce the throughput.
>
>This isn't a problem with larger files.
The size of small files vary depending on OS and hardware of the client, a
few years backup after some extensive testing I found that a file size of
~200 Kbytes on a NT4 client took as long to write the information about
the file (directory entry) as to write the data in that file.

>
>> 2. In general, is it safe to say that recovery will be slower than
>> writing since it has to de-multiplex the data from the other streams
>> that were written at the same time?
>
>You're talking two different things here...
>
>The data throughput of one recovery stream may well be lower than the
>data throughput of multiple backup streams..
>
>However the amount of time taken for the original backup will likely be
>comparable to the time for the restore (plus time for the client to
>manage file creation).
I'd also add that usually disk hardware take longer to write information
than to read it (yes it does depend on lots of other factors). I've newver
seen a recover that was quicker than the backup.
>
>> 3. What might you expect for recovery times knowing the speed of your
>> writes and target sessions? Can any rough estimates be expected?
>
>Don't put too many sessions on a volume if the clients are "fast"
>(relative to the speed of the tape).  The purpose is to keep the drive
>utilized.  The fewest number of clients that accomplish the goal, the
>better.
>
>If you have 'n' equivalent sessions, then you'd expect throughput (both
>backup and recovery) to be about max/n where max is the maximum speed of
>the network/server/drive path.
You must also consider whether the data you want to recover is in multiple
streams on multiple tapes and how you are going to recover, using a single
nwrecover window only one drive will be used, if you have savestreams
starting on other tapes more nwrecover windows could be started
specifically for those save sets, oh and of course if you are using a
full/diff/incremntal cycle you will have a worst case scenario when
recovering just before the next scheduled full (ie maximum number days to
go back to the previous full.
I believe that is usual for backup administrators to use a rule of thumb
for most recoveries as there are a lot of factors to be considered - in
our case we usually say a recovery will take twice as long as a full
backup for a particular system.
>
>> 4. Is there a way, aside from just eyeballing and watching the clock, to
>> calculate the speed that the data is being recovered at?
>
>You might use a network monitor to watch the traffic.
>
>You could use iostat to see the speed of the data coming from the drive
>(which would include all the streams)
>
>
>--
>Darren Dunham                                           ddunham AT taos DOT com
>Senior Technical Consultant         TAOS            http://www.taos.com/
>Got some Dr Pepper?                           San Francisco, CA bay area
>         < This line left intentionally blank to confuse you. >

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

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