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

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.


Reply to: