Learn how to set up rsync backups on AlmaLinux 10 with a repeatable backup job, verification steps, and rollback guidance.

Introduction

This tutorial shows how to build a practical rsync backups workflow on AlmaLinux 10 for a dedicated server. You will create a source and destination path, run an initial synchronized copy, schedule the job with cron, and confirm that the backup behaves as expected on subsequent runs.

The goal is a straightforward file-level backup job that experienced administrators can apply to a server data set without adding unrelated services or platform changes. If you are validating backup output later, the process pairs well with Backup Verification on Ubuntu 26.04 and AlmaLinux 10.

Prerequisites

• AlmaLinux 10 on the dedicated server.
• Root access or a normal administrative user with sudo privileges.
• Network access to install packages from the configured repositories.
• A shell session on the server where you will manage the backup job.

Tutorial steps

Install rsync

Install rsync first so the backup command and verification checks are available:

sudo dnf install -y rsync

Confirm the installation succeeded:

rsync --version

Create the backup source and destination directories

Create a simple source tree and a backup destination that mirrors it under /backup/rsync:

mkdir -p /srv/source-data /backup/rsync/source-data

Populate /srv/source-data with the files you want to protect, or replace that path with your own dedicated-server data directory if you already have one in place. Keep the source and destination paths consistent so the rsync job stays predictable.

Run the first rsync backup

Run the initial backup with archive mode and the preservation flags needed for a practical server backup job:

rsync -aHAX --delete /srv/source-data/ /backup/rsync/source-data/

This command copies the contents of the source directory into the destination and removes files from the backup target when they no longer exist in the source. The trailing slashes matter because they instruct rsync to copy directory contents rather than the directory itself.

Automate the backup with cron

Edit the crontab for the account that should run the backup job:

crontab -e

Add a schedule that repeats the same rsync command at your preferred interval. Use the exact source and destination paths you tested manually so the cron job matches the working backup command.

After saving the crontab, confirm that the entry is present:

crontab -l

Verification

After the first run, confirm that the destination directory contains the copied files and matches the expected backup contents. A quick file listing in /backup/rsync/source-data should show the data you placed under /srv/source-data.

Run rsync in dry-run mode to verify that the next execution would not introduce unexpected changes:

rsync -aHAX --delete --dry-run /srv/source-data/ /backup/rsync/source-data/

If the source and destination are aligned, the dry run should report no surprising file additions, removals, or attribute changes. For a broader verification workflow, you can also compare the backup result with the practices described in Automating PostgreSQL Backups on Linux a Guide.

Finally, use crontab -l again to verify that the scheduled entry still exists and matches the command you intended to automate.

Troubleshooting

If the backup does not behave as expected, check the most common causes first:

• Missing permissions on /srv/source-data or /backup/rsync/source-data.
• Incorrect source or destination paths in the rsync command.
• Using a different user in cron than the one that successfully ran the manual backup.

When permissions are the issue, rerun the command with the correct administrative access and ensure the backup target is writable. When the path is wrong, compare the manual command with the cron entry and confirm both match exactly.

Rollback

If you need to remove the backup copy and undo this tutorial's destination data, delete the backup directory:

sudo rm -rf /backup/rsync/source-data

This rollback removes the backup set created for the example job without changing the source directory on the dedicated server. If you also added a cron entry, remove it from the same user's crontab before considering the setup fully reverted.

Conclusion

You have now set up rsync backups on AlmaLinux 10 for a dedicated server, tested the initial synchronization, scheduled it with cron, and validated the result with dry-run checks. After completing this tutorial, you can confirm both the copied backup data and the presence of the cron entry that drives the repeated job.