Monitoring hard disk health with smartmontools

January 23, 2010

I always install smartmontools when I use SMART-enabled hard drives. It wasn’t until recently, though, that I started automating the tests.

Here’s a link that explains it: http://www.captain.at/howto-linux-smartmontools-smartctl.php.

Based on that, here’s the code I added to my /etc/smartd.conf:
# Per http://www.captain.at/howto-linux-smartmontools-smartctl.php
DEVICESCAN -d sat -a -o on -S on -s (S/../.././19|L/../../3/21|C/../.././20) -m root
# -d sat because /dev/sdX doesn't seem to run without it
# S/../.././19 = short test every day at 19:00
# C/../.././20 = conveyance test every day at 20:00
# L/../../3/21 = long test every wednesday (3) at 21:00
# -m root = root will be emailed if anything strange occurs

Note that this has to come before any other DEVICESCAN (apparently the first one takes priority). Don’t forget to kill -HUP the smartd process so the new config will take effect, and make sure /etc/default/smartmontools has uncommented:

start_smartd=yes

After this, you can get useful info with:

sudo smartctl -l selftest /dev/sda

(or whatever drive you care about).

A very good description of the output of smartctl can be found at: www.cyberciti.biz/tips/linux-find-out-if-harddisk-failing.html


Using rsync to back up a Windows box to Ubuntu Server 8.04

December 10, 2009

After getting rsync working so well for backing up hard drive to hard drive, I naturally wanted to back up from my Windows box to my Ubuntu server. Luckily, Cygwin has an rsync for Windows – so I started by installing that. (I actually already had it installed – Cygwin is nice.)

I found some good instructions here, and used them as the basis for what I did.

The steps I went through:

  1. First I created /etc/rsyncd.conf. I wanted to share a single directory called shared, so I had just one entry:
    [shared]
    path=/data/shared
    comment=Shared directory
    uid=andrew
    gid=sambashare
    read only=false
    auth users=rsyncuser
    secrets file=/etc/rsyncd.secret

    I picked group sambashare just to be consistent with my Samba configuration. rsyncuser does not exist on the machine; it is instead mapped to andrew (uid)

  2. Next I created /etc/rsyncd.secret:
    rsyncuser:secretrsyncpassword
  3. After that, I needed to enable rsync (both right now and after reboot). First, I edited /etc/default/rsync and changed RSYNC_ENABLE to true:
    RSYNC_ENABLE=true
    

    Next I started the rsync daemon:

    sudo /etc/init.d/rsync restart
    
  4. The /etc/inetd.conf of a plain Ubuntu 8.04 Server install was empty, which was a surprise to me. There appears to be a utility called “update-inetd” to update the file and then restart inetd. Because I couldn’t be bothered to find out the syntax, I just edited /etc/inetd.conf and put in:
    rsync  stream  tcp     nowait  root    /usr/local/bin/rsync rsyncd --daemon

    Then I used update-inetd from the command line to restart inetd for me:

    sudo update-inetd --disable rsync
    sudo update-inetd --enable rsync
  5. At this point, I could telnet to port 873 (the rsync port) and see a connection, but rsync itself still didn’t want to run. Instead, it failed (even when I entered the correct password) with this message:
    @ERROR: auth failed on module shared
    rsync error: error starting client-server protocol (code 5) at main.c(1383)

    Andrew Tridgell has awesome utilities, but he really has a problem with displaying meaningful messages.

    It turns out that rsync really wants the secrets file (in my case /etc/rsyncd.secret) to be readable only by the rsync user. There is a global option “strict modes” that can be set to false to allow you to get around this, but I decided why not just do the right thing:

    sudo chown root.root /etc/rsyncd.secret
    sudo chmod 400 /etc/rsyncd.secret
  6. Finally, I needed a command for the rsync on my Windows box. Here was one I came up with:

    @echo off
    set RSYNC_PASSWORD=secretrsyncpassword
    rsync -vrtz --delete --delete-excluded --exclude "Temp/" --exclude "*.tmp" --exclude "parent.lock" --exclude "UsrClass.dat*" --exclude "NTUSER.DAT" --exclude "ntuser.dat.LOG" --exclude "Cache/" "/cygdrive/c/Documents and Settings/" "rsyncuser@myserver::shared/win2k-backup/Documents and Settings"

    This command preserves timestamps (t) and prints out what it’s doing (v) as it recursively (r) goes through Documents and Settings and backs up the files, using compression so it’s faster over the net (z). It excludes a bunch of things.

I should probably have used a file to specify what’s excluded (–exclude-from), but I was lazy and just kept adding to the command line. I’m excluding cache files, as well as lock/log files that are kept open by Windows 2000 (they report as errors if you try to back them up).

At some point I’ll probably add a “hosts allow” line to my /etc/rsyncd.conf, as soon as I decide which machines I want to let backup to the server.


Automatically mounting drives with UUIDs

December 6, 2009

Until now, I’ve always mounted drives by accessing their devices. However, I ran into a situation where this wouldn’t work. Luckily, Ubuntu has the ablility to access drives by UUID – which solved my problem.

I have a drive that holds networked data, which I mount on Ubuntu 8.04 Server as /data/. I also back that drive up to a drive which is normally read-only as /databackup/.

Both of these drives are SATA – meaning they could be unplugged at any time. If both are unplugged, whichever drive gets plugged in first becomes /dev/sda1 – and the other becomes /dev/sdb1. This means I can’t rely on mounting /dev/sda1 on /data and /dev/sdb1 on /databackup.

To get around this, I mounted the drives using UUID in /etc/fstab. First, I had to figure out what the UUIDs of the drives were. To start with, I killed Samba and unmounted both – I knew /dev/sda1 was /data and /dev/sdb1 was /databackup. Then I obtained the UUIDs of both drives:

$ sudo vol_id --uuid /dev/sda1
7b932326-717b-4ba6-bef2-fedfbafcabe6
$ sudo vol_id --uuid /dev/sdb1
94efd7bd-8498-46f3-ab6d-cb706c413567

Next, I replaced the device mounts (/dev/sda1 and /dev/sdb1) in /etc/fstab with:

UUID=7b932326-717b-4ba6-bef2-fedfbafcabe6 /data ext3...
UUID=94efd7bd-8498-46f3-ab6d-cb706c413567 /databackup ext3...

Under Ubuntu 9.10, it appears that vol_id has merged into blkid – so now you would use:

$ sudo blkid /dev/sda1
/dev/sda1: UUID="f30ba2a3-9da6-48b1-8ab5-75952ef26cc4" TYPE="ext3"

to determine the UUID, and then update /etc/fstab as you’d do for 8.04.