Quick start

For those who just want the commands and don't want to wait:

git clone user@hostname.tld:/path/to/git-svn.git git-svn-clone

cd git-svn-clone

git svn init -s svn://hostname.tld/path/to/svn

git config svn.authorsfile $(basename $(pwd))/git-authors

rsync -avpP user@hostname.tld:/path/to/git-svn.git/svn .git/

git update-ref refs/remotes/trunk origin/master

git svn fetch --all && git svn rebase

Full details

So,  what does all this do? Let's look at it in stages.

1. Clone the existing git-svn repository, to get the history and avoid hitting the Subversion server any more than we need to (git clone)
2. Set up the Subversion integration information (git svn init)
3. Set up the translation between Subversion authors (bare username) and git authors (name + email address) (git config svn.authorsfile)
4. Copy the Subversion branch metadata from the original git-svn repository
5. Create the local "trunk" reference that git-svn will require
6. Fetch any new revisions from Subversion (and update the revision map between git and Subversion), and then make sure that "master" points at the head of the Subversion trunk

Bonus tip

If you have a number of git branches, it can be a pain to keep rebasing them to the latest trunk (as Subversion doesn't like non-linear history). This little script may help:

This will automatically rebase all of the branches onto master, although it won't handle sub-branches very well.

The host server partitions were LVM-formatted volumes on top of hardware RAID-1, and each of the virtual hosts were partitioned with LVM too, internally. This means that the restore process will not be at all trivial. With just a complete image of the host system, I would need to restore (deep breath) files on a partition on an LVM logical volume (inside a volume group, on a physical volume) in a VMWare hard disk stored on LVM (logical volume inside volume group of physical volumes) inside a disk image that is itself a file on a disk. How very convoluted.

I used a Gentoo system to restore the data, although any Linux system with the appropriate packages should be able to do it. No searches turned up information on doing all of this, and I had to come up with some of it myself, so I thought I would document the process.

Just to illustrate the complexity of the data layout:

Requirements

The machine that is performing the restore requires:

• Linux
• LVM2
• VMWare Server
• losetup
• NBD (Network Block Device) kernel driver
• file system drivers (if applicable)

Procedure

Boot the dead server (vm-host) using a Linux LiveCD and copy its partitions to files on another drive. If you don't know which partitions the LVM was stored across, you can either copy all of them, or use <tt>pvscan</tt> (possibly after running <tt>vgscan</tt>) to work out which belong to the appropriate volume group. This dump may take some time.

Attach the drive with the partition images to the rescue machine (rescue-host), edit /etc/lvm/lvm.conf on rescue-host, and modify the filter line to allow LVM to scan loopback and network block devices. You'll probably want to change this back afterwards, so remember what it was.

Set up the partition images as loop devices:

Scan for and activate the volume group:

Find the logical volume with the data we're after (LogVol06 in volume group VolGroup00 in this case) and mount it:

Copy the VMWare hard disk files out of the LVM mount, because we know that the volume group stored on them will conflict with the existing one:

Check the partition table on the virtual hard disk:

This will give you something like:

The second partition (with type 8E) is the one we wanted in this case, but it's LVM-formatted. This means we can't use vmware-mount because an LVM partition cannot be mounted normally.

We need to unmount the currently-active volume group on the loopback devices (i.e. the LVM from vm-host):

Now you need a dedicated terminal to mount the LVM partition from the virtual hard disk, as this process must stay running in order to access the virtual drive:

If you have more than one virtual partition as part of the LVM, you'll need to have one terminal for each, and select partition numbers and NBD device numbers as appropriate.
Now find the volume group again:

Find the appropriate logical volume and mount it:

Do whatever you need to do with the data, then unmount it all:

And that's it! I hope this helps someone other than me...

Disclaimer: This is non-standard usage of 4od, and while they may not be able to detect you doing this, there is a chance that this may violate their terms of service. I'm providing this method only for reference purposes, and for convenience in navigating their system, in a similar way to the BBC's iPlayer.

It's essentially simple: instead of bringing the 4od system up in its own little window, use a browser. I've only tested this with IE7 (as that's what runs within the dedicated 4od application window) but I see no reason it won't work with Firefox too, as the BBC site does.

"But wait," I hear you cry. "I don't know the URL!"

Well panic not, for a little network sniffing later gave me this: http://vodapp.grid.channel4.com/c4site-web

Now you can open program downloads in multiple tabs so that you can just click "confirm" on each of them and let the downloads begin. This makes queueing an entire series for download at once much easier!

Enjoy...