The numbers speak for themselves – in my opinion RapidShare is completely unusable at the moment (and even more for less tech-savvy people than for me).

svn propset $propertyName "`svn propget $propertyName $fromFileName`" $toFileName

# add svn propcopy
function svn() {
    case "$1" in
        pc|propcopy)
            propName=$2
            fromFile=$3
            shift 3
            `which svn` propset $propName "`\`which svn\` propget $propName $fromFile`" $@
        ;;
        *)
            `which svn` $@
        ;;
    esac
}

Update: Thanks to Raim for the wildcard support. Using subversion auto-props is an option for files, but unfortunately, auto-props don’t work on directories yet.

• Co-Workers

  Colleagues probably have the largest impact on the atmosphere at work (at least when working in an office with a couple of other people around). Whether they are friendly, open and humorous (jokes make work a lot more fun) is one of the two key factors deciding whether I feel comfortable working at that place.
  Unfortunately you hardly talk to your co-workers before picking up work, but that's probably why there's a probationary period…

• Your Boss

  They guy in charge at your company can make your work life a misery. If he doesn't like you (or he's a complete id**t) and you don't have backup from your colleagues work can be a pain.
  Hey bosses, if you're reading this, here's to you: how to be a good boss (PDF document, 98KB) at number17.com

• Your Client(s)

  If you're working in the services sector you're working for someone. That's fine, however there usually is a simple problem with this person (or these persons, depending on whom you're working for this might be a large user base): they've got the money. And as we all know having the money makes you the king.
  We all know the saying customer is king, but sometimes you should (at least try to) parent your customers to be less exhaustive towards you.
  Oh, hey clients, read this: how to be a good client (PDF document, 66KB) at number17.com

• Equipment

  This one's not a very big part, but it helps if you can work with a somewhat current system. Oh, and two screens are luxury, too.

Inspired by Lektion in Unusability und “Placebo forte!” on Keep Smoking
number17 comics via pixelgraphix.de

I can live without the rescue system, but no backup? No way.

Since I don't have a dedicated Linux box around at home, I needed to store the backup on my Windows PC. There's a problem with storing files from a Unix system on Windows though: You'll lose the owner, group and permission data for the files, since the file systems supported by Windows can't store this information. A backup without this metadata is useless, though.

Finding a solution

Some kind of container solution was needed. Tar archives support Unix permissions, however packing all files into a huge tar file would require transferring all data on every backup run. My internet connection at home is not T1, so transferring all data every time I do a backup is probably not a good idea (and it's perfectly useless, too).

There's rsync — the state-of-the-art tool to transfer only the changes (yes, changes, not only changed files; very useful if you have some multiple GB files around). So combining rsync and tar seems the way to go.

I could have packed all files into a huge tarball and rsynced it to my PC (effectively only tranferring the changes), but that would mean the tarball would need to be stored at the server (at least temporarily). Now imagine the disk is 95% full and you're trying to pack the whole filesystem — we have a problem here.

Fortunately I'm not the first one facing this problem: Thanassis Tsiodras outlines a way to backup your Linux server preserving permissions to a Windows PC using a loop-mounted file system on a Samba share.
This technique would require a Linux box, though. Bummer! (If I had a Linux box around, I'd backup to it directly).

Setting it up

So I went with Virtualization: I remember having an old version of Parallels Workstation (now VMware Workstation) laying around. This should do the job. I installed a minimalistic Debian Etch in a virtual machine. The virtualization software supports folder sharing with the host operating system after installing some kernel extensions. Sounds good for my needs. Installed the kernel modules (I had to compile them, since there were none pre-built for my kernel), added a shared folder and found it in /mnt/hgfs/backup/.

#cd /mnt/hgfs/backup/ followed by
#dd if=/dev/zero of=destinationfilename bs=1M count=1 seek=150000
provided me with a 15GB file full of zeroes to put my file system to. Notice the seek parameter; on file systems supporting sparse files (NTFS does, FAT32 does not) it prevents physically writing 15GB of junk to the disk, but will instead create a file that only looks like it was 15GB. Physically this file is only a couple of KB large. If you need more than 15GB, adjust the seek parameter. Basically the block size (bs) times the seek parameter equals the size of your file system.
Next I mounted the file to a loopback device:
#losetup -f /mnt/hgfs/backup/destinationfilename
-f will tell losetup to use the next free loop device and print it's name to stdout.
Now I had to create a file system on the loopback device. You can chose whatever filesystem you think is best, I went with ext3:
#mkfs -t ext3 /dev/loop0
Make sure to substitute /dev/loop0 with the device losetup printed after mounting.
Finally, I mounted the file system by executing
#mount -t ext3 /dev/loop0 /media/backup.
In this case the device /dev/loop0 is mounted to /media/backup (the folder needs to be created before) using the ext3 filesystem driver.

Make it stick

You wouldn't want to execute losetup and mount every time you start the system, so here's what you need to add to /etc/fstab to have the file mounted automatically on startup:

/mnt/hgfs/backup/destinationfilename /media/backup ext3 loop,defaults 0 0

Backup

Finally you need to use rsync to backup the files. I wrote a small shell script for my needs:

#!/bin/bash
# make sure we're in ~; adjust this, if you want your rsync-backup.err file to be elsewhere
cd
# remove old log file. you could use logrotate for this, if you want to do it right
[ -f rsync-backup.err.gz ]
rm -f rsync-backup.err.gz
# gzip existing log file
[ -f rsync-backup.err ]
gzip rsync-backup.err
# do the rsync; this will sync remote /* to /media/backup
rsync --delete avze ssh servername:/ /media/backup/ 2>rsync-backup.err

You might ask why I didn't backup to the disk of the virtual machine directly. Doing it this way allows me to exchange the virtual machine without the data getting lost (the machine could even refuse to boot, and the data would still be there).