From: Andrew Kemmy (kemmya at domain free.net.nz)
Date: Fri 13 Sep 2002 - 23:51:07 IST
I'd just like to add this for those suggesting using dump as a backup :
It seems it's unsupported ;0
(shameless copy n' paste follows)
From: Linus Torvalds <torvalds at domain transmeta.com>
To: Neil Conway <nconway.list at domain ukaea.org.uk>
Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
Cc: Kernel Mailing List <linux-kernel at domain vger.kernel.org>
[ linux-kernel added back as a cc ]
On Fri, 27 Apr 2001, Neil Conway wrote:
>
> I'm surprised that dump is deprecated (by you at least ;-)). What to
> use instead for backups on machines that can't umount disks regularly?
Note that dump simply won't work reliably at all even in 2.4.x: the
buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.
So anybody who depends on "dump" getting backups right is already
playing
russian rulette with their backups. It's not at all guaranteed to get
the
right results - you may end up having stale data in the buffer cache
that
ends up being "backed up".
Dump was a stupid program in the first place. Leave it behind.
> I've always thought "tar" was a bit undesirable (updates atimes or
> ctimes for example).
Right now, the cpio/tar/xxx solutions are definitely the best ones, and
will work on multiple filesystems (another limitation of "dump").
Whatever
problems they have, they are still better than the _guaranteed_(*) data
corruptions of "dump".
However, it may be that in the long run it would be advantageous to have
a
"filesystem maintenance interface" for doing things like backups and
defragmentation..
Linus
(*) Dump may work fine for you a thousand times. But it _will_ fail
under
the right circumstances. And there is nothing you can do about it.
--
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:18:52 GMT