Penguin
Blame: MigratingDisksExample
EditPageHistoryDiffInfoLikePages
Annotated edit history of MigratingDisksExample version 3, including all changes. View license author blame.
Rev Author # Line
1 DanielLawson 1 If you've ever been in the situation where you are doing a full upgrade of the disks in a server, you'll face the problem of getting the data from one set of disks to the other, without wanting to reinstall from scratch.
2
3 Here's how I'd do it:
4
5 * Install the new hardware in such a way that the old hardware is still the default. IE, your old disks are still the boot disks, and the new hardware comes up somewhere else entirely. This is easy if you're migrating from normal IDE to IDE-RAID or to SCSI or something, not so easy if moving from one SCSI controller to another.
6
7 * Boot into your old OS, and then partition and format the new drives as you would like them setup. Set up RAID volumes here too..
8
9 * Mount the new rootfs under /mnt/root
10
11 * Mount all the new partitions at appropriate points under /mnt/root, eg the new var goes to /mnt/root/var. You'll need to create appropriate dirs for these mountpoints first, of course.
12
13 * Make sure you are in runlevel 1 - single user mode. If you aren't, you might have files like the mailspool change while you are copying. This will mean you LOSE DATA. DANGER.
14
15 * recursively copy all the other directories (ie, *exclusing /mnt) into /mnt/root. Don't copy /proc or /tmp either eg
16
17 cp -a /bin /boot /dev /etc /home /lib /opt /root /sbin /usr /var /mnt/root/
18
19 * Have a coffee or two
20
21 * Make /proc and /tmp
22
23 mkdir /mnt/root/proc
24 mkdir /mnt/root/tmp
25
26 * Set the permissions on /tmp properly (rwxrwxrwt)
27
28 chmod 1777 /mnt/root/tmp
29
30 * Once this has finished, you can use chroot to set the new partition as the root for your shell, and verify that things work
31
32 chroot /mnt/root /bin/bash
33
34 * Make sure everything looks like its ok.
35
2 DanielLawson 36 * Reinstall your bootloader. if you are in the chroot as described above. Note that <new boot device> is just that! if you are booting off a SCSI RAID array, it'll possibly be /dev/md0. If it's an IDE disk that will eventually be on /dev/hda but is currently on /dev/hde, try /dev/hde - but I can't guarantee that'll work. You might want to make a bootdisk so you can boot off that when you yank the old disks.
1 DanielLawson 37
38 lilo -b <new boot device>
39
40 ** If you aren't in the chroot, specify the config file
41
42 lilo -C /mnt/root/etc/lilo.conf -b <new boot device>
43
44
45
46 * Reboot, remove the old disks, and hopefully boot off the new ones.
3 CriggieCriggie 47
48 ----
49 I cheat a little when building a linux box that is primarily a server rather than a workstation. Normally a linux server has plenty of disks, and quite often more than one. So I attempt to have a completely separate root drive from any data drives. For example - a 36 Gb IDE root drive and four 275 Gb drives in a software RAID-0
50
51 belt:~# df -h
52 Filesystem Size Used Avail Use% Mounted on
53 /dev/hda1 18G 1.5G 16G 9% /
54 /dev/md0 1.1T 739G 379G 67% /backup
55
56 Doing it this way means that the data drives could be moved to another box with minimal fuss, and if a data drive goes then the root drive can still boot. The root drive speed doesn't really matter once the machine is up, but the data drives do.

PHP Warning

lib/blame.php:177: Warning: Invalid argument supplied for foreach()