Cron Expressions for Database Backups

Database backup scheduling is one of the most operationally critical uses of cron expressions, and getting it wrong has irreversible consequences. The right backup schedule balances recovery point objective (RPO — how much data you can afford to lose) against storage costs and system load. A system with a one-hour RPO needs at least hourly backups; a system with a 24-hour RPO can get by with nightly backups. This collection shows eight backup scheduling patterns covering different frequency tiers. Hourly snapshots (0 * * * *) provide the finest recovery granularity but generate 24 backup files per day per database. Nightly full backups (0 2 * * *) are the most common baseline — scheduled at 2 AM to hit the lowest-traffic window for most systems while staying late enough that most end-of-day processing has completed. Weekly off-site sync (30 1 * * 0) runs on Sunday at 1:30 AM to push the week's most important backups to a remote location for disaster recovery. The staggering pattern (0 2 * * * and 15 2 * * *) is important for systems with multiple databases on the same host or in the same storage tier. If all databases back up simultaneously, disk I/O saturates and the backup takes longer, potentially extending into business hours. Staggering by 15 minutes per database ensures backups complete before the next one starts. Nightly vs weekly backup strategy: for many production systems the recommended pattern is hourly differential backups (backing up only changed data) during business hours, a nightly full backup, and a weekly backup retained for 90 days offsite. This provides fine-grained recent recovery options while managing long-term storage costs through tiered retention. Scheduling timing recommendations: midnight exactly (0 0 * * *) is the most overloaded minute in any cron system — hundreds of automated tasks from different systems all fire at the same instant. Choosing 0 2 * * * or 0 3 * * * distributes the load. Avoid 0 0 1 * * (first of month at midnight) for the same reason — the first of the month compounds with the midnight overload. Verifying backup coverage: the cron parser shows the next ten execution times for any expression. Use this to confirm your backup schedule has no gaps — for example, if your nightly backup runs at 2 AM and your hourly backups run at the top of each hour, verify there's no window longer than 60 minutes between successful backup points. Real-world backup architecture: automated backups scheduled with cron are only half of a backup strategy. The other half is automated restoration testing — a backup that has never been tested for restoration is not a backup. Schedule monthly or quarterly restoration drills to verify that backups are not corrupted and that the restoration procedure is documented and working.

0 * * * *
0 2 * * *
30 1 * * 0
0 3 * * 1-5
15 2 1 * *
0 4 * * 0
45 23 * * *
0 1 * * 1