Jonathan's blog

I was musing today about the lifetime of my data, and what might happen to it after I die. I’m a jolly character, aren’t I?

But there are two questions here. First there’s the question of my private data – e.g. online banking stuff and other personal documents that I want to keep to myself for now, but may well have to be released to the executor of my will or whatever.

Then there’s the question of the data I’d love to share. For example my photographs and musical recordings – I’d like to think that they will persist long after I’ve gone. Maybe even wind up in a futuristic museum so people can marvel at how we used to live. Perhaps.

Private data

If I died tomorrow, would my family be able to get at my private files? It’s a bit more involved than looking in a box-file on top of my wardrobe. Nobody has an account on my home server and PC except me, and nobody else knows my root password (I hope).

But I don’t want to give anyone access to my data today. I don’t want to create accounts for other people that can access my stuff, and I don’t want to tell anyone my password. Can you imagine telling somebody all your passwords and saying they weren’t allowed to use them until your death?

That’s not to say that my data is totally inaccessible. My disks are not encrypted so booting from a live CD would be an easy way to read the data without having to log on as me. This would be an easy job for most of my geeky friends, but I don’t think my parents, brothers or girlfriend would be able to do it. Would my next-of-kin have the initiative to ask one of my colleagues or friends to “hack” my systems in the event of my untimely death?

I expect if the circumstances of my death were suspicious, police would confiscate my computers anyway and examine them. A police computer expert would have no problem in extracting the data, but whether or not they would hand it over to my family is a different question.

Of course for accounts I hold with third parties, such as online banking, email companies and of course my employers, it is usually possible to present a death certificate and the account will be opened for the executor.^{[1, 2]} But this doesn’t apply to my systems.

The flip-side of allowing access to my data is that the executor or next-of-kin gets access to all of my data. After I die, I may well be happy for the executor of the will to browse my financial and legal documents, but what if I don’t want him or her to know about my plans to take over the world, or my illegal downloads? What if I have some embarrassing secrets that I don’t want my family to find out about?

The only two approaches here are to specify in my will which files should be deleted and which should be kept^[3], or to encrypt everything that I do not wish to be read. Bear in mind that if you wish to make the encryption effective, you will also need to encrypt the backups.

Maybe the best idea would be to write down my password and some brief instructions for accessing my data if necessary, and then seal this in an envelope to be kept in a safe place with my will. Anything I don’t want seen, ever, can be encrypted. Then it should be straightforward for the relevant people to get access to my private documents, with minimal risk of abuse.

Public data

As I touched upon in the introduction, the second section is to do with the longevity of my created data. A large part of this is to do with choosing an appropriate format, and ensuring that the format stays current.

For example, my photos are currently stored on a hard disk, formatted with the ext4 filesystem, and saved as TIFF images. They are backed up, but that’s mainly irrelevant here. The point is that I don’t expect my hard disks to still be working in ten years’ time, and there’s a fair chance that today’s popular filesystems won’t be in widespread use after a decade either.

While I’m alive, it’s easy for me to move my things around. Let’s suppose next year hard disks start to become obsolete and a new type of memory card becomes commonplace. It will be easy for me to copy my photos from my hard disk onto this new memory card. I can also convert my images from their TIFF format to tomorrow’s shiny new format if necessary.

But who will do this after I’m dead?

It was easy for me. After my grandad died, I inherited a box of 35mm slides, as well as some 35mm negatives and some 6″×4″ prints. Things you can see with your eyes don’t tend to go obsolete in a decade. Provided I look after these physical photos and protect them from heat, light and moisture, they are likely to last for decades or centuries.

I’ve also scanned them in and archived them on disk – where they are safe from paper-curling humidity, but still prone to obsolescence as I mentioned above.

So long as I have backups and I keep with the times and convert my photos to whatever format is appropriate and save them on whatever media is current, I can’t see a problem. I could even make prints of all my photos and store them securely.

The snag comes when I die, and I will have to entrust my photos to a descendant. Hopefully they will treasure the photos and look after them, as I am doing with my late grandfather’s work – but there’s no guarantee. If I didn’t have an interest in photography myself, it’s entirely plausible that I might have declined my grandad’s slides.

It seems here that the best approach is to preserve my data while I’m still alive and kicking, and make it known to my family that I wish my photos to be looked after when I’m gone. Hopefully they will take heed!

Perhaps undermining the tone of this whole article, I might add that I’ll be dead so why should I care!

References

1. https://windowslivehelp.com/community/t/150085.aspx
2. http://www.news.com.au/technology/story/0,28348,26303927-5014239,00.html
3. Maybe this could be automated, and my will could specify the path to a script that deletes some things and preserves others.

In this article I will talk you through how to set up automatic backups from your Linux computer, to another Linux/Unix computer of some description. This works for OS X, too. I have tested these instructions on Fedora and Ubuntu.

These backups will use rsync, a handy program for copying only the files that have changed. The first backup will obviously copy all of your stuff, but after then if you only create/change one text file, it only copies one text file.

Your receiving computer (let’s call it the server) needs to be running an SSH server. This is standard on almost every Linux/Unix/OS X computer. If not, consult your OS documentation for guidance on how make it go. Don’t forget you need to poke a hole in your firewall (port 22/tcp) as well as setting up the SSH server.

Setting up key authentication

Your sending computer (the client) needs to be set up with a private/public key pair. This is so it can communicate with the server without having to ask for a password. First check if you have keys by doing the following:

jonathan@hyperion:~$ ls ~/.ssh

If this command results in displaying the files id_rsa and id_rsa.pub then you are all set. Skip ahead to the step about copying the key to the server.. If those files or that directory don’t exist then you’ll need to create them, like so:

jonathan@hyperion:~$ ssh-keygen

Accept the default options and it will create a private/public key pair for you. Now we set permissions on your keys to keep them secure, and to ensure that the key authentication works properly:

jonathan@hyperion:~$ chmod 600 ~/.ssh
jonathan@hyperion:~$ chmod 600 ~/.ssh/id_rsa*

Copy the public key (identified by its .pub extension) to the server. Don’t whatever you do copy the private key to any other computer. You should treat the private key as securely as your password Copying is easiest using scp, but you can use a USB memory stick, email attachment or any other method of copying data.

jonathan@hyperion:~$ scp ~/.ssh/id_rsa.pub jonathan@server.com:~

Now you need to log onto the server and tell it to trust your key. Be doubly sure to use a double >>, otherwise you will overwrite the authorized_keys file rather than appending to it.

jonathan@server:~$ cat id_rsa.pub >> .ssh/authorized_keys
jonathan@server:~$ chmod 600 ~/.ssh/authorized_keys

Your key authentication should now be fully set up. You can test it by connection to the server from the client using ssh – if the key authentication is set up properly you will get automatically logged in without being asked for a password.

The backup script

Consider what you actually want to back up. Most likely just your home directory, i.e. /home/jonathan. Also think about where the backups will be stored on the server. If this is your home directory again, then no problem. If you wanted to store it in a different directory, you would probably need to grant write access to that directory to your user account.

In this article, we will assume that I want to back up /home/jonathan on my client to /media/private/Backup/hyperion on the server. So let’s make a script to do this. Call it backup.sh and save it in your home directory. Change the paths, usernames and server name in this example to suit your setup. You can also use an IP address instead of a server name if you don’t have DNS running on your LAN.

#!/bin/sh
rsync -rutvz --delete --exclude=".*" /home/jonathan jonathan@zeus.jonathangazeley.com:/media/private/Backup/hyperion


Note: the line starting with rsync is one long line – don’t put a linebreak in
Note: this excludes hidden files (ones starting with a dot, such as .test). If this is not what you want, remove --exclude=".*" from the rsync line.

Set it as executable, and run it for the first time

jonathan@hyperion:~$ chmod +x backup.sh
jonathan@hyperion:~$ ./backup.sh

Depending on the size of your home folder, the first run could take ages. I strongly recommend having a gigabit LAN in your home for copying large amounts of data. After it has completed, check on the server that your files have indeed made it across to the place you intended.

Now run it again. It should take only a few seconds to run, as no files have changed since you last ran the script.

Create a text file in your home directory with a few words on it. Run your script again. Check the new file got copied to the server.

Delete the text file from your home directory. Run your script again. Check the the file got deleted from the server.

Setting the script to run regularly

If your server and client are on the same LAN, the server is always on, and it’s a fast LAN, the best option will probably be to set this to run regularly.

For example, my desktop PC is set to sync with my server every hour. They are both on gigabit so even if I’ve got loads of new data to copy it rarely takes longer than a few minutes.

My server then syncs with an offsite server every night at 3am, when I don’t notice if my broadband is running slowly due to the traffic. (Yes, maybe you consider this to be OTT, but I have lots of irreplacable photos and recordings, and had you considered what might happen to my data if I was burgled and both PC and server were taken, or if a fire destroyed my home and its contents?)

For scheduling regular jobs, cron is your friend. The syntax can be a bit odd but if you open up /etc/crontab in an editor, you can add some comments to the start as a reminder of what each field means. When you’re done, add a new entry to the bottom, like I have here.

# +---------------- minute (0 - 59)
# |  +------------- hour (0 - 23)
# |  |  +---------- day of month (1 - 31)
# |  |  |  +------- month (1 - 12)
# |  |  |  |  +---- day of week (0-6) (Sun=0 or 7)
# |  |  |  |  |
# *  *  *  *  *  command to be executed

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 3 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
30 * * * * jonathan /home/jonathan/backup.sh

This command tells my script to run at 30 minutes past the hour, every hour of every day of every month. It is vitally important that you run the script as the same user you configured the key authentication for, otherwise it won’t be able to authenticate. Finally fill in the full path to the backup.sh script we prepared earlier.

Setting up an icon in Ubuntu Netbook Remix

If you are running Ubuntu Netbook Remix (UNR), I assume you are also using a netbook. The hourly (or daily, etc) backups described above might not be what you want – you probably don’t have a permanent network. And what if you’re connected via a 3G USB modem, or the slow wireless at friend’s house? Unlikely you’d want to copy several gigabytes of data over such a connection. So the obvious choice here is to put you in charge of when the script runs.

You already know how to run the script manually from the command line, but here we will set up a pretty icon for your desktop. While these instructions are particularly aimed at UNR (because I have it on my EeePC), a similar method will also work in any GNOME environment.

• Click on Preferences, and then Main Menu
• Under the Favourites category, click New Item
• Give it a sensible title, like Backup to server
• Fill in the path to your script
• Pick your favourite icon

That’s it! Now you can just click the icon to start a backup when you know you’re in a position to make a backup.

The backup icon on my desktop