How to Set Up Automatic Backups on an Ubuntu VPS Using Restic Print

How to Set Up Automatic Backups on an Ubuntu VPS Using Restic

Regular backups are essential for protecting your VPS against accidental deletion, software failures, ransomware, and hardware problems. A reliable backup strategy should include automated execution, encryption, offsite storage, retention policies, and periodic restoration testing.

In this guide, you will learn how to configure automatic backups on an Ubuntu VPS using Restic, an open-source backup utility that supports encrypted, incremental, and deduplicated backups.

The instructions apply to Ubuntu 24.04 LTS, Ubuntu 26.04 LTS, and other supported Ubuntu releases.

Prerequisites

• An Ubuntu VPS with root or sudo access.
• Sufficient storage for the initial backup.
• SSH access to your VPS.
• Optional: A separate server or storage account for offsite backups.

Need a Linux server? Explore Owned Networks KVM VPS hosting for flexible infrastructure and full root access.

1. Install Restic on Ubuntu

Update your package repositories and install Restic:

sudo apt update
sudo apt install -y restic

Verify the installation:

restic version

Restic is available through Ubuntu's package repositories. The installed version depends on your Ubuntu release and configured repositories.

2. Understand How Restic Backups Work

Restic stores backups inside a repository. Each backup creates a snapshot representing the selected files at a particular point in time.

Restic provides several important features:

• Encryption: Backup contents are encrypted before being stored.
• Deduplication: Identical data does not need to be stored repeatedly.
• Incremental backups: Subsequent backups reuse previously stored data.
• Snapshots: Previous backup states can be restored.
• Remote storage: Repositories can be stored on separate servers or supported cloud storage services.

Important: Restic protects stored backup data with encryption, but it does not automatically guarantee application-consistent backups of active databases. Database workloads require additional preparation.

3. Create a Local Backup Repository

For an initial test, create a local repository:

sudo mkdir -p /var/backups/restic
sudo chmod 700 /var/backups/restic

Create a password file for the backup repository:

sudo install -m 600 /dev/null /root/.restic-password
sudo nano /root/.restic-password

Enter a strong, unique password on a single line and save the file.

Initialize the repository:

sudo restic \
-r /var/backups/restic \
--password-file /root/.restic-password \
init

Critical: Store a secure copy of the repository password outside the VPS. Without the password, encrypted Restic backups cannot be restored.

A repository stored on the same VPS is useful for testing and recovering individual files, but it does not protect against complete server or storage failure.

4. Create Your First VPS Backup

Back up important system configuration and application files:

sudo restic \
-r /var/backups/restic \
--password-file /root/.restic-password \
backup \
/etc \
/home \
/var/www \
/root

This example includes:

• /etc — system and application configuration.
• /home — user files.
• /var/www — website files.
• /root — root user's files and configuration.

Adjust the paths according to your VPS workload.

Do not include temporary filesystems such as /proc, /sys, or /dev in ordinary file-level backups.

5. List Available Backup Snapshots

Display the snapshots stored in your repository:

sudo restic \
-r /var/backups/restic \
--password-file /root/.restic-password \
snapshots

Each snapshot includes an identifier, timestamp, hostname, and backed-up paths.

To inspect repository statistics:

sudo restic \
-r /var/backups/restic \
--password-file /root/.restic-password \
stats

6. Configure Offsite Backups Using SFTP

For production environments, storing backups on a separate server is strongly recommended.

Restic supports SFTP repositories over SSH.

First, configure SSH key authentication from your VPS to the backup server using a dedicated backup account.

Verify the connection:

sudo ssh backupuser@BACKUP_SERVER_IP

On the backup server, create a repository directory owned by the backup account:

mkdir -p ~/restic-repositories/vps01
chmod 700 ~/restic-repositories/vps01

Exit the backup server and initialize the remote repository from your VPS:

sudo restic \
-r sftp:backupuser@BACKUP_SERVER_IP:restic-repositories/vps01 \
--password-file /root/.restic-password \
init

Create an offsite backup:

sudo restic \
-r sftp:backupuser@BACKUP_SERVER_IP:restic-repositories/vps01 \
--password-file /root/.restic-password \
backup \
/etc \
/home \
/var/www \
/root

Replace the example username, server address, and repository path with your actual backup destination.

Security recommendation: Use a dedicated SSH key and backup account. Verify the backup server's SSH host key before trusting the connection.

For stronger ransomware protection, use a backup destination with immutable snapshots, versioning, or restricted deletion capabilities. A writable SFTP repository alone does not prevent a compromised VPS from deleting its remote backups.

7. Create a Restic Backup Configuration

To simplify automated backups, create a protected environment file:

sudo nano /etc/restic-backup.conf

Add the following configuration:

RESTIC_REPOSITORY="sftp:backupuser@BACKUP_SERVER_IP:restic-repositories/vps01"
RESTIC_PASSWORD_FILE="/root/.restic-password"

Restrict access to the configuration file:

sudo chmod 600 /etc/restic-backup.conf
sudo chown root:root /etc/restic-backup.conf

Restic recognizes the RESTIC_REPOSITORY and RESTIC_PASSWORD_FILE environment variables.

8. Create an Automated Backup Script

Create a backup script:

sudo nano /usr/local/sbin/restic-backup.sh

Add:

#!/bin/bash
set -euo pipefail

set -a
source /etc/restic-backup.conf
set +a

restic backup \
  /etc \
  /home \
  /var/www \
  /root \
  --exclude /root/.cache \
  --exclude /home/*/.cache

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

This script creates a backup and applies the following retention policy:

• Seven daily snapshots.
• Four weekly snapshots.
• Six monthly snapshots.

The retention rules preserve snapshots selected by each policy; they do not necessarily produce exactly 17 distinct snapshots.

Make the script executable:

sudo chmod 700 /usr/local/sbin/restic-backup.sh
sudo chown root:root /usr/local/sbin/restic-backup.sh

Run the script manually:

sudo /usr/local/sbin/restic-backup.sh

Important: The script assumes that the backup repository has already been initialized and that SSH authentication to the backup server works without interactive prompts.

9. Schedule Automatic Backups with systemd

Systemd timers provide a reliable way to schedule recurring backups on Ubuntu.

Create a systemd service:

sudo nano /etc/systemd/system/restic-backup.service

Add:

[Unit]
Description=Restic VPS Backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-backup.sh
User=root
TimeoutStartSec=infinity

Create the corresponding timer:

sudo nano /etc/systemd/system/restic-backup.timer

Add:

[Unit]
Description=Daily Restic VPS Backup

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
Unit=restic-backup.service

[Install]
WantedBy=timers.target

This schedules the backup for 03:00 server time each day.

The Persistent=true setting allows systemd to trigger a missed scheduled run after the timer becomes active again.

Enable the timer:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer

Verify the schedule:

sudo systemctl list-timers --all | grep restic

10. Monitor Backup Execution

Check the latest backup service status:

sudo systemctl status restic-backup.service --no-pager

Review backup logs:

sudo journalctl \
-u restic-backup.service \
-n 100 \
--no-pager

Run the backup service manually:

sudo systemctl start restic-backup.service

Check the timer:

sudo systemctl status restic-backup.timer --no-pager

Recommendation: Configure external monitoring or alerts for failed backup jobs. A scheduled backup is not sufficient unless failures are detected and investigated.

11. Verify Backup Repository Integrity

Restic includes a repository verification command:

sudo bash -c '
set -a
source /etc/restic-backup.conf
set +a
restic check
'

This checks repository structure and metadata integrity.

For additional verification, check stored data:

sudo bash -c '
set -a
source /etc/restic-backup.conf
set +a
restic check --read-data-subset=5%
'

This reads and verifies a subset of stored backup data.

For a complete data verification, use restic check --read-data. This can require substantial time and I/O for large repositories.

12. Restore Files from a Restic Backup

Before restoring files, load the repository configuration:

sudo -i
set -a
source /etc/restic-backup.conf
set +a

List available snapshots:

restic snapshots

Restore the latest snapshot into a temporary directory:

mkdir -p /root/restic-restore
restic restore latest --target /root/restic-restore

Restored files will appear under the target directory while preserving their original directory structure.

For example, a file originally located at:

/var/www/example.com/index.html

will be restored under:

/root/restic-restore/var/www/example.com/index.html

To restore a specific directory:

restic restore latest \
--target /root/restic-restore \
--include /var/www

Review restored files before copying them into production.

Important: Restoring files does not automatically recreate running services, operating system packages, network configuration, or database consistency. A complete disaster recovery procedure may require additional steps.

13. Back Up MariaDB and PostgreSQL Safely

File-level backups of active database directories may not produce a consistent database backup.

For MariaDB, create a logical database dump before running Restic:

sudo mariadb-dump \
--single-transaction \
--routines \
--triggers \
--events \
app_database \
| gzip > /root/app_database.sql.gz

For PostgreSQL:

sudo -u postgres pg_dump \
-Fc \
-f /tmp/app_database.dump \
app_database

Move the PostgreSQL dump to a protected backup staging directory and include that directory in your Restic backup.

For production systems, integrate database dumps into the automated backup workflow and verify that dump creation succeeds before starting the Restic backup.

Database backups should also be tested through restoration into a separate environment.

14. Troubleshooting Common Restic Problems

Repository password incorrect: Verify that the configured password file matches the password used when initializing the repository.

SFTP connection failed: Check SSH authentication, the remote repository path, and the backup server's network connectivity.

Permission denied: Verify file permissions on the source directories, repository, password file, and SSH key.

Repository locked: Check whether another Restic process is running before removing repository locks.

ps aux | grep '[r]estic'

Only use restic unlock after confirming that no active process is using the repository.

Backup job not running: Check the systemd timer and service logs.

sudo systemctl status restic-backup.timer
sudo journalctl -u restic-backup.service -n 100 --no-pager

15. VPS Backup Best Practices

• Follow the 3-2-1 backup principle where practical.
• Maintain at least one backup copy outside the VPS.
• Encrypt backup repositories and protect encryption credentials.
• Use dedicated backup accounts and restricted access.
• Configure appropriate snapshot retention policies.
• Monitor scheduled backup execution.
• Verify repository integrity periodically.
• Test file and database restoration regularly.
• Use immutable or protected backup storage where available.
• Document your recovery procedures and required credentials.

Remember: A backup is only useful if it can be successfully restored. Regular restoration testing is essential for reliable disaster recovery.

Related Ubuntu VPS Tutorials

• How to Set Up and Secure a New Ubuntu VPS
• How to Set Up SSH Key Authentication on an Ubuntu VPS
• How to Install and Secure MariaDB on an Ubuntu VPS
• How to Install and Secure PostgreSQL on an Ubuntu VPS
• How to Configure UFW Firewall on an Ubuntu VPS

Protect Your VPS Data with Owned Networks

Deploy websites, applications, and databases on an Owned Networks KVM VPS with full root access and flexible server resources.

Combining reliable hosting infrastructure with encrypted offsite backups helps reduce the risk of permanent data loss and improves disaster recovery readiness.

Explore Owned Networks VPS Hosting and deploy your next Linux server today.