VPS Snaps
← All articles

Linux Server Backups: A Practical Strategy That Works

Linux Server Backups: A Practical Strategy That Works

Compact Linux server in a utility room

A reliable Linux server backup has four parts: a defined list of what to protect, a schedule tied to how much data you can afford to lose, copies stored somewhere the server cannot damage, and a restore you have actually tested. Tools matter less than those four decisions. This guide walks through each one, compares the common approaches, and shows where automation removes the failure points that scripts tend to hide.

Vpssnaps
vpssnaps.com
Automate Linux Server Snapshots
VPS Snaps automates provider API snapshots with encrypted credentials and run logs that track successful operations and alert you to failures.
Register for VPS Snaps

TL;DR

  • Decide your recovery targets first (how much data you can lose, how long you can be down), then pick the tool and schedule.
  • Follow the 3-2-1 rule, and make at least one copy unreachable from the server it protects, because ransomware goes looking for backups.
  • Use application-aware dumps for databases. Raw file copies of a busy database can come back corrupted.
  • A backup you have not restored is a hope, not a backup. Schedule restore drills and keep run logs that show failures.
  • Cron plus rsync works until it fails silently. Monitoring, alerting and retention are what separate a script from a backup system.

Table of Contents

Start with what you can afford to lose

Before you compare software, write down two numbers per server. NIST defines the recovery point objective (RPO) as the point in time to which data must be recovered after an outage. The recovery time objective (RTO) is how long a system’s components can sit in recovery before the mission or business processes suffer.

In practice:

  • RPO decides your backup frequency. If you can lose a day of data, a nightly job is enough. If you can lose fifteen minutes, you need frequent incremental runs or database log shipping.
  • RTO decides your restore method. Rebuilding a server from a file archive and reinstalling packages takes longer than booting a provider snapshot. If the business cannot wait, you want a snapshot or an image alongside file-level copies.

A small business with a single web server and a customer database might accept an RPO of 24 hours and an RTO of four hours. A payment-adjacent API might need minutes on both. Tiering your servers this way keeps cost in check, since you do not need to protect a staging box like production. For a deeper treatment with worked numbers, see our RPO and RTO explainer and the tiering templates. If you are a smaller organization and want a plain-language take on setting these targets against a budget, this guide to RPO and RTO for small businesses is a useful read.

What to back up on a Linux server

The common mistake is backing up “the server” as one undifferentiated blob. Break it into layers, because each layer restores differently.

Layer Examples Best method
Whole machine Boot disk, installed packages, kernel and bootloader Provider snapshot or disk image
Configuration /etc, systemd units, cron entries, SSH and TLS config File-level backup, ideally also in version control
Application data Uploads, media, app directories, /var/www File-level, incremental
Databases PostgreSQL, MySQL, MariaDB, MongoDB Logical dump or native tooling
Containers Docker volumes, Compose files, Kubernetes manifests and persistent volumes Volume backups plus manifest export
Secrets API keys, certificates, .env files Encrypted backup, stored separately from the data

We keep a longer checklist of what to back up on a Linux server if you want to audit your own setup against it.

Two items get forgotten more than others. The first is the list of installed packages and the infrastructure definition, which turn a data restore into a working server. The second is the credentials your backup job itself uses. If those live in a plaintext script on the server, anyone who compromises the server also gets the keys to your backups.

Choosing a method: snapshots, file-level tools, and dumps

No single method covers everything. Most solid setups combine two or three.

Provider snapshots

A snapshot captures the whole disk at a point in time through your cloud provider’s API. It is the fastest route to a running server again, and it needs no agent inside the machine. The trade-offs: snapshots are crash-consistent rather than application-consistent unless you quiesce the workload, they live in the provider’s account and region, and managing schedules and retention by hand through each provider’s console gets tedious across several accounts. Provider-specific walkthroughs are in our guides for DigitalOcean, Vultr and Hetzner snapshots.

File-level backup tools

Tools like restic, BorgBackup and Kopia create encrypted, deduplicated, incremental backups of directories. Restic, for example, documents direct support for Amazon S3 and S3-compatible storage. Deduplication means nightly runs after the first are small and fast, and versioned snapshots let you roll back to last Tuesday. These tools are excellent, but they are tools, not systems: you still own the scheduling, the alerting, the retention pruning, and the credential handling. We compare them in restic vs Borg vs Kopia and cover a Borg setup in this tutorial.

Database dumps

Databases are where naive file copies hurt. Copying data files while PostgreSQL or MySQL is writing can produce something that will not start. Practitioners handle this with pre-backup hooks that run an application-level tool first, as PodWarden’s backup guide describes. PostgreSQL’s own documentation says pg_dump produces consistent exports even while the database is in use, without blocking other users. Dump to a file, then ship the file with the rest of your data.

Containers and Kubernetes

Docker volumes are just directories on the host, but the container writing to them may be mid-transaction. Stop or quiesce stateful containers, or run an application-aware dump through the container. The same idea applies in Kubernetes: the K8up operator lets you annotate pods with backup commands that stream an application-aware backup to stdout. Back up the manifests too, since persistent volumes without the objects that mount them are slow to reassemble.

Build your strategy around 3-2-1, then harden it

The 3-2-1 rule is the standard starting point. CISA’s data backup guidance frames it as three copies of your data (one primary, two backups), on two different types of media, with one copy off-site. For a cloud server that translates roughly to:

  1. The live data on the server.
  2. A provider snapshot of the disk, for fast whole-server recovery.
  3. A file-and-database backup in an object storage bucket, ideally with a different provider or region than the server.

Our own write-ups cover the 3-2-1 rule for servers and VPSs and how to harden it with one immutable copy.

Why “off the server” is not optional

Ransomware looks for your backups. The CISA and MS-ISAC Ransomware Guide recommends keeping offline, encrypted backups and testing their availability and integrity. CISA’s August 2026 advisory on the Gunra ransomware-as-a-service operation is a current reminder that these groups target organizations broadly and that backup hygiene is part of the recommended mitigations. The lesson for Linux servers is concrete:

  • Do not back up to a drive or network share that stays mounted read-write on the server. Anything the server can write and delete, an attacker on the server can too.
  • Give the backup credentials the narrowest permissions possible, and keep them out of plaintext files.
  • Use a storage bucket with versioning or object lock where your provider supports it, so a compromised key cannot erase history.
  • Keep retention long enough to outlast attacker dwell time. Intrusions are sometimes found weeks after they begin, and a 7-day retention window can mean every copy is already tainted. Our retention matrix and retention policy guide lay out options. More on the defensive side is in how to protect backups from ransomware.

Encrypt before the data leaves the machine. We explain two good options in encrypting backups with GPG and age.

Why cron and rsync are not a backup system

A cron job calling rsync is the most common Linux backup there is, and it is a fine building block. It becomes a liability when it is the whole plan. Scripts tend to fail silently: the disk fills, a token expires, the destination host changes its key, and nobody notices for months. CISA’s guidance for ransomware preparedness stresses that backups need to be tested, and a script with no logging and no alerting cannot tell you whether it worked.

What a script rarely gives you:

  • Failure alerts. Not just “the cron ran” but “the backup completed and the data is in the bucket”.
  • Retention management. Pruning old copies safely, so you do not either hoard storage or delete the only good copy.
  • A per-run record. A log you can show to an auditor or a customer.
  • Credential hygiene. Keys stored encrypted and rotated, not pasted into a shell script.
  • Multi-server consistency. Ten servers with ten slightly different scripts is ten places for drift.

If you manage one server and enjoy tinkering, restic or Borg with a timer and a monitoring ping is a respectable approach. Once you manage several servers, several clients, or several cloud accounts, the maintenance cost of that approach tends to exceed the cost of a managed tool.

Test restores, or you do not have backups

Silent failure is the biggest risk even with automated tools. The CISA ransomware guide recommends testing backup availability and integrity in a documented process. Here is a lightweight drill you can run quarterly:

  1. Pick a server and a restore point, ideally one that is a few weeks old, not last night’s.
  2. Provision a fresh, isolated machine. Never restore over production for a drill.
  3. Restore files and the database dump. Restart services.
  4. Check that the application works: log in, load a record, run a query you know the answer to.
  5. Record how long it took. Compare that to your RTO. If it is longer, you have found a gap before an outage did.
  6. Write down anything you had to figure out, and fix the runbook.

Two checks are worth automating: a periodic listing or integrity check of the repository, and an alert if a scheduled run does not report success.

Perspective: automate the boring parts, keep ownership of the data

We built VPS Snaps because most backup failures we see are not exotic. They are an expired credential, a script nobody updated after a migration, or a backup that was never verified. The fix is rarely a cleverer algorithm. It is removing the manual parts and keeping a record of every run.

Our view comes down to three principles. First, backup data should stream straight into a bucket you own, rather than being staged on someone else’s infrastructure. Second, the backup must be restorable without us: snapshot artifacts stay in your provider account, and your data sits in S3-compatible storage under your control, so you are not dependent on a proprietary restore tool. Third, every run should leave evidence: logs that show what succeeded, and alerts for what did not.

If you take one thing from this guide, make it this: choose a design where losing access to any single tool, including ours, does not mean losing your data.

— Scott

Automating it with VPS Snaps

VPS Snaps handles scheduled provider snapshots, database dumps, Docker volume backups, file backups, and Kubernetes manifest and volume backups. It works with seven cloud providers, detects applications on your servers, streams backups directly into your own S3-compatible bucket, stores credentials encrypted, keeps detailed run logs, and manages retention automatically. For private infrastructure with no inbound access, the Backup Agent makes outbound-only connections. You can see how we handle credentials and data on the security page.

Plans on the pricing page run from a Free plan at $0 per month, then Starter at $10 per month, Standard at $30 per month, Pro at $57 per month and Agency at $117 per month. Annual billing is $120 per year for Starter, $360 for Standard, $684 for Pro and $1,404 for Agency. Our service is aimed at DevOps engineers, IT teams, freelancers and small businesses managing cloud servers, not at home PC backup. If you are weighing storage options, our storage guides are a good place to start, including a walkthrough of UpCloud Object Storage for server backups.

Automating it with VPS Snaps — overview diagram

A sensible starting setup

If you are starting from nothing, this is a configuration most small teams can reach in an afternoon:

  • Nightly provider snapshot of each production server, retained for 7 to 14 days, for fast whole-machine recovery.
  • Nightly file and database backup to an S3-compatible bucket in a different provider or region, with encryption on and versioning enabled.
  • Longer retention tier, for instance weekly copies for several months, to outlast slow-to-detect incidents.
  • Alerts on any failed or missed run, sent to a channel someone reads.
  • Quarterly restore drill on an isolated machine, with the time recorded against your RTO.
  • Separate credentials for backups, scoped so they can write new data but not wipe the bucket.

Adjust frequency per server tier. A staging box might need weekly backups and a short retention window. A production database might need hourly dumps. The point is that every choice traces back to the RPO and RTO you wrote down at the start.

For more on the Linux side, browse our Linux guides and the wider server backup library.

FAQ

What is the best backup tool for a Linux server?

There is no single best tool. Restic, BorgBackup and Kopia are strong open source choices for encrypted, deduplicated file backups, and provider snapshots are best for fast whole-server recovery. Pick based on your recovery targets and how much scheduling, alerting and retention work you want to own yourself.

How do I back up a Linux server while it is running?

For files, incremental tools like restic or Borg run on a live system without trouble. For databases, use an application-level dump such as pg_dump rather than copying data files. For a full disk, take a provider snapshot, and quiesce write-heavy services first if you need application consistency.

What is the 3-2-1 backup rule?

Keep at least three copies of your data, on two different types of media, with one copy off-site. CISA describes it in its data backup guidance. For cloud servers, that usually means live data, a provider snapshot, and a backup in object storage at a different provider or region.

How often should I back up my Linux server?

As often as your recovery point objective demands. If losing 24 hours of data is acceptable, nightly is enough. If not, back up more frequently, and use database-level tools for tighter intervals. Always test a restore, because frequency means nothing if the backup cannot be recovered.

Sources