Re: migrate to new system disk
Sorry for top posting, there is just too much for individual responses.
Thanks for all your advice. I made use of much of it.
First, I ended up going with a SATA/PCI controller and 500GB WD SATA
drive as my fastest onboard IDE controller was ATA/66. I installed both
card and drive after compiling a new kernel with scsi_disk and libata
support. I created a /boot partition of 100MB, a / partition of 35GB,
and a swap partition of 1GB. I formatted the first two with ext2, and
mounted them as /newboot and /newroot, then started copying all the
files over, a directory at a time using your "cp -a" advice, though
using "cp -p" on some individual files.
Before copying over "critical" stuff, instead of entering runlevel 1 (as
I did everything remote via SSH), I merely stopped most of the
multi-user services, mainly postfix and postgrey.
The last things I did were to edit /newroot/etc/fstab and
/newroot/etc/lilo.conf. I then ran lilo to install the MBR on the new
disk, and rebooted. I hit a couple of minor snags, but the machine is
now runnin from solely the new disk, and AFAICT after much
checking/testing, everything is working great.
Now I just need to decide how to carve up the remaining 45GB of this
sucker and put it to good use. I right now I'm going to move /home to a
new partition of probably at least 100GB. I may install the samba
server so other machines can use some of this 500GB goodness.
Thanks again for the advice. Hit minor bumps along the way, but
overall, I'm please that the migration went as smoothly as it did. If
I'd anticipated a few things more correctly it would have been an almost
flawless migration.
--
Stan
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.
>
> A
Reply to: