Uback 0.7 – A universal bridge between backup sources and destinations

Hacker News

Share card

Uback 0.7 – A universal bridge between backup sources and destinations

Throughout my career, the "who handles backups" job (in a "we have our data on our own servers, not in the cloud" context) has always ended up on my plate. One of the most painful aspects, along with crons. My observation: - When you start from the "what do I want to back up" perspective, there are tons of excellent solutions. Using ZFS? Type "zfs backup" into your favorite search engine and you'll find something that fits; the same goes for MariaDB, Postgres, btrfs… - When you start from the "where do I want to back up to" perspective — S3, FTP, WebDAV? Same thing, you're spoiled for choice. However, once you ask "I want to back up this to there ", compatibility between the two can get thorny. Add requirements like "I want my backups encrypted," and you might not find a solution at all. And even if you do? Congratulations, you now have as many backup tools as you have "what I want to back up" / "where I want to back up to" pairs, each with its own separate configuration in a separate format, with different encryption keys in a different format. And when your annual disaster recovery drill comes around… well, let's just say it makes you want to leave this planet. So 5 years ago I created uback, a system that acts as an intermediary between "sources that produce backups" (a few are built-in, but the idea is you can write your own in shell or your favorite programming language) and "destinations that can receive those backups" (same), handling encryption, compression, and retention policy. I never promoted it until now, but I'm taking the occasion of 0.7(.1) to do so: I consider this version "final," feature-complete. Going forward, it will very likely be bug fixes and routine maintenance only. Not in the "I'm abandoning the project" sense, but in the "it does everything I need, and I don't see anything to add" sense. The only area I'm not entirely happy with is the configuration system, but the problem is legitimately (and surprisingly!) complex, and I don't really see how to do significantly better. Why not 1.0 if I consider 0.7 "final"? Because I'm reserving "1.0" for the (unlikely, but you never know) scenario where "the project gains traction, with many users and contributors, and after extensive feedback we publish a definitively stable 1.0" (in other words: when it's not just me who considers the current version final). In the meantime, what do I reserve the right to break in 0.x? Everything except the ability to restore old backups. Are there good chances I'll (intentionally) break things? The odds are low for the configuration system, virtually zero for everything else.