Using rsync for efficient file synchronisation and backup

rsync is a Linux command-line program for synchronising files between directories, hosts and remote systems. It compares source and destination, sends only changed blocks and can preserve ownership, timestamps, permissions, links and directory structure. That makes it useful for everything from copying a web project to maintaining a local backup of home directories.

For administrators on RHEL, CentOS Stream and Fedora, rsync offers a compact, scriptable alternative to repeated tar archives or full cp operations. It works well over SSH, supports dry runs and detailed statistics, and can create versioned copies. It is not, by itself, a complete disaster-recovery system: destination selection, retention, monitoring and restore testing still matter.

How rsync reduces transferred data

The default algorithm checks each file’s size and modification time. When a file has changed, rsync divides source and destination files into blocks, calculates checksums and sends only the differing blocks before assembling the destination file. This delta-transfer behaviour is especially valuable for large logs, virtual-machine images and database exports that change slightly between runs.

The archive flag, -a, combines recursive copying with preservation of symbolic links, permissions, timestamps, ownership and special files. Add -A for ACLs, -X for extended attributes and -H for hard links when those metadata types matter. Use -c for a full checksum comparison when timestamps are unreliable; it consumes more CPU and disk I/O but avoids trusting superficial file attributes.

Preparing a safe local synchronisation

Install the package with sudo dnf install rsync on Fedora or RHEL, and on CentOS Stream where the repository provides it. First run a dry run such as rsync -avzn --delete /srv/app/ /backup/app/ and inspect the file list carefully. The trailing slash on /srv/app/ copies its contents, whereas omitting it can create a nested app directory inside the destination.

Ownership can be a common failure point when a destination directory has restrictive access. A clear explanation of Linux permissions and umask helps set expectations before transfer. Keep a dedicated service account, preserve only metadata the destination can support, and run the first copy with --stats to expose permission errors, unexpected growth and files skipped by exclude rules.

Remote transfers across Australian networks

Use SSH to move data between Linux hosts: rsync -az --partial --info=progress2 user@sydney-host:/srv/data/ /mnt/backup/data/. The --partial option preserves incomplete transfers for resumption, while -z compresses data in transit. Compression helps text and uncompressed media over constrained links, but adds CPU work and rarely benefits files that are already compressed.

Australian NBN connections often provide much faster downloads than uploads, and traffic between Perth, Adelaide, Brisbane, Sydney and Melbourne can cross substantial distances. Delta transfers and scheduled off-peak runs reduce WAN usage, but administrators should measure upload throughput rather than rely on headline download speeds. Public cloud regions in Sydney and Melbourne offer another destination, although object-storage sync clients may not reproduce rsync’s exact metadata and deletion behaviour.

Versioning and protecting deleted files

The --delete option makes a destination match the source by removing files absent from it. That is useful for mirroring, but dangerous for backups because corruption, a mistaken rm or a compromised account can propagate. Use --delete-delay to reduce mid-transfer deletion risk, and consider --backup --backup-dir=/backup/versions so replaced or removed files are retained separately from the live mirror.

For versioned snapshots, --link-dest can hard-link unchanged files to a previous backup while storing new data once, reducing disk consumption. Hard-linked snapshots still need an independent retention policy and protection against destructive changes to the source tree. Test restoration regularly, record which backup was selected, and align the process with the ASD Essential Eight where it applies to the organisation.

Scheduling, logging and security controls

Run rsync from a systemd service paired with a timer on RHEL-family systems, or use cron where that matches local operations. Put the command in a script protected by flock to prevent overlapping runs, and include an exit-code check so failures raise an alert instead of disappearing in the scheduler log. Specify an Australian time zone because Sydney and Melbourne change clocks while Brisbane and Perth do not.

Store logs outside the synchronised tree and review them for changed-file counts, transfer volume and vanished destinations. Endpoint protection remains useful, and Norton security advice can help teams assess security controls, but malware protection cannot replace a recoverable copy. Where the Privacy Act 1988 applies, Australian Privacy Principle 11 requires reasonable steps to protect personal information from misuse, interference, loss and unauthorised access; backup access, retention and disposal should therefore match the organisation’s privacy obligations.

A practical backup routine

A workable schedule pairs an incremental rsync run each night with weekly versioned snapshots and monthly restore checks. Keep a working copy on a local disk or NAS, a versioned copy on a second storage system, and one copy in a separate Australian site so a ransomware event or hardware fault does not destroy every generation. Exclude caches, temporary files and live database sockets with --exclude rules, then document each excluded path.

During each monthly drill, restore a representative document set, application configuration and database export into a clean directory, then compare file counts, permissions and application behaviour. Retain logs and test results as evidence rather than assuming a zero exit code proves recoverability. The practical takeaway is simple: automate small incremental transfers, retain dated versions, protect one copy from deletion and verify that a required file can actually be restored.