mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "John Stoffel" <john@stoffel.org>
To: Gene Heskett <gene.heskett@gmail.com>
Cc: linux-kernel@vger.kernel.org, "John Stoffel" <john@stoffel.org>,
	Jeff Garzik <jeff@garzik.org>
Subject: Re: I give up
Date: Mon, 9 Apr 2007 16:08:33 -0400	[thread overview]
Message-ID: <17946.40257.794493.294518@smtp.charter.net> (raw)
In-Reply-To: <200704091549.51805.gene.heskett@gmail.com>

>>>>> "Gene" == Gene Heskett <gene.heskett@gmail.com> writes:

Gene> I wouldn't touch dump/restore with a 50 foot pole, particularly
Gene> since I have serious doubts about it viability in the LVM
Gene> environment.

Why?  It's can't be any worse than Tar with it's silly assumption
about the static device numbers, which are shown in their own docs to
be an invalid assumption over NFS, so why enforce them locally?  

On Linux, dump/restore are open source, so it's not like you can't get
your data back, you know the format it's written in.  Any backup
software has problems with filesystems which change underneath them as
they run, esp for incremental backups.  

The only sure strategy is to do your dumps in single user mode, with
only one process touching the filesystem during the backup window.
This obviously won't fly in a 24x7 environment, so people take their
calculated chances and run backups with the system live.  

Some people are working to be able to take snapshots of live
filesystems, then backups the snapshots, but that's still a work in
progress right now.  I'd personally love to do that, but not quite
yet. 

Gene> For those of you with big tapes that can hold a complete dump of
Gene> every partition (and partitions is the only way dump works in
Gene> case some have forgotten), go ahead and use dump/restore.  Tar
Gene> quite simply, allows one to break his backup files down into
Gene> small enough pieces that a tape drive that's only 20% of the
Gene> system drives size is totally usable. 

So does Bacula.  *grin*  It will happily span backups across multiple
volumes (read tapes).  

The problem with Amanda is that you have to *manually* break down your
filesystem into chunks small enough to fit on a single volume.  I
don't have to think about it with Bacula.

Gene> I ran dds2 tapes for a long time, and it wasn't at all unusual
Gene> to have amanda fill those to the 95% or better mark every night
Gene> for a week running, without ever hitting EOT.

The problem with Amanda for the longest time was that if you had a
full backup which spanned more than one tape, you were screwed.  

>> This tar borkness is pretty annoying, since Amanda (from the docs
>> page) only keeps indexes in terms of host/filesystem/path/date,
>> nothing about the major/minor (device) numbers.
>> 
>> It just re-inforces my desire to never use Amanda again.

Gene> Your call, that's what this linux thing is all about.  But do I
Gene> not recall your name from the amanda lists at some point in the
Gene> last 8+ years?

Probably, but it's been a long time since I was active in Amanda,
probably back in my WPI days (john@wpi.edu) or my Fluent days
(jfs@fluent.com), but I honestly don't remember.

As I said, the big problem with Amanda for the longest time (and which
has now been worked around I understand) was a single backup which had
to span multiple volumes.  

Bacula does this all for you, and works better than Amanda IMHO.  It
also allows you to stage to disk and then to DVD or other types of
volumes.  

And it doesn't have amanda's inistence of writing to a new piece of
media each day either.  Which I admit is a tradeoff, but for a home
system, not having to swap tapes daily is a big help, and saves me
money.  DLTIV tapes aren't cheap, even on ebay...

Heck, if you don't trust Dump, find tar to be broken, what about cpio?
*grin*

John

  reply	other threads:[~2007-04-09 20:08 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-09 14:07 Gene Heskett
2007-04-09 14:47 ` Jeff Garzik
2007-04-09 15:37   ` Gene Heskett
2007-04-09 16:49     ` Jan Engelhardt
2007-04-09 17:03       ` H. Peter Anvin
2007-04-09 18:36         ` Gene Heskett
2007-04-09 19:38         ` Gene Heskett
2007-04-09 21:35           ` Jan Engelhardt
2007-04-09 22:22             ` Dave Dillow
2007-04-10  1:27               ` Dave Jones
2007-04-10  1:40                 ` Dave Dillow
2007-04-10  2:01                   ` Dave Jones
2007-04-10  7:12                   ` Olaf Hering
2007-04-10  7:51                     ` Gene Heskett
2007-04-10  8:19                       ` Jeff Garzik
2007-04-10 16:08                       ` Olaf Hering
2007-04-10 17:29                         ` David Lang
2007-04-10 16:14                       ` Jan Engelhardt
2007-04-11  3:54                         ` Gene Heskett
2007-04-11 15:39                           ` Jan Engelhardt
2007-04-11 15:51                             ` John Stoffel
2007-04-11 19:29                               ` Gene Heskett
2007-04-11 20:27                                 ` John Stoffel
2007-04-11 21:16                                   ` Gene Heskett
2007-04-11 21:26                                     ` John Stoffel
2007-04-11 19:27                             ` Gene Heskett
2007-04-10  7:53                     ` Gene Heskett
2007-04-10 12:24                       ` John Anthony Kazos Jr.
2007-04-10 20:45                         ` Gene Heskett
2007-04-10 19:05                       ` Phillip Susi
2007-04-11  4:01                         ` Gene Heskett
2007-04-11 14:46                           ` Phillip Susi
2007-04-11 15:07                             ` Gene Heskett
2007-04-11 15:12                             ` John Anthony Kazos Jr.
2007-04-11 16:43                               ` Krzysztof Halasa
2007-04-11 17:03                                 ` Jan Engelhardt
2007-04-10  3:47                 ` Gene Heskett
2007-04-10  3:41             ` Gene Heskett
2007-04-09 17:11     ` John Stoffel
2007-04-09 19:49       ` Gene Heskett
2007-04-09 20:08         ` John Stoffel [this message]
2007-04-09 20:11           ` Jeff Garzik
2007-04-09 20:08         ` Jeff Garzik
2007-04-09 20:32           ` Ralf Baechle
2007-04-09 20:44             ` Jeff Garzik
2007-04-09 20:51               ` H. Peter Anvin
2007-04-09 20:33           ` Valdis.Kletnieks
2007-04-09 20:47             ` Jeff Garzik
2007-04-10  3:34           ` Gene Heskett
2007-04-10  3:38             ` John Stoffel
2007-04-10  6:50             ` Jeff Garzik
2007-04-10  6:59             ` CaT
2007-04-10 17:52             ` H. Peter Anvin
2007-04-11  3:57               ` Gene Heskett

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=17946.40257.794493.294518@smtp.charter.net \
    --to=john@stoffel.org \
    --cc=gene.heskett@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®