[Idea] Retries for backup operations
- Dominant language
- Perl
- Stars
- 2.1k
- Forks
- 139
- PR merge metrics
- No merged PRs in 30d
Description
I'm backing up ~20 subvolumes on 4 servers via a DSL and a PowerLine connection. Even though everything is quite stable, backup failures (time-outs etc) happen approx. every 1 backup out of 10. The good news is, it's always self-healing – meaning failing backups are resumed the next time. Nevertheless, I have ugly ERROR messages in my notification email.
My idea is that after the entire btrbk run any failed targets would be given a second (and maybe a third, and so on…) chance to resume without errors. If it succeeds, the affected target would be considered as backup successful. So "btrbk-mail" would generate a subject line of "All backups successful" rather than "At least one backup task aborted".
I think it would be better to queue retries at the end rather than retrying immediately. That way, network conditions could be given more time to recover. For example, a run of 4 targets could look like this:
- Target A, successful
- Target B, failed
- Target C, successful
- Target D, successful
- Target B, successful
- → entire Backup successful
I'm aware that I could already now just execute "btrbk run" and then "btrbk resume". The resume would be a no-op if the run was already successful. However, it's not so easy to aggregate output of both invocations into a single notification that can still be successful even if the first "run" (partially) fails. Maybe a more native implementation of the feature would be desired?
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.