Justin, Thanks for the offer. Please post, or send me the documentation on
how to.
'preciate it.
Ferg'
-----Original Message-----
From: fedora-list-bounces(a)redhat.com [mailto:fedora-list-bounces@redhat.com]
On Behalf Of Justin W
Sent: Monday, July 02, 2007 9:03 PM
To: For users of Fedora
Subject: Re: RAID gotchas!
Roberto Ragusa wrote:
Jeffrey Ross wrote:
> Roberto Ragusa wrote:
>
>> Dump is considered a bad choice by Linus himself; read this:
>>
>>
http://lwn.net/2001/0503/a/lt-dump.php3
>>
>> (a few years ago, but the words are quite strong)
>>
>> Best regards.
>>
>>
> I've read the arguments here's the rebuttal to the 2001 message:
>
http://dump.sourceforge.net/isdumpdeprecated.html
>
Thank you for this link, very interesting.
Basically thay say that there was a bug in 2.4, now fixed.
They claim three advantages when using dump, but they are rather weak,
I have to say (IMHO).
1) dump unmounted filesystem; but why not just mount it read-only and
use a normal file copy tool? they talk about trying to dump corrupted
unmountable filesystems for rescue purposes, but it looks like a very
stretched motivation, especially when trying to prove that dump is
preferable for normal uncorrupted filesystems.
For less informed readers (or curious readers later finding this thread in a
search of the archives), copying unmountable file systems is already
possible: use dd. You can even take the image of a partition (or a whole
drive) and mount the file system located within it using loop devices
(though the whole drive takes more work aligning the mount to the beginning
of a "partition", and thus, an understandable file system).
[snip]
6) dump can not create accessible backups; I want to be able to use
the files in my backup (find, grep,...), not just restore them.
Using the method I describe above, this is possible.
Finally they say that by using snapshots you can have a stable
read-only image of the filesystem to run dump on. But the same is true
for other tools too.
I just backed up my server using a combination of an LVM snapshot, dd to
copy the partition initially, and now it'll be maintained with nightly
rsyncs to a mounted image file. (Note: If anyone is interested, I can post
some documentation describing how I set up the backup and the script which
will keep my backup up-to-date).
Certainly there is not a right way and wrong way to do things.
If dump gives you reliable backups and you are used to it, it's a
valid choice.
File copy tools will remain my preferred choice.
In this exact moment I have two backups running across the LAN; they
involve a couple of millions of files; one is using tar|tar, another
rsync. (I'm not kidding) All filesystems are reiser here, so I
couldn't try dump if I wanted, but even if I could, I think I would
not. :-)
You gave me an opportunity to understand dump better.
For what I've seen, it should be called e2dump and should be part of
ext2progs, together with e2fsck, e2label, resize2fs and dumpe2fs
(which is something else).
It is a filesystem tool, not a file tool.
Linux is not always ext2/ext3.
Maybe the summary of all this is just that dump is a tool to backup a
filesystem, but I want to backup the files.
Best regards.
Justin W
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-list