Full-server vs database-only backups: what you’re actually protecting

Most teams find out the hard way that "we have backups" and "we can get the server back" are two different sentences. A nightly database dump is real protection, but it protects rows, not the box. When the underlying machine is gone — bad disk, a provider that suspended your account, a kernel update that won't boot — a folder full of .sql files is the start of a long, manual day. Here's the honest breakdown of what each kind of backup actually covers, and when each is the right call.

What a database-only backup actually protects

A db dump is a logical export of your data: schemas, tables, rows, indexes, sometimes stored procedures. pg_dump, mysqldump, a Mongo archive — they all do the same job, which is to capture the state of your data at a point in time, in a format you can replay into a fresh database.

That's genuinely valuable, and for a specific class of failure it's exactly right:

• Someone runs DELETE without a WHERE.
• A migration corrupts a table.
• You need last Tuesday's version of a record for an audit.
• You're moving the database — and only the database — to a new engine or version.

Dumps are small, portable, and engine-aware. You can restore one table without touching anything else. They compress well and they're cheap to keep a lot of. If your disaster is data-shaped, a dump is the precise tool.

What a dump does not contain is everything around the data that makes the data useful.

What a database dump quietly leaves behind

Think about everything on a running server that isn't a row in a table. A database dump captures none of it:

• The operating system and packages. Your exact distro, kernel, and the dozen apt packages you installed over six months and never wrote down.
• Application code and runtimes. The deployed build, the Node/Python/Go version, the env that actually works.
• Configuration. Nginx/Traefik routing, TLS certificates, firewall rules, cron jobs, systemd units, /etc in general.
• Secrets and env files. The .env that isn't in git (it shouldn't be), API keys, service credentials.
• Uploaded files. User avatars, PDFs, anything on disk instead of in object storage.
• System state. Users, SSH keys, fail2ban bans, the small hardening decisions that took an afternoon each.

None of that is in the dump. So when the box itself is gone, a database backup means you still have to rebuild the server from memory before the dump is even useful. You're reconstructing the environment under time pressure, then restoring data into it, and hoping you didn't forget a package or a config line. That gap — between "I have the data" and "the service is running again" — is where a lot of "we had backups" stories go wrong.

What a full-server image protects

A whole-server image captures the machine, not just its data. The goal is different: not "give me back this table," but "give me back this server, running, the way it was."

A good image includes the filesystem, the installed packages, the application, the config, the certs, the cron jobs, the system users — the entire working state. Restoring it isn't a rebuild; it's a rehydration. The box comes back as itself.

This is the difference between two very different bad days:

Db-only restore: provision a new box, install the OS, reinstall packages, redeploy code, reconfigure Traefik, reissue certs, recreate cron, set env, then load the dump, then debug what you forgot.

Full-image restore: stand up the image, point DNS at it, verify. The data comes along because the data lives on the box.

The distinction matters most in the failure modes people don't drill for: a provider suspends or deletes your account, a region goes dark, hardware dies, or you simply decide to leave a host. A db dump answers "did I lose data?" A full image answers "can I be running somewhere else by this afternoon?"

This is the lens HostSSH is built around — back up, clone, relocate. An encrypted full-server image isn't just a recovery artifact; it's an exit. The same image that restores you after a disk failure is the one that moves you to a different provider when you want out. Concept-wise, the point of capturing the whole box is that the box becomes portable, not pinned to whoever happens to host it today.

When to use which

These aren't competitors. They cover different failure modes, and mature setups run both.

Reach for a database-only backup when:

• The likely disaster is data-shaped: bad deletes, corruption, migration mistakes.
• You need frequent, cheap, granular restores — hourly dumps, single-table recovery.
• You're doing point-in-time recovery or feeding a read replica / analytics copy.
• You want to migrate just the data to a new engine or major version.

Reach for a full-server image when:

• The disaster is box-shaped: dead hardware, an unbootable host, a suspended account.
• You want a defined recovery target measured in minutes of work, not hours of rebuilding.
• You're relocating the whole server to another provider, or cloning it for staging.
• The environment itself is hard to reproduce — lots of undocumented config and packages.

The combined posture

The strong pattern is layered: frequent db dumps for granularity, periodic full images for survivability. Dumps give you a fine-grained timeline of your data. Images give you a floor under everything else. Dumps are how you undo a mistake; images are how you survive losing the machine.

One detail that's easy to skip: a backup you can't reach during an outage isn't a backup. If the box that holds your data is also the only place your backups live, a single failure takes both. This is why custody and destination matter as much as cadence.

Where the backup lives is part of the backup

The most overlooked question isn't "what did I back up" — it's "whose infrastructure is my backup sitting on, and can I get to it without them?"

If your backups live on the same provider as your servers, you've correlated your failure: the account suspension or region outage that kills the box can take the backup with it. The principle worth internalizing is your data, your bucket, your exit — backups land in storage you control (your own R2 or S3), so recovery never depends on the goodwill of the host you're trying to recover from. Bring your own bucket, and the question of "can I leave" answers itself.

There's a custody dimension too, and it's worth deciding deliberately rather than by accident. Roughly three models exist for who holds the keys to an encrypted image:

• Agent-local — the agent on your box holds the keys; encryption and custody stay with you end to end.
• Zero-knowledge — images are encrypted so the control plane can orchestrate restores without ever being able to read your data.
• Escrow — keys are held in managed escrow for teams that want recoverability even if they lose their own copy.

The right choice depends on your threat model and your tolerance for "what if we lose the key." The point is that custody is a decision you should make on purpose.

The takeaway

Database dumps and full-server images aren't a versus. A dump protects your rows with surgical precision and lets you undo a mistake in seconds. An image protects the whole machine and lets you walk away from a host on your own terms. Knowing which one answers which question — did I lose data versus can I be running somewhere else — is most of the work. The rest is making sure both land somewhere you actually control, before the day you need them.