Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Allow systemd randomize RandomizedDelaySec parameter in the schedule command #217

Open
darkblaze69 opened this issue May 29, 2023 · 9 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@darkblaze69
Copy link

Allow systemd randomize RandomizedDelaySec parameter in the schedule command.

This is a convenient way to avoid starting the jobs on all hosts at one time if config is the same for them with the same schedule time.

@creativeprojects
Copy link
Owner

Hi,

I don't think I would want to backup multiple machines at the same time (to the same repository).
In case of different repositories it doesn't matter if they start at the same time.

I mean I don't mind adding this feature but I'm not sure it's advised to do so

@creativeprojects
Copy link
Owner

closing as it can be set via a systemd template: https://creativeprojects.github.io/resticprofile/schedules/systemd/index.html#how-to-change-the-default-systemd-unit-and-timer-file-using-a-template

@scy
Copy link
Contributor

scy commented Mar 14, 2024

Hi! I've stumbled across the same issue just now, trying to add some randomness to the schedule.

I don't think I would want to backup multiple machines at the same time (to the same repository).

Which is one of the reasons why RandomizedDelaySec makes sense. It basically allows you to use the same config on multiple machines, but have systemd spread out the iterations over some configurable interval.

For example, you could have 10 machines configured to run a daily backup at 2am, but add RandomizedDelaySec=2h to have these backups actually start between 2am and 4am.

In case of different repositories it doesn't matter if they start at the same time.

That's not quite true. Imagine having 10 machines at home that start uploading their backups at the same time, although to different off-site repos. You'd probably run into congestion of your upstream link. This, too, could be solved by adding a random delay.

closing as it can be set via a systemd template: https://creativeprojects.github.io/resticprofile/schedules/systemd/index.html#how-to-change-the-default-systemd-unit-and-timer-file-using-a-template

Hm. I've thought about doing this, but I don't see how I can use different values for different profiles, because the template is a global setting. So, if I have one profile running every 10 minutes, I might want to add a 2 minute randomized delay to it, but if I have another profile running every 24 hours, 1 hour of randomized delay might make more sense there. Is there a way to do this using the custom template?

I even might want to use different delays for different tasks in the same profile. For example, run backup every 10 minutes (± 2 minutes), but run forget only every 24 hours (± 2 hours).

I've also tried using a drop-in file to do this, but since drop-in files are associated with the .service and not the .timer (they are written to resticprofile-<action>@profile-<profile>.service.d, systemd doesn't allow overriding timer settings in it:

/etc/systemd/system/resticprofile-backup@profile-local.service.d/90-slide-2h.resticprofile.conf:1: Unknown section 'Timer'. Ignoring.

@creativeprojects
Copy link
Owner

I guess it's an easy change in the configuration.

@creativeprojects creativeprojects added enhancement New feature or request good first issue Good for newcomers labels Mar 15, 2024
@jkellerer
Copy link
Collaborator

Config change or extend drop-in support to place drop-ins in the timers directory if they contain [Timer]?

@creativeprojects
Copy link
Owner

drop-ins in the timers directory would definitely be better 👍🏻

@scy
Copy link
Contributor

scy commented Mar 15, 2024

But drop-ins are set on the profile level, not on the action level. Different drop-ins for backup and forget would not be possible then.

@jkellerer
Copy link
Collaborator

jkellerer commented Mar 15, 2024

We could add them to the upcoming schedule structure in 0.27 (#333). Then it covers all use cases. @creativeprojects what do you think?

@jkellerer
Copy link
Collaborator

@creativeprojects , since the changes were quite small I had opened 2 PRs. Let me know what you think about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants