Edward Milstein wrote:

On Mar 14, 2007, at 9:35 AM, Bowie Bailey wrote:

...

I have a CentOS 4.4 system where all of the main filesystems are on a single hard drive. This drive is starting to give some errors, so I got a new (larger) drive to replace it with. What is the easiest way to copy my filesystems over to the new drive?

I considered using dd, but I lose the extra capacity of the new drive that way.

I tried using SystemImager, but it is giving me some errors.

I think the easiest way may be to boot from the LiveCD, recreate the partitions, copy the info with rsync and then fix the boot partition and grub. Any tips or pointers to a good how-to?

-- Bowie

Here is what I recently did for a similar operation.

1. Download the system restore iso http://www.sysresccd.org/Main_Page

If you have Knoppix, that works well too.

2. Boot into the sysrescue cd

3. Run partimage against your old disk to save the slices.

4. Partition your new disk as per your old disk (sfdisk -d /dev/disk1 |

sfdisk /dev/disk2)

That can give rise to funny errors if the geometries are different in some ways.

5. Use partimage to restore backups you just did to the new disk.

6. Remove old disk

7. Remove CD

8. Reboot

Viola..

-ed-

PS. You might need to fix grub if addressing for the new disk changed but there are smarter people to comment on that aspect.

Your recipe requires fixing grub (I didn't see you copying the boot sector). It's something I forgot to mention, but it quickly becomes apparent.

John R Pierce wrote:

I'm assuming you're using straight ext3 without LVM or raid....

Good point. A while ago I copied an 80 Gb drive to existing partitions on 120 Gb. The source didn't use LVM, the destination did.

I got it working, but I couldn't describe what I did with any reliability.

I'd probably boot the regular CD into rescue mode, without mounting the file systems, then partition the new disk to suit (making each partition at least as large as the original drive, and in the same order, then run something like....

this assumes new drive is hda, old drive is hdb

mkdir /mnt/src /mnt/dst for f in 1 2 5 6; do mount /dev/hdb$f /mnt/src mount /dev/hda$f /mnt/dst dump 0f - /mnt/src | (cd /mnt/dst; restore rf - ) umount /mnt/dst /mnt/src end mkswap /dev/hda3 mount /dev/hda2 /mnt/dst && mount /dev/hda1 /mnt/dst/boot chroot /mnt/dst grub-install /dev/hda ^z umount /mnt/dsk/boot; umount /mnt/dsk

adjust file and device names to suit. dump to restore like that creates a very accurate copy of a file system, complete with special files, links, ACLs, permissions, etc, etc intact.

And presumably, fairly quickly. I've never used dump/restore, but if it does the obvious and decides which blocks top copy, sorts the list then copies, it should be quickest of all, regardless of the data content.

now, swap the new drive

(where 1, 2, 5, 6 are your file system partitions, leaving out your swap which I'm guessing is hda3) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

John R Pierce wrote:

John Summerfield wrote:

...

John R Pierce wrote:

...

dump 0f - /mnt/src | (cd /mnt/dst; restore rf - ) ...

And presumably, fairly quickly. I've never used dump/restore, but if it does the obvious and decides which blocks top copy, sorts the list then copies, it should be quickest of all, regardless of the data content.

dump/restore is an exact file by file copy of a filesystem, it replicates the directory entries quite exactly including all supported attributes.. I probably got in the habit of using it from Solaris, which has the rather similar ufsdump/ufsrestore.

I used to use, on OS/VS many years ago, a program called IEHDASDR. It does a track-by-track dump of a disk, in track order, of those tracks used by files and ignores tracks outside of allocated space. The only track requiring special attention is cyl 0, track 0 which contains a pointer to the VTOC (directory) which itself is a file.

My ordering the tracks, it all but eliminates seeking.

another method is

cd /source; tar clf - . | (cd /dest; tar xvf -)

That's what I said, more-or-less;-)

but not all versions of tar have the -l (--one-file-system) option (gnu tar in CentOS does, however).

oh yeah, dump will dump an unmounted filesytem too, so in fact, that could have been...

mount /dev/hda1 /mnt/dst cd /mnt/dst dump 0f - /dev/hdb1 | restore rf -

That supports my suggestion that it might, like IEHDASDR, order the block list so as to minimise seeking.

Archive programs such as tar are slow when there's a lot of data, but perform relatively well when there's not a lot of files, and doesn't copy deleted files. Tar causes lots of seeking.

dd is a straightforward sector-by-sector copy and is faster than tar when the disk is relatively full of files, but it copies deleted files and any other junk.

I think dump copies the smallest necessary volume of data, in the best possible order. Its disadvantage is that it cannot change from own filesystem to another.

There are other dump/restore programs for other filesystems.