With the recent release of obnam 1.4, I thought it might be a good time to look at it again. I had first looked into it when it was a bit before it's 1.0 release, and at the time it had a number of issues that made me decide to not use it and keep my existing rdiff-backup setup running here at home. Happily, with 1.4, almost all of those issues are cleared up. Some background: (which you can possibly get better at the upstream link above). obnam is a backup system that uses sftp (and optionally gpg encryption). It stores things in efficent 'chunks' on the backup store system. If multiple clients backup to the same store, it only keeps 1 of each 'chunk'. The first backup is full/all files, and after that it's deltas. You can run backups as many times as you like, and 'forget' old generations if you like (by default everything is kept forever). With previous versions you could backup multiple machines to the same backup store, and get dedup, but you could only backup clients one at a time. With 1.4, there's locking so you can indeed have multiple clients backing up to the same store at the same time. They might wait for locks at times, but they won't cause any problems or have to wait for the entire backup to finish. Compression seems to work fine (--compress-with=deflate), although it's not entirely clear how much space is saved by the compression. The pre 1.0 versions were painfully slow on rerunning (after the inital full backup was done). At least with some smaller test directories here, 1.4 really seems to do a much better job of that. This is one of the main reasons I didn't start using obnam, it would have taken more than a day to do a daily backup. We will see how it does with larger backup sets over the next few weeks here. The one issue (which I admit may be a personal one) left to me is that obnam has it's own format. The nice thing about rdiff-backup and some other setups is that you can simply copy files from the backup and look at them they are all there. With obnam you need to use it's command line (or there's a FUSE filesystem being worked on) to see whats in your backups, etc. If the backup store got corrupted, bad things would happen. On the plus side the upstream author really takes pains to make sure things are robust on the backend, so this might be nothing to really worry too much about. So, I'm going to try and do some full backups and see how obnam works out over the next week or two. Look for a followup then. If all goes well it could well replace rdiff-backups here and possibly help with Fedora infrastructure backups down the road.