linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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