Setting Up Reliable Backups With Duplicity On CentOS

A sound backup strategy protects files, configuration, databases, and encryption keys from accidental deletion, hardware failure, ransomware, and site outages. On CentOS, duplicity provides encrypted, incremental backups through familiar command-line tools, while supporting destinations such as SFTP, Amazon S3-compatible storage, and local disks.

For Australian administrators, the backup location deserves particular thought. An office in Sydney may have dependable NBN service, while a regional Queensland site can face outages during storms or flooding. A Melbourne business may also need a recovery copy outside the city, and organisations covered by the Australian Privacy Act should understand where sensitive data is stored.

Define What Needs Protection

Start by listing the data that must be recovered. Common candidates include /etc, web content under /var/www, application data, user home directories, SSL certificates, cron definitions, and database dumps. Avoid backing up temporary files, package caches, mounted media, and large log files unless they have a specific retention requirement.

Duplicity uses a full-and-incremental model. A full backup contains the selected source data, while later incremental sets record changes since the previous backup. This reduces upload time and storage use, although recovery depends on the relevant backup chain remaining intact.

A practical policy might keep daily incrementals for 14 days, weekly full backups for two months, and a monthly archive for a year. Keep at least one copy away from the server. For a Perth or Darwin deployment, an interstate storage region can reduce the effect of a local incident.

Prepare CentOS And Encryption

Install duplicity and GnuPG from the appropriate repositories. On a CentOS 7 host, administrators commonly enable EPEL before installation:

sudo yum install epel-release
sudo yum install duplicity gnupg2

On CentOS Stream or a newer compatible system, use the available dnf package manager and verify the package version with duplicity --version. Repository names and Python dependencies can vary, so test the command on a non-production host first. Administrators building a desktop status utility may also find this coordinate reference useful when aligning notification windows, although the backup process itself should remain command-line driven.

Create a dedicated GPG key for backup encryption rather than using a personal key. Export the public key to the backup host if required, and store the private key in a protected offline location. Never place a passphrase directly in a world-readable shell script.

Create The Backup Job

A simple encrypted backup to an SFTP server can look like this:

export PASSPHRASE='use-a-protected-secret-source'
duplicity --encrypt-key BACKUP_KEY_ID \
  /etc sftp://backupuser@backup.example.net//srv/backups/web01
unset PASSPHRASE

The double slash after the hostname helps identify an absolute remote path. For a real system, use a restricted SSH key, disable interactive password authentication for the backup account, and grant that account access only to its backup directory. Add web content and application data as separate source paths or create a carefully reviewed staging directory.

A database should be dumped before duplicity reads its files. For MariaDB, a scheduled mysqldump can write to a root-owned directory, after which duplicity backs up the resulting archive. Check exit codes and log output; a command that runs without a visible error is not proof that the remote files are usable. The Linux and Unix guides provide useful background for permissions, shell scripting, and service administration.

Select Storage And Retention

The destination should match recovery speed, budget, compliance needs, and network reliability. A local USB disk offers fast restores but can be stolen or damaged with the server. Object storage is geographically resilient, while SFTP gives straightforward control over another Linux host.

Destination	Strength	Limitation	Suitable Use
Local disk	Fast backup and restore	Vulnerable to the same physical incident	Quick operational recovery
SFTP server	Familiar Linux access controls	Requires a second maintained host	Offices and private infrastructure
S3-compatible storage	Off-site durability and automation	Egress and API costs may apply	Long-term remote copies
Removable disk	Works during internet outages	Requires disciplined rotation	Regional or bandwidth-limited sites

Remove obsolete chains only after confirming that newer backups and at least one full recovery path exist:

duplicity remove-older-than 60D --force \
  sftp://backupuser@backup.example.net//srv/backups/web01

For Australian organisations, check whether data must remain in an Australian region and account for AUD-denominated storage, retrieval fees, and limited upload capacity on some NBN or mobile links.

Schedule Tests And Recovery

Use a systemd timer or a root-owned cron job to run backups outside peak hours, such as overnight AEST. Remember that daylight saving changes affect Sydney, Melbourne, Adelaide, and Hobart, but not Queensland, the Northern Territory, or Western Australia. Logging should include start time, destination, transferred volume, and exit status.

A test restore should be performed on a clean virtual machine, not over the live source directory. For example:

export PASSPHRASE='use-a-protected-secret-source'
duplicity restore \
  sftp://backupuser@backup.example.net//srv/backups/web01 \
  /tmp/web01-restore
unset PASSPHRASE

Useful operational safeguards include:

• Run duplicity collection-status after each full backup cycle.
• Monitor free space on both the source server and remote destination.
• Keep GPG private keys and recovery instructions offline.
• Test a representative file, configuration directory, and database restore quarterly.
• Send failures to an administrator through email, monitoring, or a local alert service.
• Document retention rules, storage regions, SSH keys, and the person responsible for recovery.

For administrators preparing for support roles, practicing these procedures alongside Linux interview questions helps connect backup theory with permissions, cron, networking, and incident response. The concrete next step is to create a small test directory on the CentOS host, run one encrypted duplicity backup to a separate destination, and restore it into /tmp before scheduling production data.