Cron Jobs for Backup
Cron is a simple scheduler and is widely available. The main risk is that cron runs with a minimal environment, so scripts that work in your interactive shell may fail silently unless you log output and control concurrency.
Quick Summary
- Cron runs with a limited PATH and environment.
- Always redirect stdout/stderr to a log.
- Use
flockto prevent overlapping backup runs. - Prefer running a script from
/usr/local/bininstead of inlining a long command.
A safe cron pattern
Create a script, make it executable, and call it from cron.
install-backup-wrapper-script.sh
sudo install -m 700 /dev/stdin /usr/local/bin/wp-backup-run <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
umask 077
export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
exec /usr/local/bin/wp-backup-full
EOF
Prevent overlapping runs with flock
Wrap the job with flock:
cron-with-flock.sh
flock -n /var/lock/wp-backup.lock /usr/local/bin/wp-backup-run
Redirect logs
Example: daily at 02:15.
crontab-entry-example.txt
15 2 * * * flock -n /var/lock/wp-backup.lock /usr/local/bin/wp-backup-run >>/var/log/wp-backup.log 2>&1
Install a crontab entry
Edit root crontab:
edit-root-crontab.sh
sudo crontab -e
List active cron entries:
list-root-crontab.sh
sudo crontab -l
Test from cron-like environment
Run the script with a minimal environment:
simulate-cron-environment.sh
env -i HOME="$HOME" PATH="/usr/bin:/bin" /usr/local/bin/wp-backup-run
Alternative: systemd timers
If your server uses systemd, timers often give better logging and dependency control.
See the timer example pattern in:
opt/docker-data/apps/docusaurus/site/docs/server/linux-server/09-performance-process-management/monitoring-health.mdx
Next steps
- Logging and verification:
opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/backup-logging-and-verification.mdx. - Alerting:
opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/alert-on-failed-backup-jobs.mdx.