Configuring automatic backups with cron and tar

Automatic backups on Linux should be predictable: a cron schedule calls a small shell script, tar produces a compressed archive, and an off-site copy protects the source disk. This approach suits RHEL, CentOS, Fedora and similar enterprise distributions where administrators need repeatable command-line jobs without adding a proprietary backup agent.

Many Australian administrators support organisations with offices in Sydney and Melbourne while remote infrastructure sits in another state or with a cloud provider. A Perth-hosted server uses AWST, whereas Sydney and Melbourne servers normally move between AEST and AEDT during daylight saving. Naming each archive in UTC avoids ambiguous timestamps when clocks change.

Storage choices also reflect the local market. Australian buyers compare AWS’s Sydney region, Azure Australia East and Google Cloud’s Melbourne region, while privacy officers check the Australian Privacy Act and Notifiable Data Breaches scheme against supplier contracts. An off-site copy is therefore a technical control and a governance decision, not merely another rsync command.

Everyday language can make a backup sound finished too soon. In an Australian operations room, “the arvo job is sorted” may mean a cron entry exists, not that a file can be restored. The workflow below covers scope, scheduling, retention, off-site replication and verification, with commands adaptable for a small server or a fleet managed through configuration management.

Plan the backup scope and destination

Begin with a recovery requirement, not a directory listing. Identify application configuration, TLS certificates, uploaded files, database exports and any logs with a genuine retention need. Linuxtpoint explains its editorial focus and audience for administrators and learners, and this workflow follows the same practical, command-first style.

Live databases need special care because tar can capture files while they are changing. Run mysqldump or pg_dump first and archive that consistent export. Copying raw tables from a running database can yield an archive that opens cleanly but cannot be trusted for recovery.

Keep the source list small and review it when the application changes. On RHEL-family systems, /etc/nginx may contain web-server configuration, while /opt/app and /srv/app may hold application code. Exclude caches, sockets and temporary files; tar’s --one-file-system option avoids crossing into mounted volumes unless they are deliberately included.

Create a reliable tar backup script

Place the job in /usr/local/sbin, away from home directories. This example creates a UTC-named tarball, records a SHA-256 checksum and removes local generations older than fourteen days:

#!/usr/bin/env bash
set -Eeuo pipefail
umask 077

backup_dir=/var/backups/site
stamp=$(date -u +%Y%m%dT%H%M%SZ)
archive="${backup_dir}/site-${stamp}.tar.gz"

install -d -m 0700 "$backup_dir"
tar -C / --one-file-system -czf "$archive" \
  etc/nginx opt/app srv/app

(
  cd "$backup_dir"
  sha256sum "$(basename "$archive")" > "$(basename "$archive").sha256"
)

find "$backup_dir" -type f -name 'site-*.tar.gz*' \
  -mmin +20160 -delete

The paths are relative to /, so extraction does not recreate the whole filesystem by accident. Adjust the directories to match the service and include the database export produced before the run. Decide separately whether content on another mounted filesystem belongs in the archive. This is a full archive schedule, not an incremental backup.

Give the script to root and deny write access to everyone else:

sudo chown root:root /usr/local/sbin/site-backup
sudo chmod 0750 /usr/local/sbin/site-backup

Run it once with sudo and inspect the exit status, archive size, checksum and contents. A cron schedule should automate a tested process rather than hide errors inside untested shell commands.

Schedule the script with cron

Install the schedule as an /etc/cron.d file so the execution account is explicit:

15 2 * * * root /usr/bin/flock -n /run/site-backup.lock /usr/local/sbin/site-backup >>/var/log/site-backup.log 2>&1

Set the file to root:root with mode 0644. A root user’s crontab can run the same job, but it must omit the user field used by /etc/cron.d. On RHEL-family systems, enable the Cronie daemon with sudo systemctl enable --now crond.

Cron uses the server’s configured local time, while the script stamps filenames in UTC. Check the zone with timedatectl and test the job around daylight-saving changes in Sydney, Melbourne, Adelaide and Hobart. Cronie handles most transitions, but an early-morning schedule still deserves a check after the clocks move.

The flock wrapper prevents overlapping runs when a large archive outlasts its normal slot. The log captures tar errors and permission failures, but it does not replace monitoring. Cron does not understand Australian state public holidays; add a wrapper or adjust the schedule when business rules require a holiday skip.

Retain and replicate copies off site

Local retention helps with accidental edits, but it cannot protect against a failed disk, ransomware or a mistaken deletion. Keep several generations, retain a copy on separate storage and keep another beyond the building or region. The age-based find command in the script is a minimum policy, not a complete disaster-recovery plan.

For Australian workloads, compare object storage or a second datacentre with the Australian regions offered by AWS, Azure and Google Cloud. Confirm service terms, replication behaviour, support response times and egress charges instead of assuming every “Australia” label provides identical residency. Encryption keys and restore credentials must survive staff or account changes.

A restricted SSH account can receive timestamped copies with rsync over an encrypted channel:

rsync -a --no-owner --no-group \
  --chmod=Du=rwx,Dgo=,Fu=rw,Fgo= \
  /var/backups/site/ backup@storage.example.com:/srv/backups/site/

The tarball itself is not encrypted, so sensitive data may also need client-side encryption. Set the destination quota and retention separately, then test downloads as well as uploads. An off-site copy that cannot be retrieved under pressure has little practical value.

Verify the backup by restoring it

Verify integrity and recoverability. A successful tar exit code proves that an archive was written, not that it contains everything needed. Compare checksums on both source and destination, list the archive before extraction, and treat warnings about changed files or vanished sources as failures to investigate.

Restore into a temporary directory rather than over a live system:

cd /var/backups/site
sha256sum -c site-20250608T021500Z.tar.gz.sha256
tar -tzf site-20250608T021500Z.tar.gz | less
install -d -m 0700 /tmp/site-restore
tar -xzf site-20250608T021500Z.tar.gz -C /tmp/site-restore

Check permissions, ownership, certificate renewal dates and application startup. When an Nginx web server is involved, validate the recovered configuration in a staging path with nginx -t -c /tmp/site-restore/etc/nginx/nginx.conf before replacing the active file.

Record the restore date, archive identifier, owner and result in the change log. Schedule recurring test restores, watch free space and send alerts to someone who is awake at 03:00 AEDT. The practical takeaway is to protect the script, retain multiple copies, verify checksums and complete a test restoration before treating a scheduled backup as operational.