Only run backups when battery is full

[ktosiek]

Is your feature request related to a problem? Please describe.
On a slow or metered connection backups can take most of the bandwidth.

Describe the solution you'd like
It should be possible to skip scheduled backups if the available connection is known to be metered, or even when it's not known to be unmetered. A running backup should be stopped if we lose a suitable connection.

Describe alternatives you've considered
The only alternative I know is enabling notifications and stopping the backup when I know I don't want it to run, which is not very handy.

[m3nu]

The Wifi settings already attempt to solve this problem. Under Schedule > Networks > Allowed Networks. Select only "unmetered" networks to use for automatic backups.

How would the feature suggested here be different and if so how would it be implemented?

[samuel-w]

But the button is not visible if you don't have Wifi, yet it is possible to have a metered wired connection.

[ktosiek]

I think that's only implemented for OSX.

On Linux with NetworkManager you can mark connections (of any type, not just WiFi) as metered, and this is honoured by some applications. NetworkManager even tries to guess that status for active connections (for example tethering through Android is marked as "guessed as metered").

The options I feel would make sense are:

• Use any connection
• Only use unmetered connections (which would be a good default, but needs a warning in the UI saying why scheduled backups are paused)
• Use explicit WiFi whitelist (but what about Ethernet connections then? Are those listed too on OSX?)

[m3nu]

Using NetworkManager to grab Wifi details on Linux came up before and would be a nice addition.

[ktosiek]

How does the networks list work on OS X? Is it just WiFi networks? Will backup run over cable when some WiFi network is selected from the list?

[samuel-w]

Communication with NetworkManager takes either another dependency https://pypi.org/project/python-networkmanager/ or DBus. Which one is prefered?

[m3nu]

If DBus is not too hard to implement, I'd rather avoid more deps. Else mark it as Linux-only in setup.cfg.

And before writing any code, feel free to summarize your planned implementation/changes.

[ktosiek]

I think we don't need python-networkmanager: the most interesting part for us is the SSID decoding function (NetworkManager provides raw SSIDs), and the library uses a different DBus implementation than Vorta already uses for notifications. And that's for enabling the WiFi block list, which I think is out of scope for this issue.

For the UI I'd just add a "Don't run backup over metered networks", enabled by default, and visible only when NM is available.

The actual implementation should have two parts:

1. An additional check in BorgCreateThread.prepare
2. Some way of stopping the backup if NM tells us we moved to a metered connection (for example, when user marks the current connection as metered). This should be possible without polling, by listening to DBus signals, but I'm not sure where something like that should live in the application code.

[ktosiek]

@m3nu do you think the approach described above is appropriate? I wonder if some additional UI that tells the user that the backup is not going to run and why would be needed, or can that be added later? I'm already thinking about other conditions, like being on battery power.

[m3nu]

Yeah, this can work and it's nice to see how you guys are coming up with new ideas. Battery power is a nice option too and should be easy to implement on all OSs.

[samuel-w]

For the battery power, we can use psutil which is already a dependency, and a UI like

[x] Run on battery power only when above [qspinbox] % charged

and place it in the schedule page, only visible when there is a battery. To run only when on charger there would be a tooltip that says "Setting this to 100% will run scheduled backups only when on charger" on qspinbox

[ktosiek]

Is there some way to get notifications from psutil? It would be great to not just check the condition once, but actually be able to stop the backup when the conditions change.

For networks it kind of happens by itself - changing the connection will probably make Borg timeout. But for battery we'd need to monitor the inputs somehow. Using something like UPower on Linux or UIKit on OSX can give us change notifications without polling, but I don't know if there's a library that abstracts over them.

[samuel-w]

Not that I know of, but there could be a loop to poll every second or so. I don't think its needed, since it complicates the code and isn't really relevant for the typical use-case of personal backups, which complete in a few minutes at most.

[ktosiek]

The backups being short is a good point, but they eat a lot of CPU. And I'm not sure if they are that short on HDDs, I've only tested on SSDs.
Maybe a poll every few (even 30?) seconds, and stopping if 2 consecutive polls say the conditions aren't right anymore? This would make the whole thing more robust against accidental power cable disconnections. I know this is getting a bit complicated, but it might work pretty well. And with borg 1.2 running a checkpoint after first SIGINT, we wouldn't waste much of the compression/encryption and upload work.

On the other hand, is there some OS-level "low power consumption" thing we can hook into on any OS? Something like Android's battery saving? It might not be as flexible, but would be a great default.

[samuel-w]

macOS does have a power saving mode https://support.apple.com/en-us/HT202824 but I have no idea what the API is.
For Linux there are so many ways to have power saving mode (TLP, pm-utils, slimbook, others) that it will be too hard to cover all cases.

Polling would be nice, but I want to reduce the complexity of this, and laptop users should know how long their battery lasts.