You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! To start with I just wanted to say thanks for maintaining this project, it's made managing backups with restic so much easier for me 😄
Describe the bug
Even when an autorestic cron run fails during the backup process, the latest cron timestamp (found in .autorestic.lock.yml) is updated.
This is an issue for me because I have cron set to back up daily, and if the autorestic cron attempt happens when my internet is temporarily unavailable (for backblaze), or my removable hard drive is unplugged (for local) then it will refuse to run again that same day with the message: Skipping "<location>", not due yet.
Expected behavior
I would expect that the next autorestic cron command triggered after my internet came back on would run and back up my data.
Environment
OS: Linux - Fedora 39
Version: 1.7.9
Additional context
I suspect this is because the timestamp is written before the backup even starts, and no error handling is performed on the result of the backup, see:
Hi! To start with I just wanted to say thanks for maintaining this project, it's made managing backups with
restic
so much easier for me 😄Describe the bug
Even when an
autorestic cron
run fails during the backup process, the latest cron timestamp (found in.autorestic.lock.yml
) is updated.This is an issue for me because I have
cron
set to back up daily, and if theautorestic cron
attempt happens when my internet is temporarily unavailable (for backblaze), or my removable hard drive is unplugged (for local) then it will refuse to run again that same day with the message:Skipping "<location>", not due yet.
Expected behavior
I would expect that the next
autorestic cron
command triggered after my internet came back on would run and back up my data.Environment
Additional context
I suspect this is because the timestamp is written before the backup even starts, and no error handling is performed on the result of the backup, see:
autorestic/internal/location.go
Lines 439 to 442 in 068121d
The text was updated successfully, but these errors were encountered: