How to Back Up Your VPS: Files, Databases and Off-Site Copies

On an Unmanaged VPS, backups are your responsibility. A deleted folder, a failed update, a hacked plugin or a mistaken rm command can wipe out months of work, and without your own backup there may be no way back.

A good routine follows the 3-2-1 rule: three copies of your data, on two different kinds of storage, with one copy somewhere else (off the VPS). This guide builds exactly that.

Which VPS is this for? These steps are for an Unmanaged VPS, where you log in as root and look after the server yourself. On a Managed VPS we take care of the operating system and server software, and you manage your websites in StackCP instead.

What to back up

Step 1: Daily database dumps

Create a backup script:

sudo nano /usr/local/bin/backup-local.sh

                        
                    

Paste:

#!/bin/bash
set -euo pipefail
DEST=/var/backups/vps
DAY=$(date +%F)
mkdir -p "$DEST"

# all databases, consistent without locking InnoDB tables
mariadb-dump --all-databases --single-transaction --routines --triggers --events \
  | gzip > "$DEST/db-$DAY.sql.gz"

# website files and important config
tar czf "$DEST/www-$DAY.tar.gz" -C / var/www
tar czf "$DEST/etc-$DAY.tar.gz" -C / etc/nginx etc/letsencrypt etc/php 2>/dev/null || true

# keep 7 days on the server
find "$DEST" -type f -mtime +7 -delete

                        
                    

Adjust the folders to match your server (for example etc/apache2 or etc/httpd; on AlmaLinux/Rocky, PHP settings are in etc/php.ini and etc/php-fpm.d). Then make it executable, protect the folder and test it:

sudo chmod 700 /usr/local/bin/backup-local.sh
sudo mkdir -p /var/backups/vps && sudo chmod 700 /var/backups/vps
sudo /usr/local/bin/backup-local.sh
ls -lh /var/backups/vps

                        
                    

The script runs as root, which can log in to MariaDB through socket authentication, so no database password is stored in it. If you use MySQL, replace mariadb-dump with mysqldump.

Step 2: Schedule it with cron

sudo crontab -e

                        
                    

Add this line to run every night at 2:30 a.m. server time:

30 2 * * * /usr/local/bin/backup-local.sh >> /var/log/backup-local.log 2>&1

                        
                    

Using a script avoids a classic cron trap: a % sign (as in date +%F) written directly in a crontab line must be escaped, otherwise the command fails silently.

Step 3: Copy backups off the server

Backups that only live on the VPS disappear with it. Choose at least one off-site method:

Option A: pull to your own computer or another server with rsync

rsync -avz -e "ssh -p 22" [email protected]:/var/backups/vps/ ~/vps-backups/

                        
                    

The deploy user needs read access to the folder; for example, make the files group-readable by a backup group, or pull them as root with a dedicated SSH key. On Windows, WinSCP's Synchronize feature does the same over SFTP.

Option B: cloud object storage with rclone

rclone copies to S3-compatible storage, Google Drive, OneDrive and many others. Install it with sudo apt install rclone (EPEL on AlmaLinux/Rocky), set up a remote with rclone config, then add to your script:

rclone copy /var/backups/vps remote:my-vps-backups --max-age 25h

                        
                    

Option C: encrypted, versioned backups with restic

restic encrypts and de-duplicates, so you can keep months of history cheaply. Install it with sudo apt install restic (EPEL on AlmaLinux/Rocky), then:

restic -r sftp:[email protected]:/srv/restic/myvps init
restic -r sftp:[email protected]:/srv/restic/myvps backup /var/backups/vps /var/www
restic -r sftp:[email protected]:/srv/restic/myvps forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

                        
                    

Store the restic password somewhere safe outside the server; without it the backups cannot be decrypted.

Snapshot backups

A snapshot is a full image of the whole VPS, which makes restoring the entire server quick. If your plan includes automatic snapshot backups, or they are offered as an add-on for your VPS in the client area, they are a great extra layer. If you don't see the option, ask our Sales team whether it is available for your VPS. Snapshots are stored with the hosting platform, so still keep your own off-site copy.

Step 4: Test a restore

A backup you have never restored is only a hope. Every few months, restore onto a test VPS or into a test database:

# restore every database from a full dump
gunzip < db-2026-09-20.sql.gz | sudo mariadb

# restore one database from its own dump
sudo mariadb shopdb < shopdb.sql

# extract website files into a temporary folder to check them
mkdir /tmp/restore && tar xzf www-2026-09-20.tar.gz -C /tmp/restore

                        
                    

Tips

• Check /var/log/backup-local.log now and then, or add a line to your script that emails you on failure.
• Keep backups out of the web root so nobody can download them from your website.
• Before big changes (upgrades, plugin updates, OS reinstall), run the script by hand.
• Managed VPS customers: use the backup tools in StackCP where available, and download your own copies of files and databases regularly.

Need help?

If something about the VPS itself is not working (it won't start, you can't reach it, or you need console access, an upgrade or a reinstall), open a support ticket from your client area or message us on WhatsApp at 01818160926. Include your VPS IP address and what you have already tried so we can help faster.