Pyrrhic: restic implementation in Python

Community
1

I just released an alpha version of pyrrhic - a Python implementation of restic.

It leverages many modern Python features like type annotations for:

  • mypy static type checking.
  • msgspec JSON serialization
  • AES/Poly1305-AES :lock: cryptography
  • Typer type-safe command line parsing
  • :desktop_computer: rich pretty-printing and syntax-highlighting (JSON) terminal output

This is not intended to be a replacement for restic, but rather a supplement and option to quickly prototype new ideas.

pyrrhic already has a progress bar for index-loading / restores and can resume restores:

screenshot
screenshot1036×641 87 KB

Any feedback an contribution is appreciated.

7 Likes
2

The CLI looks great, the code impressively clean and concise. Do I understand it right that this is a completely independent implementation and not wrapping any restic code? As redundancy counts with backups, it is also good to know that there are two tools available to restore data.

1 Like
3

Thank you!
Indeed: I only used the restic design document to do this implementation.

At its core, restic has a fairly simple data storage model. It reminds of the elegant Git Plumbing-and-Porcelain design with the only difference that restic plumbing also provides encryption and authentication codes.

I can only recommend everyone to take a look at the internals. It is very informative.

1 Like
4

There is also rustic (in rust): GitHub - rustic-rs/rustic: rustic - fast, encrypted, and deduplicated backups powered by Rust

1 Like
5

The real question is: where are perlic, cobolic, fortranic and lispic?

4 Likes
6

This shows the importance of the restic design document. It allows anyone to recover data without relying on restic code.

3 Likes
7

I agree. It also shows the power and importance of free and open source software.

2 Likes
8

I fully agree! When writing rustic, I also just used that document in the beginning. While it is very good to get things starting, I must say there are some details which are not described and where I needed to have a look at the code - to be fair, this is all metadata which might not be top prio when restoring:

  • The snapshot file json format is not really described in the design document; it is more an example of an old version
  • The tree json format is not only not described, but also yields some surprises like an in-fact quoted file name (using a go specific quoting) or file modes which are defined in a go-specific manner.

I wanted to submit a PR to point these things out in the design document but so far didn’t find enough time…