RAID gotchas!

[Roberto Ragusa]

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.

2) dump doesn't modify the access time of the files on the
filesystem; well, you can mount read-only or noatime.

3) dump is faster; no benchmark is available and they also doubt
that this is valid today, given great filesystem caches.

They, honestly, list one disadvantage:

1) dump needs knowledge of filesystem internals, so no reiser or
other kind of filesystem; normal file copy works on everything
(including nfs)

But they forget to say that:

1) parsing the internals of the filesystem is a duplication of
the filesystem code; as dump is certainly less tested than the actual
filesystem code, I'd trust the latter for my backups.

2) accessing the device twice at the same time (filesystem+dump)
is a recipe for inconsistency because of the filesystem cache;
they suggest to sync the filesystem and keep low activity
or, better, to unmount or mount read-only before running dump.
They also acknowledge that this is a fundamental issue that
cannot be fixed (paragraph "Is that problem peculiar to Linux?").

3) dump has to be costantly keep aligned to the filesystem
improvements: many things where added to ext3 during its life
(e.g. EA/ACL), and ext4 will be available in a few months.

4) it is true that backup of "live" data is a fundamentally
undefined problem, but with file copy tools I'm definitively sure
that working in a directory while copying another works well;
with dump I'm not so sure.

5) file copy tools can descend in other filesystems (or not,
as they often have the -x option).

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.

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.

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.
-- 
   Roberto Ragusa    mail at robertoragusa.it