From: Thomas Fjellstrom <tfjellstrom@shaw.ca>
To: linux-raid@vger.kernel.org
Subject: Re: Is My Data DESTROYED?!
Date: Sat, 24 Oct 2009 23:26:07 -0600 [thread overview]
Message-ID: <200910242326.07365.tfjellstrom@shaw.ca> (raw)
In-Reply-To: <20091025023059520.QFQH17264@cdptpa-omta04.mail.rr.com>
On Sat October 24 2009, Leslie Rhorer wrote:
> > On Sat, Oct 24, 2009 at 6:52 PM, Leslie Rhorer <lrhorer@satx.rr.com>
> >
> > wrote:
> > >> I'm going to go on a limb here and say for anyone (with data they want
> > >> to preserve), no matter what, backups make sense and are cost
> > >> effective. I'm going to be crazy and say that there's no reason that
> > >> someone who thinks they can afford a 8TB disk array and dual SLI video
> > >> cards, etc, etc, can't also consider some sort of disk or tape backup.
> > >
> > > I agree with the disk backup, but not the tape.
> > >
> > >> Cumbersome? Can be. But having worked with datasets and filesystems
> > >
> > > Cumberesome, slow, kludgy, and expensive.
> >
> > Well, like anything else, having a system helps. And by system I mean
> > a library, barcodes on all tapes, and a good tape storage system. Yes,
> > it involves Humans.
>
> Well, that wasn't quite my point, but it is another aspect of the
> issue.
>
> > >> that run into the hundreds of terabytes, and having backed them up to
> > >> tape, it makes sense. If you have something on the order of tens of
> > >> disks, sure, go ahead, take that next step and back them up somewhere
> > >> else to another set of disks. If you have more disks, seriously
> > >> consider tape--in terms of capacity and power consumption (and data
> > >> integrity), tape wins.
> > >
> > > Power consumption, yes. Capacity is a somewhat more complex
> > > problem, with a number of variables. For speed, tapes lose
> >
> > disastrously.
> >
> > > For cost, hard drives win unless the array is very large. For
> >
> > reliability
> >
> > > and availability, drives win hands down. I've had quite a bit of data
> >
> > lost
> >
> > > with bad tape sets, and the most persistent problems on my systems
> > > which
> >
> > do
> >
> > > use tapes involve the tape drives, even sans data loss. Once someone
> >
> > wiped
> >
> > > out a directory which someone up in corporate was backing up to tape.
> >
> > It
> >
> > > took 3 days to recover the directory, no doubt because no one could
> > > find
> >
> > the
> >
> > > tape.
> >
> > I'm not so sure about the speed--you can stream 100MB/sec to a single
> > tape drive, and if you have multiple in a library, it just scales
> > horizontally.
>
> First of all, that assumes the tape is loaded and ready. It can
> take hours or even days to retrieve a tape and load it. Secondly, while
> the tape can stream 100MB/sec, it isn't random access. Finding a 200 byte
> file in the middle of a 1T tape backup is going to take a while. Getting
> it from an online backup server takes perhaps 10ms after the admin
> finishes typing the copy command.
Wouldn't you use some 'tar' like format on the tape so there's a file index
you can search without having to scan the entire tape? Then you can just
"ffwd" (seek) to the position. _should_ be lots faster than reading all of the
data from the beginning to the files location trying to find it. Or maybe
there's something I'm missing about tapes?
> > But, where I was working, we were also duplicating tape sets for
> > offsite, which means there was two copies per backup set.
> >
> > Is this expensive? You betcha! But...you know. The bad old days of DDS
> > are also gone, so there's some rejoicing there.
>
> They may be for you. I have to manage over 300 of the beasts on the
> same number of hosts. What's worse, not only are the backups themselves
> often incompatible, the drives often can't even use the same tapes. I have
> to see to it a half dozen different tape types get stocked in 75 different
> cities. Then I have to try to make sure the gopher in every city remembers
> to replace the tape.
:(
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Thomas Fjellstrom
tfjellstrom@shaw.ca
next prev parent reply other threads:[~2009-10-25 5:26 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <70ed7c3e0910221840o795a61b9u77774725386868e2@mail.gmail.com>
2009-10-23 2:04 ` Is My Data DESTROYED?! adfas asd
2009-10-23 20:32 ` Billy Crook
2009-10-23 20:46 ` Christian Pernegger
2009-10-23 20:57 ` Mattias Wadenstein
2009-10-23 21:44 ` Billy Crook
2009-10-23 22:00 ` adfas asd
2009-10-23 22:46 ` Billy Crook
2009-10-23 22:49 ` adfas asd
2009-10-23 23:54 ` berk walker
2009-10-24 0:13 ` berk walker
2009-10-25 0:22 ` Leslie Rhorer
2009-10-23 21:55 ` adfas asd
2009-10-23 22:36 ` Guy Watkins
2009-10-23 23:05 ` Bill Davidsen
2009-10-23 23:20 ` adfas asd
2009-10-23 23:20 ` NeilBrown
2009-10-23 23:25 ` Ben DJ
2009-10-24 3:39 ` Bill Davidsen
2009-10-24 12:01 ` adfas asd
2009-10-24 14:59 ` Christopher Chen
2009-10-25 1:52 ` Leslie Rhorer
2009-10-25 2:03 ` Christopher Chen
2009-10-25 2:30 ` Leslie Rhorer
2009-10-25 5:26 ` Thomas Fjellstrom [this message]
2009-10-25 5:41 ` Guy Watkins
2009-10-25 6:21 ` Eyal Lebedinsky
2009-10-25 22:55 ` Guy Watkins
2009-10-26 1:36 ` Leslie Rhorer
2009-10-26 2:40 ` Guy Watkins
2009-10-26 7:32 ` Eyal Lebedinsky
2009-10-26 18:14 ` Thomas Fjellstrom
2009-10-26 23:14 ` John Robinson
2009-10-27 2:50 ` Leslie Rhorer
2009-10-27 3:15 ` Thomas Fjellstrom
2009-10-27 14:37 ` adfas asd
2009-11-02 22:53 ` NiftyFedora Mitch
2009-10-26 23:21 ` Leslie Rhorer
2009-10-25 6:15 ` Christopher Chen
2009-10-25 13:06 ` Leslie Rhorer
2009-10-25 12:46 ` adfas asd
2009-10-25 13:38 ` Gabor Gombas
2009-10-25 15:47 ` adfas asd
2009-10-25 18:12 ` Christopher Chen
2009-10-25 18:33 ` Gabor Gombas
2009-10-25 14:16 ` Leslie Rhorer
2009-10-25 16:06 ` adfas asd
2009-10-25 16:58 ` Thomas Fjellstrom
2009-10-26 0:55 ` Doug Ledford
2009-10-26 12:22 ` adfas asd
2009-10-25 16:49 ` Thomas Fjellstrom
2009-10-25 1:28 ` Leslie Rhorer
2009-10-23 23:49 ` berk walker
2009-10-25 1:36 ` Leslie Rhorer
2009-10-25 1:50 ` Christopher Chen
2009-10-25 2:20 ` Leslie Rhorer
2009-10-27 21:08 adfas asd
2009-10-27 21:11 ` John Robinson
2009-10-27 21:22 ` adfas asd
2009-10-27 21:31 ` Christian Pernegger
2009-10-27 21:56 ` adfas asd
2009-10-28 3:14 ` Guy Watkins
[not found] <1256656849.15137.126.camel@poledra.romunt.nl>
2009-10-27 20:31 ` adfas asd
2009-10-27 20:39 ` Ryan Wagoner
2009-10-27 21:00 ` Christian Pernegger
2009-10-28 0:39 ` Leslie Rhorer
2009-10-28 2:57 ` Rudy Zijlstra
-- strict thread matches above, loose matches on Subject: below --
2009-10-26 12:56 adfas asd
2009-10-26 18:21 ` Thomas Fjellstrom
2009-10-27 14:32 ` adfas asd
2009-10-27 14:36 ` Gabor Gombas
2009-10-27 14:40 ` adfas asd
2009-10-27 18:22 ` Ryan Wagoner
2009-10-28 9:50 ` Lars Schimmer
2009-10-27 20:45 ` Bill Davidsen
2009-10-27 20:53 ` adfas asd
2009-10-27 21:00 ` Ryan Wagoner
2009-10-27 21:05 ` adfas asd
[not found] <70ed7c3e0910221912h70b33ca0m3df9eedd9a54c459@mail.gmail.com>
2009-10-23 2:18 ` adfas asd
2009-10-23 2:43 ` Majed B.
2009-10-23 2:59 ` adfas asd
2009-10-23 3:14 ` Majed B.
2009-10-23 19:24 ` adfas asd
2009-10-23 23:07 ` NeilBrown
2009-10-23 23:25 ` adfas asd
2009-10-23 23:39 ` Majed B.
2009-10-24 4:37 ` NeilBrown
2009-10-25 0:54 ` Leslie Rhorer
2009-10-23 22:37 ` Bill Davidsen
2009-10-23 22:41 ` adfas asd
2009-10-24 9:02 ` Luca Berra
2009-10-23 2:30 ` adfas asd
2009-10-23 22:28 ` Bill Davidsen
2009-10-26 15:38 ` Darius S. Naqvi
2009-10-23 1:36 adfas asd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200910242326.07365.tfjellstrom@shaw.ca \
--to=tfjellstrom@shaw.ca \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).