Feature: timeout #411
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#411
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
For long running backups (e.g. when a large amount of files are added at once) I would find it useful to make the backup stop after a while.
Currently, if the backup runs long enough where cron starts a second instance, it sometimes runs into issues like healthchecks failing or database dumps not being created or deleted properly. Of course, backup integrity is ensured by borg locks but it still requires manual intervention or causes unnecessary notifications.
I propose a configuration option
that will stop borgmatic after some amount of time (if doable, preferably waiting for the next checkpoint).
This feature has other uses, like ensuring backups are run during idle hours. For example, starting a backup at 2 AM and always stopping it before 8 AM even if it hasn't finished yet (it will continue the next day).
Great idea! Are you perhaps using systemd to run borgmatic? If so, you might be able to accomplish a timeout via systemd's TimeoutSec service option. It still might make sense to add timeout support to borgmatic, but I wanted to see if systemd's timeout would work for you in the meantime.
I'm closing this ticket due to inactivity. But please feel free to reopen if you have any follow-up comments.
Fair enough, I've managed to solve the issue of concurrent backups using
run-one
.