LTO-3 tapes - supplying data fast enough

[Rob Nicholson]

Its time to look at upgrading our tape backup system from two LTO-1 external
drives. We're considering a 8 cartridge LTO-3 system which gives us
considerable future proofing as well as reducing the current tape pool by a
factor of 4.

However, last time I read up about LTO-3, there was a concern that backup
speed was drastically reduced if you couldn't supply data to the tape drive
fast enough. We would probably connect the tape loader to the server that
contains the bulk of the data and then drag the remaining data across a
1GBit LAN connection - this would be backing up Exchange and SQL server.

Any comments? Would the drive be continually be back stepping (or whatever
it's called) because the data isn't coming through fast enough? Exchange
backups (brick level) seem particularly slow anyway with Backup Exec.

Thanks, Rob.

 

[Steve Cousins]

Its time to look at upgrading our tape backup system from two LTO-1 external
drives. We're considering a 8 cartridge LTO-3 system which gives us
considerable future proofing as well as reducing the current tape pool by a
factor of 4.

However, last time I read up about LTO-3, there was a concern that backup
speed was drastically reduced if you couldn't supply data to the tape drive
fast enough. We would probably connect the tape loader to the server that
contains the bulk of the data and then drag the remaining data across a
1GBit LAN connection - this would be backing up Exchange and SQL server.

Any comments? Would the drive be continually be back stepping (or whatever
it's called) because the data isn't coming through fast enough? Exchange
backups (brick level) seem particularly slow anyway with Backup Exec.

I don't know about performance of backing up the types of data that you
are talking about but I backup in a Linux environment to a LTO-3 library
(Overland Neo 2000) and I have been able to backup over GbE without much
slow-down. The big question is not necessarily the Gigabit connection
but the data source speed. Is it on a disk system that can supply 80
MB/sec? Our data is on RAID systems that can be read at ~180 MB/sec.

 

[Yousuf Khan]

Its time to look at upgrading our tape backup system from two LTO-1 external
drives. We're considering a 8 cartridge LTO-3 system which gives us
considerable future proofing as well as reducing the current tape pool by a
factor of 4.

However, last time I read up about LTO-3, there was a concern that backup
speed was drastically reduced if you couldn't supply data to the tape drive
fast enough. We would probably connect the tape loader to the server that
contains the bulk of the data and then drag the remaining data across a
1GBit LAN connection - this would be backing up Exchange and SQL server.

Any comments? Would the drive be continually be back stepping (or whatever
it's called) because the data isn't coming through fast enough? Exchange
backups (brick level) seem particularly slow anyway with Backup Exec.

I'm not entirely familiar with the capabilities of Backup Exec, but I am
familiar with its sister product from Veritas (now Symantec), Netbackup.
Netbackup has for years allowed you to "multi-stream" backups to the
drives, which means that you can kick off multiple simultaneous backups,
and even if one client is a laggard, the other clients going
simultaneously will simply take up the slack, and complete their own
backups quicker.

There are even more sophisticated tricks that Netbackup can do, if you
have a SAN connected to your machines. And there are some snapshotting
and checkpointing tricks that are available to it that will allow you to
backup snapshot raw image of your Exchange databases quicker than
having to wait for it to get sent over by Exchange itself to deliver it
to you. Also Netbackup has optional Exchange agents that allow it to
hook up directly to the Exchange application and take hot backups.

Yousuf Khan

 

[Rob Nicholson]

I'm not entirely familiar with the capabilities of Backup Exec, but I am

familiar with its sister product from Veritas (now Symantec), Netbackup.
Netbackup has for years allowed you to "multi-stream" backups to the
drives, which means that you can kick off multiple simultaneous backups,
and even if one client is a laggard, the other clients going
simultaneously will simply take up the slack, and complete their own
backups quicker.

Ohh, now that's clever

Cheers, Rob.

 

[Rob Nicholson]

I don't know about performance of backing up the types of data that you

are talking about but I backup in a Linux environment to a LTO-3 library
(Overland Neo 2000) and I have been able to backup over GbE without much
slow-down. The big question is not necessarily the Gigabit connection but
the data source speed. Is it on a disk system that can supply 80 MB/sec?
Our data is on RAID systems that can be read at ~180 MB/sec.

The two servers are new high-power Dell servers with latest SCSI drivers and
interfaces so I think we'll probably be okay.

Cheers, Rob.

 

[Steve Cousins]

The two servers are new high-power Dell servers with latest SCSI drivers and
interfaces so I think we'll probably be okay.

The servers may be high-powered but if they are single disk systems
(non-RAID) you may not be able to get 80MB/sec (uncompressed).
Especially since you say you that the Exchange backups are particularly
slow. It is best to check this out before spending thousands of dollars
on a new tape library.

Good luck,

Steve

 

[Rob Nicholson]

The servers may be high-powered but if they are single disk systems

(non-RAID) you may not be able to get 80MB/sec (uncompressed).

They are RAID systems, RAID-5 I think from memory.

Rob.

 

[John Turco]

Rob Nicholson wrote:

Any comments? Would the drive be continually be back stepping (or whatever
it's called) because the data isn't coming through fast enough? Exchange
backups (brick level) seem particularly slow anyway with Backup Exec.

Thanks, Rob.

Hello, Rob:

It's called "shoe-shining," incidentally.


Cordially,
John Turco <[email protected]>

 

[Rob Nicholson]

It's called "shoe-shining," incidentally.

I knew it had a real name

Thanks, Rob.