At Tue, 14 Sep 2010 12:13:53 -0400 CentOS mailing list centos@centos.org wrote:
On Tue, Sep 14, 2010 at 9:39 AM, Scott Robbins scottro@nyc.rr.com wrote:
On Tue, Sep 14, 2010 at 09:03:13AM -0400, Robert Heller wrote:
At Tue, 14 Sep 2010 13:12:46 +0100 CentOS mailing list centos@centos.org wrote:
Is there a document with instructions for this? I've had smartd warnings that a hard disk in my server is sick, so I am installing a new drive (in addition to the old).
Here is an article I wrote about doing this:
http://www.deepsoft.com/2009/01/how-to-transfer-a-linux-system-from-one-disk...
As someone who came from FreeBSD, dump restore was always considered best there. Hoewver, I've heard (though not deeply investigated), that due to various things in the Linux kernel, dump restore isn't the best approach for Linux, and there will be metadata loss. DISCLAIMER--this isn't something I've really looked into, however last time I was going to do it, I saw enoughw warnings about it to make me look for another method. If Robert has been doing it successfully, then, chances are he's right. (Perhaps these changes in the Linux kernel are newer than the CentOS kernel.)
FWIW, I only use dump/restore on unmounted or mounted read-only filesystems
There was the email below (old, I know, but probably the source of the "dump restore isn't the best approach for Linux" thought):
I *suspect* that whatever was going on (metadata corruption) has long since been fixed. I've *never* had any problems with using dump and restore, *even on live Read/Write filesystems while in full multiuser mode*. Generally, I don't do backups of *busy* file systems. Given the number of times I've done this, either the conditions that cause the problems are exceedingly rare or else it is/was only really an issue with bleeding edge kernels (I only ever used RedHat's not partitularly bleeding edge kernels -- eg stock kernels from RH's distros).
From: Linus Torvalds To: Neil Conway 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 vger Dot kernel Dot 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 roulette 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. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos