Goal

My goal for today is to introduce a new chunk type to represent an entire backup. That means, one snapshot of the live data.

Plan

Add a new variant Chunk::Backup that contains or references all the data in a backup.
Change obnam backup finish to create and upload a backup chunk.
Add new command obnam backup list to list all backup chunks.

Notes

The minimal data about a backup is "list of chunks for the files database" and "when was backup made". Representing time is always a fun problem. For backups I need a format that will work for a long time: someone might need to restore backups many decades in the future, and the software they use then needs to understand the timestamp.
The Rust standard library has the std::time::SystemTime type for representing a point in time. However, it is an opaque type, not suitable for long term storage.
A SystemTime can be converted into the standard Unix time representation as "seconds since the beginning of 1970". Storing that in a 64-bit integer would work fine. Integers are also easy to order. However, it would need to be converted to a human readable form. I do not expect that to be a problem in the future, either.
I may need to change this in the future, but for now I'll store the backup timestamp as a Unix timestamp.
For now I'm also only storing the time when the backup chunk was created. I may want to add the start and end timestamps for the backup run.
I will, however, add a custom type for time stamps rather than using bare integer types. Future me will thank current me for once.

With that, I can define the backup chunk variant:

Backup {
    metadata: Metadata,
    when: Timestamp,
    files_db: Vec<Id>,
},

I am at this time opting to assume the files database fits in one chunk. This is for simplicity. I will change this later, but it's a short-term compromise for easy of development.
Actually, no. I have a helper function that uploads a file as chunks and that returns a vector of chunk IDs, so I'll just store that in the backup chunk. That's easier than checking there is only one chunk.
I'd forgotten I didn't add verification scenarios for the backup commands. It's because the current CLI is very much temporary. Oh well. I still don't think it's worth it, but I've also forgotten how to use the obnam backup commands correctly and thought I'd check the tests.
The reason I wanted to check how this is used is I'm having trouble getting obnam backup add to work. It complains it can't open the client chunk: it can't decrypt it. If I try to open it directly with obnamn client show it works.
A-ha! Its because I'd misunderstood the --client-key option. It takes the actual key, not the name of the credential.
After that the rest was plain sailing. Merged.
I really need to make obnam easier and less error prone to use, very soon. I may well be doing code refactoring at the same time.

Summary

Got everything done today, despite a lengthy debugging tour to find out I was using the command line wrong.

Support?

If you'd like to fund Obnam development, see my funding page. My high level goal is described on the architecture page. What is most important about backup software to you?