LTO-3 Autoloader Recommendation

[Dan Adams]

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]

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]

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.

 

[HVB]

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]

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]

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]

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.

 

[HVB]

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 Nicholson]

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.

 

[Rob Turk]

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 Turk]

Hmm, might be better sticking with LTO-2. Can an LTO-2 drive write to
LTO-1 tapes?

Thanks, Rob.

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?

Rob

 

[Dan Adams]

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]

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]

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]

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]

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.

 

[Steve Cousins]

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]

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

 

[Steve Cousins]

Hi Joshua,

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]

That's "odd" -- FC3 should be pretty close to centos-4 kernel wise. What's
the MPT driver version? Mine reports 3.02.18.

[...]
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