|
Home > Archive > Data Storage > February 2006 > LTO-3 Autoloader Recommendation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
LTO-3 Autoloader Recommendation
|
|
| Dan Adams 2006-02-04, 5:47 pm |
| I am looking at the Gateway 823 LTO-3 Autoloader, and I will appreciate
user feedback. What features should I look for in such a tape drive?
The featues I seek include the following: U320 or U160 interface, NT
Backup and Veritas BENT/Win2003 compatibility, 8 slots, support for a
cleaning tape, internal barcode ready (as a future upgrade option), and
rackmountable. I'll look at other vendors if recommended.
Thanks
Dan Adams
| |
| Rob Nicholson 2006-02-04, 5:47 pm |
| >I am looking at the Gateway 823 LTO-3 Autoloader, and I will appreciate
> user feedback. What features should I look for in such a tape drive?
> The featues I seek include the following: U320 or U160 interface, NT
> Backup and Veritas BENT/Win2003 compatibility, 8 slots, support for a
> cleaning tape, internal barcode ready (as a future upgrade option), and
> rackmountable. I'll look at other vendors if recommended.
Interested in this too as I'm looking at our strategy for the next five
years. Anyone had any experience of the Freecom Superloader units? In the
UK, the 8 slot LTO2 is £2,300 and 8 slot LTO3 is £3,000. The HP 8 slot LTO3
StorageWorks is £3,400.
Cheers, Rob.
| |
| Dan Adams 2006-02-04, 8:45 pm |
| I haven't heard of the brand name. However I had a look at an EXABYTE
VXA autoloader. It uses propriertary media but the user was quite
bullish about the technology, and especially the option to use firewire
in a Mac XSERVE environment. BTW, EXABYTE also makes LTO drives.
What backup strategy are you looking at? I'm moving to a
disk-to-disk-to-tape system. I probably will go with disk-to-disk
replication using low-end DAS/NAS with SATA drives, and then upgrade to
a continous protection backup server with a higher end DAS
fiber-to-SATA backplane.
| |
|
| On 4 Feb 2006 06:24:00 -0800, "Dan Adams" wrote:
>I am looking at the Gateway 823 LTO-3 Autoloader, and I will appreciate
>user feedback. What features should I look for in such a tape drive?
To Dan & Rob... you guys are aware that LTO-3 isn't the right choice
for every environment, right? It's not just a tape capacity issue,
you need to make sure that your solution will be able to _stream_ data
to the tape drive.
HVB
| |
| Dan Adams 2006-02-05, 3:19 pm |
| How does this differ from using DDS3 and DDS4 DAT drives to backup
files stored on local and remote servers using NT Backup and Veritas
Backup Exec ?
Dan
| |
| Rob Nicholson 2006-02-06, 7:53 am |
| > What backup strategy are you looking at? I'm moving to a
> disk-to-disk-to-tape system. I probably will go with disk-to-disk
I don't think we need that level of redundancy so we'll be sticking (I
assume) with disk-to-tape backup across the network using BE agents with the
backups running most of the time across a gigabit backbone. Our current
backup requirements are only 200GB so actually a single LTO-3 drive would
suffice. But we're planning for growth.
Rob.
| |
| Rob Nicholson 2006-02-06, 7:53 am |
| > To Dan & Rob... you guys are aware that LTO-3 isn't the right choice
> for every environment, right? It's not just a tape capacity issue,
> you need to make sure that your solution will be able to _stream_ data
> to the tape drive.
We'll be streaming off SCSI servers on a gigabit backbone. We'll probably
carry on using our existing LTO-1 tapes for anyway.
Should that be okay?
Thanks, Rob.
| |
|
| On 5 Feb 2006 10:58:45 -0800, "Dan Adams" wrote:
>How does this differ from using DDS3 and DDS4 DAT drives to backup
>files stored on local and remote servers using NT Backup and Veritas
>Backup Exec ?
Again for Dan & Rob...
With LTO-3 you need to make sure that you can supply data to the tape
drive at a rate *no less than* 35MB/sec.
If your data rate drops below this, the tape drive will have to stop,
rewind, reposition and restart (known as shoe-shining). This is not
only bad for your tape and drive, it also kills backup performance.
Most, if not all, LTO-3 drives have a built-in buffer and tape
performance management routines that allow the drive to slow the tape
down to match the performance of the server. Even with this
technology, you still need that 35MB/sec data rate.
This performance issue can mean that LTO-2 actually provides better
overall throughput performance, because the data rate requirements are
a lot lower (around 20MB/sec IIRC).
I'd recommend LTO-3 in a Fibre Channel only environment, preferably
with disk-staging also - all to maximize performance.
If you're in doubt, ask your supplier to qualify your environment
before you buy LTO-3.
HVB
| |
| Rob Turk 2006-02-06, 5:48 pm |
| "Rob Nicholson" <rob.nicholson@nospam_informed-direct.com> wrote in message
news:ds781d$9ja$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
>
> We'll be streaming off SCSI servers on a gigabit backbone. We'll probably
> carry on using our existing LTO-1 tapes for anyway.
>
> Should that be okay?
>
> Thanks, Rob.
A single LTO-3 drive (70+ MB/s native...) can fully saturate the practical
bandwith of a GbE interface, so in reality a Gigabit backbone is not
adequate. You'll also have a hard time getting all your servers to deliver
the required data fast enough. If you really want to use LTO-3 you'll need
either SAN shared connectivity or a local fast disk buffer on the backup
server (read up on D2D2T).
Also, LTO-3 drives can *read* LTO-1 media but you can not write on them.
Rob
| |
| Rob Nicholson 2006-02-06, 5:48 pm |
| > Also, LTO-3 drives can *read* LTO-1 media but you can not write on them.
Hmm, might be better sticking with LTO-2. Can an LTO-2 drive write to LTO-1
tapes?
Thanks, Rob.
| |
| Dan Adams 2006-02-07, 5:54 pm |
| How does my proposed setup stnadup against "shoe-shining":
12-bay dsik array with SCSI U320 to SATA backplane (initially 5 500GB
SATA II drives), and LTO3 drive attached to an Adaptec 39160 (SCSI
U160) PCI-X HBA on a Dual Xeon/800FSB 2.8Ghz box with 1GB DDR RAM.
Veritas Backup Exec 10d with CPS, AOFO, IDR and DLO pulls data from
servers and desktops/laptops to disk array, which in turn is backuped
to LTO3 autoloader.
| |
| Rob Turk 2006-02-07, 5:54 pm |
| "Dan Adams" <akwete@hotmail.com> wrote in message
news:1139341307.456576.28390@z14g2000cwz.googlegroups.com...
> How does my proposed setup stnadup against "shoe-shining":
>
> 12-bay dsik array with SCSI U320 to SATA backplane (initially 5 500GB
> SATA II drives), and LTO3 drive attached to an Adaptec 39160 (SCSI
> U160) PCI-X HBA on a Dual Xeon/800FSB 2.8Ghz box with 1GB DDR RAM.
>
> Veritas Backup Exec 10d with CPS, AOFO, IDR and DLO pulls data from
> servers and desktops/laptops to disk array, which in turn is backuped
> to LTO3 autoloader.
>
Looks fairly good, assuming the disk array actually does it's own RAID
handling. Aas long as you keep the disk array and the LTO-3 drive each on a
separate channel of the 39160 you should be OK.
One thing to keep an eye on is BackupExec. It's notorious for the load it
puts on the index databases. If you have lots of small files and you put
your BE index on a slow (internal IDE) disk or have it share the OS disk
then you're in for trouble. If switching to a different software package is
an option then checkout NetVault (Bakbone Ltd) or Commvault Galaxy.
Make sure you set the tape blocksize to as large as you can. By default the
blocksize may be limited to just 64K or 128K if the Adaptec 39160 driver
uses it's default DMA scatter/gather settings.
Rob
| |
| Steve Cousins 2006-02-07, 5:54 pm |
| Dan Adams wrote:
>How does my proposed setup stnadup against "shoe-shining":
>
>12-bay dsik array with SCSI U320 to SATA backplane (initially 5 500GB
>SATA II drives), and LTO3 drive attached to an Adaptec 39160 (SCSI
>U160) PCI-X HBA on a Dual Xeon/800FSB 2.8Ghz box with 1GB DDR RAM.
>
>Veritas Backup Exec 10d with CPS, AOFO, IDR and DLO pulls data from
>servers and desktops/laptops to disk array, which in turn is backuped
>to LTO3 autoloader.
>
As far as hardware I'd think this would be fine as long as your disk
array is fast enough. We have a somewhat similar setup with a two
channel LSI U320 card. One channel goes to a 16x400GB RAID6 array and
the other channel goes to an Overland Neo2000 with a LTO-3 drive.
Backup speed is fine with this setup. I have tried backing up over GB
Ethernet and, while I think the drive is still streaming, it is not up
to the ~80MB/sec that the drive can handle. More like half that.
I posted a message a while back about slowdowns when restoring from the
LTO-3 tapes. It appears to be a problem between the LTO-3 drive and the
LSI SCSI card. I have no problems reading from the tapes when I moved
the library to a different server with a 39160 controller on it. When I
told Overland that it was connected to a LSI controller they asked me
why I used LSI, as if that was a known problem. The answer was that
that was the recommended card that the RAID array vendor specified.
Has anyone else had problems with LSI U320 cards and LTO-3 drives?
Steve
| |
| Rob Nicholson 2006-02-08, 7:46 am |
| >> Hmm, might be better sticking with LTO-2. Can an LTO-2 drive write to
>
> Yes it can. You do have a media recycle and archive policy in use, I
> assume? Do you keep track on how often your current tapes are used and
> when you should retire them?
Yes we do and the majority of the tapes aren't that old. Haven't a clue
though on their lifespan. Backup Exec I believe keeps a record of how much
the tapes have been used.
Cheers, Rob.
| |
| Joshua Baker-LePain 2006-02-08, 5:48 pm |
| On 2006-02-07, Steve Cousins <steve.cousins@maine.edu> wrote:
>
> I posted a message a while back about slowdowns when restoring from the
> LTO-3 tapes. It appears to be a problem between the LTO-3 drive and the
> LSI SCSI card. I have no problems reading from the tapes when I moved
> the library to a different server with a 39160 controller on it. When I
> told Overland that it was connected to a LSI controller they asked me
> why I used LSI, as if that was a known problem. The answer was that
> that was the recommended card that the RAID array vendor specified.
>
> Has anyone else had problems with LSI U320 cards and LTO-3 drives?
I'm running an LTO3 drive (well, actually, an Overland Neo2K library)
on an LSI U320 card, and it works quite well. My backups reports speeds
of ~70MB/s writing to the drive.
Is the "known problem" OS specific? I'm running Linux (centos-4) on
a dual Opteron server.
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
| |
| Steve Cousins 2006-02-08, 5:48 pm |
| Joshua Baker-LePain wrote:
>
> I'm running an LTO3 drive (well, actually, an Overland Neo2K library)
> on an LSI U320 card, and it works quite well. My backups reports speeds
> of ~70MB/s writing to the drive.
How about restores? I get very good performance and no errors when
backing up. It wasn't until I did a restore that I had intermittent
problems. It would slow way down and then finally it would stop
completely. tar would complain about a read error but the LSI controller
would say:
Jan 27 12:09:50 triton-gb kernel: mptscsih: ioc1: >> Attempting task
abort! (sc=e4ed4c80)
Jan 27 12:09:50 triton-gb kernel: mptbase: ioc1: IOCStatus(0x0048): SCSI
Task Terminated
Jan 27 12:09:50 triton-gb kernel: mptbase: ioc1: LogInfo(0x11010101):
F/W: bug! MID not found
Jan 27 12:09:51 triton-gb kernel: mptbase: ioc1: LogInfo(0x11010101):
F/W: bug! MID not found
Jan 27 12:09:51 triton-gb kernel: mptbase: ioc1: IOCStatus(0x004b): SCSI
IOC Terminated
Jan 27 12:09:51 triton-gb kernel: mptscsih: ioc1: >> Attempting target
reset! (sc=e4ed4c80)
Jan 27 12:09:51 triton-gb kernel: mptscsih: ioc1: >> Attempting bus
reset! (sc=e4ed4c80)
Jan 27 12:09:52 triton-gb kernel: mptbase: Initiating ioc1 recovery
> Is the "known problem" OS specific? I'm running Linux (centos-4) on
> a dual Opteron server.
They wouldn't say anything specific. Ours is a Dual Opteron too with
FC3.
I'd be interested in hearing if you are able to restore multiple tapes
without a problem. It would happen at different times. Sometimes it
would get through a full tape fine. Other times it would get close to
the end and then bomb. It would also vary for a given tape. Finally I
was able to restore the data from another machine so it isn't a drive,
or tape problem. I used the same cable and terminator too. Difference
between U320 and U160? Or is it in fact something buggy with the LSI
MPT software? I haven't had time to figure it all out yet.
Steve
| |
| Joshua Baker-LePain 2006-02-09, 5:48 pm |
| On 2006-02-08, Steve Cousins <steve.cousins@maine.edu> wrote:
> Joshua Baker-LePain wrote:
>
> How about restores? I get very good performance and no errors when
> backing up. It wasn't until I did a restore that I had intermittent
> problems. It would slow way down and then finally it would stop
> completely. tar would complain about a read error but the LSI controller
> would say:
I haven't had a problem with restores, either. I've used both dd
and amrestore (from AMANDA) to grab backup images from the tapes.
What block size are you using? I've used both 32K (amanda's default)
and 2M, with 2M obviously getting better speeds. tar's default
block size is awfully small.
>
> They wouldn't say anything specific. Ours is a Dual Opteron too with
> FC3.
That's "odd" -- FC3 should be pretty close to centos-4 kernel wise. What's
the MPT driver version? Mine reports 3.02.18.
> I'd be interested in hearing if you are able to restore multiple tapes
> without a problem. It would happen at different times. Sometimes it
> would get through a full tape fine. Other times it would get close to
> the end and then bomb. It would also vary for a given tape. Finally I
> was able to restore the data from another machine so it isn't a drive,
> or tape problem. I used the same cable and terminator too. Difference
> between U320 and U160? Or is it in fact something buggy with the LSI
> MPT software? I haven't had time to figure it all out yet.
I just dumped 1.5TB to 4 tapes and pulled it all back off with no
problems. In fact, I've been very happy with the reliability of this setup
<knocks wood>.
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
| |
| Steve Cousins 2006-02-09, 5:48 pm |
| Hi Joshua,
Joshua Baker-LePain wrote:
>I haven't had a problem with restores, either. I've used both dd
>and amrestore (from AMANDA) to grab backup images from the tapes.
>
>
That's good to hear.
>What block size are you using? I've used both 32K (amanda's default)
>and 2M, with 2M obviously getting better speeds. tar's default
>block size is awfully small.
>
I've been using 512 KB blocks.
>
>That's "odd" -- FC3 should be pretty close to centos-4 kernel wise. What's
>the MPT driver version? Mine reports 3.02.18.
>
Mine reoports 3.01.18 (although I don't see that on the LSI version
history for this driver (?)). What is weird is that in January I had
updated the kernel to 2.6.12-1.1381_FC3smp and the mpt driver was
3.01.20. With this kernel (and probably it just boiled down to this mpt
driver) I got consistent symptoms after restoring about 10 GB of data on
each tape. I booted from the older kernel with (2.6.11-1.35_FC3smp)
and I could at least restore most of the data. The next step is
obviously to update the mpt driver. Maybe the kernel too I guess. Maybe
I should upgrade to FC4 since FC3 is frozen at this kernel. I wonder if
yum can update from FC3 to FC4 for me. It never stops! I'll start with
the driver.
>
>I just dumped 1.5TB to 4 tapes and pulled it all back off with no
>problems. In fact, I've been very happy with the reliability of this setup
><knocks wood>.
>
Great news.
Thanks for your information.
Steve
| |
| Torbjorn Lindgren 2006-02-09, 5:48 pm |
| Steve Cousins <steve.cousins@maine.edu> wrote:
[...][vbcol=seagreen]
>obviously to update the mpt driver. Maybe the kernel too I guess. Maybe
>I should upgrade to FC4 since FC3 is frozen at this kernel. I wonder if
>yum can update from FC3 to FC4 for me. It never stops! I'll start with
>the driver.
yum upgrade (not update) can to some extent be used to upgrade between
some versions of Fedora Core, but it's quirky and complicated. Not
really recommended, I've done the easier FC2 to FC3 upgrade that way
but not FC3 to FC4 which is apparently quite a bit quirkier.
Fedora Legacy will release new kernels for FC3, but that's likely to
only be security related fixes as compared to the last FC3 kernel.
Also, I haven't tested this but a FC4 or even FC5t2 kernel plus a few
other RPMs (kernel-utils+?) *MAY* work (I've seen FC2 kernels on FC3
machines *and* vice-versa, not sure if anyone tried it with FC4+
kernels on FC3).
But really, you would probably be best of with either upgrading (to
FC4 or something else) or respinning a FC3 kernel with a newer MPT
driver (rebuilding from SRPM with new driver), but the last
alternative requires a bit of know-how.
http://www.fedoraproject.org/wiki/YumUpgradeFaq
| |
| Dan Adams 2006-02-09, 5:48 pm |
| Thanks for the eval. Gateway recommends I use separate U160 or U320
SCSI cards. My backup server OS and Veritas BE 10d (EVAL) currently
sits on mirrored 80GB SATA I hard drives.
| |
| Odie Ferrous 2006-02-09, 5:48 pm |
| Torbjorn Lindgren wrote:
>
> Steve Cousins <steve.cousins@maine.edu> wrote:
> [...]
>
> yum upgrade (not update) can to some extent be used to upgrade between
> some versions of Fedora Core, but it's quirky and complicated. Not
> really recommended, I've done the easier FC2 to FC3 upgrade that way
> but not FC3 to FC4 which is apparently quite a bit quirkier.
>
> Fedora Legacy will release new kernels for FC3, but that's likely to
> only be security related fixes as compared to the last FC3 kernel.
> Also, I haven't tested this but a FC4 or even FC5t2 kernel plus a few
> other RPMs (kernel-utils+?) *MAY* work (I've seen FC2 kernels on FC3
> machines *and* vice-versa, not sure if anyone tried it with FC4+
> kernels on FC3).
>
> But really, you would probably be best of with either upgrading (to
> FC4 or something else) or respinning a FC3 kernel with a newer MPT
> driver (rebuilding from SRPM with new driver), but the last
> alternative requires a bit of know-how.
>
> http://www.fedoraproject.org/wiki/YumUpgradeFaq
???????? And the Linux community are trying to persuade everyone that
Linux is easier to install, manage, and use, than Windows?
The mind truly boggles.
Odie
--
Retrodata
www.retrodata.co.uk
Globally Local Data Recovery Experts
| |
| Folkert Rienstra 2006-02-09, 8:46 pm |
| "Dan Adams" <akwete@hotmail.com> wrote in message news:1139520602.610828.119990@g47g2000cwa.googlegroups.com
> Thanks for the eval.
> Gateway recommends I use separate U160 or U320 SCSI cards.
So avoid Gateway, obviously.
The only bottleneck you may possibly experience is your U320 array
connected to your U160 controller and that rather depends on what type
and/or what number of arrays you have there and the capability of the
external raid controller (speed wise) and the SATA drive specifications.
And none of that has anything to do with the tape.
> My backup server OS and Veritas BE 10d (EVAL) currently
> sits on mirrored 80GB SATA I hard drives.
|
|
|
|
|