Adding Drives

Back in the good old days, people would buy computer components separately. After gathering the necessary components, such as a motherboard, case, memory, video card, and monitor, they would slap together a working computer. Today it is usually cheaper to get a pre-built system. Few people (except power users like yourself) upgrade the video card or memory after buying the computer; most people will just upgrade the entire system. Even though most of the hardware stays the same, there is one thing that is usually upgraded: the hard drive. This could be because you need more disk space, or maybe you want a second drive for backups or additional storage.

Upgrading Drives

When you upgrade your hard drive, you want to make sure you transfer over all of your personal files. This could be as simple as transferring the contents of /home from one system to another. But if you have installed any custom applications (very likely) or tuned any configurations, then you will probably need to transfer system files too. Here's an easy way for doing it.

1. Shut down the system, remove the old drive, and install the new drive. Do not leave the old drive in the system since you do not want to accidentally reformat the wrong drive.

2. Install Ubuntu on the system (see Chapter 1). Be sure to use the same base install. Don't bother customizing this new install-it is only needed for making the drive bootable.

3. Shut down the system and install the old hard drive as the second drive. Do not boot from the old hard drive.

4. Start up the computer and boot from the new drive.

5. Log in when the computer has rebooted, then run the System Administration Disks. This brings up the Disks Manager applet. All of the drives on the system are listed, including their disk size. The new drive should be listed first, and the old one listed second. (See Figure 3-5.)

   
   Figure 3-5: The Disk Manager applet

6. Select the old drive and click on the Partitions tab.

7. Mount the old drive partition(s).

   • If you only have one partition, then select the partition name, enter a temporary mount point, such as /mnt/disk, and click the Enable button. You may need to make the mount point first (for example, sudo mkdir -p /mnt/disk).

   • If you have multiple partitions, such as /usr and /home, mount the root partition first, and then mount the other partitions in place. For example, the old / would be mounted at /mnt/disk and /usr would be at /mnt/disk/usr.

   Tip 

   If you don't know what is on a particular partition then mount it to a temporary location and click on the Browse button. This allows you to see the partition's contents.

8. As root, copy over all of the files to the new system.

    $ cd /mnt/disk $ ls bin    dev   initrd          lib         mnt   root  sys  var boot   etc   initrd.img      lost+found  opt   sbin  tmp  vmlinuz cdrom  home  initrd.img.old  media       proc  srv   usr  vmlinuz.old $ sudo tar -cf - * | ( cd / ; tar -xvf - ) 

   Note 

   You may want to remove temporary and device directories first, such as /mnt/disk/mnt, cdrom, tmp, dev, and proc. Alternately, you could only list the directories to keep in the tar -cf command.

9. Since the copy may have brought over a newer kernel, you will want to reset the boot loader.

    sudo update-grub 

10. Now that everything is copied over, you can reboot the system immediately. You don't want to use the shutdown applet since that can save desktop settings over your new settings. To force an immediate reboot, use the -f parameter.

     sudo reboot -f 

When the system comes back up, you should have all of your old files right where you left them, and a minimal amount of residue (undesirable files) that you did not originally want. This method is great for switching partition layouts since it only copies files, but it should not be used when upgrading operating systems.

Mounting Systems

In Chapter 1, we covered how to partition and format a drive. Now, since you have a second drive in the system, you can make it mount each time you boot the system.

1. Unmount the drive, partition, and format it. For this example, we will assume you have configured it with one partition: /dev/hb1.

2. Create a place to mount the drive. For example: sudo mkdir /mnt/backup.

3. Add the drive (/dev/hdb1) to the /etc/fstab file so it is mounted automatically.

    # /etc/fstab: static file system information. # # <file system> <mount point>   <type>  <options>       <dump> <pass> proc            /proc           proc    defaults        0        0 /dev/hda1       /               ext3    defaults,errors=remount-ro 0 1 /dev/hda5       none            swap    sw              0        0 /dev/hdc        /media/cdrom0   udf,iso9660 user,noauto     0       0 /dev/hdb1       /mnt/backup     ext3    defaults        0        0 

4. Mount the new file system using either sudo mount -a or sudo mount /mnt/backup.

With these changes in place, the new drive will be mounted every time you boot.

Using Simple Backups

Back in the old days, I would make backups using floppy disks. As drives increased in size, I switched over to magnetic tapes. Today, home systems can be cheaply backed up using a second hard drive. Listing 3-3 is a simple script that I use to backup my Ubuntu system onto a second hard drive.

Listing 3-3: Very Simple Backup Script: /usr/local/bin/backup2disk-full

     #!/bin/sh     # backup files to disk     # (Be sure to make this executable! chmod a+rx backup2disk)     for i in bin boot etc home lib opt root sbin sys usr var ; do         tar --one-file-system -cf - "/$i"  2>/dev/null | \         gzip -9 > /mnt/backup/backup-$i-full.tgz     done 

This simple script creates a bunch of compressed TAR files containing all of my data. For example, /mnt/backup/backup-home-full.tgz contains the contents of my /home partition. You can also create a version that does incremental backup by replacing the tar command in Listing 3-3 with:

 tar --newer /mnt/backup/backup-$i-full.tgz \   --one-file-system -cf - "/$i" 2>/dev/null | \   gzip -9 > /mnt/backup/backup-$i-inc.tgz 

For my system, I added the full backup script to my root crontab and configured it to run once a week. The incremental runs nightly.

1. Edit the root crontab. This allows files to run at specific times.

    sudo crontab -e 

2. Add a line to make the full backup run weekly and the incremental run daily. (See Chapter 7 for details on Cron.)

    # minute hour day-of-month month day-of-week  command 5 0 * * 0 /usr/local/bin/backup2disk-full 5 0 * * 1-6 /usr/local/bin/backup2disk-inc 

Using this script, I can restore any file or directory using tar. For example, to restore the /home/nealk/book2 directory, I can use:

 cd / sudo tar -xzvf /mnt/backup/backup-home-full.tgz home/nealk/book2 sudo tar -xzvf /mnt/backup/backup-home-inc.tgz home/nealk/book2 

Warning 

This backup script is very simple and can still lead to data loss. It does not keep historical backups and can lose everything if a crash happens during the backup. Although this script is a hack that is better than having no backups, it should not be depended on for critical backup needs. For long-term or critical data recovery, consider using a professional backup system.

Configuring a RAID

A Redundant Array of Inexpensive Disks (RAID) is a simple solution to surviving a disk crash. Ubuntu supports hardware RAIDs as well as software RAIDs. A hardware RAID needs no extra configuration for use with Ubuntu. The entire RAID just appears as a single disk. On the other hand, software RAIDs require some configuration.

A software RAID requires multiple hard drives. The simplest RAID uses two identical hard drives. I recommend buying the same make and model at the same time because they are certain to be identical. Other people recommend buying similar-but not identical-drives in case the drives have an unknown common problem. The choice really depends on your level of paranoia. I have had identical drives die within months of each other, but never both at the same time.

After installing the drives (for example, sda and sdb), partition them with the same size partitions (sda1 and sdb1). Now comes the fun part, turning them into a RAID.

Note 

This example assumes that you have added two additional hard drives to your systems and they are already partitioned. The software RAID works by combining multiple real partitions into one virtual partition. Usually the partitions are on different hard drives, since having a RAID hosted on a single hard drive does not protect against hardware failure.

Warning 

Creating a RAID requires modifying disk partitions and format. If you accidentally specify the wrong partition, you may end up destroying some or all of your system.

1. Use the mdadm tool to create the RAID. The man page for mdadm contains many additional options for striping, setting the RAID level, and so on. In this example, we will create a simple RAID1, or mirrored disks, configuration using the two partitions. The result is one RAID drive called /dev/md0.

    sudo mdadm --create /dev/md0 --level=1 \            --raid-devices=2 /dev/sda1 /dev/sdb1 

2. Creating the RAID happens in the background and can take hours to complete. Do not continue until it finishes. To watch the progress, use:

    nice watch cat /proc/mdstat 

3. Now you can create the file system for the RAID. You can use any file system on the RAID. For example, to create an Ext2 file system, you can use:

    sudo mkfs /dev/md0 

When you're done, you can view the RAID details using sudo mdadm -Q –detail /dev/md0. You can also mount the partition (sudo mount /dev/md0 /mnt/disk) and add it to your /etc/fstab.

Note 

Under earlier versions of Ubuntu, such as Hoary, you could not easily add a RAID to /etc/fstab since the drivers started up in the wrong order. Dapper has fixed that problem and you can now boot the system with a RAID listed in /etc/fstab.

Between a Rock and a Hard Disk

In 2004 I had a hard disk crash that hurt. Years worth of research was on that drive and it had a head crash. Although I did have simple backups, that's not the same thing as having the entire working system. Although 98 percent of the data was recovered (thank you Reynolds Data Recovery in Longmont, Colorado!) and the lost 2 percent was easily recreated, I quickly learned my lesson: don't store critical data on one hard drive.

Today, my main research computer has four hard drives. One is the main operating system, one is configured as a removable backup, and two are identical drives used in a software RAID for storing all research. A single drive failure will not cause me any data loss, and a massive electrical surge should only cost me a day of work and some hardware. I also use daily backups and off-site, out-of-state storage. A massive file system corruption might take a day or two to recover and result in a few hours of lost work, but the majority of my data is safe.

Although this type of configuration may sound like overkill for most home and SOHO environments, you need to ask yourself: which costs less? Configuring a software RAID and a simple backup script, or rebuilding everything after a total loss? Even the hourly costs for recovery time are less when maintaining a minimal backup system.