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 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 Tue, 2010-09-14 at 13:16 +0100, Marcelo M. Garcia wrote:
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. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
In offline mode is even better :)
kalinix wrote:
I think the command rsync is a better approach for this task. It has much more features, for example, you can exclude certain files.
In offline mode is even better
How exactly? This is my server, so if I stopped it I would not have access from any other machine.
Marcelo M. Garcia wrote:
I was thinking of copying the old root partition with sudo cp -a -P /* /mnt/hd
I think the command rsync is a better approach for this task. It has much more features, for example, you can exclude certain files.
Thanks for the suggestion. Could you offer a precise command for copying the system from / to /mnt/hd , say? Would one exclude /dev or /proc , for example?
On Tue, 14 Sep 2010, Timothy Murphy wrote:
Could you offer a precise command for copying the system from / to /mnt/hd , say? Would one exclude /dev or /proc , for example?
I've not updated this in years nor for a 2.6 kernel and grub, but the process is basically unchanged: http://www.owlriver.com/tips/rsync-cookbook/
The only changes would be to manually make ./proc, ./sys, and ./dev on the target device, to either run a recovery CD or grub at the command line to get the boot loader right [remember to edit /boot/grub/grub.conf ], and make sure the new /etc/fsttab matches your partitioning scheme
-- Russ herrold
R P Herrold wrote:
On Tue, 14 Sep 2010, Timothy Murphy wrote:
Could you offer a precise command for copying the system from / to /mnt/hd , say? Would one exclude /dev or /proc , for example?
I've not updated this in years nor for a 2.6 kernel and grub, but the process is basically unchanged: http://www.owlriver.com/tips/rsync-cookbook/
The only changes would be to manually make ./proc, ./sys, and ./dev on the target device, to either run a recovery CD or grub at the command line to get the boot loader right [remember to edit /boot/grub/grub.conf ], and make sure the new /etc/fsttab matches your partitioning scheme
Ah, yes. Boot off a DVD or CD or USB key, run linux rescue, then chmod /mnt/sysimage, and then run $ grub-install /dev/<newdrivewithNOpartition> For example, $ grub-install /dev/sda
mark
Timothy Murphy wrote:
Marcelo M. Garcia wrote:
I was thinking of copying the old root partition with sudo cp -a -P /* /mnt/hd
I think the command rsync is a better approach for this task. It has much more features, for example, you can exclude certain files.
Thanks for the suggestion.
Thanks for all the responses.
Further to my query, I'm wondering if one can safely copy partitions (in particular the root partition / ) while the system is running.
The reason that I ask is that I'm slightly afraid the machine will not re-boot into single-user mode with the present OS on the sick disk.
On 9/17/2010 4:52 PM, Timothy Murphy wrote:
I was thinking of copying the old root partition with sudo cp -a -P /* /mnt/hd
I think the command rsync is a better approach for this task. It has much more features, for example, you can exclude certain files.
Thanks for the suggestion.
Thanks for all the responses.
Further to my query, I'm wondering if one can safely copy partitions (in particular the root partition / ) while the system is running.
The reason that I ask is that I'm slightly afraid the machine will not re-boot into single-user mode with the present OS on the sick disk.
Theoretically you shouldn't, but I've never had a problem using rsync to copy running machines - the same should apply to tar/cp/cpio, etc. A dd-style image copy would not be safe with the disk changing, though.
Be sure you exclude /proc, /sys, /dev. And if you have trouble, you can boot the system install disk in rescue mode to recover.
Timothy Murphy wrote:
Timothy Murphy wrote:
Marcelo M. Garcia wrote:
I was thinking of copying the old root partition with sudo cp -a -P /* /mnt/hd
I think the command rsync is a better approach for this task. It has much more features, for example, you can exclude certain files.
Thanks for the suggestion.
Thanks for all the responses.
Further to my query, I'm wondering if one can safely copy partitions (in particular the root partition / ) while the system is running.
The reason that I ask is that I'm slightly afraid the machine will not re-boot into single-user mode with the present OS on the sick disk.
I've done a number of machines - actually, I'll be doing another one Monday. What we do is mkdir /new /boot/new mkdir /old /boot/old rsync -HPaxvz --exclude olddrve-or-machine:/old olddriveormachine:/. /new/. and ditto for /boot - note you need the /. Then zsh load files/modules (I forget the exact line, and it's all at work), but you need this, can't do it, AFAIK, with other shells. cd /boot mv * old/ mv old/new/* . cd / mv * old/ mv old/new/* . mv old/lost+found . sync sync Then edit /etc/sysconfig/network-scripts/ifcfg-eth? as needed, and also /boot/grub/grub.conf, and /boot/grub/device.map, and finally grub-install /dev/sd<whatever, usually a> And reboot.
mark
On 17/09/2010 22:52, Timothy Murphy wrote:
Timothy Murphy wrote:
Marcelo M. Garcia wrote:
I was thinking of copying the old root partition with sudo cp -a -P /* /mnt/hd
I think the command rsync is a better approach for this task. It has much more features, for example, you can exclude certain files.
Thanks for the suggestion.
Thanks for all the responses.
Further to my query, I'm wondering if one can safely copy partitions (in particular the root partition / ) while the system is running.
The reason that I ask is that I'm slightly afraid the machine will not re-boot into single-user mode with the present OS on the sick disk.
telinit 1 doesn't require a reboot and shuts down most things which could update disk while leaving the platters spinning. I understand your fears about it not restarting, I've had problems like that in the past and now I at least try to extract as much info as I can from the sick drive before risking powering it down.
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.
John R Pierce 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 generally use dump ... | restore ... to clone a complete e2fs/e3fs volume. it copies everything exactly on an inode by inode basis.
Thanks for the suggestion. Could you give a concrete command for copying / to say a new filesystem on /mnt/hd ?
(I'm wondering how this approach deals with symbolic links, /dev , /proc , etc
On 9/14/10 7:54 AM, Timothy Murphy wrote:
John R Pierce 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 generally use dump ... | restore ... to clone a complete e2fs/e3fs volume. it copies everything exactly on an inode by inode basis.
Thanks for the suggestion. Could you give a concrete command for copying / to say a new filesystem on /mnt/hd ?
(I'm wondering how this approach deals with symbolic links, /dev , /proc , etc
If you want an exact copy and are going to the same sized drive or larger, one of the handiest ways is to boot a clonezilla-live cd and let it do a disk-disk copy. It knows enough about most file systems to only copy the used disk blocks but otherwise it is an exact image copy.
Otherwise, 'rsync --one-file-system -aH source target' will work and will pick up where it left off it you stop and restart. I usually cd into the source directory and use '.' as the source to avoid having to remember whether the directory name will be created on the target or not. /dev and /proc are mount points best skipped with the --one-file-system option.
Les Mikesell wrote:
On 9/14/10 7:54 AM, Timothy Murphy wrote:
John R Pierce 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 generally use dump ... | restore ... to clone a complete e2fs/e3fs volume. it copies everything exactly on an inode by inode
basis.
Thanks for the suggestion. Could you give a concrete command for copying / to say a new filesystem on /mnt/hd ?
(I'm wondering how this approach deals with symbolic links, /dev , /proc , etc
As someone else said, you do *NOT* copy /dev, /prov, or /sys - those are memory-only virtual filesystems. <snip>
Otherwise, 'rsync --one-file-system -aH source target' will work and will
<snip> Or, as we do at work, after mounting /dev/<newdisk/3 /mnt
rsync -HPavxz --exclude /mnt /. /mnt/.
mark
At Tue, 14 Sep 2010 13:54:38 +0100 CentOS mailing list centos@centos.org wrote:
John R Pierce 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 generally use dump ... | restore ... to clone a complete e2fs/e3fs volume. it copies everything exactly on an inode by inode basis.
Thanks for the suggestion. Could you give a concrete command for copying / to say a new filesystem on /mnt/hd ?
(I'm wondering how this approach deals with symbolic links, /dev , /proc , etc
You *don't* copy /dev, /proc, or /sys! These are run-time generated file systems. /dev is a ramdisk, populated by udevd, /proc and /sys are file system mappings of kernel data structures. All three will appear and be 'populated' during the boot process. dump 'does the right thing' WRT links (both hard and symbolic), does the right thing for sockets and named pipes. Does things by physical file system -- does exactly one, skipping other mounted file systems encountered along the way). You do need to dump ... | restore ... *each* disk file system (/, /boot, etc.).
On 09/14/10 5:54 AM, Timothy Murphy wrote:
John R Pierce 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 generally use dump ... | restore ... to clone a complete e2fs/e3fs volume. it copies everything exactly on an inode by inode basis.
Thanks for the suggestion. Could you give a concrete command for copying / to say a new filesystem on /mnt/hd ?
(I'm wondering how this approach deals with symbolic links, /dev , /proc , etc
it handles symlinks, hardlinks, etc all perfectly, as the copy is inode by inode rather than file by file.. do note, /dev and /proc are special file systems, and not normal disk storage, so they aren't even in your root fs.
k, lets see. dump is best run on unmounted file systems, or in single user mode to dump / restore wants to write to a fresh file system thats been mkfs and mounted.
so, to copy one filesystem from /dev/sda1 to the new volume in /mnt/hd, try...
dump 0uf - /dev/sda1 | (cd /mnt/hd; restore rvf - )
if you have more file systems, for instance, /dev/sda3 is /var, something like...
mkfs -j /dev/sdb3 && mount /dev/sdb3 /mnt/hd/var dump 0uf - /dev/sda3 | (cd /mnt/hd/var; restore rvf -)
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).
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...
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.)
At Tue, 14 Sep 2010 09:39:07 -0400 CentOS mailing list centos@centos.org 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.)
I've used dump & restore so many times over the years with Linux systems to believe there is nothing wrong with using dump & restore. Note: dump & restore are only for ext2/ext3. It does not work for riserfs, xfs, etc. I don't know about ext4 (and the problems you've heard about might be related to ext4 or something else).
On Tue, Sep 14, 2010 at 09:53:42AM -0400, Robert Heller wrote:
At Tue, 14 Sep 2010 09:39:07 -0400 CentOS mailing list centos@centos.org 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:
Here is an article I wrote about doing this:
http://www.deepsoft.com/2009/01/how-to-transfer-a-linux-system-from-one-disk...
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.
....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.)
I've used dump & restore so many times over the years with Linux systems to believe there is nothing wrong with using dump & restore. Note: dump & restore are only for ext2/ext3. It does not work for riserfs, xfs, etc. I don't know about ext4 (and the problems you've heard about might be related to ext4 or something else).
Thanks much for the quick reply. The things that I would bother moving (vs. a reinstall, for less important things) are all on ext3, so this is VERY handy. (Especially, since as mentioned, it's what I'm used to from the BSDs. )
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):
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.
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
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@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@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?
At Tue, 14 Sep 2010 13:19:16 -0400 CentOS mailing list centos@centos.org wrote:
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 .
dd only works IFF (!) the new drive is exactly the same size as the old drive. Otherwise dd can be very bad. This is a serious misuse of dd!
Gabe
On 9/14/10 8:12 AM, "Timothy Murphy" gayleard@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?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, Sep 14, 2010 at 1:42 PM, Robert Heller heller@deepsoft.com wrote:
At Tue, 14 Sep 2010 13:19:16 -0400 CentOS mailing list centos@centos.org wrote:
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 .
dd only works IFF (!) the new drive is exactly the same size as the old drive. Otherwise dd can be very bad. This is a serious misuse of dd!
You can resize the target partition after the dd but it's a lot of extra work.
On Tuesday, September 14, 2010 01:42:05 pm Robert Heller wrote:
At Tue, 14 Sep 2010 13:19:16 -0400 CentOS mailing list centos@centos.org wrote:
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 .
dd only works IFF (!) the new drive is exactly the same size as the old drive. Otherwise dd can be very bad. This is a serious misuse of dd!
I routinely use dd for offline cloning to larger drives. Works fine. Just have to edit the partition table later, which isn't hard either, using several different open and closed source tools. Using a blocksize of 8225280 makes it go faster (this being a remap CHS default for LBA drives, and a guaranteed greatest common divisor of any hard drive size of modern drives); but use fdisk -l (or equivalent parted command for non-MBR disks (like my laptop's GPT drive) to get the blocksize to a good value.
But having done a few now I vastly prefer doing it online using LVM. No downtime, and it just works, including resizing, as long as you are going to a larger lv.
When a server simply has to have minimal downtime, LVM is worth its LoC in gold for this use.
Lamar Owen wrote:
But having done a few now I vastly prefer doing it online using LVM. No downtime, and it just works, including resizing, as long as you are going to a larger lv.
When a server simply has to have minimal downtime, LVM is worth its LoC in gold for this use.
What do you mean by "no downtime"? What exactly do you do? Is it documented anywhere?
On Thursday, September 16, 2010 01:43:19 pm Timothy Murphy wrote:
Lamar Owen wrote:
When a server simply has to have minimal downtime, LVM is worth its LoC in gold for this use.
What do you mean by "no downtime"? What exactly do you do? Is it documented anywhere?
Sorry for the delay; been too busy to read CentOS mailing list.
By 'no downtime' I mean moving to a new disk while the system is running. I did this with a Fedora 12 SPARC (beta) system (Sun Enterprise 6500 with 18 CPUs and 20GB of RAM, two diffSCSI channels to a D1000 SCSI storage shelf, six 36GB 10KRPM SCSI drives in each half of the D1000) a while back; the F12 SPARC beta has some real install issues that only work out right when you don't do anything custom. So the root filesystem went to a single drive when I really wanted it on a RAID 6 MD. The procedure I used is documented in the LVM HOWTO ( http://tldp.org/HOWTO/LVM-HOWTO/ ), specifically see section 13.5.2. In my case the target physical volume was /dev/md0 which was separately built with mdadm by hand.
This won't get /boot; but that's fairly safe to copy while mounted. Essentially you can set up the new disk's partitions, dd over the MBR boot code and the other areas your boot loader needs, copy over everything in /boot to the new boot partition, since /boot can't be on LVM with GRUB 1, then make the new physical volume on the new drive and add it to the volume group that contains your root filesystem. Do note that if you have swap on a logical volume, you have to deactivate it before the pvmove or the kernel will panic.
The pvmove from one physical volume to the other uses the power of LVM to make this 'just work' like an EMC Clariion would work when doing LUN migrations between RAID groups. It does take a while, and the system will be slower while pvmove is doing its thing, but the only downtime required will be when you reboot to boot off of the new /boot partition.
But pvmove is a MOVE, not a copy, so the data is gone from the source drive when you're done; that can be a downside in some use cases.
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
Bill Campbell wrote:
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.
Well, yes.
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
Urk! What, no kernel updates?
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''.
Does cpio do links, hard and soft? Rsync also gives nice warm fuzzies for progress. <snip> mark
-
Bill Campbell -
Gabriel Rosca -
John R Pierce -
kalinix -
Kevin Thorpe -
Kwan Lowe -
Lamar Owen -
Les Mikesell -
m.roth＠5-cent.us -
Marcelo M. Garcia -
Phil Schaffner -
R P Herrold -
Robert Heller -
Scott Robbins -
Terry Polzin -
Timothy Murphy -
Tom H