Backup Verification on Ubuntu 26.04 and AlmaLinux 10

Backup verification tells you whether a backup can actually be restored when a server, database, or site needs recovery. A backup that exists but cannot be opened, mounted, or restored only proves that a job ran. This tutorial shows you how to verify backup integrity on a fresh Linux server, test a restore safely, review logs, and leave the system ready for repeatable recovery.

This guide uses a small file-based example that fits most hosting setups: website files, configuration archives, and database dumps. It is designed for dedicated servers from HostnExtra, where root access, NVMe storage, and consistent performance make recovery testing straightforward. If you are still choosing infrastructure, start with a dedicated server at https://hostnextra.com/dedicated-server.

What you will build and verify

SSH access from your local computer to the server.
A non-root sudo user for safe administration.
A backup source directory, a backup archive, and checksum files.
A restore test directory that proves the archive can be extracted.
Log review steps for cron, tar, and system messages.
A rollback path if the verification test fails.

Supported systems: Ubuntu 26.04 LTS, Debian 13, AlmaLinux 10, and Rocky Linux 10. The commands below split where package names, sudo groups, firewalls, or SELinux handling differ.

Prerequisites: one dedicated server, one local terminal, DNS not required for this file-based test, and SSH access on port 22 unless your provider uses a custom port. Replace placeholders such as SERVER_IP=203.0.113.10, ADMIN_USER=deploy, and BACKUP_DIR=/var/backups/verify-demo with your own values.

Connect to the server and create a sudo user

Run the SSH command from your local computer first. Keep the original root session open until you test the new user in a second terminal.

ssh root@SERVER_IP

If your provider uses a custom SSH port, use this pattern instead:

ssh -p 2222 root@SERVER_IP

After login, run the operating system check as root. This confirms which package and firewall instructions to follow.

cat /etc/os-release

On Ubuntu/Debian, create the admin user and add it to the sudo group. Run these commands as VPS as root.

apt update
apt install -y sudo openssh-client ca-certificates rsync tar coreutils
adduser deploy
usermod -aG sudo deploy

These commands update packages, install the tools used for verification, create the non-root account, and grant sudo access. Replace deploy with your preferred admin username. If the commands complete without errors, the user is ready.

On AlmaLinux and Rocky Linux, run the equivalent commands as VPS as root.

dnf -y update
dnf -y install sudo openssh-clients ca-certificates rsync tar coreutils
useradd -m deploy
passwd deploy
usermod -aG wheel deploy

The wheel group provides sudo access on RHEL-compatible systems. If you set a password with passwd, store it securely and replace it after key-based login works.

Now prepare SSH keys from your local computer. If you already have a key, reuse it; otherwise create one. Run this locally:

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_backup_verify

This creates a modern SSH key pair with a strong key-derivation setting. Accept the default location if you prefer, but keep the private key on your local machine only.

Copy the public key to the new user. Use your local computer again:

ssh-copy-id -i ~/.ssh/id_ed25519_backup_verify.pub deploy@SERVER_IP

If your SSH port is custom, add -p 2222 to the command. The expected result is that the public key is appended to ~/.ssh/authorized_keys on the server.

On the server, finish the permissions work as the new sudo user or as root if needed. These permissions matter for SSH access.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Test the new session from a second local terminal before making root access changes. Run:

ssh -i ~/.ssh/id_ed25519_backup_verify deploy@SERVER_IP

Then test sudo in the new session. Run this as VPS as the named sudo user:

sudo -v

If the command returns without asking for a root password and without errors, the account is ready. Only after that should you harden root or password login to match your site policy.

Create a backup set and verify backup verification

This example backs up a small directory and then verifies it with checksums and a restore test. Run the remaining commands as VPS as the named sudo user or root if your sudo policy allows it.

sudo mkdir -p /opt/backup-verify-demo/source
sudo mkdir -p /var/backups/verify-demo
sudo mkdir -p /srv/restore-test
sudo chown -R deploy:deploy /opt/backup-verify-demo /srv/restore-test

Create sample files so the archive has predictable content.

cat > /opt/backup-verify-demo/source/site.conf <<'EOF'
APP_NAME=demo-site
ENVIRONMENT=production
EOF

cat > /opt/backup-verify-demo/source/index.html <<'EOF'
<html><body>Backup verification test</body></html>
EOF

These files simulate a small application or website tree. Confirm they exist:

ls -l /opt/backup-verify-demo/source

Create the backup archive and checksum file:

tar -czf /var/backups/verify-demo/site-backup.tar.gz -C /opt/backup-verify-demo/source .
sha256sum /var/backups/verify-demo/site-backup.tar.gz | tee /var/backups/verify-demo/site-backup.tar.gz.sha256

The archive contains your source tree, and the SHA-256 file records the expected hash. Success means both files exist in /var/backups/verify-demo.

Verify the checksum immediately. This catches corruption before you try a restore.

sha256sum -c /var/backups/verify-demo/site-backup.tar.gz.sha256

Expected output ends with OK. If it says FAILED, recreate the archive and checksum before continuing.

Test the restore safely

Extract the archive into a separate restore directory, never over the source. This is the clearest proof that backup verification passed.

sudo rm -rf /srv/restore-test/*
sudo tar -xzf /var/backups/verify-demo/site-backup.tar.gz -C /srv/restore-test
ls -l /srv/restore-test

The restore directory should now contain site.conf and index.html. Validate the file contents:

cat /srv/restore-test/site.conf
cat /srv/restore-test/index.html

If the files match the originals, the archive can be restored successfully. If extraction fails, check whether the tarball was truncated or whether permissions blocked the write path.

Add scheduled verification and log checks

A backup only becomes dependable when you check it on a schedule. Create a small verification script and a cron job that verifies the archive daily. First, create the script as the sudo user:

cat > ~/verify-backup.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
ARCHIVE=/var/backups/verify-demo/site-backup.tar.gz
CHECKSUM=/var/backups/verify-demo/site-backup.tar.gz.sha256
RESTORE_DIR=/srv/restore-test
rm -rf "$RESTORE_DIR"/*
sha256sum -c "$CHECKSUM"
tar -xzf "$ARCHIVE" -C "$RESTORE_DIR"
EOF
chmod 700 ~/verify-backup.sh

This script checks the hash and performs a restore test. Review it before scheduling so you understand what it changes.

Add the cron entry for daily execution at 02:15 as the same sudo user:

crontab -e

Insert this line in the editor, save, and exit:

15 2 * * * /home/deploy/verify-backup.sh >> /var/log/verify-backup.log 2>&1

Confirm the cron entry exists:

crontab -l

Check logs after the first run. On Ubuntu/Debian, use:

journalctl -u cron --since "1 hour ago"
cat /var/log/verify-backup.log

On AlmaLinux and Rocky Linux, use:

journalctl -u crond --since "1 hour ago"
cat /var/log/verify-backup.log

Look for checksum success and tar extraction without errors.

Rollback procedure if verification fails

If checksum or restore validation fails, stop using the archive and create a fresh one from known-good source data. Remove the bad files before rebuilding:

rm -f /var/backups/verify-demo/site-backup.tar.gz
rm -f /var/backups/verify-demo/site-backup.tar.gz.sha256
tar -czf /var/backups/verify-demo/site-backup.tar.gz -C /opt/backup-verify-demo/source .
sha256sum /var/backups/verify-demo/site-backup.tar.gz | tee /var/backups/verify-demo/site-backup.tar.gz.sha256
sha256sum -c /var/backups/verify-demo/site-backup.tar.gz.sha256

If the restore directory is polluted, clear it and repeat the extraction:

rm -rf /srv/restore-test/*
tar -xzf /var/backups/verify-demo/site-backup.tar.gz -C /srv/restore-test

If the archive still fails, check disk space, source permissions, and backup storage health before another attempt.

Server and client verification

Finish with a real verification pass. On the server, confirm ownership, file sizes, and free space:

df -h
ls -lh /var/backups/verify-demo
stat /var/backups/verify-demo/site-backup.tar.gz

Check that the scheduled job exists and the restore test directory contains the expected files:

crontab -l
ls -l /srv/restore-test
sha256sum -c /var/backups/verify-demo/site-backup.tar.gz.sha256

From your local computer, run a final SSH test to confirm the host is reachable after all changes:

ssh -i ~/.ssh/id_ed25519_backup_verify deploy@SERVER_IP 'hostname && uptime'

That command should print the server hostname and uptime. If it does, your backup verification workflow is working end to end.

Need a server that makes recovery testing practical? Browse HostnExtra dedicated servers at https://hostnextra.com/dedicated-server or choose a region that matches your users: USA, Germany, London, Netherlands, or Switzerland.

FAQ

How often should I test restores?
At least once after every backup policy change, then on a fixed schedule. A backup that is never restored is not verified.

Should backup verification use the production path?
No. Restore into a separate directory or test host so you do not overwrite live files by mistake.

What is the simplest integrity check?
A checksum comparison with sha256sum -c is the simplest reliable file-level integrity check before a restore test.

Can I apply this to database dumps?
Yes. Replace the tar archive with a SQL dump, then verify the dump file and restore it into a test database before using it in production.