Linux VPS Backups and Snapshots for Small Businesses

The short answer

A snapshot and a backup are different tools, and a small business running on a Linux VPS needs both. A snapshot freezes the whole server at one moment so you can roll back fast after a bad update. A backup is a separate copy of your data, stored somewhere else, that survives when the server itself does not. Snapshots get you back in minutes from a mistake. Backups get you back from deleted files, ransomware, a compromised account or a lost server.

This guide covers what each one protects, what to back up on a typical Linux VPS, how to set up automatic encrypted backups with a tool such as restic, how to handle databases properly, and the part most teams skip: testing a restore. Commands are for Ubuntu and Debian, and they work the same way on Rocky Linux and AlmaLinux once the packages are installed.

Snapshots vs backups

	Snapshot	Backup
What it captures	The whole disk at one moment	The files and data you choose
Where it lives	Next to the server, on the same platform	A separate location, ideally off site
Best for	Rolling back a bad update or config change	Recovering data after loss, deletion or attack
Restore style	Roll the whole server back	Restore one file, one database or everything
Keep it	Short term, a few at a time	On a schedule, with history going back weeks or months

A good rule: take a snapshot before every risky change, and run backups every day whether or not anything changes. A snapshot that lives on the same platform as the server is a convenience. It is not a disaster plan by itself.

Step 1: Decide what matters and how much you can lose

Before choosing tools, answer two questions for each system:

• How much data can you afford to lose? If losing a day of orders or edits would hurt, back up at least daily, and more often for busy databases. This is your recovery point.
• How long can it be down? If the answer is "not long," keep a recent snapshot for fast rollback and make sure your backups restore quickly. This is your recovery time.

Write the answers down. They decide how often you back up, how long you keep copies, and how much storage you need.

Step 2: Know what to back up on a Linux VPS

You rarely need a copy of the whole operating system, because you can reinstall it. What you cannot recreate is your data and your configuration. On a typical Linux VPS that means:

• Application data, such as /var/www for websites, uploaded files and anything your app writes to disk
• Databases, dumped properly (see Step 4), not just their raw files
• Configuration, mainly /etc, which holds web server, firewall, SSH and service settings
• Scheduled jobs and scripts, such as crontabs and anything in /usr/local/bin or /opt
• Home directories of the people and service accounts that run the server
• TLS certificates and keys, if you manage them yourself

Leave out caches, temporary folders, logs you do not need to keep, and /proc, /sys and /dev, which are not real files.

Step 3: Follow the 3-2-1 rule

The 3-2-1 rule is the standard starting point: keep three copies of your data, on two different kinds of storage, with one copy off site. For a VPS, that usually looks like the live server, a recent snapshot on the hosting platform, and an encrypted backup in a separate location such as object storage or a backup server in another site.

Two extra habits make the rule much stronger:

• Encrypt backups before they leave the server, so a copy in someone else's storage cannot be read.
• Keep at least one copy the server cannot delete. If an attacker gets root on the VPS, they can delete anything the server has write access to. Use storage with object lock or retention settings, or a backup system that pulls from the server instead of the server pushing to it.

Step 4: Back up databases the right way

Copying the raw files of a running database can give you a backup that will not restore. Use the database's own dump tool, then back up the dump.

For MySQL or MariaDB:

mysqldump --single-transaction --routines --all-databases | gzip > /var/backups/mysql-$(date +%F).sql.gz

For PostgreSQL:

sudo -u postgres pg_dumpall | gzip > /var/backups/postgres-$(date +%F).sql.gz

Run the dump on a schedule just before your file backup, so each backup run includes a fresh, consistent copy. For WordPress and WooCommerce stores, our WooCommerce backup and uptime guide covers the store side in more detail.

Step 5: Automate encrypted backups with restic

restic is a free, open source backup tool that encrypts everything, stores only changed data after the first run, and works with local disks, SFTP servers and S3 compatible object storage. Install it:

sudo apt install restic

On Rocky Linux and AlmaLinux, install it from EPEL with sudo dnf install restic.

Create a repository. This example uses an SFTP backup server; restic also supports S3 compatible storage with an s3: address:

export RESTIC_REPOSITORY="sftp:backup@your-backup-host:/backups/myserver"
export RESTIC_PASSWORD_FILE="/root/.restic-password"
restic init

Store the repository password somewhere safe outside the server, such as your company password manager. Without that password, nobody can restore the backup, including you.

Run a backup of the paths from Step 2:

restic backup /etc /var/www /var/backups /home --exclude-caches

Then set a retention policy so old copies are pruned on a schedule, for example:

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

Pick the numbers to match the answers from Step 1. Put the dump commands, the backup and the retention step in one script, and run it nightly with a cron job or a systemd timer. Have the script send an alert when it fails, so a broken backup does not go unnoticed for weeks.

If you prefer a different tool, BorgBackup works on the same principles. The important parts are the same either way: encrypted, automatic, off site, with retention.

Step 6: Take a snapshot before risky changes

Before a major upgrade, a control panel or PHP version change, or a big configuration edit, take a snapshot. If the change goes wrong, rolling back the snapshot is usually the fastest way to get back to a working server.

Keep snapshots short lived. Delete them once you are confident the change is good, because old snapshots use storage and can slow some platforms down. A snapshot taken weeks ago also holds old software and old settings, so it is a rollback point, not an archive.

How snapshots work depends on the platform. On a KVM VPS the snapshot covers the virtual disk; on an LXC container it covers the container's file system. Our KVM vs LXC guide explains the difference between the two. If you are not sure what your GlassHosting plan includes, ask us.

Step 7: Test your restores

A backup you have never restored is a guess. Make restore tests part of the routine:

• List your snapshots with restic snapshots and confirm recent runs are there.
• Check the repository with restic check to catch damaged data early.
• Restore a few files to a test folder, for example restic restore latest --target /tmp/restore-test --include /etc/nginx, and compare them to the originals.
• Restore a database dump into a test database and confirm your app can read it.
• Run a full rebuild drill from time to time: build a fresh VPS, restore onto it, and write down every step and how long it took. That document becomes your recovery runbook.

Schedule restore tests on the calendar, and run one after any big change to the server or the backup setup.

Step 8: Protect the backups themselves

Backups contain everything an attacker wants, so treat them like production:

• Use a dedicated backup account with access only to the backup location.
• Use SSH keys, not passwords, for SFTP backup targets. Our SSH security guide covers keys and access limits.
• Keep the restic password and any storage keys out of the backup itself and out of shared documents.
• Review backup logs and alerts as part of your regular checks.

Quick checklist

Area	What good looks like
Scope	Data, databases, /etc and scripts listed and included
Databases	Dumped with the database's own tool before each backup
Schedule	Automatic, at least daily, with failure alerts
Encryption	Backups encrypted before they leave the server
Location	At least one copy off site, one the server cannot delete
Retention	Daily, weekly and monthly history matched to your needs
Snapshots	Taken before risky changes, deleted after
Restores	Tested on a schedule, with a written runbook

Where GlassHosting fits

These steps apply to any Linux VPS, including GlassHosting KVM and LXC plans. If you would rather have someone else own backups, snapshots and restore testing, that is what managed hosting is for. Read managed vs unmanaged VPS to see the difference, then tell us what you run or email sales@glasshosting.com, and we will help you build a backup plan you can actually restore from.