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). I was thinking of copying the old root partition with sudo cp -a -P /* /mnt/hd (after mounting the prospective new root partition). Then I'd have to modify the new /etc/fstab . Is that a sensible approach? -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Timothy Murphy wrote:> I was thinking of copying the old root partition with > sudo cp -a -P /* /mnt/hd > (after mounting the prospective new root partition). > Then I'd have to modify the new /etc/fstab .Hi I think the command rsync is a better approach for this task. It has much more features, for example, you can exclude certain files. Regards mg.
On 09/14/10 5:12 AM, Timothy Murphy 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). > > I was thinking of copying the old root partition with > sudo cp -a -P /* /mnt/hd > (after mounting the prospective new root partition). > Then I'd have to modify the new /etc/fstab . > > Is that a sensible approach? >I generally use dump ... | restore ... to clone a complete e2fs/e3fs volume. it copies everything exactly on an inode by inode basis.
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). > > I was thinking of copying the old root partition with > sudo cp -a -P /* /mnt/hd > (after mounting the prospective new root partition). > Then I'd have to modify the new /etc/fstab . > > Is that a sensible approach?Probably not. Do you have a separate /boot file system? The default CentOS installer generally creates a separate /boot file system and puts everything else on a LVM volume group (and carves two logical volumes from that: one for swap and one for /). 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/ -- 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/
On Tue, 2010-09-14 at 13:12 +0100, Timothy Murphy 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). > > I was thinking of copying the old root partition with > sudo cp -a -P /* /mnt/hd > (after mounting the prospective new root partition). > Then I'd have to modify the new /etc/fstab . > > Is that a sensible approach? >If your partitions are LVM then you could just migrate them from drive to the other, exceptions of course would be /boot, non LVM swap. You would then also have to install grub on the new disk.
On Tue, Sep 14, 2010 at 8:12 AM, Timothy Murphy <gayleard at eircom.net> 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). > > I was thinking of copying the old root partition with > ? ? ? ?sudo cp -a -P /* /mnt/hd > (after mounting the prospective new root partition). > Then I'd have to modify the new /etc/fstab . > > Is that a sensible approach? >I prefer to do this by cloning LVMs. Add the second drive to the volume group then separately mirror each LV to the new drive. Once done, remove the copy from the original disk.
What about doing all with dd ... If you have the second disk installed in the same machine you can do "dd if=/dev/sda of=/dev/sdb" ort you can use clonezilla is a live cd . Gabe On 9/14/10 8:12 AM, "Timothy Murphy" <gayleard at eircom.net> 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). > > I was thinking of copying the old root partition with > sudo cp -a -P /* /mnt/hd > (after mounting the prospective new root partition). > Then I'd have to modify the new /etc/fstab . > > Is that a sensible approach?
On Tue, Sep 14, 2010, Timothy Murphy 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). > >I was thinking of copying the old root partition with > sudo cp -a -P /* /mnt/hd >(after mounting the prospective new root partition). >Then I'd have to modify the new /etc/fstab . > >Is that a sensible approach?IHMO, the most sensible approach is to do a fresh install on a new HD. After the install is complete, install and mount the old HD read-only to allow you to copy things over. I just went through this process about 10 days ago when a fan went Tango Uniform on our mail e-mail/file server which had been up 1,390 days before the crash. The old system had two partitions, one for ``/'', the other on ``/home'' making it easy to copy the old ``/home'' to the new one using any of a number of tools. I prefer ``cd /oldhome; find . | cpio -pdum /home'' as it takes care of everything (of course it's important to add the appropriate users and groups before doing this). Using ``rsync'' would also work, but given that the initial copy is not likely to have anything to update, I prefer ``cpio''. Things get a bit more complicated when the old and new systems are different distributions as user/group ids may differ. In my recent case, the old machine was running SuSE Linux Enterprise 10 while the new one is CentOS 5.current. This required a bit of ``chown -R username: ~username'' work after the ``/home'' copy to get things the way CentOS prefers. In this case transferring user accounts was complicated a bit as SuSE used different encryption in the ``/etc/shadow'' file so simply copying the relevant part of the files was not sufficient, but the passwords had to be reset so CentOS recognized them. In our case, we didn't have to worry about things that were installed under /usr/bin as we use the OpenPKG portable package management system for pretty much everything including vendor systems like openssh and postfix, and they are installed under the ``/home'' file system. Installing non-distribution software under /usr/local with that either in its own file system or symlinked to a non-root file system avoids having to sort out what belongs to the distribution, and what has been added from other sources. With most open source software this simply requires using a simple option when building ``./configure --prefix=/usr/local ...'' This was standard practice with open source software long before Linux came around, and is probably my main gripe with Linux standards (the other is changing APIs without considering how the change breaks installed systems). Bill -- INTERNET: bill at celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186 Skype: jwccsllc (206) 855-5792 Just because you do not take an interest in politics doesn't mean politics won't take an interest in you. -- Pericles