Obnam 1.0 was released during several months when I
had no well-connected server to use for backups. Yesterday I installed a
terabyte disk in a basement with a fiber optic network connection, so my
backupless time is over.
Now, granted, I have a very multi-layered approach to backups; all my data
is stored in git, most of it with dozens of copies automatically
maintained, and with archival data managed by git-annex. But I still like
to have a "real" backup system underneath, to catch anything else.
And to back up those parts of my user's data that I have not given them
tools to put into git yet...
My backup server is not
my basement, so I need to securely encrypt
the backups stored there. Encrypting your offsite backups is such a good
idea that I've always been surprised at the paucity of tools to do it. I
got by with
duplicity for years, but it's increasingly creaky, and the
few times I've needed to restore, it's been a terrific pain. So I'm excited
to be trying Obnam today.
So far I quite like it. The only real problem is that it can be slow, when
there's a transatlantic link between the client and the server. Each file
backed up requires several TCP round-trips, and the latency kills the
bandwidth. Large files are still sent fast, and obnam uses little resources
on either the client or server while running. And this mostly only affects
the initial, full backup.
But the encryption and ease of use more than make up for this. The real
killer feature with Obnam's encryption isn't that it's industry-standard
encryption with gpg, that can be trivially enabled with a single option
(
--encrypt-with=DEADBEEF). No, the great thing about it is its key
management.
I generate a new gpg key for each system I back up. This prevents systems
reading each other's backups. But that means you have to backup the
backup keys.. or when a system is lost, the backup would be inaccessible.
With Obnam, I can instead just grant my personal gpg key access to
the repository:
obnam add-key --keyid 2512E3C7. Now both the machine's
key and my gpg key can access the data. Great system; can't revoke access,
but otherwise perfect. I liked this so much I stole the design and used
it in git-annex too. :)
I'm also pleased I can lock down
.ssh/authorized_keys on my backup
server, to prevent clients running arbitrary commands. Duplicity runs
ad-hoc commands over ssh, which defeated me from ever locking it down.
Obnam can be easily locked down, like this:
command="/usr/lib/openssh/sftp-server"
This could still be improved,
since clients can still read the whole filesystem with sftp. I'd like to
have something like git-annex's
git-annex-shell,
which can limit access to only a specific repository. Hmm, if Obnam
had its own server-side program like this, it could stream backup data to
it using a protocol that avoids the roundtrips needed by the SFTP protocol,
and fix the latency issue too. Lars, I know you've been looking for a Haskell
starter project ... perhaps this is it? :)
D-I beta 1 is in preparation. Commits to level 1 are still allowed but
no guarantee they'll make it to beta1 and therefore wheezy.
A bug-fix release 0.9.12 of 
Howdy party people,
I ve uploaded version 7.0.0 of desktop-base to unstable, which means yes! Joy! By default! :)
Please be sure to report your issues!
So, six days until DebCamp and we are here working in order to have a great Debian Conference for the first time in Central America! 
We are waiting for you!
the hypervisor wasn t configured to enslave the correct physical interface to the correct bridge on boot. My bad. Sorry for the outage. Again.
Today, 
I have recently read 
Short before Debian is 
.
So, I did some yak shaving this morning. Turns out other folk have already run into this and filed a 
I was looking for an excuse to try 
good news of the RCBW week: more & more patches from people I haven't
seen before in the BTS. keep them coming!
