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. A
Attachment:
signature.asc
Description: Digital signature