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

Backrest should provide options for rescheduling and running skipped tasks #401

Closed
JokerQyou opened this issue Jul 24, 2024 · 1 comment
Closed
Labels
bug Something isn't working p1

Comments

@JokerQyou
Copy link

Describe the bug

I'm running BackRest 1.2.0 with docker on unRAID. I have a repo scheduled to run backup every 7 days. But I also have unRAID's AppData-backup plugin set to backup docker container data (volumes and container definitions) every week. So before BackRest started the first scheduled backup, AppData-backup restarts BackRest container, and BackRest seems to re-schedule the next backup to be 7 days ahead of its startup point. This way the scheduled backup would never trigger.

To Reproduce
Steps to reproduce the behavior:

  1. Go to backrest and configure a repo to backup evrery 7 days.
  2. On the 6th day, restart the backrest container.
  3. Backrest re-schedule the next backup to another 7 days ahead.

Expected behavior

I would expect backrest to store the schedule info into database or local configuration files so it survives container restarts.

Screenshots

None.

Platform Info

  • unRAID 6.12.3. But this is not relevant, any Linux with docker would do.
  • Backrest Version 1.2.0.

Additional context

I checked changelog for newer versions of backrest and found no mentioning of changes related to plan scheduling.

@JokerQyou JokerQyou added the bug Something isn't working label Jul 24, 2024
@garethgeorge garethgeorge changed the title Scheduled backup never run Backrest should provide options for rescheduling and running skipped tasks Aug 12, 2024
@garethgeorge
Copy link
Owner

Hey, Backrest now provides a solution for scheduling tasks relative to their "last run time" in 1.5.0 which should address this. Realizing I forgot to link the bugs at the time but this report was on my radar and related to #372 which I've been tracking.

Will go ahead and resolve this, feel free to ping on that issue w/any feedback on the solution if you have questions/run into issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working p1
Projects
None yet
Development

No branches or pull requests

2 participants