In an attempt to save a system without doing a fresh reinstall by copying the contents from dying hard drive to new hard drive using external hard drive enclosure. This method seems to have worked well for me. I’m posting it as reference so others have a guide to work from and improve upon. I have only used this method once so make sure you know what you are doing if you follow the guide.

WARNING: Use the following formation at your own risk. Make sure you make proper backups. The following information may have errors or may not work properly and could possibly damage your system or cause the loss of data. Once again, use the following at your own risk. Research how to use each individual command so you know what you are doing.

Guide to moving a Debian or Ubuntu Linux installation from an old hard drive to a new hard drive without re-installing.

1. Attach external hard drive
2. Reboot computer into single user mode (i.e. rescue mode)
3. Find the new device of the external hard drive (probably sda or sdb) dmesg | grep hd; dmesg | grep sd
4. create new partions on new drive: fdisk /dev/sd(a,b, etc.)
   1. create swap partition
   2. create linux partition(s)
5. initialize swap: mkswap
6. create filesystem (I’m using ext3): mkfs.ext3
7. Mount the new hard drive (referred to as /dev/sda2 from now on): mount -t ext3 /dev/sda2 /mnt
8. Use debootstrap to get base install (ubuntu edgy example): debootstrap edgy /mnt http://us.archive.ubuntu.com/ubuntu
9. Now the copy command: rsync -av –exclude=/dev –exclude=/sys –exclude=/mnt –exclude=/proc –exclude=/media / /mnt
10. Make partition bootable: fdisk /dev/sda2 # use the ‘a’ option
11. Shutdown system and put in the new drive.
12. Get Grub working again:
    1. Insert Ubuntu or other Debian based live CD (Knoppix is a good choice too).
    2. Mount the new drive: mount -t ext3 /dev/hda2 /mnt
    3. Install grub: install-grub –root-directory=/mnt /dev/hda2
    4. chroot into new drive: chroot /mnt
    5. edit /boot/grub/menu.lst
       1. Update groot(hd0,) #if bootable partition changed (i.e. Was /dev/hda5 is now /dev/hda2… Old: groot(hd0,4) New: groot(hd0,1)
       2. Update kopt=root #if bootable partition changed (i.e. Was /dev/hda5 is now /dev/hda2… Old: kopt=root=UUID= or kopt=root=/dev/hda5 New: kopt=root=/dev/hda2 (NOTE: There is probably a way of getting the new UUID of the new partition, in which case you can just update the UUID option, but I don’t know enough about this yet to offer advice… Feel free to post a comment if you know more.)
    6. type: update-grub
13. Reboot and hope everything works properly.

I loaded up bconsole this morning to check the status of the full backups that were suppose to run last night and found out that all of the backups had failed. The error message: “Failed to connect to Storage daemon”

I discovered that bacula-sd (storage daemon) was only listening to 127.0.0.1. Then I changed it to the full qualified domain for the server, and the client file daemon still failed to connect to the storage daemon (form WinXP boxes). Then I changed it to the ip address of the server and everything started to work properly.

Config files I changed:

bacula-dir.conf:

• Storage directive
  • Address #changed to bacula-sd server ip address

bacula-sd.conf:

• Storage directive
  • SDAddress #changed to bacula-sd server ip address

After getting tired of maintaining and updating a custom Python based backup network script that used smbclient to backing up WinXP machines using samba, I decided to look into open source solutions. I found two high-end open source network based backup solutions that handle WinXP, Mac OS X, and Linux machines:

• AMANDA
• Bacula (My choice — reason in a moment)
• [update: 2006Aug31] BackupPC

AMANDA has it’s advantages, including paid enterprise support through Zmanda, which maybe be important to people in the business world.

The main reason why I choose bacula is because AMANDA uses samba for connecting to WinXP clients and I have one pesky WinXP box which came with some high-end biology equipment and therefore the company we bought it from decided to mangle WinXP enough that samba from Linux won’t connect to it. And for the fear of bringing down an important piece of biology equipment, I have decided to not mess with that machine more than I need to. Bacula runs a file daemon (a.k.a. ‘service’ for you Windows users) which gets me past the samba problem. So, if you were looking here for me to tell you which one is better, I really don’t know. I haven’t tried AMANDA yet.

The other feature that really sold me is the Python scripting ability built into Bacula for extending the backup process.

Bacula seems to work great… Although the big test will be coming in next day to three months. I just finished setting up a bacula server and 7 clients… 6 WinXP clients and 1 Kubuntu client.

Quick overview:
Bacula consists of three daemons:

1. director (runs the show)
2. storage (manages storage pools & volumes: disk, tape, DVD, etc.)
3. file (client side backup daemon/service)

What’s confusing about bacula at first is it’s concept of ‘pools’ and ‘volumes’. My original thought was that ‘pools’ and ‘volumes’ were meant for tape drives and that I would only need one pool with one volume since I wanted to use file based storage on a raid-5 hard drive setup. As it turns out, it is convenient to use different pools for full, incremental, and differential backups. Also, within a pool, by putting multiple volumes (i.e. multiple disk files for it to write the backups to), you can set it up to recycle used volumes after a set amount of time! What does this mean for me… If I have enough hard drive space, it will just reuse the space over and over again. If everything is going well, I won’t have to worry about backups. Automation is wonderful! Oh, and it does e-mail me when something goes wrong and there is this ‘bconsole’ which allows you to trigger backups, check backup status, create new pools/volumes and much much more!

Here is my pool/volume setup:

FullPool:
3 Volumes
28 Day Use
56 Day Expire

IncPool:
12 Volumes
7 Day Use
28 Day Expire

DiffPool:
4 Volumes
13 Day Use
28 Day Expire

Note that I only need a full backup to last a month and I have three volumes, so I should always have two full backups and the third will be recycled.

Here is the key schedule I use in the bacula-dir.conf:

Schedule {
Name = “WeeklyCycle”
Run = Level=Full Pool=FullBackupPool 1st sun at 23:05
Run = Level=Differential Pool=DiffPool 3rd-5th sun at 23:05
Run = Level=Incremental Pool=IncPool mon-sat at 23:05
}

Let me know if you would like me to post additional information.