resticprofile
resticprofile copied to clipboard
creativeprojects
Account for metered conncetions.
https://github.com/restic/restic/issues/2353
tldr there are 4 states of metered based on
- did the system detect the state
- metered or not resulting in metered-confirmed, metered-guess, unmetered-confirmed, unmetered-unconfirmed (default, very common)
Not sure about MacOS, but I'd guess there as well, OS integration is possible. Setting network (AP) names in resticprofile config doesn't sound sane.
- don't run on metered connections
- after a period of not being backed up, do also back up on metered
- run with 1 thread (in case of roaming / interruptions (by user)), maybe bwlimit?
It is a good idea indeed, but as I was looking around at how to get this information, it looks like it's almost impossible to detect. Most OS don't advertise it very well, and also ... they're kind of guessing anyway.
I wouldn't want to give a false sense of security where the user will end-up with thousands of [insert your own currency here] bill because it wasn't detected properly.
Even though this is an old issue, I'd like to add an idea: Filter by wireless network!
At least for me, the only metered connection I use is my phone's WiFi hotspot which has a known SSID. So by listing this in the config I could pretty reliably prevent backups on metered connections. Maybe a regular expression could be allowed for more flexibility?
This has the added benefit of (likely) not giving a false sense of security since a config option named schedule-ignore-on-wireless-network does not imply any guarantees beyond detecting certain wireless networks (which should ideally be testable and/or throw an error if it is not possible to detect when setting the schedule – not sure if there is a daemon independent way of detecting it on linux but on macOS/Windows it could be pretty reliable I'd imagine).
You could still start a backup on an unmetered connection, and continue on a metered connection.
The backup will keep going if the interruption in the middle is short enough to be covered the retry mechanism of restic 🤔
Good point, would it be possible to abort a running backup if that happens (i.e. by ~nicely~ killing the process)? If I'm not mistaken restic itself is capable of dealing with that.
yes it would be possible to keep checking in the background and send a termination signal to restic