Assessment of the iteration that has ended

The goal of the previous iteration was:

Change the Obnam client to use async Rust to be more concurrent. The result doesn’t need to make optimal use of all cores, but it needs to pass the test suite and needs to work.

This was achieved, though not entirely as originally intended. The Obnam client now uses async for all operations that only read from the chunk server, which at this time is all operations except obnam backup. That work will continue in this iteration.



The next step in the use of async in the Obnam client is to make obnam backup us async. This should improve backup performance on multi-CPU hosts.

Minimum supported Rust version

In #137 Alexander asks what minimum version of Rust should Obnam require. Please add your viewpoint to the issue if you have one, or have experience about this from other projects.


Goal for 1.0 (not changed this iteration)

The goal for version 1.0 is for Obnam to be an utterly boring backup solution for Linux command line users. It should just work, be performant, secure, and well-documented.

It is not a goal for version 1.0 to have been ported to other operating systems, but if there are volunteers to do that, and to commit to supporting their port, ports will be welcome.

Other user interfaces is likely to happen only after 1.0.

The server component will support multiple clients in a way that doesn’t let them see each other’s data. It is not a goal for clients to be able to share data, even if the clients trust each other.

Goal for the next few iterations (not changed for this iteration)

The goal for next few iterations is to have Obnam be performant. This will include, at least, making the client use more concurrency so that it can use more CPU cores to compute checksums for de-duplication.

Goal for this iteration (new for this iteration)

Change the Obnam client to use async Rust for making backups.

Commitments for this iteration

Lars intends to change the obnam backup command to use async (#113). After this is done, the client should be entirely async.

  • #56 – SQLite databases for generations have no metadata about themselves (1h)
  • #113 – Client is not async (4h)
  • #118 – Lacks way to expand a geneneration reference (“latest”) as a generation id (1h)
    • there is already a merge request for this
  • #121 – Release process needs review, update (1h)
    • should probably make at least a trial release
  • #133 – Test suite assumes location of binary (1h)

That’s a total of about 8 hours, rough estimate, for Lars.

Meeting participants

  • Lars Wirzenius