Configuring your backups

Use Virtualizor for panel‑level backups if the Backups section is visible for your VPS, then create or restore there. If you need in‑guest backups, install restic on your VPS and schedule it with systemd as below; this works on AlmaLinux 9 and Ubuntu 24.04.

Before you start

• Log in to the Hostworld client area and open Virtualizor for your VPS if you want panel‑level backups.
• Every command below is written for a normal user account with sudo. If you are logged in as root, leave the sudo off. The restic configuration files are owned by root, so the restic commands are run through sudo too.
• If you run MySQL, MariaDB or PostgreSQL on the VPS, a file‑level copy of the live data directory is not a reliable backup. You need a database dump as well. Step 3 covers this.
• If you plan to store the repository on S3‑compatible object storage, that is a separate third‑party service with its own account and billing, not part of your Hostworld service. Have the bucket name, region and access keys ready.

Step 1: Check for panel‑level backups in Virtualizor

This uses the Virtualizor Backups section to create or restore a full‑VPS backup. Restoring here replaces the VPS disk with the selected backup.

1. Open Virtualizor from the Hostworld client area and go to your VPS. Look for the Backups section and use it to run a backup or start a restore. Restoring will overwrite the current VPS state, so take an in‑guest backup first if you have changes you want to keep.
2. If you do not see backups in Virtualizor, open a support ticket and we will check your plan and enable panel backups if available.

Step 2: Install restic on your VPS

This installs restic from your OS repositories.

• AlmaLinux 9: This enables EPEL then installs restic.

  sudo dnf install -y epel-release
  sudo dnf install -y restic

• Ubuntu 24.04: This updates package lists then installs restic.

  sudo apt update
  sudo apt install -y restic

Step 3: Configure a repository and run your first backup

These commands create a protected password file, define restic settings, initialise the repository, dump any databases, add sensible excludes, then take a backup. The repository can be a local path, a path on another server you run with us, or an S3 URL. Because the configuration files are readable only by root, each restic command is run inside a root shell that loads and exports the environment file first.

# Create a password file for restic and restrict its permissions.
echo 'your-long-passphrase' | sudo tee /root/.restic-password >/dev/null
sudo chmod 600 /root/.restic-password

# Create an environment file that restic and systemd will read.
sudo tee /root/.restic-env >/dev/null <<'EOF'
RESTIC_REPOSITORY=/var/backups/restic
# Example third-party S3 storage instead:
# RESTIC_REPOSITORY=s3:https://s3.amazonaws.com/your-bucket/path
RESTIC_PASSWORD_FILE=/root/.restic-password
# For S3 uncomment and set:
# AWS_ACCESS_KEY_ID=AKIA...
# AWS_SECRET_ACCESS_KEY=...
# AWS_DEFAULT_REGION=eu-west-2
EOF
sudo chmod 600 /root/.restic-env
sudo mkdir -p /var/backups/restic

# Initialise the repository if it is new.
sudo bash -c 'set -a; . /root/.restic-env; set +a; restic init'

# Dump databases so the backup contains a consistent copy.
# Skip whichever of these you do not run.
sudo mkdir -p /var/backups/db
sudo chmod 700 /var/backups/db
sudo bash -c 'mysqldump --single-transaction --all-databases > /var/backups/db/mysql-all.sql'
sudo -u postgres pg_dumpall | sudo tee /var/backups/db/postgres-all.sql >/dev/null

# Create an exclude list so pseudo-filesystems and live database
# data directories are not copied. Remove the database lines if you
# do not run that database.
sudo tee /root/restic-excludes.txt >/dev/null <<'EOF'
/dev
/proc
/sys
/run
/tmp
/mnt
/media
/lost+found
/var/lib/mysql
/var/lib/pgsql
/var/lib/postgresql
EOF

# Run the first backup, including the dumps. Add extra mount points if separate.
sudo bash -c 'set -a; . /root/.restic-env; set +a; restic backup --one-file-system --exclude-file=/root/restic-excludes.txt / /home'

# List snapshots to confirm it worked.
sudo bash -c 'set -a; . /root/.restic-env; set +a; restic snapshots'

Step 4: Schedule automatic backups with systemd

This creates a systemd service and timer that dump the databases, run a daily backup and enforce retention. The timer runs at 03:30 and catches up after reboots.

# Create the service that performs the dumps, backup and retention.
# Remove the ExecStartPre line for any database you do not run.
sudo tee /etc/systemd/system/restic-backup.service >/dev/null <<'EOF'
[Unit]
Description=Restic backup

[Service]
Type=oneshot
EnvironmentFile=/root/.restic-env
ExecStartPre=/bin/bash -c 'mysqldump --single-transaction --all-databases > /var/backups/db/mysql-all.sql'
ExecStartPre=/bin/bash -c 'su -s /bin/bash -c pg_dumpall postgres > /var/backups/db/postgres-all.sql'
ExecStart=/usr/bin/restic backup --one-file-system --exclude-file=/root/restic-excludes.txt / /home
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
EOF

# Create the timer that schedules the service.
sudo tee /etc/systemd/system/restic-backup.timer >/dev/null <<'EOF'
[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=03:30
Persistent=true

[Install]
WantedBy=timers.target
EOF

# Reload systemd, enable the timer, and start it now.
sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer

# Optionally run an immediate test backup, then view snapshots.
sudo systemctl start restic-backup.service
sudo bash -c 'set -a; . /root/.restic-env; set +a; restic snapshots'

Step 5: Test a restore safely

This restores the latest snapshot into a staging directory so you can verify files before any in‑place recovery. Database content comes back as the dump files under /var/backups/db, which you load with the matching database client rather than copying into place.

# Restore the most recent snapshot into /root/restore-test.
sudo mkdir -p /root/restore-test
sudo bash -c 'set -a; . /root/.restic-env; set +a; restic restore latest --target /root/restore-test'

If it does not work

• No Backups section in Virtualizor: Your plan may not include panel backups. Open a support ticket and we will check and enable them if available.
• Permission denied on the password or environment file: Both files are owned by root with mode 600. Run the restic commands through sudo in the form shown above, which loads and exports the environment file inside a root shell.
• restic says “wrong password” or “repository does not exist”: Confirm /root/.restic-password matches the repository, check RESTIC_REPOSITORY in /root/.restic-env, and run restic init for a new repo. For S3, verify your keys, region and bucket path.
• Backups are huge or never finish: Ensure you used the exclude file and --one-file-system so /proc, /sys and mounted media are skipped. If snapshots are not expiring, include --prune with restic forget as shown.

What next

For a wider look at backup approaches, retention choices and restores, see our VPS guides. If you are planning a new VPS to hold offsite copies from another server, see our London VPS. If you need help enabling panel‑level backups or reviewing your setup, open a support ticket.