At Tue, 14 Sep 2010 12:13:53 -0400 CentOS mailing list <centos at centos.org> wrote: > > On Tue, Sep 14, 2010 at 9:39 AM, Scott Robbins <scottro at 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 at 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-to-another/ > > > > 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos > > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller at deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/