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.

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).

So Ubuntu 7.10, codename “Gutsy Gibbon” was released today, and as I always like to live at the edge, I thought I’d upgrade - well, at least I tried. The update manager stopped responding multiple times when trying to download the updater script. A quick Google search, let’s see how the servers do this… there’s a command-line tool called do-release-upgrade, maybe this one is more stable?
First it seemed it was not, since it took about 5 minutes just to find that there’s an upgrade, but it did the job or at least does it until now, and I’m already at downloading packages. At the moment of writing, I’m downloading libcroco3 (whatever this is - funny name, though).

New post will follow once the system is running Gutsy Gibbon.