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 cryptography
Typer type-safe command line parsing
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:
Any feedback an contribution is appreciated.
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.
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.
There is also rustic (in rust): GitHub - rustic-rs/rustic: rustic - fast, encrypted, deduplicated backups powered by pure Rust
The real question is: where are perlic, cobolic, fortranic and lispic?
This shows the importance of the restic design document. It allows anyone to recover data without relying on restic code.
I agree. It also shows the power and importance of free and open source software.
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…