How to Perform Automated Backups in Linux

There are two kinds of system administrators: those who have lost important data, and those who will. The difference between a minor inconvenience and a catastrophic disaster almost always comes down to one thing — whether reliable, automated backups were in place.

Manual backups fail because humans forget, get busy, or simply assume “someone else is handling it.” Automated backups remove human memory from the equation entirely — the system backs itself up on a schedule, without anyone needing to remember to do it.

This article covers how to design and implement automated backup systems on Linux from first principles: what to back up, where to store it, how to schedule it, and how to verify it’s actually working — because a backup you’ve never tested is really just a hope, not a backup.

Why Automated (Not Manual) Backups?

The 3-2-1 Backup Rule

Before any technical implementation, it’s worth understanding the industry-standard guiding principle for backup strategy:

• 3 copies of your data (the original plus two backups)
• 2 different storage media types (e.g., local disk + cloud, or disk + tape)
• 1 copy stored offsite (so a fire, flood, or theft doesn’t destroy everything at once)

flowchart TD
    A[Production Data] --> B[Local Backup Copy]
    A --> C[Offsite/Cloud Backup Copy]
    B -.->|Different Media Type| D[e.g. External Disk]
    C -.->|Different Location| E[e.g. Cloud Storage / Remote Site]

Step 1: Decide What to Back Up

Not everything on a server needs backing up. Focus on:

• Configuration files (/etc/)
• Application data (databases, uploaded files, application state)
• User data (/home/)
• Web content (/var/www/)
• Databases (dumped in proper format, not just copied as raw files while running)

You generally do not need to back up:

• Operating system binaries (easily reinstalled)
• Temporary files (/tmp/)
• Cache directories
• Log files (unless required for compliance/auditing)

Step 2: Choose a Backup Tool

rsync — The Workhorse of Linux Backups

rsync efficiently copies only the parts of files that have changed, making it fast even for large datasets on repeat runs.

rsync -avz --delete /var/www/ /backup/www/

rsync -avz --delete /var/www/ /backup/www/

tar — Simple Archive Creation

tar -czvf /backup/website-backup-$(date +%F).tar.gz /var/www/

tar -czvf /backup/website-backup-$(date +%F).tar.gz /var/www/

rclone — For Cloud Storage Backups

rclone sync /var/www/ remote:my-backup-bucket/www/

rclone sync /var/www/ remote:my-backup-bucket/www/

rclone supports dozens of cloud providers (AWS S3, Google Drive, Backblaze B2, and more) with the same simple syntax.

Step 3: Automate with cron

cron is the classic Linux job scheduler — perfect for running backup scripts on a recurring schedule without any manual intervention.

Writing a Backup Script

sudo nano /usr/local/bin/backup.sh

sudo nano /usr/local/bin/backup.sh

#!/bin/bash
# Simple automated backup script

BACKUP_DIR="/backup"
SOURCE_DIR="/var/www"
DATE=$(date +%F)
LOGFILE="/var/log/backup.log"

echo "[$(date)] Starting backup..." >> "$LOGFILE"

mkdir -p "$BACKUP_DIR"

tar -czf "$BACKUP_DIR/backup-$DATE.tar.gz" "$SOURCE_DIR"

if [ $? -eq 0 ]; then
    echo "[$(date)] Backup completed successfully: backup-$DATE.tar.gz" >> "$LOGFILE"
else
    echo "[$(date)] BACKUP FAILED!" >> "$LOGFILE"
fi

# Remove backups older than 14 days
find "$BACKUP_DIR" -name "backup-*.tar.gz" -mtime +14 -delete

#!/bin/bash
# Simple automated backup script

BACKUP_DIR="/backup"
SOURCE_DIR="/var/www"
DATE=$(date +%F)
LOGFILE="/var/log/backup.log"

echo "[$(date)] Starting backup..." >> "$LOGFILE"

mkdir -p "$BACKUP_DIR"

tar -czf "$BACKUP_DIR/backup-$DATE.tar.gz" "$SOURCE_DIR"

if [ $? -eq 0 ]; then
    echo "[$(date)] Backup completed successfully: backup-$DATE.tar.gz" >> "$LOGFILE"
else
    echo "[$(date)] BACKUP FAILED!" >> "$LOGFILE"
fi

# Remove backups older than 14 days
find "$BACKUP_DIR" -name "backup-*.tar.gz" -mtime +14 -delete

Make it executable:

sudo chmod +x /usr/local/bin/backup.sh

sudo chmod +x /usr/local/bin/backup.sh

Scheduling with Cron

sudo crontab -e

sudo crontab -e

Add a line to run the backup every night at 2:00 AM:

0 2 * * * /usr/local/bin/backup.sh

0 2 * * * /usr/local/bin/backup.sh

Understanding Cron Syntax

* * * * *  command
│ │ │ │ │
│ │ │ │ └── Day of week (0-6, Sunday=0)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)

* * * * *  command
│ │ │ │ │
│ │ │ │ └── Day of week (0-6, Sunday=0)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)

Step 4: Automate Database Backups

Databases need special handling — copying raw database files while the database is running can produce corrupted, unusable backups. Always use the proper dump tool.

MySQL/MariaDB

mysqldump -u root -p'password' --all-databases | gzip > /backup/db-$(date +%F).sql.gz

mysqldump -u root -p'password' --all-databases | gzip > /backup/db-$(date +%F).sql.gz

PostgreSQL

pg_dumpall -U postgres | gzip > /backup/pgdb-$(date +%F).sql.gz

pg_dumpall -U postgres | gzip > /backup/pgdb-$(date +%F).sql.gz

Step 5: Send Backups Offsite

A local-only backup doesn’t protect against site-wide disasters (fire, theft, ransomware encrypting everything it can reach, including local backups!).

Using rsync to a Remote Server

rsync -avz -e ssh /backup/ user@remote-backup-server:/backups/server1/

rsync -avz -e ssh /backup/ user@remote-backup-server:/backups/server1/

Using rclone to Cloud Storage

rclone copy /backup/ remote:company-backups/server1/

rclone copy /backup/ remote:company-backups/server1/

Architecture Diagram: A Complete Automated Backup Flow

flowchart LR
    A[Cron Trigger 2 AM Daily] --> B[Backup Script Runs]
    B --> C[Dump Databases]
    B --> D[Archive Files with tar]
    C --> E[Local Backup Storage]
    D --> E
    E --> F[Sync Offsite via rsync/rclone]
    E --> G[Rotate: Delete Backups Older Than 14 Days]
    B --> H[Write Log Entry]
    H --> I[Alert on Failure via Email/Monitoring]

Real-World Example: E-Commerce Website Backup Strategy

A small online store running on a single Linux VPS might implement this layered strategy:

This layered approach means: if a bad deployment corrupts data at 3 PM, the store can restore from a 6-hour-old database snapshot rather than losing an entire day (or week) of orders.

Cisco Example: Backing Up Network Device Configurations

Automated backups aren’t just for servers — network device configurations should be backed up too. Cisco devices support automatic configuration backup via TFTP/SCP triggered from a script:

copy running-config tftp://192.168.1.100/backups/router1-config.txt

copy running-config tftp://192.168.1.100/backups/router1-config.txt

This can be automated from a Linux server using a scheduled script that connects via SSH and issues backup commands to multiple devices in sequence — often built with tools like Python’s netmiko library or Ansible.

Python Example: A More Robust Backup Script

import subprocess
import datetime
import os
import logging

logging.basicConfig(filename='/var/log/backup.log', level=logging.INFO,
                     format='%(asctime)s %(message)s')

BACKUP_DIR = "/backup"
SOURCE_DIR = "/var/www"
RETENTION_DAYS = 14

def run_backup():
    os.makedirs(BACKUP_DIR, exist_ok=True)
    date_str = datetime.date.today().isoformat()
    archive_path = f"{BACKUP_DIR}/backup-{date_str}.tar.gz"

    try:
        subprocess.run(
            ["tar", "-czf", archive_path, SOURCE_DIR],
            check=True
        )
        logging.info(f"Backup succeeded: {archive_path}")
    except subprocess.CalledProcessError as e:
        logging.error(f"Backup FAILED: {e}")
        return

    cleanup_old_backups()

def cleanup_old_backups():
    cutoff = datetime.datetime.now().timestamp() - (RETENTION_DAYS * 86400)
    for filename in os.listdir(BACKUP_DIR):
        filepath = os.path.join(BACKUP_DIR, filename)
        if os.path.getmtime(filepath) < cutoff:
            os.remove(filepath)
            logging.info(f"Removed old backup: {filename}")

if __name__ == "__main__":
    run_backup()

import subprocess
import datetime
import os
import logging

logging.basicConfig(filename='/var/log/backup.log', level=logging.INFO,
                     format='%(asctime)s %(message)s')

BACKUP_DIR = "/backup"
SOURCE_DIR = "/var/www"
RETENTION_DAYS = 14

def run_backup():
    os.makedirs(BACKUP_DIR, exist_ok=True)
    date_str = datetime.date.today().isoformat()
    archive_path = f"{BACKUP_DIR}/backup-{date_str}.tar.gz"

    try:
        subprocess.run(
            ["tar", "-czf", archive_path, SOURCE_DIR],
            check=True
        )
        logging.info(f"Backup succeeded: {archive_path}")
    except subprocess.CalledProcessError as e:
        logging.error(f"Backup FAILED: {e}")
        return

    cleanup_old_backups()

def cleanup_old_backups():
    cutoff = datetime.datetime.now().timestamp() - (RETENTION_DAYS * 86400)
    for filename in os.listdir(BACKUP_DIR):
        filepath = os.path.join(BACKUP_DIR, filename)
        if os.path.getmtime(filepath) < cutoff:
            os.remove(filepath)
            logging.info(f"Removed old backup: {filename}")

if __name__ == "__main__":
    run_backup()

Schedule this with cron just like the Bash version:

0 2 * * * /usr/bin/python3 /usr/local/bin/backup.py

0 2 * * * /usr/bin/python3 /usr/local/bin/backup.py

Comparison Table: Backup Tool Options

Best Practices

• Follow the 3-2-1 rule — multiple copies, multiple media types, at least one offsite.
• Automate everything — never rely on a human remembering to run a backup.
• Test restores regularly — a backup that’s never been restored is unverified and untrustworthy.
• Log every backup run, and alert on failures — a silent failure is worse than an obvious one.
• Encrypt backups, especially offsite/cloud copies, to protect sensitive data.
• Rotate old backups to avoid unbounded storage growth.
• Dump databases properly — never just copy live database files directly.
• Document your backup and restore procedures so anyone on the team can execute a recovery, not just the person who built it.

Troubleshooting

Useful Diagnostic Commands

# View recent cron job logs
grep CRON /var/log/syslog

# Manually test a backup script
sudo /usr/local/bin/backup.sh

# Verify archive integrity
tar -tzf /backup/backup-2026-07-24.tar.gz > /dev/null && echo "Archive OK"

# View recent cron job logs
grep CRON /var/log/syslog

# Manually test a backup script
sudo /usr/local/bin/backup.sh

# Verify archive integrity
tar -tzf /backup/backup-2026-07-24.tar.gz > /dev/null && echo "Archive OK"

Summary

Automated backups turn data protection from a fragile, human-dependent hope into a reliable, repeatable system. By combining simple, well-understood Linux tools — tar, rsync, rclone, database dump utilities, and cron scheduling — with sound principles like the 3-2-1 rule, proper logging, and regular restore testing, you can build a backup system that will actually save you when disaster strikes, not just when everything is already going fine.

Further Reading

• rsync Official Documentation
• rclone Documentation
• BorgBackup Documentation
• restic Documentation
• Cron man page
• MySQL mysqldump Reference
• PostgreSQL Backup and Restore Documentation