@liw 2020 is now closer to passing its acceptance tests.

@liw Why not use borg or restic?

I don't understand the need for shared repository, why not have multiple repositories - if you encrypt, you can't share the data between users anyway, but have to deal with multiple encryption keys per repo.

@juliank "Why not use..." - because I enjoy developing backup software.

"I don't understand..." - I'm going to address that in the architecture documentation, eventually.

@liw I'm curious if you'll manage to write a Rust thing that's easy to package and not end up with a hundred deps, the ecosystem is so split up, it's like node.js.

@juliank > Why not use borg or restic?

I'm currently using Borg. I migrated to it from the original Obnam. At the time, I also considered Restic and Zbackup.

The original Obnam was a complete solution with great UX and great docs. Everyone else supply building blocks.

Borg doesn't have a config file, so you got to script around it. It doesn't honour CACHEDIR.TAGs by default. No progress reports by default. No deleting old archives by default.

Borg doesn't even have a default format for snapshots' names. Like, seriously?

No default format for snapshot names! The next thing they'll make me configure is endianness of the on-disk datastructures.

I'm a bit fuzzy on Restic now, as I haven't touched it in three years, but my recollection of it is "a slightly better Borg": nicer CLI, faster backups, worse compression. Evidently, "slightly better" wasn't good enough for me to pick it over Borg.

Zbackup is a really cool deduplicating compressor for tar files which happens to have "backup" in its name.

So yeah, Obnam2 isn't something you would migrate to (although I will), but it'll probably be a great first backup tool for people who never done backups before. And I wager most users will stay, because it's probably going to be great.

@liw actually gave a talk (at DebConf, I think) about a default backup solution for Debian. He really cares, both about the backups and the users.

@liw What's meant by "live data" in this context?

1TB net capacity is ... pretty modest these days.

1TB of incremental update is more substantial, though I'm not sure how that compares with major system loads (YouTube, Soundcloud, Facebook, Twitter, enterprise RDBMS, etc.).

Text vs. blobs, etc.?

@dredmorbius @liw Napkin math for Facebook: 350M photo uploads per day at 1MB per photo is around 1TB of incremental updates per 4 minutes.

@dredmorbius Live data is the data you want to back up.

A terabyte is twice the amount of storage I have in my laptop. It'll do for a start.

@liw OK.

Desktops are well into the multi-TB range now. Laptops tend to run smaller, mostly due to SSD / costs.

@dredmorbius Yep. Once Obnam2 manages a terabyte easily, I'll up the goal.

@dredmorbius Also, of course, I don't want to buy a lot of large hard drives to test bigger data sets properly. Maybe some day.

@liw Right. Anyhow, you answered the question, I've got a good notion of scope.

Nothing to report on FUSE, BTW.

@dredmorbius I've since started on a FUSE implementation, here's the sub-thread about it: functional.cafe/@minoru/105051 PoC seems good, now waiting for more detailed requirements so I can figure out how to evolve the program.


@dredmorbius Oh, so that is where all the GItHub stars are coming from! Thanks for sharing the link :)


Sign in to participate in the conversation

Lars and friends