[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: migrate to new system disk

On Tue, Dec 01, 2009 at 08:22:57PM -0600, Stan Hoeppner wrote:
> I currently have a 40GB IDE boot disk in a Lenny server.  I boot with
> LILO, but not INITRD.  I have the following partitions:
>    Device Boot      Start         End      Blocks   Id  System
> /dev/hda1            4623        4865     1951897+  82  Linux swap
> /dev/hda2   *        4607        4622      128520   83  Linux
> /dev/hda3               1        4606    36997663+  83  Linux
> Partition table entries are not in disk order
> I would like to add a new IDE disk between say 160GB and 250GB, on
> another IDE channel, and copy/mirror/etc the exact contents of the
> current system disk to the new disk; make the new disk the system (boot)
> disk, and remove the original disk from the machine.  I've never done a
> disk migration such as this with Linux.

This is very doable. I've done it, throwing in niceties such as lvm on
the way across as well.
> This is a production email firewall/gateway.  Thus, I need to have the
> system down as little as possible to complete this.  I know I'll need to
> enter single user mode to do the work.  I'm just not sure what work I
> need to do in order to properly accomplish this task.

only parts of it need to be done in single user mode, and that at the
very end, so downtime should be minimal. And, if it doesn't work, you
can always reboot into the old disk while you sort it out. 

> So, what's the best method to pull this off, guaranteeing (as best as
> possible) that all the data made it across the river intact, with an
> identical partition and directory structure, will identical permissions
> on all dirs and files, and that will be bootable?

why exactly do you want an identical partition structure? That's
really not necessary. What is necessary is that the whole file tree
makes the migration with permissions and structure intact. Little bits
like tweaking /etc/fstab are easily done to accomodate a new partition

>  If I start up Postfix
> after the migration to the new disk, and the queue directory/file
> permissions are incorrect, my mail server would be dead in the
> water.


> I've been unable to find a concise how-to via Google so far that gives
> me the right comfort level on this.  I'm sure one of you can point me to
> a good set of docs.

I doubt there is a concise how to, but here are the steps I've used in
the past, as well as I can remember them. 

1. get yourself a rescue cd of some kind. Make it one you are familiar
with. If you messup, you might need it. 

2. make good current backups.

3. shutdown the machine, install the disk, restart.

4. take your time creating partitions and filesystems on the new

5. Begin to migrate chucks of the filesystem. Here's where things get
itneresting, because it depends on hoow you like to structure stuff. I
like to have many partitions for various bits of the fs, and this
really helps in this case, but you can make it work in a monolithic
file system as well. 

Typically, since it's all on the same machine, I just use cp -a (which
handles all the permission). There are other solutions use tar and
friends, but I don't really think it's necessary. Start out by
migrating over things that are fairly static like /usr, /bin, /sbin,
/boot, /root etc. If /home is pretty static on this machine, then move
it over as well. YOu have to make a judgement call about each section
of the file system, but the ones to save for the very end are /var and

Now, here is where you can really take your time. Move over just one
chunk, say /usr, and then remount it back into the current running
system and use it and make sure it's working properly. YOu can do this
with each piece of the file tree as you go. 

For migrating /var and /tmp(debatable whether this even needs to be
done for /tmp as it'll get handled on a reboot), you'll want to go to
single user mode, copy it over, remount the new copy back into the
system and then go back to multi-user mode and make sure it's all

Doing things this way, you can test each piece as you go and you
aren't messing with the original working install, so rolling back on
problems is simple. 

Now fix up /etc/fstab, if needed, on the new disk. 

Finally, once you've got this all working the way you like, you'll
want to install a bootloader into the new disk, although, if you use
grub, even that can be avoided until later. You *can* reboot and edit
the grub entries to boot from the new disk using grub from the old
disk. At the end of this, you'd be running the system off the new
disk, but booting from the old. Then install grub on the new disk,
shutdown, remove the old disk and see if it comes back up.

Sorry it's not *specific* instructions. But, depending on your skill
level, it's really not that hard. THe key is the -a flag on cp, taking
your time, and jsut doing it one piece at a time. 


Attachment: signature.asc
Description: Digital signature

Reply to: