How to Automate Dedicated Server Backups Using Restic on Ubuntu 24.04

Introduction

A dedicated server can host critical business applications, websites, databases, email services and important customer information. Losing this data because of hardware failure, accidental deletion, ransomware or a failed system update can cause serious operational problems.

That is why having a reliable and automated server backup strategy is essential.

Manually creating backups is time-consuming and easy to overlook, particularly when managing multiple dedicated servers. Automating the process ensures that important files are regularly backed up without requiring an administrator to execute backup commands every day.

One effective solution is Restic, an open-source backup program that supports encrypted, deduplicated and incremental snapshot-based backups.

In this tutorial, you will learn how to configure Restic backup on Ubuntu 24.04 and automate the entire process using S3-compatible object storage and systemd timers.

We will cover everything from installing Restic and creating an encrypted backup repository to scheduling automatic backups, configuring retention policies and restoring files when needed.

By the end of this guide, you will have a practical backup workflow that can help protect data stored on your dedicated server.

What You Will Build

The completed setup will allow your Ubuntu 24.04 dedicated server to:

• Automatically back up selected system and application directories.

• Encrypt backup data before storing it remotely.

• Upload backups to S3-compatible object storage.

• Create scheduled daily backups using systemd timers.

• Retain selected daily, weekly and monthly snapshots.

• Verify backup repository integrity.

• Restore individual files or complete directories when required.

Prerequisites

Before configuring automated Linux server backups, make sure you have:

• A dedicated server running Ubuntu 24.04 LTS.

• Root or sudo access.

• An active internet connection.

• An S3-compatible storage bucket.

• S3 access key and secret key.

• Sufficient storage capacity for your backup requirements.

• Basic knowledge of Linux commands and system administration.

You should also have permission to install packages and configure systemd services.

1. What Is Restic and Why Use It for Dedicated Server Backups?

Restic is an open-source command-line backup utility designed to protect data across different storage environments.

It supports several backup destinations, including local storage, SFTP, REST servers and cloud object-storage services such as Amazon S3 and compatible providers.

For dedicated server administrators, Restic offers several useful capabilities.

Encrypted backups

Restic encrypts backup data before storing it in the repository. This helps protect sensitive server information, including configuration files, application data and database dumps.

A repository password is required to access and decrypt the backup data. Therefore, keep a secure copy of the password outside the server.

Data deduplication

Deduplication helps reduce unnecessary storage consumption.

Instead of uploading all existing data during every backup, Restic identifies data already stored in the repository and reuses it. This makes recurring backups more efficient, particularly when only a small portion of your server data changes between backup sessions.

Snapshot-based backups

Restic creates snapshots that represent the selected files and directories at a particular point in time.

You can browse previous snapshots and restore files from a specific backup rather than recovering the entire server.

Multiple storage destinations

Restic supports different backup destinations, making it possible to build a flexible backup infrastructure. For example, you can store backups in:

• Amazon S3.

• S3-compatible object storage.

• SFTP servers.

• Local backup disks.

• REST-based backup storage.

For this tutorial, we will use S3-compatible object storage to keep backup data separate from the production server.

2. Update Ubuntu 24.04 and Install Restic

Before installing Restic, update your Ubuntu package repositories and existing packages.

Connect to your dedicated server through SSH and execute:

Once the system is updated, install Restic:

Verify that the installation was successful:

The command should display the installed Restic version.

Next, create directories for Restic configuration and backup-related logs:

Restrict access to the configuration directory:

These directories will help organize backup credentials and configuration files.

3. Configure an Encrypted Restic Backup Repository

A Restic repository is the location where backup snapshots and their associated data are stored. In this tutorial, the repository will be hosted in S3-compatible object storage.

Step 1: Prepare your S3-compatible storage

Create a private storage bucket through your preferred object-storage provider. You will need the following information:

For example: https://s3.example-storage.com

Replace this example with the actual endpoint provided by your storage provider. Create an access key with only the permissions required to access your backup bucket.

Step 2: Create the Restic environment configuration

Create an environment file:

Add the following configuration:

Replace the placeholder values with your actual storage credentials and configuration.

Some S3-compatible providers require additional settings for endpoint compatibility, region handling or bucket addressing. Follow the provider's documentation when configuring these options.

Save the file and restrict access:

Security recommendation: Never publish your S3 access credentials or store them in publicly accessible scripts or repositories.

Step 3: Generate a strong repository password

Restic requires a password to encrypt and decrypt repository data.

Generate a strong random password:

Set the correct permissions:

Keep a separate, securely stored copy of this password. If the password is lost, Restic cannot decrypt the repository. Storing the only recovery copy on the server defeats an important part of an off-site backup strategy.

4. Initialize the Restic S3 Backup Repository

Now that the storage configuration and repository password are ready, initialize the repository.

First, open a root shell:

Load the environment configuration:

Initialize the repository:

If the configuration is correct, Restic will create the encrypted repository in your selected S3-compatible storage bucket. You should receive a confirmation that the repository has been successfully created.

Verify repository access:

Because this is a new repository, the snapshot list should initially be empty.

You now have an encrypted Restic repository ready to receive dedicated server backups.

Important: Repository initialization is normally performed only once. Do not initialize an existing repository again when troubleshooting connection problems.

5. Select the Files and Directories to Back Up

Before creating an automated backup script, decide which server directories contain important information. A typical Ubuntu dedicated server may store important data in several locations.

For this example, we will back up these directories. However, the correct backup selection depends on your server configuration. For example, if your website stores application files in a custom directory, add that location to the backup script.

What about MySQL and PostgreSQL databases?

Database backups require additional consideration. Simply copying a running database's data directory may produce an inconsistent backup because database files can change while Restic is reading them.

For MySQL or MariaDB, create a database dump using an appropriate database backup procedure. For example:

This example is suitable only when its assumptions match your database engine, storage engine and privileges. Use appropriate authentication configuration rather than placing database passwords directly in command arguments.

For PostgreSQL, use its native backup utilities, such as pg_dump or pg_dumpall, depending on your recovery requirements. Store the resulting backup files in a protected directory included in your Restic backup.

This approach allows Restic to back up a consistent database export rather than relying on an ordinary file copy of a live database directory.

6. Create an Automated Restic Backup Script

Manually executing Restic commands every day is not an efficient backup strategy. Instead, create a reusable shell script that performs the backup and applies the retention policy.

Create the script:

Add the following code:

Save the script. Make it executable:

Set the correct ownership:

Understanding the backup script

Let's examine the important parts.

Environment configuration

This loads the repository location, storage credentials and password-file location.

Backup directory selection

These are the directories Restic will include in the backup. Remove paths that do not exist on your server and add any application-specific directories that contain important data.

Backup tags

These tags help identify snapshots created by this backup script.

Retention policy

These settings determine how many daily, weekly and monthly snapshots Restic should retain. The --prune option removes repository data that is no longer required by retained snapshots.

The example exclusions are only starting points. Check that excluded cache and temporary directories do not contain unique information required for recovery.

7. Run the First Backup Manually

Before configuring automatic scheduling, test the backup script manually.

Execute:

Restic will begin scanning the selected directories and uploading the backup data to your S3-compatible repository. The first backup may take longer because the repository does not contain previously uploaded data. Subsequent backups can be faster because Restic reuses existing data through deduplication.

Once the command finishes, verify the available snapshots:

You should see the newly created snapshot, including its ID, timestamp, hostname and tags.

If the command reports an error, resolve it before continuing. Common issues include incorrect S3 credentials, unavailable directories, insufficient permissions and storage connectivity problems.

8. Automate Daily Backups Using Systemd Timers

Now we will configure systemd to execute the Restic backup script automatically. Systemd timers provide a convenient scheduling mechanism for recurring Linux administration tasks.

We will create two files:

1. A systemd service that executes the backup script.

2. A systemd timer that determines when the service runs.

Step 1: Create the systemd service

Create the service file:

Add:

Save the file. This service executes the Restic backup script with root permissions, allowing it to read protected system and application directories. The CPU and disk I/O priority settings can help reduce interference with production workloads.

Step 2: Create the systemd timer

Create the timer configuration:

Add:

This configuration schedules the backup every day at approximately 2:30 AM server local time. The randomized delay distributes execution times within the configured window, while Persistent=true allows a missed calendar run to be triggered when the timer becomes active again.

Check the server timezone:

Choose a backup schedule that avoids your server's busiest operating hours.

Step 3: Enable automatic backups

Reload systemd:

Enable and start the timer:

Check the timer status:

To see the next scheduled execution:

Automation configured: Your dedicated server is now configured to run the Restic backup script automatically according to the systemd timer schedule.

9. Monitor Automated Backup Jobs

Scheduling backups is only one part of server backup management. You should also monitor backup execution to identify failures before they become serious problems.

Systemd provides useful commands for checking backup activity.

View recent backup logs:

Follow backup logs in real time:

Check the service status:

Run the backup service manually:

Check the last execution result:

For production environments, consider configuring monitoring or notifications when a backup fails or when the latest successful snapshot becomes too old. A scheduled job that silently fails is not a reliable backup solution.

10. Configure Restic Backup Retention Policies

As backups accumulate, repository storage requirements increase. Keeping every snapshot indefinitely may consume unnecessary storage capacity.

Restic provides the forget command to manage snapshot retention. In our example, we use:

This configuration retains:

The retention policy provides a combination of recent recovery points and longer-term snapshots. However, retention requirements differ between businesses. For example:

• A small website may need only a short recovery window.

• An e-commerce platform may require more frequent backups.

• A business handling regulated information may have specific retention obligations.

• A large database environment may require transaction-log backups and longer recovery history.

Before applying a new retention policy, preview which snapshots would be removed:

Review the results before applying the policy. Remember that pruning physically removes repository data no longer required by retained snapshots. Choose retention settings carefully.

11. Verify Restic Backups and Restore Files

Creating automated backups does not guarantee that the data can be recovered successfully. You should periodically verify repository integrity and perform restoration tests.

Step 1: List available snapshots

Execute:

This displays the snapshots stored in the repository.

Step 2: Check repository integrity

Run:

This checks repository structure and metadata. For a deeper verification that reads stored backup data, execute:

A full data check can take considerable time and bandwidth for large repositories. Schedule it appropriately or use supported subset-check options for regular sampling.

Step 3: Browse files inside a snapshot

To inspect the latest snapshot:

To inspect a specific snapshot:

Replace SNAPSHOT_ID with the actual snapshot identifier.

Step 4: Restore backed-up files

Create a separate restore directory:

Restore the latest snapshot:

Restic will reconstruct the backed-up directory structure inside /restore. For example, a backed-up /etc directory will be available under: /restore/etc

You can also restore a specific directory from a selected snapshot:

Replace the snapshot ID with the actual identifier.

Always restore to a separate directory or test server first. Check file ownership, permissions and application compatibility before replacing production files.

Best practice: Perform regular restoration tests. A backup strategy is only reliable when you have verified that important files and databases can actually be recovered.

12. Common Restic Backup Errors and How to Fix Them

Even with a correctly configured backup script, you may encounter problems related to storage authentication, repository access, permissions or network connectivity. Here are some common Restic errors and their solutions.

Error 1: S3 authentication failed

Possible causes:

• Incorrect access key or secret key.

• Insufficient bucket permissions.

• Incorrect S3 endpoint.

• Incorrect region configuration.

Solution: Check the credentials in: sudo nano /etc/restic/backup.env. Verify that the access key has the required permissions to access the backup bucket. Also confirm that your storage provider supports the endpoint format being used.

Error 2: Restic repository not found

This error may occur when Restic cannot locate the configured repository.

Possible causes:

• Incorrect repository URL.

• Incorrect bucket name.

• Repository has not been initialized.

• Storage credentials cannot access the repository.

Solution: Verify the repository configuration: sudo nano /etc/restic/backup.env. Check the RESTIC_REPOSITORY value and confirm that the bucket is accessible. For a genuinely new repository, initialize it using: restic init. Do not initialize an existing repository simply because Restic cannot connect.

Error 3: Incorrect repository password

Restic requires the correct password to access encrypted repository data.

Possible causes:

• Missing password file.

• Incorrect password.

• Incorrect password-file location.

• Password file permissions preventing access.

Solution: Check the password-file configuration: sudo ls -l /etc/restic/repository-password. Confirm that RESTIC_PASSWORD_FILE points to the correct file. If the original repository password has been lost, generating a new password will not recover access to the existing encrypted repository.

Error 4: Permission denied

This error may occur when Restic cannot read selected directories.

Solution: Confirm that the backup service runs with root permissions. Check the service configuration: sudo systemctl cat restic-backup.service. Make sure the selected directories exist and are accessible.

Error 5: Insufficient storage capacity

Large backup repositories can eventually exceed available storage quotas.

Solution: Check local disk capacity: df -h. Review the storage usage and your Restic retention policy. You can remove snapshots that are no longer required using Restic's forget command and reclaim unneeded repository data through pruning. Never manually delete individual repository files from the S3 bucket.

Error 6: Systemd backup timer is not running

If automatic backups are not executing, check the timer: sudo systemctl status restic-backup.timer. Review scheduled executions: sudo systemctl list-timers --all. Check the service logs: sudo journalctl -u restic-backup.service -n 100.

If you recently modified the service or timer configuration, reload systemd: sudo systemctl daemon-reload. Then restart the timer: sudo systemctl restart restic-backup.timer.

13. Dedicated Server Backup Best Practices

Automating backups with Restic provides a strong starting point, but reliable server protection requires more than scheduling a backup command. Consider the following practices when managing production dedicated servers.

• Keep backups in a separate location. Do not store your only backup on the same physical server that contains the original data. Use remote object storage or another independent backup destination. This protects your backup data if the production server experiences hardware failure or becomes inaccessible.

• Protect backup credentials. Restrict access to S3 credentials and repository passwords. Use strong authentication, least-privilege access policies and secure password storage. Where possible, separate backup credentials from ordinary server administration credentials.

• Monitor backup execution. Regularly check backup logs and snapshot timestamps. Configure alerts when a scheduled backup fails or when no successful snapshot is available within the expected interval.

• Test recovery procedures. Schedule restoration tests to verify that important files and database backups can be recovered. Do not wait until a hardware failure or security incident to discover that your backup repository is unusable.

• Use database-native backup tools. Databases require appropriate backup procedures. Use database-specific utilities to create consistent backups and include the resulting files in your Restic repository. For critical databases, also consider transaction-log backups and point-in-time recovery.

• Consider storage capacity and bandwidth. Large dedicated server backups can consume considerable storage and network bandwidth. Choose an appropriate backup schedule and retention policy based on your data volume. Monitor backup duration and resource consumption to avoid unnecessary impact on production workloads.

• Maintain an independent recovery copy. Keep the Restic repository password and required recovery credentials somewhere secure and separate from the production server. For critical workloads, consider maintaining another independent backup copy or storage destination. Remember that RAID configurations and local server snapshots are not substitutes for off-site backups.

14. Why Storage Dedicated Servers Matter for Backup Infrastructure

As businesses generate more data, backup storage requirements continue to increase. Websites, databases, application files, media libraries and archived business information can consume substantial storage capacity.

For larger environments, a storage dedicated server can provide an additional layer of infrastructure for backup repositories and data-intensive workloads. A dedicated storage server can be useful for:

• Storing large backup archives.

• Maintaining secondary backup copies.

• Hosting file repositories.

• Supporting disaster-recovery infrastructure.

• Managing large volumes of application data.

• Providing dedicated storage resources for business workloads.

When selecting storage infrastructure, consider drive capacity, HDD or SSD requirements, RAID configuration, network connectivity and expected restoration speeds.

Explore KW Servers Storage Dedicated Servers to find dedicated infrastructure options for storage-intensive workloads and backup environments.

Conclusion

Automating dedicated server backups is an important part of maintaining reliable Linux infrastructure.

With Restic on Ubuntu 24.04, you can create encrypted and deduplicated backup snapshots, store them in S3-compatible object storage and automate recurring backup operations using systemd timers.

In this tutorial, we covered the complete workflow:

• Installing Restic on Ubuntu 24.04.

• Configuring an encrypted backup repository.

• Connecting S3-compatible storage.

• Creating automated backup scripts.

• Scheduling backups using systemd.

• Managing snapshot retention.

• Verifying repository integrity.

• Restoring files and troubleshooting common errors.

However, remember that creating backups is only half of the process. Regularly verify repository integrity, monitor backup execution and test restoration procedures. A properly maintained backup strategy helps reduce data-loss risks and improves the recovery capabilities of your dedicated server infrastructure.