VPS backups: what we back up and how to make your own

We manage the VPS backups, and in the customer area you can restore the whole disk from them. For individual files, databases and a copy outside our infrastructure, you set up your own backups. We'll show both.

Automatic StormHost backups#

We create VPS backups automatically. You'll find them in the customer area: My services › your VPS › Backups tab.

• For each backup, the list shows Created (date and time), Size and the Storage it's kept on.
• You can't create a backup manually from the customer area. Before a risky change (a system upgrade, a big configuration change), make your own backup as described in the rest of this guide.
• If you see “One of the backup storages isn't responding right now — the list may be incomplete”, some backups are temporarily unavailable. Try again later, or contact us.
• A member of a shared service only sees backups with the Backups and restore permission.

Restoring the whole VPS#

1. In the Backups tab, find the backup by its date in the Created column.
2. Click Restore.
3. Read the warning and confirm it by moving the slider (“Slide to restore”).
4. Wait for it to finish. During the restore the VPS is shut down and locked, and the console won't connect.
5. After the restore, start the VPS (if it doesn't start by itself) and check your services.

Full restore, or individual files?#

The 3-⁠2-⁠1 rule#

A proven rule for backups: 3 copies of your data, in 2 different places or storage types, with 1 of them outside the main infrastructure.

For a VPS that means:

1. The data on the VPS (the original copy).
2. Our automatic backups (the second copy, outside your VPS).
3. Your own backup elsewhere: a home NAS, another server, cloud storage (the third copy, outside our infrastructure).

The third copy protects you even when a restore in the customer area won't help: you need an older state, a single file, or you want to move elsewhere.

What to back up#

Backup script#

Every day, the script exports all databases, archives the important directories and deletes backups older than 7 days.

1. Create the script file:

   nano /usr/local/sbin/zaloha.sh

2. Paste the content:

   #!/bin/bash
   set -euo pipefail
   umask 077
   
   CIL=/var/backups/vps
   DNES=$(date +%F)
   UCHOVAT_DNI=7
   
   mkdir -p "$CIL"
   
   # 1) databases (only if MariaDB/MySQL is installed)
   if command -v mariadb-dump >/dev/null 2>&1; then
     mariadb-dump --single-transaction --routines --events --all-databases | gzip > "$CIL/db-$DNES.sql.gz"
   fi
   
   # 2) files
   tar -czf "$CIL/soubory-$DNES.tar.gz" --ignore-failed-read /etc /home /root /var/www /opt /srv || [ $? -eq 1 ]
   
   # 3) delete old backups
   find "$CIL" -type f -name '*.gz' -mtime +"$UCHOVAT_DNI" -delete
   
   echo "$(date '+%F %T') backup done"

3. Save (Ctrl+O, Enter), close (Ctrl+X) and make it executable:

   chmod 700 /usr/local/sbin/zaloha.sh

   • chmod 700 – only root can read and run the script.

What the script does:

4. Try the script by hand:

   /usr/local/sbin/zaloha.sh
   ls -lh /var/backups/vps

   You'll see backup done and the files db-….sql.gz and soubory-….tar.gz. The message tar: Removing leading '/' from member names is normal: paths are stored in the archive without the leading slash.

Running it automatically with cron#

1. Make sure cron is installed (if it already is, nothing happens):

   apt -y install cron

2. Open root's crontab:

   crontab -e

   On the first run, choose the nano editor.

3. Add this line at the end:

   30 3 * * * /usr/local/sbin/zaloha.sh >> /var/log/zaloha.log 2>&1

4. Save and close the editor. You'll see crontab: installing new crontab.

A crontab line has five time fields and a command:

More time examples:

Times follow the VPS's time zone (timedatectl). Schedule backups for when the server has the least traffic.

Copying off the VPS#

Setting up SSH access to the target server#

Send the backups to another server (a home NAS with SSH, another VPS). In the examples, the target server has the IP address 198.51.100.25; use your own server's address instead.

On the target server (Ubuntu or Debian, logged in as root), create a user and a directory it can write to:

adduser zaloha
mkdir -p /srv/zalohy
chown zaloha:zaloha /srv/zalohy
chmod 700 /srv/zalohy

• adduser zaloha – creates the user zaloha. It asks for a password (you'll need it in step 2 below) and for optional details, which you can skip with Enter.
• mkdir -p /srv/zalohy – the backup directory.
• chown zaloha:zaloha – the directory belongs to the zaloha user so it can write there. Without this, both rsync and restic fail with Permission denied.
• chmod 700 – nobody else can access the directory.

Password login must be allowed on the target server at least until you upload the key (step 2). On a NAS, follow its own instructions (user, shared folder, SSH enabled).

Then, on the VPS being backed up:

1. Create a passwordless SSH key used only for backups:

   ssh-keygen -t ed25519 -f /root/.ssh/zaloha -N "" -C "zaloha-vps"

   • -t ed25519 – a modern key type.
   • -f /root/.ssh/zaloha – where to save the key (creates zaloha and zaloha.pub).
   • -N "" – no key passphrase, so cron can use it without you.
   • -C "zaloha-vps" – a key label.

2. Upload the public key to the target server (you'll enter the password of the zaloha user on the target server):

   ssh-copy-id -i /root/.ssh/zaloha.pub [email protected]

   On the first connection SSH asks Are you sure you want to continue connecting (yes/no/[fingerprint])?. Type yes: the target server's fingerprint is saved to /root/.ssh/known_hosts, and cron won't be asked again.

3. Create a connection shortcut. Open nano /root/.ssh/config and add:

   Host zalohy
       HostName 198.51.100.25
       User zaloha
       IdentityFile /root/.ssh/zaloha

   • Host zalohy – the shortcut you'll use instead of the address.
   • HostName – the target server's IP address or domain.
   • User – the user on the target server.
   • IdentityFile – the key used to log in.

4. Test the connection: ssh zalohy must log in without a password. Log out with exit.

Working with keys in detail: SSH key.

rsync#

rsync only copies changed files, so it's fast even with large backups. It must be installed on both sides (apt -y install rsync).

rsync -az /var/backups/vps/ zalohy:/srv/zalohy/vps1/

• -a – archive mode: copies recursively and preserves permissions, times and links.
• -z – compresses data during the transfer.
• /var/backups/vps/ – what to copy. The trailing slash means “the directory's contents”, not the directory itself.
• zalohy:/srv/zalohy/vps1/ – the target: the shortcut from ~/.ssh/config and the directory on the target server.

Add the transfer as the last line of zaloha.sh, or to the crontab an hour after the backup:

30 4 * * * rsync -az /var/backups/vps/ zalohy:/srv/zalohy/vps1/ >> /var/log/zaloha.log 2>&1

restic (advanced)#

restic stores backups encrypted and with deduplication: repeated data is stored only once, so you can keep dozens of daily versions with little space. It can back up to an SFTP server as well as to cloud storage.

1. Install restic: apt -y install restic.

2. Create a file with the repository password and restrict its permissions:

   nano /root/.restic-heslo
   chmod 600 /root/.restic-heslo

   Put a long random password in the file (password generator).

3. Create a repository on the target server:

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo init

   • -r sftp:zalohy:/srv/zalohy/restic-vps1 – a repository over SFTP; zalohy is the shortcut from ~/.ssh/config.
   • --password-file – the password file, so restic doesn't ask (required for cron).
   • init – creates a new empty repository. You'll see created restic repository ….

4. Back up (you can put this command in the script instead of the tar archive; keep the database export):

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo backup /etc /home /root /var/www /opt /srv /var/backups/vps

5. Delete old versions according to a policy:

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

   • forget – removes versions (snapshots) the policy doesn't keep.
   • --keep-daily 7 – keeps the latest version from each of the last 7 days that have a backup.
   • --keep-weekly 4, --keep-monthly 6 – also one version per week for 4 weeks and one per month for 6 months.
   • --prune – immediately deletes data no version refers to anymore (frees up space).

Useful commands:

An alternative to restic is BorgBackup (documentation (opens in a new window)), which works on a similar principle.

Testing a restore#

A backup you've never tried to restore is just hope. Test it every now and then:

1. List the archive's contents: tar -tzf /var/backups/vps/soubory-2026-10-01.tar.gz | head.

2. Extract a single file into a temporary directory:

   mkdir -p /tmp/obnova
   tar -xzf /var/backups/vps/soubory-2026-10-01.tar.gz -C /tmp/obnova etc/nginx/nginx.conf

   • -x – extract, -z – gzip format, -f – from a file.
   • -C /tmp/obnova – where to extract (so the live file isn't overwritten).
   • etc/nginx/nginx.conf – what to extract (path without the leading slash).

3. Check the database export: zcat /var/backups/vps/db-2026-10-01.sql.gz | head -n 20 must show the beginning of an SQL export.

4. Do a full test (restoring the database, starting the app) on a separate test VPS, not on your production one.

Verification#

• The morning after the first night: tail /var/log/zaloha.log contains the line backup done.
• ls -lh /var/backups/vps shows new files with today's date and a sensible size (not 0 bytes).
• The target server has the same files (rsync), or restic snapshots shows today's version.

Troubleshooting#

Cron didn't run the script#

Check that cron is running and what it wrote to the log:

systemctl status cron
journalctl -u cron -n 50

Common causes: the crontab is missing the full path to the script, the script isn't executable (chmod 700), or you edited the crontab of a user other than root (crontab -l prints it).

mariadb-dump: Got error: 1045: "Access denied for user …"#

The script isn't running as root, or the database root uses a password instead of the unix socket. Run the script from root's crontab. If root has a database password, store it in /root/.my.cnf, where mariadb-dump reads it automatically:

[client]
user=root
password=<DB_ROOT_PASSWORD>

• [client] – the option group for all MariaDB client programs (mariadb, mariadb-dump).
• user, password – the credentials. Replace <DB_ROOT_PASSWORD> with the password of the database user root (without the angle brackets).

Secure the file with chmod 600 /root/.my.cnf so nobody else can read the password.

The backup is 0 bytes or suspiciously small#

The script failed partway through. Run it by hand and read the error. Thanks to set -euo pipefail, an export error doesn't go unnoticed.

Permission denied (publickey) with rsync or restic#

The target server didn't accept the key. Test ssh zalohy. If it asks for a password or fails, upload the key again (ssh-copy-id) and check that IdentityFile in /root/.ssh/config points to the right file.

restic: Fatal: wrong password or no key found#

The password in /root/.restic-heslo doesn't match the repository. Check that the file doesn't contain an extra space or a different password.

restic: Fatal: unable to open config file … Is there a repository at the following location?#

There's no repository at the given path (a typo in the path, or you didn't run init).

The disk is filling up#

Backups aren't being deleted, or they're too large. Check that the find … -delete step runs, lower UCHOVAT_DNI and leave out directories with large data that you back up another way.

Further reading#

• restic: documentation (opens in a new window)
• BorgBackup: documentation (opens in a new window)
• rsync: man page (opens in a new window)
• crontab(5): crontab format (opens in a new window)
• MariaDB: mariadb-dump (opens in a new window)