garethgeorge
commented
1 week ago Hmm, its an interesting idea.
Backrest tries to provide error policies on hooks which are supported as a way of implementing a "preflight" check that the network is available etc / that a backup is likely to succeed if attempted.
I'm a bit concerned about blanket retries on backup operations. I'm not sure if backrest would be able to reliably differentiate between an error that prevents a snapshot from being created and an error, say during restic's cleanup steps, that happened after a backup was created. In the latter case it might just keep retrying forever and still creating snapshots.
It might be possible for backrest to integrate a preflight check or a hook type that allows for explicitly checking that the repo is available (e.g. retry later if it can't cat the repo's config or some such thing ...). But I'm not sure if that would help with flaky reads on the storage provider's end of things.
Ideally this is something to work around in rclone's restic serve implementation if at all possible.
Hi! I have used this tool and is perfect in almost everything. As backend, I use pCloud through the rclone provider, and it behaves perfectly. Sometimes it fails for random reasons, and I would like that would be available a retry option that with an exponential backoff, retries a X time when something fails, according to the existing scheduling.