0

I am trying to set up a regular backup regime for my desktop running debian stable. Its not always on, so I might miss the required times if I just use cron. But for now thats what I am doing because of the following logic.

Doing some tests my weekly backup takes about 3 hours to run. Reading the anacron man page implies that the timestamps are updated when the job terminates. So on the first week it runs at about 8 am, then if it waits a week since the last timestamp, on the second week it will not run until after 11am (I think anacron is run at startup and then through an hourly timer controlled by systemd). This run's timestamp will get set about 2pm. If we carry on like this, the timestamp will slip into the next day. More importantly it will slip to a time when I am about to go to bed and power off my machine (and the NAS server which it is backing up to will also close down)

There appears to be an attempt to mitigate this in Debian, by having a file called 0anacron in the /etc/cron.weekly directory which sets timestamps as the first thing but I can't figure out how it works, because the timestamps would still be updated at the end of the job.

Is there a mechanism I don't understand to stop anacron slowly (or rapidly) slipping the time the run starts backwards.

akc42
  • 351
  • 4
  • 16

1 Answers1

2

Quoting the manpage:

Only the date is used for the time calculations. The hour is not used.

So job start times don’t shift based on how long they take, at least as long as they take less than a full day: your weekly backup job will start running at approximately the same time every week.

(As far as I can tell, 0anacron is there so that anacron is aware of cron jobs even if it doesn’t run them itself.)

Stephen Kitt
  • 434,908
  • I think I worked out why 0anacron is there. If cron somehow runs the job, then anacron won't. I had missed the statement in the man page that you quoted. So I have now installed anacron. Thanks – akc42 Feb 26 '20 at 07:38