1. "crontab -e" lets you edit your crontab file, and "crontab -r" deletes it (without asking). The two keys are next to each other.
2. "crontab" (no arg) reads the contents of the crontab file from stdin and replaces it. When you accidentally hit Ctrl-D after it, your crontab is replaced with an empty file.
The new section should be called: 'Gotcha'.
Also, I name the files according to host so I remember exactly where they were installed in a networked environment (e.g. "host1.crontab", "host2.crontab").
Make changes active with `crontab ~/.cron/crontab`
Diff with `diff -du <(crontab -l) <(cat ~/.cron/crontab)`
For servers or not-my-own-user crontabs, config management is the way to go. The crontabs should be in a config management repository, so there's not just a single copy that's deployed and active.
crontab -u www-user x.crontab
OnCalendar= has a less insane format than cron, exit code and output logging, locking, proper command line tools, and other niceties like Persistent= (catch up e.g. after system was powered off) etc.
(And yes, you can still have user "cronjobs" if you enable systemd user session lingering.)
1. mysqldump can require quite a few more permissions than mentioned, depending on your utilization of mysql
2. The best way I've found to test the cron-like environmentis by following this: http://stackoverflow.com/questions/2135478/how-to-simulate-t...
Otherwise you run the risk of .profile (and similar) being loaded, where they will not be when run in the cron task.
3. Extra emphasis on using a lock file to avoid overlapping cron tasks!
4. I love using `time` or similar means to pass execution time somewhere (a log file, or a web hook), which helps with point 3.