LTO-3 tapes - supplying data fast enough

  • Thread starter Thread starter Rob Nicholson
  • Start date Start date
R

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.
 
Rob said:
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.
Click to expand...

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.
 
Rob said:
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.
Click to expand...

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
 
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.
Click to expand...

Ohh, now that's clever :-)

Cheers, Rob.
 
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.
Click to expand...

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.
 
Rob said:
The two servers are new high-power Dell servers with latest SCSI drivers and
interfaces so I think we'll probably be okay.
Click to expand...

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
 
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).
Click to expand...

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

Rob.
 
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.
Click to expand...


Hello, Rob:

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


Cordially,
John Turco <[email protected]>
 
Back
Top