Monthly Archives: May 2006

I wrote earlier about getting a hard drive added to one of my Linux boxes so that I could do backups. I’ve been meaning to get backups in order for many years, but it’s been more urgent since about 10 months ago (yeah yeah, must not’ve been too urgent if it waited that long), when I lost all the data on my laptop and had to recover what I could from a backup I had manually made some months before. More precious than most of the data I might have lost in that case are the photos and videos we’ve accumulated of Lennie over the past two years. When I had to send Mleeka’s laptop in to the shop a few months ago, I made an effort at dumping her files onto a Linux fileshare, but it wasn’t terribly successful, it wasn’t easy, and it wasn’t a long-term, self-sustaining solution. My project tonight was to put such a solution in place.

Backing up from Linux to Linux is simple, and I’ve had that going for several days. You just run rsync as a daemon on the fileshare, create a module, put the client’s public ssh key on the server, and run a cron job on the client that pushes to the module. All I had to to today to make this work on the new disk was move the files from one disk on the server to the other, edit the module in /etc/rsyncd.conf to reflect the new path, and restart rsync. Nothing to it.

Backing up the Windows box has been somewhat more challenging. I spent a few hours wrangling with a couple of different options for running rsync clients and daemons on the Windows laptop. I kept running into problems with weird Windows path issues, Windows firewall issues, other connection issues, permissions issues, and so on. It was very frustrating. Finally, I read a suggestion that one just mount the Windows directory on the Linux fileshare and then rsync locally. Simple and brilliant!

Ubuntu Linux appears not to ship with smbfs enabled, so after getting errors with the mount, I issued “apt-get install smbfs” to get that module. Then I did the following to create a mountpoint and a share:

mkdir /mnt/laptop_mleeka
mount -t smbfs //server/sharename /mnt/laptop_mleeka

This is of course after right-clicking properties on the My Documents folder on the Windows laptop and sharing the folder as “sharename.”

Once that was mounted, I issued the following:

rsync -a /mnt/laptop_mleeka/* houston@localhost::mleeka_bak

In this case, “mleeka_bak” at the end of the command is an rsync module I set up that manages permissions and file locations for the sync. The initial backup is running as I type. I understand that samba mounts are pretty slow, so it’s taking a while to haul the 9 GB of data across even my local network. Luckily, rsync is incremental, so in the future, it’ll sync only differences between the file systems.

All that remains is to add the mount command to /etc/fstab so that the server tries to remount the drive in the unlikely event of a reboot and to toss the rsync command itself into a cron job so that the backup takes place nightly. Continue reading →

Dilemma: I’ve got an old desktop system with less than 20 GB of disk space. On that system, I wanted to store backups of my laptop and our photos of Lennie. I also wanted to use it as a machine that will allow me to build software from time to time (which can take up a few GB of disk space). Without even starting backing up the many GBs of photos yet, I’ve nearly filled up the 20GB, and that’s after deleting a bunch of stuff. I happen to have another desktop system that has been on its last legs for a while, but it’s got a 65 GB hard drive.

Objective: Put the 65 GB hard drive in the working desktop system and make it operational.

Dilemma 2: I don’t really know anything about hardware. I forged ahead anyway, though, and I got it working. Here’s how.

Disclaimer: I did this on a Ubuntu Linux box. I have no idea how it’d go on any non-Linux box (so don’t ask). If you try these steps and you or your computer blow up or become otherwise harmed or incapacitated, note well that by reading further, you’re asserting that you’ve proceeded at your own risk.

1. Remove hard drive from dying computer. (This is pretty straightforward and doesn’t merit more detailed instructions.)
2. Read the back edge of the hard drive (the part with the pins) to figure out how to make it a slave so that the computer doesn’t get confused when it tries to boot up with two drives, This usually involves pulling a little plastic tab that slips over two pins off and sliding it back down onto two other prongs. I learned this the hard way by installing the drive, having the computer fail to boot, and remembering that something like this had to be done, whereupon I consulted the back edge of the hard drive.
3. Install the hard drive in a free bay in the working computer. This is pretty straighforward and, like initial removal, will require a screwdriver.
4. Cross your fingers that you’ve got the necessary cables available in your working computer’s case. If you don’t, you should probably consult some other guide. I was lucky. One cable is a ribbon cable with a plastic component that will receive the long array of pins on the back edge of the disk drive. The other is a little bundle of colored cables capped by a white plastic piece. It’s got four or five holds in the back for receiving pins. These plug into the obvious spots on the back edge of the disk drive.
5. Now boot up. The computer should boot as it did previously.
6. Get a terminal window open. If you don’t know how to do this, you probably shouldn’t go any further.
7. Find out what the disk is named. The following command will give you some output about your disks and partitions. You should look for one that’s the same size as the disk you installed and one that’s not listed in the output of the command “df”. If you don’t see one, something went wrong with the hardware install and I probably can’t help you.sudo fdisk -l
8. Make a directory to mount the drive on. I used /bak: Sosudo mkdir /bak
9. Now give your user permission on that directory. You might have to do something more involved if you need to allow more than one user to access the disk. This works for me, though.sudo chown -R houston /bak
10. Now partition the disk using fdisk. This is weird if you don’t know what you’re doing. I’ll walk you through my steps, which may or may not be the best to have taken.
    1. First do the following command, which takes you into a little interactive prompt (where /dev/hdb is the disk; note that it differs from /dev/hdb1, which I guess represents the partition on that disk; also note that you should substitute your disk identifier as above):sudo fdisk /dev/hdb
    2. At the command, enter “d” and then “1″ to delete the first partition on the disk. If there are other partitions, delete them as well.
    3. Then press “w” to write the changes to the disk and exit. This’ll probably take a few seconds or minutes.
    4. Next do sudo fdisk /dev/hdb again (substituting your disk identifier)
    5. Press “n” to add a partition. Chances are that you want just one, in which case you can just accept the defaults in the ensuing prompts.
    6. Then press “w” to write the changes to disk and exit.
11. Now format the new disk as an ext3 disk. Note that the /dev/hdb1 below is the same as what I discovered in step 7 to be my new disk. Substitute your value there.sudo mkfs /dev/hdb1 -t ext3
12. Ok, now you’ve got an ext3-formated disk with one partition. All that’s left is to mount it so that it can be used. To do this, edit /etc/fstab and add the following line to the end (again, substituting the drive identifier and directory the disk should be mounted on in columns one and two):/dev/hdb1 /bak ext3 defaults 0 0
13. Finally, typing the following command should mount the drive so that you can begin writing to it (substitute your path if needed):sudo mount /bak
14. Since we added the entry to /etc/fstab, the drive should come back mounted on reboot as well.

Continue reading →