Networker

Re: [Networker] Initial Report on Functionality improvements in N W7 using Adv_Fil e devices

2003-05-22 17:17:29
Subject: Re: [Networker] Initial Report on Functionality improvements in N W7 using Adv_Fil e devices
From: Bokkelkamp Ernst <ernst.bokkelkamp AT SIEMENS DOT COM>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Thu, 22 May 2003 23:16:38 +0200
I am "playing" with d2d at the moment, unfortunately the HW is not the
optimal and the performance is way below that what can be expected from raid
arrays and LTO tape drives.

What I have noticed is that staging does not multiplex, not during staging
and not while a backup is performed on the same drive. What I mean to say is
that only one saveset at a time is staged from the source media to the
destination media.
The source for automatic staging is a device, the destination a pool, any
pool. If the destination is a backup pool that in use for backup then
staging waits for the backup to complete.
Another thing I found is that staging can be interesting to overcome a
bottleneck with low performance tape drives. My test setup has DLT4 with a
maximum thruput of 1.5 (3.0) Mbyte(sec). The maximum thruput with backup to
disk over the LAN runs at about 10Mbyte/sec. Staging from disk seems to
obtain a slightly better performance compared to backup directly to tape.
But I  suspect that this will change drastically if the tape drive can
outperform the disk system.

The nice part of staging unfortunately does not work because Legato did not
make it possible ;-)

What I see as a "problem" (because it would be a fantastic "oppertunity") is
that savesets are deleted from the index immediately after they have been
transfered to tape. t would have been very interesting if the savesets would
not be "deleted" (in the index, free space is later) so that it would be
possible to 1) stage from disk to tape, and 2) use the savesets on disk for
recovery until the space is released. My idea would be that it should be
possible to do all backups to disk, automatically staged to tape once the
backups have been completed but the savesets only removed after a number of
days (set in the staging policy). This would have the following advantage:
all recoveries can be done from disk while the savesets are available on
disk or from tape (when they have been released.) That would give a very
fast recovery time from recent backups and a "normal" recovery time for the
rest, while having a copy on tape in case the disk system crashes.
Unfortunately, that is not the way it works.


Bye
Ernie


-----Original Message-----
From: Joel Fisher [mailto:jfisher AT WFUBMC DOT EDU]
Sent: Thursday, May 22, 2003 10:47 PM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] Initial Report on Functionality improvements in
NW7 using Adv_Fil e devices


My 2 cents

You probably right, it's a leap to assume that this is everyone's
direction, but as for my self it just makes the most sense.  You make a
valid point that tape(with hardware compression) is, and probably will
remain "faster" than disk(disk that is cheap enough to even consider d2d
with anyway).  However, in my case I'm running into serious problems
keeping these(9940B) fast drives streaming while at the same time
providing decent recovery speed.  With d2d and disk to tape
staging/cloning you've really alleviated these problems because it
doesn't matter if you have 30(250k/s) streams going to disk, they all
are written to their own randomly accessible file.  So when a recover
request comes in not only is the unload/load/rewind/fsf/fsr pretty much
gone, once located the data can be read all at once not having to skip
other interleaved "chunks".  Also when that saveset is staged/cloned to
tape, it is then written in a contiguous chunk at maximum
disk(presumable local disk) to tape transfer speed rather than across
the network and interleaved with other save streams.  So in a disaster
situation, recovery from tape will also be much faster because all the
data for each saveset will be written contiguously.

I'm looking at moving complete d2d next year, and will be evaluating
several d2d class arrays(Nexsan ATAboy2, STK Bladestore, EMC Clariion
CX600(ATA)) in the coming months and will summarize to the list.

One question I have along these lines is about the adv_file devices.  It
seems a bit odd to me that a save stream will not move to another volume
when the one it is currently writing to is full.  In a large environment
I would think that could cause some problems, you'd have to have
very(TB+) large volumes.  Anyone know what the idea behind these is?
I'd rather have 20x1TB adv_file devices over 2x10TB devices, but the
smaller the device the more likely it'll run out of room and just hang
there until something expires.  I don't have 7 yet so maybe this isn't
really a problem, but it seems like it could be.


Joel

----Original Message-----
From: Davina Treiber [mailto:treiber AT HOTPOP DOT COM]
Sent: Thursday, May 22, 2003 2:20 PM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] Initial Report on Functionality improvements in
NW7 using Adv_Fil e devices

On Thu, 22 May 2003 12:05:46 -0400, Robert Maiello
<robert.maiello AT MEDEC DOT COM> wrote:

>Presuming we're all heading in this direction (ie..backup to disk,
stage
>to tape)

Now that's an interesting assumption. I would say that this is not the
universal direction. I agree that staging via disk has many attractions,
mainly the quick access for recoveries and ability to clone multiple
times
more quickly, however for pure speed, today's tape drives are streets
ahead. If quick file recoveries are the aim, there are other ways to do
this, such as snapshotting software, and the snapshotting features of
the
various disk storage technologies that are around. Staging is a useful
tool, but just another option in our backup armouries.

What do you think?

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

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

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