An automatic Linux backup is one you never have to remember: it runs on a schedule, keeps a sensible history, sends copies offsite and tells you when it fails. This guide builds that setup step by step with tools that ship with or install easily on any distribution: restic for encrypted, deduplicated backups, and systemd timers (or cron) for scheduling.

The problem with manual backups

Manual backups work for a week. Then a deploy, a holiday or a busy month gets in the way, and the last copy quietly gets older. When a disk fails, someone runs rm -rf in the wrong directory or ransomware encrypts the server, the team discovers that the newest backup is from months ago, or is sitting on the same server that was lost.

The consequence is not only lost files. It is rebuilding configuration from memory, lost customer data and days of downtime. Automation removes the human step that always fails first.

What a good automatic backup needs

  • A schedule that runs even after reboots.
  • Incremental, deduplicated storage, so daily runs are fast and cheap.
  • Encryption before data leaves the server.
  • Retention: daily, weekly and monthly versions, pruned automatically.
  • An offsite destination: another server or S3-compatible object storage.
  • Alerts on failure and periodic integrity checks.

restic covers the first five in one tool. Alternatives such as BorgBackup work similarly; plain rsync copies files but has no built-in versioning or encryption.

Step 1: install restic

# Debian / Ubuntu
apt install restic
# RHEL / Rocky / Alma (EPEL)
dnf install restic

restic version

Distribution packages can lag behind; you can also download the official static binary from the restic releases page and run restic self-update later.

Step 2: create the repository

Put the credentials in a root-only file, so they do not appear in scripts or shell history:

# /root/.backup.env  (chmod 600)
RESTIC_REPOSITORY=s3:https://s3.example.com/my-bucket/web-01
RESTIC_PASSWORD_FILE=/root/.restic-password
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
openssl rand -base64 32 > /root/.restic-password
chmod 600 /root/.restic-password /root/.backup.env

set -a; . /root/.backup.env; set +a
restic init

Save the repository password in a password manager outside the server. Without it, nobody can decrypt the backup, including you after the server is gone. restic also supports SFTP (sftp:user@host:/path), local disks and other backends.

Step 3: the backup script

#!/usr/bin/env bash
# /usr/local/sbin/auto-backup.sh
set -euo pipefail
set -a; . /root/.backup.env; set +a

# Save the list of installed packages, to rebuild the server faster
mkdir -p /var/backups/meta
if command -v dpkg >/dev/null; then dpkg --get-selections > /var/backups/meta/packages.txt; fi
if command -v rpm  >/dev/null; then rpm -qa | sort > /var/backups/meta/packages.txt; fi
crontab -l > /var/backups/meta/root-crontab.txt 2>/dev/null || true

restic backup \
  /etc /home /root /srv /var/www /usr/local /var/backups /var/spool/cron \
  --exclude-caches \
  --exclude '/home/*/.cache' \
  --exclude '*.tmp' \
  --tag auto

restic forget --tag auto --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Adjust the paths to your server and remove any that do not exist: restic reports missing source paths as errors, and with set -e the job is marked as failed. Databases need a dump before this step, written to /var/backups, because copying live database files is not consistent: see automatic MySQL backup and how to automate PostgreSQL backups.

Step 4: schedule with a systemd timer

# /etc/systemd/system/auto-backup.service
[Unit]
Description=Automatic Linux backup
Wants=network-online.target
After=network-online.target
OnFailure=backup-alert@%n.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/auto-backup.sh
Nice=10
IOSchedulingClass=idle

# /etc/systemd/system/auto-backup.timer
[Unit]
Description=Run automatic backup every night

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=20m
Persistent=true

[Install]
WantedBy=timers.target
chmod 700 /usr/local/sbin/auto-backup.sh
systemctl daemon-reload
systemctl enable --now auto-backup.timer
systemctl start auto-backup.service      # first run now
journalctl -u auto-backup.service -f

Persistent=true runs a missed backup as soon as the server boots, which cron does not do. Nice and IOSchedulingClass=idle keep the backup from slowing down production.

Prefer cron? Use: 30 2 * * * /usr/local/sbin/auto-backup.sh >> /var/log/auto-backup.log 2>&1.

Step 5: get alerted when it fails

The OnFailure= line above starts a unit when the backup fails. A minimal template sends an email:

# /etc/systemd/system/[email protected]
[Unit]
Description=Backup failure alert for %i

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'journalctl -u %i -n 50 | mail -s "Backup FAILED on %H" [email protected]'

Failure alerts do not catch a timer that stopped running. Add a "dead man's switch": a monitoring service that expects a ping after each successful run (for example with curl at the end of the script) and alerts you when the ping does not arrive.

Step 6: verify and test restores

restic snapshots
restic check --read-data-subset=5%        # weekly integrity check of a sample

# Restore a directory to a temporary location
restic restore latest --target /tmp/restore --include /etc/nginx
diff -r /etc/nginx /tmp/restore/etc/nginx

Once a month, restore a full snapshot onto a test machine and confirm the applications start. Note the time it took: that is your real recovery time. Our guide on RPO and RTO explains how to set targets.

Common mistakes

  • Backing up to a second disk in the same server and calling it offsite.
  • Keeping the repository password only on the server being backed up.
  • Including /proc, /sys, /dev or /run, which are virtual and break backups.
  • Copying database files instead of dumps.
  • Relying on success emails that nobody reads instead of failure alerts.

For what to include on each type of server and how to recover a whole machine, read the Linux server backup guide. Backnix is being built to automate Linux backups with an agent, encryption and offsite storage, without writing scripts: see the server backup page for the current status and the plans.

References

Topics: Automatic backupLinuxresticsystemd