Run Cron Jobs After Sleep: Systemd Timers & Linux Backup

cron can’t replay missed runs by itself while the machine is asleep, but you can get that behavior by switching your job to a systemd timer with Persistent=true or by using anacron for day-granular catch-up; systemd timers give cron-like OnCalendar scheduling plus automatic catch-up on boot. For Time Machine–style, versioned/incremental backups on Linux use Timeshift for system snapshots and an rsync-based snapshot scheme (or Borg/Cronopete for user files) that creates dated, hardlink-backed snapshots; schedule those snapshot jobs with a systemd timer or anacron so missed runs execute after wake.

Contents

• Why cron misses jobs when the computer is asleep
• Use anacron to run missed cron jobs at boot (anacron)
• Use systemd timers to catch missed runs (systemd timer)
• Practical systemd example: timer + service for your backup
• Practical anacron example and a weekday workaround
• Time Machine–style versioned / incremental backups on Linux (timeshift linux, rsync backup, cronopete)
• Recommended combined setup for reliable linux backup jobs
• Testing, logging and troubleshooting your scheduled backups
• Sources
• Conclusion

Why cron misses jobs when the computer is asleep

Cron runs jobs at wall-clock times only when the cron daemon is awake and the system is running. If your machine is suspended at 00:00, the cron daemon simply doesn’t run the job and has no built‑in “catch up later” facility. You might see the job run next time exactly on schedule only if the system happened to be up then; otherwise nothing happens.

So: cron is fine for always-on servers, but on laptops or desktops that sleep it’s not reliable for guaranteed, run-after-wake backups. For that you need a scheduler that can detect missed events and trigger them at the next boot (or shortly after boot). Two practical options are anacron (day-granular catch-up) and systemd timers (calendar precision + Persistent catch-up).

Use anacron to run missed cron jobs at boot (anacron)

Anacron is designed for machines that aren’t guaranteed to be on 24/7: if a scheduled job was missed because the machine was off, anacron runs it once after the machine boots. It works with a simple table in /etc/anacrontab using this format:

period (days) | delay (minutes) | job-identifier | command

Example entries:

# /etc/anacrontab
1 15 daily-backup /usr/local/bin/backup-daily.sh
7 10 weekly-backup /usr/local/bin/backup-weekly.sh

This means “run daily-backup once per day (period=1) 15 minutes after boot if it was missed” and “run weekly-backup once per 7 days, 10 minutes after boot if missed.” Anacron doesn’t attempt minute-level scheduling; it’s day-granular, which is ideal for routine backups on laptops. See a practical comparison of Cron vs Anacron for more details: Cron vs. Anacron guide.

Limitations and notes

• Anacron won’t run two missed weekly events separately if the machine was down for two weeks; it ensures the job runs at least once per period.
• You can’t directly express “run on Sunday and Thursday at midnight” by weekday with anacron alone; it’s intended for periodic (daily/weekly/monthly) jobs.

Use systemd timers to catch missed runs (systemd timer)

systemd timers offer cron-like scheduling (OnCalendar) plus features to catch missed runs. The key option is Persistent=true in the [Timer] section: when set, systemd records the last runtime and—if a calendar event was missed during suspend/off—it will queue the job to run once when the system next boots. Systemd also supports monotonic timers (OnBootSec, OnUnitActiveSec) if you want to run shortly after boot rather than at fixed wall-clock times.

See the full guide and examples for systemd timers here: Systemd Timers: A Comprehensive Guide For Beginners and practical notes on Persistent and OnBootSec here: Working with systemd timers.

Why choose systemd timers

• You can schedule by weekday and time (e.g., Sun & Thu at 00:00) using OnCalendar.
• Persistent=true gives the “run if missed while asleep” behavior you want.
• Integration with systemctl/journalctl makes observing failures and logs straightforward.

Practical systemd example: timer + service for your backup

Map your crontab 0 0 * * 0,4 (midnight on Sunday and Thursday) to a systemd timer like this.

Create the service unit /etc/systemd/system/backup.service:

[Unit]
Description=Run backup script

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Create the timer unit /etc/systemd/system/backup.timer:

[Unit]
Description=Run backup on Sun and Thu at 00:00 (catch missed runs)

[Timer]
OnCalendar=Sun,Thu 00:00:00
Persistent=true
Unit=backup.service

[Install]
WantedBy=timers.target

Enable and start the timer:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

Check timers and next/last run:

systemctl list-timers --all | grep backup
journalctl -u backup.service -n 200

A simple backup.sh using rsync with hardlink snapshots (space-efficient, versioned) — adapted from the rsync approach used for versioned backups:

#!/usr/bin/env bash
set -euo pipefail

SRC="/home"
DEST="/mnt/backup"
TODAY="$(date +%F)"
LAST="$DEST/last"
SNAP="$DEST/$TODAY"

mkdir -p "$SNAP"
rsync -a --delete --link-dest="$LAST" "$SRC"/ "$SNAP"/
ln -sfn "$SNAP" "$LAST"

Notes

• --link-dest lets rsync hardlink unchanged files to the previous snapshot, saving space while keeping full snapshots by directory.
• Make sure /mnt/backup is mounted before the job runs (use systemd mount units or check in the script).
• Lock the script (flock) to prevent overlapping runs if desired.

For the rsync example above and more on link-dest snapshots see the systemd timers guide and rsync snapshot pattern in the systemd timers article: Systemd Timers guide (contains rsync example).

Practical anacron example and a weekday workaround

If your laptop sleeps often and you don’t require minute precision, install anacron and add entries to /etc/anacrontab as shown earlier:

1 15 daily-backup /usr/local/bin/backup-daily.sh
7 10 weekly-check /usr/local/bin/conditional-weekly-backup.sh

Because anacron works in periods (days), to simulate “run weekly but only on Thu and Sun” you can add a small wrapper that checks the weekday:

#!/usr/bin/env bash
# /usr/local/bin/conditional-weekly-backup.sh
dow=$(date +%u) # 1..7 (Mon..Sun)
# Thu = 4, Sun = 7
if [ "$dow" -eq 4 ] || [ "$dow" -eq 7 ]; then
 /usr/local/bin/backup.sh
fi

This workaround runs the weekly check every 7 days (per anacron) but only performs the backup on the days you want. For more on anacron syntax and behavior see the Cloudns guide: Cron vs. Anacron: A Comprehensive Guide.

Time Machine–style versioned / incremental backups on Linux (timeshift linux, rsync backup, cronopete)

There are two separate needs: system snapshots (roll back your OS) and user-file versioning (retrieve past versions of documents and photos). Pick the tool that fits each role.

Timeshift — system snapshots

• Timeshift focuses on system-level snapshots (like restore points) and uses rsync or BTRFS snapshots under the hood. It excludes user files by default (you can include them, but that increases size).
• Install and configure (Ubuntu/Debian example): sudo apt install timeshift, then run the GUI to select snapshot type, schedule and destination.
• Restore from a live USB or via the Timeshift UI to roll back system state. See step-by-step usage here: How To Use Timeshift To Backup And Restore Linux System and a high-level announcement: Timeshift brings Time Machine to Linux.

Rsync + hardlink snapshots — user files (versioned)

• The rsync + --link-dest pattern creates dated snapshots that look like full backups but share unchanged files via hard links; it’s very space efficient.
• Example (already shown above) produces /mnt/backup/YYYY‑MM‑DD directories, with a last symlink to the most recent snapshot. Old snapshots remain intact and can be browsed or mounted.
• Pros: simple, transparent, easy to restore with cp/rsync. Cons: no built-in encryption or deduplication across many snapshots.

Cronopete — GUI Time Machine clone

• If you want a macOS Time Machine–like GUI for user files, Cronopete is a solid open‑source option that performs incremental backups and shows a timeline for restores: Cronopete – An Apple’s Time Machine Clone For Linux.

Borg (brief mention)

• For encrypted, deduplicated backups that are very storage-efficient, BorgBackup is a common choice; pair Borg with systemd timers to schedule repository snapshots.

Where to store snapshots

• External USB drives, NAS, or remote rsync/SSH targets. If storing offsite, encrypt (Borg offers encryption).

Retention and pruning

• Rotate snapshots by removing oldest directories (or use a retention script). For rsync snapshots you can safely rm -rf old snapshot directories; for borg use borg prune.

Recommended combined setup for reliable linux backup jobs

If you want both reliability after sleep and Time Machine–style versioning, here’s a pragmatic combination that works well in production and on laptops:

1. Use systemd timers with Persistent=true to schedule the backup job at the exact weekdays/times you want (Sun and Thu midnight). That preserves weekday precision and runs missed jobs after wake. See the systemd timers guide for details: Systemd timers guide.

2. Implement the backup job as:

• Timeshift for system snapshots (schedule via its UI or CLI) to capture OS state.
• An rsync --link-dest script (or Borg) for user files, producing dated snapshots you can browse/restore.

3. Put the rsync script under systemd control (service + timer) and add basic safety: mount checks, locking (flock), exit codes, and logging to /var/log/backup.log.

4. For laptops that sleep frequently and where daily consistency matters rather than exact time-of-day, use anacron with a 1-day period (and a wrapper if you need particular weekdays).

This hybrid gives you:

• Precise schedule and missed-run catch-up (systemd timers + Persistent=true).
• Space-efficient, versioned snapshots for file retrieval (rsync --link-dest or Borg).
• System rollback points (Timeshift).

Testing, logging and troubleshooting your scheduled backups

• Confirm timer state and next run:
• systemctl list-timers --all | grep backup
• systemctl status backup.timer and systemctl status backup.service
• Inspect logs:
• journalctl -u backup.service -b (service logs since boot)
• Add explicit logging inside your script (logger or redirect stdout/stderr to /var/log/backup.log).
• Simulate a missed run:
• Suspend your laptop before the scheduled time, resume after, then check whether the timer/service ran (Persistent=true should have triggered it).
• Prevent overlapping runs:
• Use flock or create a PID lock file in your script.
• Validate restores:
• Periodically restore one or two files from a snapshot to verify integrity (don’t just assume backups are usable).

If you want step-by-step examples and deeper explanations for timers and snapshot patterns, review the systemd timers tutorial and rsync snapshot examples here: Systemd Timers guide and the anacron primer: Cron vs. Anacron guide.

Sources

• https://blog.techiescamp.com/systemd-timers/
• https://www.cloudns.net/blog/cron-vs-anacron-a-comprehensive-guide/
• https://itsfoss.gitlab.io/post/cronopete–an-apples-time-machine-clone-for-linux/
• https://yieldcode.blog/post/working-with-systemd-timers/
• https://linuxconfig.org/how-to-schedule-tasks-with-systemd-timers-in-linux
• https://www.xda-developers.com/timeshift-brings-time-machine-to-linux-machine/
• https://ostechnix.com/how-to-backup-and-restore-linux-system-with-timeshift/

Conclusion

Cron itself won’t replay jobs missed during sleep, but switching to a systemd timer with Persistent=true or using anacron fixes that: systemd timers provide weekday/time precision plus catch-up, while anacron provides simple day-level reliability. For Time Machine–style, versioned backups use Timeshift for system snapshots and an rsync --link-dest (or Borg/Cronopete) approach for user files; schedule those jobs with systemd timers (or anacron on laptops) so missed runs execute after wake. Test restores regularly, log runs, and lock your scripts to avoid overlapping runs — you’ll end up with reliable linux backup and retrievable historical versions.