Re: migrate to new system disk
Andrew Sackville-West put forth on 12/1/2009 9:54 PM:
> 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
> structure.
>
>
>> 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.
>
> right.
>
>> 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
> disk.
>
> 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
> /tmp.
>
> 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
> working.
>
> 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.
Don't apologize. They're more than specific enough to get me going. A
couple of things though.
1. My fstab mounting skills are rusty, but I'll refresh
2. I'm sticking with LILO. I've never "manually" installed a boot
loader, only during Debian clean/scratch installations using the Deb
installer. The last time I did that was with Woody, like 4 years ago.
How do I manually install LILO to the boot sector of the new disk? I'm
sure it's simple, I just don't know the command.
Thanks so much for your very helpful insight to this point Andrew.
--
Stan
Reply to: