{"id":1569,"date":"2026-10-26T22:12:08","date_gmt":"2026-10-26T22:12:08","guid":{"rendered":"https:\/\/affordablevpsserver.com\/blog\/?p=1569"},"modified":"2026-10-26T22:12:08","modified_gmt":"2026-10-26T22:12:08","slug":"small-vps-native-backup-cron-efficiency-tuning","status":"publish","type":"post","link":"https:\/\/affordablevpsserver.com\/blog\/small-vps-native-backup-cron-efficiency-tuning\/","title":{"rendered":"Making Nightly Backups Cheap on a Small VPS: Scheduling, Compression and Retention Math"},"content":{"rendered":"
\n

On a 1–2 GB VPS, a backup job is a competing workload: it wants CPU while your site is serving traffic, it wants disk bandwidth while MySQL is flushing, and it wants to write a file large enough to matter. Done carelessly, the nightly backup is the slowest thing on the box and the reason your monitoring alerts at 03:10 every night. Done properly, it is a 90-second job that barely registers. The difference is scheduling, priority and compression level — and those choices also decide how much storage you have to rent.<\/p>\n

This is about the mechanics and cost of running the job itself. The rotation scheme is a separate decision; here the focus is how to make one nightly run cheap in CPU and I\/O on hardware you are paying for by the gigabyte of RAM<\/a>.<\/p>\n

Cron or systemd timer: what each actually costs<\/h2>\n

Both wake a process once a night. The difference is bookkeeping, not CPU. Cron is a small daemon resident in memory (roughly 1–3 MB RSS), starts jobs with a minimal environment, and gives you nothing if the job fails silently. A systemd timer adds Persistent=true<\/code> (run the missed job after downtime), RandomizedDelaySec<\/code> (spread load across hosts), captured logs via journald, and cgroup accounting so you can see exactly what the backup cost.<\/p>\n

# \/etc\/systemd\/system\/backup.service\n[Unit]\nDescription=Nightly backup\nNice=15\nIOSchedulingClass=idle\nMemoryMax=300M\n\n[Service]\nType=oneshot\nExecStart=\/usr\/local\/bin\/backup.sh\nUser=backup\n<\/code><\/pre>\n
# \/etc\/systemd\/system\/backup.timer\n[Timer]\nOnCalendar=*-*-* 03:20:00\nRandomizedDelaySec=15m\nPersistent=true\n\n[Install]\nWantedBy=timers.target\n<\/code><\/pre>\n
On a 1 GB box the systemd unit’s MemoryMax=300M<\/code> is the useful part: it caps the compression process so a runaway tar<\/code> cannot push the site into swap. Cron can approximate this with ulimit -v<\/code> in the script, but the accounting in systemctl status backup.service<\/code> is worth the extra file.<\/p>\n
nice, ionice and CPU cost<\/h2>\n
Scheduling priority is the cheapest optimisation available and the most often skipped.<\/p>\n