Linux Backup and Recovery Scripts

The backup you don't have is the one you'll need. Every sysadmin knows this. Most of them also know, from experience, that the backup they had wasn't tested, ran out of retention space six weeks ago, or was pointed at the wrong directory. A backup strategy that isn't automated is a plan that depends on nobody forgetting.

The scripts on this page automate the parts that people skip. Timestamped archives that create themselves on a cron. MySQL dumps that run before the deploy, not after the fact. Incremental rsync backups over SSH that pick up where they left off if the connection drops midway. Retention management that deletes copies older than 30 days so the backup disk doesn't silently fill and start failing writes.

Local backups protect you from accidental deletions and failed deployments. They do not protect you from a disk failure, a datacenter incident, or a compromised server. The rsync-remote-backup script on this page pushes copies to a remote server over SSH — it's the difference between a backup and an offsite backup. Both matter.

Before you schedule any of these scripts, decide two things: where the backups live (a separate disk, a mounted NFS share, a remote server, or object storage), and how long you keep them. The scripts use a configurable retention period — 30 days is the default. The correct answer depends on your recovery time objective and how much storage you have, not on what the default is.

The most common backup failure mode isn't a missing script — it's a script that runs without errors for months until the day you need to restore, when you discover the archive was writing to a directory that didn't have enough space, or the database user had lost its dump privileges after a password rotation. Test restores. Schedule them. The scripts are the easy part.