How to Set Up Automatic Backups on Your VPS

Backups are one of those things everyone agrees they should have and surprisingly few people actually automate. On a VPS, you are responsible for your own data. Your provider keeps the hardware running and the network connected. If your database corrupts, a deployment script goes sideways, or you accidentally overwrite a configuration file at 2 a.m., the recovery plan is whatever you set up in advance.

If you have been through the VPS security checklist, you already know that "configure automated backups and test a restore" is one of the ten essential steps before going live. This guide is the expanded version of that step: what to back up, which tools to use, how to automate the schedule, and where to store the results so they actually survive a worst-case failure.

Running an unmanaged VPS means backups are entirely on you. Managed plans sometimes include scheduled snapshots, but the scope and retention vary between providers. Either way, understanding the mechanics puts you in a better position to verify that your data is actually protected.

What to Back Up

Not everything on your server needs the same backup treatment. Separating what matters from what can be reinstalled saves time, storage, and complexity.

Back up these:

• Application data and uploaded files (anything your users created or uploaded)
• Database contents (the most critical asset for most applications)
• Configuration files: web server configs, SSL certificate paths, cron entries, firewall rules, environment files
• Custom scripts and deployment tooling that would be painful to recreate

Skip these (they can be reinstalled):

• Operating system packages (reinstall from the package manager)
• Application runtimes (Java, Node.js, PHP, Python, etc.)
• The web server binary itself (Nginx, Apache, Caddy)
• Cached and temporary files
• Log files (unless you need them for compliance or auditing)

The goal is a backup that lets you rebuild a working server from a fresh OS image plus your backup archive, rather than a full disk clone that includes gigabytes of reinstallable software.

Database Backups Come First

If your server runs a database, this is the single most important thing to get right. Application files can usually be redeployed from version control. Database contents cannot.

PostgreSQL:

pg_dump -U your_db_user -d your_database -F c -f /backups/db/your_database_$(date +%Y%m%d_%H%M%S).dump

The -F c flag produces a compressed custom-format dump, which supports selective restore (individual tables or schemas) and takes less space than a plain SQL dump.

MySQL / MariaDB:

mysqldump -u your_db_user -p your_database > /backups/db/your_database_$(date +%Y%m%d_%H%M%S).sql

For both, the key details:

1. Run the dump as a scheduled job, not manually. A backup you have to remember to run is a backup you will forget.
2. Include the timestamp in the filename. This prevents overwriting previous dumps and gives you a history to restore from.
3. Compress the output if the tool does not do it automatically. Pipe through gzip or use the format flag that produces compressed output.

Database dumps are fast for most small-to-medium databases. A nightly dump of a database under a few gigabytes finishes in seconds on typical VPS hardware.

File Backups with tar and rsync

For application files and configuration, two tools cover most needs.

tar for local compressed archives

tar -czf /backups/files/app_backup_$(date +%Y%m%d).tar.gz \
  /var/www/your-app/ \
  /etc/nginx/ \
  /etc/letsencrypt/ \
  /home/your-user/.ssh/

This creates a single compressed archive of the directories you care about. It is simple, portable, and works on every Linux distribution without installing anything.

The downside: tar creates a full copy every time. If your application data is large, nightly full archives consume significant disk space. For small-to-medium sites (under a few gigabytes of data), this is perfectly workable.

rsync for incremental copies

rsync -az --delete /var/www/your-app/ /backups/files/app-mirror/

rsync copies only the files that changed since the last run. The --delete flag removes files from the backup that no longer exist in the source, keeping the mirror accurate. The -a flag preserves permissions, ownership, and timestamps. The -z flag compresses data during transfer.

For off-site backups, rsync can push directly to a remote server over SSH:

rsync -az --delete /var/www/your-app/ backup-user@remote-host:/backups/vps-app/

rsync is particularly useful for large file sets where a full tar archive every night would be wasteful. The first run copies everything; subsequent runs transfer only the differences.

Restic for Encrypted, Deduplicated Backups

If you want something more robust than shell scripts gluing together tar and rsync, Restic is worth considering. It is an open-source backup tool that handles encryption, deduplication, and remote storage backends in a single binary.

Why Restic over raw scripts:

• Encryption is on by default (AES-256), so your data stays protected even if someone gains access to the storage destination.
• Deduplication keeps storage costs honest. A nightly backup of 50 GB of mostly-unchanged files only transfers and stores what actually changed since the last run.
• It speaks multiple remote backends natively: SFTP, S3-compatible object storage (Backblaze B2, Wasabi, cloud provider buckets), and REST servers. No wrapper scripts needed for the transfer layer.
• Each backup is a discrete snapshot. You can browse any snapshot individually, compare two of them, or restore from a specific point in time without touching the others.

Basic workflow:

Initialize a repository (one-time setup):

restic -r sftp:backup-user@remote-host:/backups/vps-restic init

Run a backup:

restic -r sftp:backup-user@remote-host:/backups/vps-restic backup \
  /var/www/your-app \
  /etc/nginx \
  /backups/db/

Notice that the database dump directory is included in the file backup. This is a practical pattern: dump the database to a local directory first, then sweep that directory into Restic along with everything else. The database dump script runs before the Restic backup in the same cron job.

Apply a retention policy to clean up old snapshots:

restic -r sftp:backup-user@remote-host:/backups/vps-restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

This keeps the last 7 daily snapshots, 4 weekly, and 6 monthly, then prunes the data that no longer belongs to any retained snapshot.

Automating Everything with cron

The tools above are useful only if they run without you thinking about them. cron is the standard scheduler on Linux and the right place for backup automation.

Edit your crontab:

crontab -e

A practical backup schedule:

# Database dump, every night at 2:00 AM
0 2 * * * /home/your-user/scripts/backup-db.sh >> /var/log/backup-db.log 2>&1

# File backup with Restic, every night at 2:30 AM
30 2 * * * /home/your-user/scripts/backup-files.sh >> /var/log/backup-files.log 2>&1

# Retention cleanup, every Sunday at 4:00 AM
0 4 * * 0 /home/your-user/scripts/backup-prune.sh >> /var/log/backup-prune.log 2>&1

A few things to get right:

• Stagger the jobs. Run the database dump first, wait long enough for it to finish, then run the file backup that includes the dump output.
• Log the output. Redirect stdout and stderr to a log file so you can check whether the jobs are actually succeeding. A cron job that fails silently is worse than no backup at all.
• Use full paths. cron runs with a minimal PATH. Specify the full path to every binary (/usr/bin/restic, /usr/bin/pg_dump) or set PATH at the top of the crontab.
• Test the job manually first. Run the exact command from your cron entry in an interactive shell before scheduling it. Fix any path, permission, or environment issues before they fail silently at 2 a.m.

Wrapper script example

A simple wrapper that combines the database dump and file backup into a single cron entry:

#!/bin/bash
set -euo pipefail

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
DB_BACKUP_DIR="/backups/db"
RESTIC_REPO="sftp:backup-user@remote-host:/backups/vps-restic"

# Step 1: Database dump
pg_dump -U your_db_user -d your_database -F c \
  -f "${DB_BACKUP_DIR}/your_database_${TIMESTAMP}.dump"

# Step 2: Remove local database dumps older than 3 days
find "${DB_BACKUP_DIR}" -name "*.dump" -mtime +3 -delete

# Step 3: Restic backup (files + today's DB dump)
restic -r "${RESTIC_REPO}" backup \
  /var/www/your-app \
  /etc/nginx \
  "${DB_BACKUP_DIR}"

echo "Backup completed: ${TIMESTAMP}"

Store Backups Off-Server

A backup stored on the same machine it protects is not a backup. It is a copy that dies when the machine dies.

Your backup destination should be physically separate from your VPS. Options, from simplest to most robust:

The strongest setup uses a different provider and a different geographic region from your VPS. If your VPS provider has an outage that affects the entire data center, your backups survive because they are elsewhere.

For S3-compatible storage, Restic connects natively. The configuration looks like:

export AWS_ACCESS_KEY_ID="your-key"
export AWS_SECRET_ACCESS_KEY="your-secret"
restic -r s3:https://s3.your-storage-provider.com/your-bucket init

Set these environment variables in your backup script or in a restricted file that cron sources. Do not put credentials in the crontab directly.

Retention: How Long to Keep What

Keeping every backup forever is wasteful. Keeping only the latest backup gives you no history to roll back to. A sensible retention policy balances storage cost against recovery flexibility.

A common pattern:

• Daily backups: keep the last 7
• Weekly backups: keep the last 4
• Monthly backups: keep the last 6

This gives you granular recent history (any day in the last week), medium-term rollback (any week in the last month), and long-term recovery (any month in the last half year), all without unlimited storage growth.

Restic, BorgBackup, and similar tools handle retention automatically with a single command. If you are using raw tar archives and rsync, you will need a cleanup script that deletes files older than your retention window. The find command handles this:

find /backups/db/ -name "*.dump" -mtime +7 -delete
find /backups/files/ -name "*.tar.gz" -mtime +30 -delete

Test Your Restores

This is the step most people skip, and it is the step that determines whether your backups are worth anything.

A backup you have never restored from is an assumption. You are assuming the dump file is not corrupted. You are assuming the restore command works. You are assuming the application starts correctly with the restored data. Every one of those assumptions can be wrong.

The test is straightforward:

1. Provision a fresh test server (or use a local virtual machine).
2. Install the base operating system and your application stack.
3. Pull the latest backup from your off-site storage.
4. Restore the database from the dump file.
5. Restore the application files.
6. Start the application and confirm it works.

Do this at least once after setting up your backup system, and repeat it periodically (quarterly is reasonable for most setups). The time investment is small. The cost of discovering your backup process is broken on the day you actually need it is not.

When Provider Snapshots Are Not Enough

Many VPS providers offer server snapshots through their control panel. These are full disk images taken at a point in time, and they sound like they solve the backup problem entirely.

They are useful, but relying on them exclusively has gaps:

• Snapshot frequency is typically daily at best. If you need point-in-time recovery within a day, you need your own more frequent backups.
• Snapshots live on the provider's infrastructure. If the provider has a data center failure or an account issue, your snapshots may be inaccessible at the exact moment you need them.
• Restoration is usually an all-or-nothing operation. You restore the entire disk image, not a single file or a single database table. Your own backup system gives you granular restores.
• Retention varies. Some providers keep only one or two snapshot versions. Your own retention policy gives you the depth of history you actually need.

Provider snapshots work well as one layer of a backup strategy. They should not be the only layer. Use them alongside your own automated backups stored off-site for genuine redundancy.

Which Approach Fits Your Setup

Most production setups land on Restic or a similar dedicated tool once the data grows beyond what a nightly tar archive handles comfortably. For a personal project or low-traffic site, tar and rsync are perfectly adequate and have the advantage of zero dependencies beyond what ships with the OS.

Bringing It Together

A solid VPS backup setup does not need to be complicated. The core pattern is:

1. Dump your database on a schedule (nightly for most workloads).
2. Back up application files and the database dumps to an off-site destination using rsync, Restic, or a similar tool.
3. Apply a retention policy so old backups are cleaned up automatically.
4. Log and monitor the backup jobs so failures do not go unnoticed.
5. Test a full restore at least once, then periodically.

If your VPS runs anything that matters to you or your users, this is not optional work. It is infrastructure that earns its value the first time something goes wrong.

For more on securing your server before going live, the VPS security checklist covers all ten essential hardening steps. If you are still in the initial setup phase, the first-time VPS setup guide walks through the full provisioning process from first login. And if you are running self-hosted tools on your VPS, those applications and their data are exactly the kind of assets this backup workflow is designed to protect.

Browse reviewed VPS providers to find plans that match your workload, or read what real users report about reliability and support in community reviews.

Where It Matters Most (and Where It Does Not)

For many VPS workloads, the bandwidth question is academic. A personal blog, a small business site, a staging server, a development environment: none of these generate enough traffic to bump against any reasonable bandwidth limit, whether stated or implied. A plan with 2 TB of monthly transfer is more than sufficient, and the "unlimited" label adds nothing of value.

Bandwidth becomes a real purchasing factor for workloads that move large volumes of data:

• Media-heavy sites and download hosts. Serving video, audio, software packages, or high-resolution image galleries can consume terabytes per month, particularly after a traffic spike from a social media mention or a product launch.
• Game servers and voice platforms. Latency matters more than total volume, but the combination of persistent connections and real-time data can add up to substantial monthly transfer.
• Backup and replication endpoints. A VPS receiving nightly database dumps, off-site backups, or replication streams from other servers can accumulate meaningful inbound transfer.
• API services with high request volume. Each individual response may be small, but millions of requests per day produce significant aggregate bandwidth.

For these workloads, a plan with a clearly stated, generous transfer allowance (and a known overage policy) is often more predictable than an "unlimited" plan where the real ceiling is hidden in a policy document.

The Provider Perspective: Why "Unlimited" Exists

It is worth understanding the economics. Bandwidth has a real cost to providers. Transit agreements with upstream carriers, peering arrangements at internet exchanges, and network hardware all cost money. No provider can offer genuinely unlimited data transfer at a flat monthly rate without losing money on some percentage of their customers.

"Unlimited" is a pricing simplification. Most customers use a fraction of what a generous cap would allow. The provider sets the plan price based on average usage across the customer base, not peak usage by any individual customer. The fair-use policy exists specifically to handle the statistical outliers who threaten that average.

This is not inherently dishonest. Mobile carriers, cloud storage platforms, and email providers all use the same playbook. "Unlimited" means "we will not charge you per unit," not "the resource has no physical boundaries." The gap between those two definitions is where buyer frustration starts.

Reading a VPS Plan Page With Better Questions

The next time a VPS plan lists "unlimited bandwidth," run through this quick diagnostic:

The VPS provider evaluation guide covers bandwidth as one of several dimensions worth checking before committing to a plan. If you are evaluating providers more broadly, that is a good companion read.

The Short Version

"Unlimited bandwidth" on a VPS means the provider will not bill you per gigabyte under normal usage conditions. It does not mean the resource has no ceiling. The real limits come from port speed, fair-use policies, and internal thresholds that may not appear on the plan page.

For most buyers running standard web applications, the distinction barely matters. For workloads that move serious volume, understanding the actual constraints behind the "unlimited" label is the difference between a predictable monthly bill and a difficult conversation with your provider's abuse department.

Read the terms. Check the port speed. Look at what other customers report. The spec sheet is the beginning of the evaluation, not the end of it. Comparing real user experiences across providers is where the providers directory is most useful: it surfaces the practical differences that plan pages leave out.