Support for environment variables

[dimejo]

Does rustic support environment variables? I tried some variations of restic's env variables but that doesn't seem to work.

[aawsome]

No, environmental variables as not yet supported.

I was actually hoping to get easy support for config files which maybe would have superseded environmental variables.
However, clap does not yet support config files but does support environmental variables. So it should be easy to implement this. Which variables are you looking for?

[aawsome]

with #134 the following env variables were added:
RUSTIC_REPOSITORY
RUSTIC_REPO_HOT
RUSTIC_PASSWORD_FILE
RUSTIC_NO_CACHE
RUSTIC_CACHE_DIR

Please tell if you are missing more environmental variables!

[dimejo]

I was mainly looking for RUSTIC_REPOSITORY and RUSTIC_PASSWORD but RUSTIC_PASSWORD_FILE works aswell.

Thanks for the fast implementation!

[aawsome]

I just merged #161 which also added support for RUSTIC_PASSWORD and RUSTIC_PASSWORD_COMMAND

[dimejo]

I really appreciate all the effort you put into rustic/restic!

Unfortunately I won't be able to further test this as I stoppped using restic and switched to Kopia. Restic (and its repository format) lacks too many features which I had to work around. And I don't see this change anytime soon. 😞

[aawsome]

No problem. Would you mind telling the features which you are missing? One of the reasons I built rustic was exactly this: missing features and too slow development in getting features to work within restic.

[dimejo]

• The feature that I personally missed the most was a configuration file. Countless wrapper scripts have been created to complement something that IMHO should be build in. I do understand that it is very difficult (as can be seen by the different approaches of wrapper scripts) to come up with a format that satisfies most people. Especially as the format can't be changed easily after it has been commonly used.
• Proper access control for multiple clients sharing a repository. Kopia by default allows to share a repository between clients and benefit from deduplication while restricting each client to only read its own files. With restic you need to decide between privacy and deduplication.
• I would have loved to have a --loglevel (debug, info, warning, error) and --logfile option. Having to deal with --quiet, -vvv and redirections is pretty annoying. Plus I never understood why restic logs unsuccessful actions when it automatically restries and succeeds.
• Lock-free pruning was one of the biggest challenges I faced with restic, especially with big repositories and lots of clients. But you already tackled that issue.
• Besides restic-browser there is no real GUI or WebUI for restic in active development (that I know of), which makes it completely unfit for end-users.
• Finding specific versions of a file is still a mess in restic because you can't sort by date when using restic find.
• Diffing snapshots for changes can be really time-consuming. Kopia automatically hides snapshots that don't contain any changes.
• Error correction is a feature that I always dreamed of but found unrealistic to be implemented in restic anytime soon. But Kopia recently started development for error correction code!
• Empty passwords isn't on top of my wishlist, but it would be handy in some cases, where encrypted repositories aren't needed at all.

[aawsome]

Thanks for your answer which gave me some inspiration what would be useful to implement in rustic 👍

FWIW, here is what I'm planning in rustic:

• The feature that I personally missed the most was a configuration file. Countless wrapper scripts have been created to complement something that IMHO should be build in. I do understand that it is very difficult (as can be seen by the different approaches of wrapper scripts) to come up with a format that satisfies most people. Especially as the format can't be changed easily after it has been commonly used.

Will come soon for rustic, see #169

* Proper [access control for multiple clients](https://kopia.io/docs/repository-server/#server-access-control-acl) sharing a repository. Kopia by default allows to share a repository between clients and benefit from deduplication while restricting each client to only read its own files. With restic you need to decide between privacy and deduplication.

I also thought about adding this. There could be some rustic serve command which reads ACLs and serves the repo. Then a rustic -r rustic:<SERVER> would access it. This is however something which needs architectural changes and is a bit postponed for rustic. (see #171)

* I would have loved to have a `--loglevel` (debug, info, warning, error) and `--logfile` option. Having to deal with `--quiet`, `-vvv` and redirections is pretty annoying. Plus I never understood why [restic logs unsuccessful actions when it automatically restries and succeeds](https://github.com/restic/restic/issues/3613).

Actually logs/output are a pain point with rustic ATM. There are some parts deep in the code where output is generated, which is not well-designed. There are nice rust crates which solve these for a library. I guess this will be tackled when rustic is separated into a library and a CLI.

* Besides [restic-browser](https://github.com/emuell/restic-browser) there is no real GUI or WebUI for restic in active development (that I know of), which makes it completely unfit for end-users.

For rustic, I don't plan a GUI. However, I do plan to separate the code into a high-level library which basically offers all CLI commands like backup, snapshots, diff etc. and a CLI-only code which then doesn't do much except calling the library.
After this, hopefully some GUI-developers are willing to create a nice GUI for rustic!

* Finding specific versions of a file is still a mess in restic because you can't sort by date when using `restic find`.

Implementing find and all the associated requirements like a nice file history, etc are actually on my high-prio list!

* Diffing snapshots for changes can be really time-consuming. Kopia automatically hides snapshots that don't contain any changes.

Is implemented in #170 .

* Error correction is a feature that I always dreamed of but found unrealistic to be implemented in restic anytime soon. But [Kopia recently started development for error correction code](https://github.com/kopia/kopia/pull/2270)!

Ok, this is a feature I won't work for in the next year. So to get fast rustic support, someone else would need to jump in!

* [Empty passwords](https://github.com/restic/restic/issues/1786) isn't on top of my wishlist, but it would be handy in some cases, where encrypted repositories aren't needed at all.

Empty password actually already work with rustic. However, disabling encryption would lead to problems as the assumption is that if you create repo files with identical content twice, the name will still be different. This is currently "guaranteed" (at least with extremely high possibility) by using a random nonce for the encryption.