I like systemd's timers when they're appropriate, but I really think the author's use case here is better suited to cron. The "issues" he listed for cron aren't very good either.

> If you want to execute pre/post commands you have to do it inside the script itself

So?

> There are no built-in logs

Every cron implementation I can remember using logs each run to syslog and emails me the output of the run by default

> There is no built-in status monitoring

I can't think of any built-in status monitoring that systemd has for timers that's materially different from cron's logging/emailing

> If the system is down when the cron needs to run, the cron will be missed

Some cron implementations support this and some don't. Most modern ones that I'm aware of do.

Much more significantly, the amount of setup involved in a systemd timer is way higher than putting a line in a crontab, especially for the author's case of just running a backup script.

Cron only involves running `crontab -e` and adding the line "@daily /path/to/script.sh" (which also handles the author's issue of cron "skipping" runs if the system was powered off, assuming the cron implementation uses something modern like anacron)

Systemd involves writing a 7 line timer unit file, an additional 5 line service file, running a daemon-reload, then enabling the timer. It turns what's usually a 10 second mindless task into a much more involved procedure. That can be worth it if there are material benefits from it, but I'm not really seeing them here.