What's so great about tape?

Eric Lee Green writes:
In article , Malcolm Weir ruminated:
Tape's failure modes tend to be less catastrophic than disk's. E.g.

That is not my experience. In general, when a section of tape becomes
unreadable, every bit of tape after that section is no longer
accessible.

I've never seen a drive which behaved that way. Are you sure it's not
the driver on your system refusing to skip past the bad block?

-- Anton

In article , Boll Weevil ruminated:
First of all, nobody makes a robotic hard drive changer. We go through
about 500 tapes a day using 20 to 40 tape drives concurrently all
managed by automated robotic tape libraries. I can't imagine to trying

Let me get this straight. You back up 50 terabytes per day? Or are you
using older/smaller capacity technology, let's say DLT1, and backing up,
say, 10 terabytes per day?

10 terabytes per day = 3650 terabytes per year. You're saying that your
installation is pushing 3650 terabytes of data per year through your
systems? Or are you saying that, due to the inefficiencies of current
tape backup solutions (which operate upon a whole-file basis rather
than on a differential block basis), you need 3650 terabytes of tape storage
to store, say, 365 terabytes of changed data?

--
Eric Lee Green
Linux/Unix Software Engineer seeks employment
see http://badtux.org for resume


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

On 3 Sep 2003 14:55:07 -0500, Eric Lee Green wrote:

In article , Boll Weevil ruminated:
First of all, nobody makes a robotic hard drive changer. We go through
about 500 tapes a day using 20 to 40 tape drives concurrently all
managed by automated robotic tape libraries. I can't imagine to trying

Let me get this straight. You back up 50 terabytes per day? Or are you
using older/smaller capacity technology, let's say DLT1, and backing up,
say, 10 terabytes per day?

10 terabytes per day = 3650 terabytes per year. You're saying that your
installation is pushing 3650 terabytes of data per year through your
systems? Or are you saying that, due to the inefficiencies of current
tape backup solutions (which operate upon a whole-file basis rather
than on a differential block basis), you need 3650 terabytes of tape storage
to store, say, 365 terabytes of changed data?


See if you can add this up. To start, we have about 200 Sun servers and
about 1200 NT servers. About 100 Sun servers and about 100 NT servers
are on the SAN and share the following EMC and Hitachi subsystems:

7 EMC 8830 frames with about 13 TB raid 10 useable, each
1 Hitachi 9980V frame with about 45 TB raid 5 useable

There are a whole lot of direct attached SCSI disk arrays and internal
disks in each of the 1200 NT servers. I can't even start as to how much
storage these servers account for. These all get backed up.

We use STK 9840A and 9840B drives. These drives can do about 20GB per
tape at about 20 to 40 mb per second.

500 tapes??? Well, I think I've mistaken or I kicked out an old number.
We probably use twice that. Most of the SAN disk is used for Oracle and
SAS databases. Oh yea, we also have about 200 TB of mainframe but IBM
manages that. So, do some math and figure out how many tapes we use on
a full backup. You can save me some time.

"Boll Weevil" wrote in message
...
On 3 Sep 2003 14:55:07 -0500, Eric Lee Green wrote:


See if you can add this up. To start, we have about 200 Sun servers and
about 1200 NT servers. About 100 Sun servers and about 100 NT servers
are on the SAN and share the following EMC and Hitachi subsystems:

7 EMC 8830 frames with about 13 TB raid 10 useable, each
1 Hitachi 9980V frame with about 45 TB raid 5 useable

There are a whole lot of direct attached SCSI disk arrays and internal
disks in each of the 1200 NT servers. I can't even start as to how much
storage these servers account for. These all get backed up.

We use STK 9840A and 9840B drives. These drives can do about 20GB per
tape at about 20 to 40 mb per second.

500 tapes??? Well, I think I've mistaken or I kicked out an old number.
We probably use twice that. Most of the SAN disk is used for Oracle and
SAS databases. Oh yea, we also have about 200 TB of mainframe but IBM
manages that. So, do some math and figure out how many tapes we use on
a full backup. You can save me some time.

So you work for Boeing, right? One of the largest Powderhorn sites I know
of...

Rob

In article , Boll Weevil wrote:

See if you can add this up. To start, we have about 200 Sun servers and
about 1200 NT servers. About 100 Sun servers and about 100 NT servers
are on the SAN and share the following EMC and Hitachi subsystems:

7 EMC 8830 frames with about 13 TB raid 10 useable, each
1 Hitachi 9980V frame with about 45 TB raid 5 useable

There are a whole lot of direct attached SCSI disk arrays and internal
disks in each of the 1200 NT servers. I can't even start as to how much
storage these servers account for. These all get backed up.

Rough calculations shows that using hardware compression for a LTO-2 setup,
one could do all of the above in about 2 (or so) fully decked out IBM 3584
LTO libraries (just as an example), assuming an average size of directly
attached storage for each of the NT servers being 1 TB. A decked-out LTO-2
library with 6 frames should yield in the neighborhood of about 720 TB of
tape storage capabilities.

If 1200 servers * 1 TB = 1200 TB; that'd be one decked out LTO library and
a second library with about 240 TB of available tape space. For the other
stuff... 13 * 7 = 91 plus 45 TB = 136 TB. So you'd still have 104 TB of
free data space, and capable of doing a single full backup for everything
with two libraries and about 3500 tapes.

This assumes 400 GB (hw compressed) LTO-2 tapes; if you are using 20 GB
tapes in uncompressed mode, then your tape requirements goes up by 20 times
3500 for at least 70,000 tapes. Also, if the average per-NT server for
storage is other than 1 TB, that would also influence number of tapes
required, as well.

-Dan

"Dan Foster" wrote in message
...
In article , Boll Weevil
wrote:

See if you can add this up. To start, we have about 200 Sun servers and
about 1200 NT servers. About 100 Sun servers and about 100 NT servers
are on the SAN and share the following EMC and Hitachi subsystems:

7 EMC 8830 frames with about 13 TB raid 10 useable, each
1 Hitachi 9980V frame with about 45 TB raid 5 useable

There are a whole lot of direct attached SCSI disk arrays and internal
disks in each of the 1200 NT servers. I can't even start as to how much
storage these servers account for. These all get backed up.

Rough calculations shows that using hardware compression for a LTO-2
setup,
one could do all of the above in about 2 (or so) fully decked out IBM 3584
LTO libraries (just as an example), assuming an average size of directly
attached storage for each of the NT servers being 1 TB. A decked-out LTO-2
library with 6 frames should yield in the neighborhood of about 720 TB of
tape storage capabilities.

If 1200 servers * 1 TB = 1200 TB; that'd be one decked out LTO library and
a second library with about 240 TB of available tape space. For the other
stuff... 13 * 7 = 91 plus 45 TB = 136 TB. So you'd still have 104 TB of
free data space, and capable of doing a single full backup for everything
with two libraries and about 3500 tapes.

This assumes 400 GB (hw compressed) LTO-2 tapes; if you are using 20 GB
tapes in uncompressed mode, then your tape requirements goes up by 20
times
3500 for at least 70,000 tapes. Also, if the average per-NT server for
storage is other than 1 TB, that would also influence number of tapes
required, as well.

-Dan

Capacity-wise you're probably correct, I didn't do the math. However, many
of these types of setups have a different limiting factor, being the number
of changes per hour that a tape robot can handle or the number of drives
available. You'd need enough drives to keep the robot busy and a fast enough
robot to keep the drives going. This all depends on the access pattern. If
such a system is used for record based archives then you'll usually need a
lot more exchanges per hour than in a pure backup environment. The fastest
Powderhorns do about 450 exchanges per hour. Just inserting a separate
cartridge for each of the 1400 systems takes 3 hours, assuming one robot and
unlimited drives. Cascading robots help bring this to a lower number.

Also, with this many systems, even if you are doing backup only, you will
run into the issue if the number of parallel tasks you can run. You need a
large number of drives in order to give each system a chance to access one,
or you need to revert to backup software that can combine (multiplex)
several data streams into one.

To make a long story short, capacity is only one factor of many when dealing
with a setup as large as this.

Rob

"Anton Rang" wrote in message
...
"Rob Turk" writes:
"Marcin Dobrucki" wrote in message
...
August 2003 issue of SysAdmin Magazine (www.sysadminmag.com) has an
article just for you. "Tapes: A Modern History, Trends", by Henry
Newman, p. 43

/Marcin

This article is so full of semi-technical nonsense that it ain't funny
anymore. I agree with the overall conclusion (tape is here to stay) but
this
guy has definitely not been doing his homework on helical scan
recording.
This stuff is directly copied out of 10-year old Quantum DLT sales
pitches.
Yuck...

I'm curious, what do you disagree with in the article? I don't know
enough about helical scan vs. linear to make a strong argument one
way or the other, but I haven't run into anyone with several hundreds
of terabytes stored on helical scan tapes yet.

Henry's company (www.instrumental.com) has set up a fair number of
multi-petabyte tape sites, so I tend to give them some trust.


The section that describes the 'differences' between linear and helical scan
is totally out of wack. The claim that 'a small defect on tape would create
data corruption in a full buffer' is so blatantly wrong, it's just sad this
shows up in such an article. The stuff about tape passes, tape longevity,
mechanical stability et all, this is the stuff that linear and helical
vendors would throw at each other 15 years ago. None of it is based on
facts, especially with most of today's implementations

In my opinion, helical scan and linear technology are just two different
ways of accomplishing the same goal; create sufficient head-to-tape speed to
get the desired transfer rate and control it well enough to allow the
desired data density. Neither is better per se, they can both be implemented
right and wrong.

Rob

(Peter da Silva) writes:
[...]
With Amanda it's always one tape per drive per night, so there's no
other messing around necessary.

Bacula supposedly allows for multi-volume backups:

http://www.bacula.org/

YMMV.

--
David Magda dmagda at ee.ryerson.ca, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

In article ,
David Magda wrote:
(Peter da Silva) writes:
[...]
With Amanda it's always one tape per drive per night, so there's no
other messing around necessary.

Bacula supposedly allows for multi-volume backups:

Amanda does too. In the situation we're discussing, being able to do just
one tape a night is an *advantage*.

YMMV.

I should say so, why would I want negative milage?

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

(Peter da Silva) writes:

Amanda does too.

Really? Last time I looked it didn't. I'll have to update my knowledge.

In the situation we're discussing, being able to do just one tape a
night is an *advantage*.
[...]

ACK. Misunderstood what was being said.

--
David Magda dmagda at ee.ryerson.ca, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI