Backups of Backups

My backup strategy for my machines at home can be effectively described as “scatty, but thorough“.  Or at least until I actually have a major crash and need to recover that important file that was outside of my normal documents, code repositories, and archived folders.

I am one of those sorts of people that has backups everywhere.  Folders stacked away with old dusty (and probably now useless) dvds.  Old hard drives filled with duplicates and archived files, stacked up in the back of cupboards and flung next to jam jars.  SD cards, USB keys, backups to other drives, backups to the machines on the other side of my flat, backups off-site.  Backups of backups backed up during the last backup.

So I decided to add one more with an external hard drive that I could plug in every now and then.  But backups aren’t really the point of this post.

Linux has a really powerful device manager called udev which detects when things are plugged into your machine (including hard drives), which you can write rules against, and have commands automagically executed.  This is really cool for my new hard drive, which can now automatically start backing up without regular cron jobs checking to see if it’s plugged in or not.  This is not the same as autorun files, it relies on that hard drive being plugged into that machine.  So don’t start crying about all the security risks with autorun, please.

Here’s how you do it.

Code block

udevadm info -a -p  $(udevadm info -q path -n /dev/sdc)

You’ll get a whole bunch of output from that, including (among a lot of other output) a line that might look a little like this:

Code block

ATTR{serial}=="312581808"

There are a lot more you can use as well, but this will identify your device.

Now create a new file inside /etc/udev/rules.d/, such as /etc/udev/rules.d/81-usb-drive.rules

Code block

KERNEL=="sd?1", ATTRS{serial}=="312581808", SYMLINK+="backup-drive", RUN+="/bin/sh /home/user/scripts/backup-to-drive.sh"

Now every time you plug in that drive, that command is going to be executed (so include for example, the script that is going to run your backups).  Cool, eh?

I started thinking about other applications; syncing podcasts, ebooks and music are the obvious choices. Even as a crude simple method of executing commands on a box you don’t even usually login to.  Or you could use this technique to build yourself some poor man usb-based security.  Keep decryption keys on your thumb drive, and have it auto decrypt volumes on your machine when you plug in that particular drive.

Just don’t forget to keep a backup of the thumb drive, yeah?

Eee Ubuntu

Since installing Ubuntu on the Eee, I had no doubt it was going to replace the Xandros install full-time.  It has a lot more features for my inner geek and better support for the applications that only I can find essential.

It also takes a hell of a lot longer to boot up.

But that’s okay, these new Atom processors don’t take up a lot of battery life when they’re in standby… If I were a real reporter, I’d test that theory.  But since I’m blogging, so I’ll throw out any kinds of lies that I like – so long as I’m upfront and honest about it.

So far so good, except Resume doesn’t work on Ubuntu Eee, either.

Great.

So I followed the steps on the usual eee user wiki about suspend/resume.  And that didn’t work either.

What I did find, is that you can actually resume from the never-ending sleep of the Ubuntu if you run the command:

sudo /etc/acpi/sleep.sh force

Furthermore, you can replace the pm-suspend command with the same – and your shiny new Ubuntu Eee will wake up when you ask it.  Rather than whining about it being too early and throwing the covers over its head.
#Make a backup, just in case.
sudo cp /usr/sbin/pm-suspend /usr/sbin/pm-suspend.bak
sudo echo "/etc/acpi/sleep.sh force" >/usr/sbin/pm-suspend


And that will let you continue to use the lid or the shut-down screen for all your eee suspension needs.  Hopefully I can do something about that initial boot-time, next.

• Eee PC 701
• Nokia N95
• Bluetooth dongle
• Ubuntu Eee installed on the 701 (not Xandros – although check out these scripts if you don’t want to change)
• T-Mobile UK contract with included data plan (preferably).  And Internet already working on the phone.

You’re going to be setting up your connection though pppd, and all of these instructions are based on instructions that I’m going to steal, slightly change and probably skip parts to suit my purposes (and hopefully yours) perfectly.

If your set-up doesn’t match exactly, perhaps you can make use of both pages and work out where things should change.  Or lovingly rip these instructions off, as I did – to make your own.

Setup your bluetooth dongle
First off, you’re going to need an apt repository that has the bluez-utils packages in. So open up a terminal
sudo nano /etc/apt/sources.list
and add the line
deb http://ftp.de.debian.org/debian etch main

Then you can install the package.

apt-update
apt-get install bluez-utils
/etc/init.d/bluetooth restart
lsusb | grep -i bluetooth
(should show the bluetooth device)
hcitool dev
(also lists bluetooth devices)


Setup networking

You can grab my gprs-settings which should be put into /etc/ppp/peers directory, and untarred.
tar -xvf gprs-settings.tar

Pair the phone

First, get the bluetooth ID of the N95
hcitool scan
Then pair your Eee with your phone, you have to do this from the N95.
Bluetooth -> right arrow (Paired devices) - Options
New paired devices (search)
Choose your eee and then type the pairing keys (anything of your choosing

Bind bluetooth to an rfcomm device

We use “rfcomm” to bind the bluetooth connection to a device. So first, find out the channel the phones bluetooth dial up networking system is on. You can do this with sdptool (Service Discovery Protocol tool):
sdptool search dun
Service Name: Dial-Up Networking
Service RecHandle: 0x1001e
Service Class ID List:
"Dialup Networking" (0x1103)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 2
Language Base Attr List:
code_ISO639: 0x454e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100

Note the “Channel: 2″ which show which channel to bind.

Then to bind the channel (in this case #2) to one of the rfcomm devices (for example, rfcomm0):
rfcomm bind 0 11:22:BE:EF:44:33 2
You can see the binding with:
rfcomm
rfcomm0: 11:22:BE:EF:44:33 channel 2 clean
You might find you need to reset the bind and restart it every now and then (especially failed connection attempts)
rfcomm release 0
rfcomm bind 0 11:22:BE:EF:44:33 2
You can edit the settings in “/etc/bluetooth/rfcomm.conf,” set bind to “yes” and give the device and channel for rfcomm0. Then you can put these commands into /etc/init.d/bluetooth and it will automatically bind and release the rfcomm device:
# At the end of the "start)" section
rfcomm bind all
# At the beginning of the "stop)" section
rfcomm release all
Start pppd to connect.
Start up pppd.  Command line first, but because we’ve called it ppp0, you will later be able to do this via the normal ubuntu eee networking menu in the menu bar.
% pppd call ppp0
You should now have a ppp0 interface in your ‘ifconfig’ output that is up and running. The output should look something like this:
# pppd call ppp0
Press CTRL-C to close the connection at any stage!
defining PDP context...
rAT
OK
ATH
OK
ATE1
OK
AT+CGDCONT=1,"IP","general.t-mobile.uk","",0,0
OK
waiting for connect...
ATD*99#
CONNECT
Connected.
If the following ppp negotiations fail,
try restarting the phone.
Serial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/rfcomm0

You can hit control-c on the pppd process and it will shut down the connection, then you can release the rfcomm binding.

So… as I was saying… It’s not the easiest thing in the world to get going, but once you’ve got the hang of it, and set it up once you’ll have a connection everywhere you go.