SearchFAQMemberlist Log in
Reply to topic Page 1 of 1
Speed of recovers?
Author Message
Post Speed of recovers? 
Hi,

I'm trying to determine a general ball park figure for what we should be
seeing for recovery speeds on our SDLT 220 drives which brings up some
questions. Here are the facts:

Quantum SDLT 220 gen 1 drives with gen 1 media
Averaging around 12 MB/sec write speeds
Target sessions = 5 per device
Linux Red Hat Dell storage node server

In recovering a recent saveset (multiple tapes), I noticed it seemed to
be averaging about 1 GB per minute, sometimes 2 GB per minute, so that's
anywhere from say 7 MB/sec to 17 MB/sec. Not bad in my opinion, but not
sure. I was recovering at most 1 of the streams that might have been
multi-plexed to the given tapes. I say 'might' because typically there's
always at least several streams writing to a given tape at a time. The
target sessions are set to 5 for all devices, but sometimes it will send
more, sometimes less depending. Obviously, depending on how much it has
to de-multiplex, speeds will vary. I have some questions:

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?

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?

3. What might you expect for recovery times knowing the speed of your
writes and target sessions? Can any rough estimates be expected?

4. Is there a way, aside from just eyeballing and watching the clock, to
calculate the speed that the data is being recovered at?

I see write speeds during backups but not recoveries.

Thanks.

George

BTW It would be nice, during big recovers, if NetWorker had the
capability to load up all available drives with the same number of
required tapes and perform multiple recovers at the same time from the
savesets on the tapes and somehow merge them on disk before continuing?
Would save a lot of time.

Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

Post Speed of recovers? 
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.

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).

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.

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.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.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

Post Speed of recovers? 
On Wed, 9 Mar 2005 13:59:13 -0800, Darren Dunham <ddunham < at > TAOS.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.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.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
  


Magic SEO URL for phpBB