Incremental Backups With rsync on RHEL

Incremental backups with rsync copy only new and changed data, reducing transfer time, storage use, and pressure on production servers. On RHEL, the utility works well for home directories, web content, application files, and selected configuration paths.

A practical backup design combines a local or remote destination, SSH authentication, a repeatable schedule, and regular restore tests. This approach suits administrators managing systems in Sydney, Melbourne, Brisbane, or smaller regional offices where bandwidth and recovery time can vary.

Install And Prepare rsync

Install the package on the RHEL source host and the backup destination:

sudo dnf install -y rsync openssh-clients
rsync --version

Create a dedicated destination directory rather than writing backups into a user’s home directory. For a remote server, create a restricted backup account and use SSH keys instead of storing passwords in scripts.

sudo useradd --system --create-home backup
sudo mkdir -p /backup/rhel01
sudo chown backup:backup /backup/rhel01

Ensure the destination has enough capacity and a filesystem that supports ownership, permissions, symbolic links, and timestamps. An encrypted volume is advisable when backups contain customer records or business data subject to Australian privacy obligations.

Run A Basic Incremental Copy

A straightforward copy uses archive mode, which preserves permissions, ownership, timestamps, symbolic links, and recursive directory contents:

sudo rsync -aHAX --numeric-ids \
  --info=progress2 \
  /etc/ /var/www/ backupuser@backup.example:/backup/rhel01/

The trailing slash on /etc/ means that its contents are copied into the destination. Without it, rsync creates an additional etc directory. The second run compares metadata and file content, transferring only files that have changed.

Use a dry run before the first production transfer:

sudo rsync -aHAXn --delete /var/www/ /backup/rhel01/www/

The --delete option makes the destination mirror the source, so use it carefully. A deleted source file may also disappear from the destination unless you keep dated snapshots.

Keep Dated Snapshots With link-dest

For recoverable daily versions, create a new directory for each run and use --link-dest to hard-link unchanged files from the previous snapshot:

today=$(date +%F)
previous=/backup/rhel01/latest
destination=/backup/rhel01/snapshots/$today

mkdir -p "$destination"
rsync -aHAX --delete \
  --link-dest="$previous" \
  /etc/ /var/www/ "$destination"/
ln -sfn "$destination" /backup/rhel01/latest

Hard-linked files occupy storage only once, while each snapshot appears complete when browsed. This is useful for recovering a configuration from last Tuesday rather than relying on the current mirror.

Keep the snapshot destination on the same filesystem because hard links cannot cross filesystem boundaries. Prune old snapshots with a tested retention policy, such as seven daily copies, four weekly copies, and several monthly copies.

Protect SSH And Network Transfers

Generate a key for the backup account and install its public key on the destination:

sudo -u backup ssh-keygen -t ed25519 -f /home/backup/.ssh/id_ed25519
sudo -u backup ssh-copy-id backupuser@backup.example
sudo -u backup ssh backupuser@backup.example hostname

Restrict the destination account in authorized_keys where practical, and permit access only from the backup host. Network transfers should use a private management network or VPN, particularly when servers are hosted across Australian offices or in separate Sydney and Perth facilities.

Host firewall policy must allow SSH only from trusted addresses. The firewalld rules guide provides useful background for limiting administrative services on RHEL-like systems.

Exclude Temporary And Sensitive Data

Not every path belongs in an incremental backup. Caches, runtime sockets, temporary files, and mounted pseudo-filesystems create noise or can cause inconsistent copies.

Create an exclude file:

/proc/
/sys/
/dev/
/run/
/tmp/
/var/cache/
/var/tmp/
/mnt/
/media/

Then apply it consistently:

rsync -aHAX --delete --exclude-from=/etc/rsync-backup.exclude \
  / backupuser@backup.example:/backup/rhel01/rootfs/

Review exclusions carefully. Application uploads, database dumps, TLS keys, and /etc configuration may be essential. Databases should generally be backed up with a database-aware dump or snapshot before rsync copies the resulting files.

Automate The Backup Schedule

A systemd timer gives clearer logging and dependency control than a traditional cron entry. Place the transfer in /usr/local/sbin/rhel-backup.sh, make it executable, and log failures:

#!/bin/bash
set -euo pipefail
rsync -aHAX --delete --exclude-from=/etc/rsync-backup.exclude \
  / backupuser@backup.example:/backup/rhel01/rootfs/

Schedule it outside peak business hours, using the server’s configured timezone. Australian organisations with staff in AEST, ACST, and AWST should document whether “midnight backup” means local site time or a central UTC schedule. Avoid assuming that public holidays remove the need for monitoring.

Backup Checks That Matter

A backup is useful only when its contents and recovery path are known. Check transfer output, destination capacity, SSH connectivity, and the age of the latest snapshot.

• Confirm the last run completed successfully.
• Check disk usage and inode availability.
• Review rsync errors and SSH logs.
• Verify that expected files exist.

Perform a small restore test to a temporary directory rather than overwriting live data:

mkdir /tmp/restore-test
rsync -aHAX /backup/rhel01/snapshots/2026-09-24/etc/ /tmp/restore-test/etc/
diff -r /etc /tmp/restore-test/etc

Also test ownership, SELinux contexts, service configuration, and application startup. Useful operational checks include:

• Restore an Nginx configuration.
• Recover one user directory.
• Rebuild a failed virtual machine.
• Record the time required for recovery.

Restore Files Safely

Restore selected files by reversing the source and destination arguments. For example:

sudo rsync -aHAX \
  /backup/rhel01/snapshots/2026-09-24/var/www/ \
  /var/www/

Use --dry-run first, especially when restoring with --delete. After restoring files under an SELinux-enforcing policy, relabel them if required:

sudo restorecon -RFv /var/www

For a full server recovery, reinstall the matching RHEL release, recreate storage and network settings, restore configuration and application data, then validate services in stages. Keep backup credentials, encryption keys, retention rules, and recovery notes separate from the host being protected.

rsync provides efficient incremental transfers, while --link-dest turns repeated transfers into space-efficient dated snapshots. The essential practice is simple: preserve the right metadata, secure the transport, schedule consistently, and prove through restore tests that the files can be recovered when an Australian business needs them.