All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.