Why VPS provider snapshots are not a database backup

A VPS provider Snapshot records a point-in-time image of one or more virtual disks. That is useful infrastructure protection, but the storage layer does not automatically understand open transactions, database buffer caches, write-ahead logs, replication state, tablespaces, or the application invariants built on top of them.

The distinction is easiest to see during recovery. A crash-consistent image resembles the disk after power was lost. A database may replay its transaction log and start successfully, or it may discover that required files were not captured together. An application-consistent backup is created through a method the database engine documents, with the locks, logs, checkpoints, or transactional snapshot needed to make recovery repeatable.

This does not make provider Snapshots bad. It makes their recovery contract different. They can reconstruct an operating system quickly, preserve packages and configuration, and provide a useful last-resort physical image. Calling that image the database backup without qualification hides assumptions that should be tested.

DigitalOcean explicitly describes automated Droplet Backups as crash-consistent images of the live system. Its documentation notes that data still in memory or cache is not captured and recommends application-level methods for databases and other heavy-I/O workloads. For manual Droplet Snapshots, DigitalOcean recommends powering off when applications need their disk state flushed.

Hetzner makes the same consistency boundary visible from another provider. Its documentation recommends powering off a Cloud server before creating a Backup or Snapshot and says it cannot guarantee data consistency when the image is created from a running system. That is a useful statement of scope: the provider copies the disk but does not promise that every workload has prepared itself for the image.

A clean shutdown changes the picture. If the database stops without error and every required disk is captured together, a full-disk image can be a valid cold physical backup. The operational price is downtime, and the recovery remains tied to compatible server software and a complete set of files.

PostgreSQL documents three broad methods: SQL dumps, file-system-level backups, and continuous archiving with point-in-time recovery. A plain filesystem copy requires the server to be shut down. The documentation also allows a consistent filesystem snapshot while PostgreSQL is running, but the complete data directory must be captured and the WAL files must be included.

Multi-volume layouts are where an apparently atomic VPS image can become dangerous. PostgreSQL warns that snapshots must be simultaneous when the data directory, WAL, or tablespaces span filesystems. If the provider image covers only the boot disk while a data directory or tablespace sits on an attached Volume, the recovery set is incomplete even if each captured disk image is internally sound.

A logical dump has different strengths. It is generally portable across PostgreSQL versions and machine architectures and can support selective restore. A physical base backup plus archived WAL supports point-in-time recovery between full backup events. These capabilities are database semantics; an undifferentiated VM image does not create them by itself.

MySQL's official documentation separates logical backups from physical copies of database files. A logical backup queries the running server and produces database structure and content. A physical backup copies data files and can restore large systems quickly, but a running server needs appropriate consistency handling so database changes do not invalidate the copy.

For InnoDB, MySQL documents hot backup tooling, cold copies made after a clean shutdown, and logical dumps. It also notes that point-in-time recovery combines a suitable backup with binary logs. A storage Snapshot may be part of a valid physical method, but the database engine still determines the locking, log, and recovery requirements.

Memory-backed state illustrates the limit of a disk-only view. MySQL's documentation notes that data in MEMORY tables is not stored on disk in the same way and is tricky for raw physical methods. More generally, a VPS image cannot preserve information that the application has not persisted or include an external dependency merely because the VM references it.

Whole-machine recovery is often faster from an image than from a blank operating system. A Snapshot can preserve the database binaries, extensions, system libraries, service configuration, firewall rules, and nearby application files as they existed together. It can also give responders a separate machine on which to inspect damage without immediately overwriting production.

Snapshots are particularly useful before planned infrastructure changes. They give you a coarse rollback point for an operating-system upgrade, package change, or migration. For a database that can tolerate a clean stop, a powered-off image can be a simple physical recovery point when all disks are included.

The limitation is granularity and portability. Restoring one table from a server image may require provisioning the entire old machine and starting a compatible database version. Rolling back the original VPS also rolls back unrelated files and loses newer state. A database-aware artifact can make those operations more precise, while the image remains available for broad disaster recovery.

Snapshot strategies fail less often because the provider lost an image than because the recovery set was defined incorrectly. Review these gaps before treating an image as sufficient.

• Attached storage is omitted, captured separately, or captured at a different instant from the boot disk.
• Database files, transaction logs, and tablespaces span several filesystems without a simultaneous snapshot guarantee.
• The image frequency is slower than the application's recovery-point objective.
• The retained history is shorter than the time corruption or accidental deletion can remain unnoticed.
• The same provider account can delete production and every image used to recover it.
• A successful VM boot is mistaken for database and application validation.
• The restored image requires an old architecture, database version, encryption key, or external service that is no longer available.
• Nobody has measured the time needed to provision, recover, replay logs, change DNS, and validate users' critical workflows.

Start with recovery objectives. If losing a day of transactions is unacceptable, a daily VPS image cannot meet the requirement regardless of image quality. Choose a database-supported logical or physical method at the required frequency. Add log archiving when point-in-time recovery is needed. Protect the resulting artifacts in encrypted storage outside the server's failure boundary.

Keep provider Backups or Snapshots for the surrounding machine when their recovery speed is valuable. Record exactly which disks and Volumes they cover, whether the database is live or stopped, and what crash recovery is expected. Do not let the existence of a database-aware backup excuse an untested rebuild of the host, or let a convenient host image excuse missing database consistency.

Separate credentials where practical. A compromised VPS should not be able to erase every older recovery point, and a compromised provider project should not remove the only application backup. Preserve repository passwords, storage access, database encryption keys, and version information somewhere responders can reach without the original machine.

A restore test should begin on an isolated target. For a Snapshot path, create a separate VPS where possible, confirm every required disk is present, and allow the database to perform its documented recovery. For a database-aware path, restore into a scratch instance using a compatible engine version. Keep the production replacement as a separate, reviewed decision.

Validation should go beyond process status. Check schemas, extensions or plugins, users and privileges, row counts for representative tables, recent records around the recovery point, background jobs, file references, and application login or transaction flows. Review logs for crash recovery, missing WAL or binary logs, corrupt pages, and version mismatch.

Record duration and manual dependencies. The better recovery path is not necessarily the one with the shortest backup job; it is the one that meets the required data-loss and downtime limits under incident conditions. A provider image and a database-aware backup earn their place only after the team has demonstrated the recoveries they are meant to provide.