Why VPS provider snapshots are not a database backup

Keep a VPS provider snapshot when fast whole-server reconstruction matters, but do not treat an ordinary live image as your only database backup. The safer default is a database-supported backup at a frequency that meets your recovery needs, stored outside the VPS failure boundary, plus an image for the surrounding machine. A cleanly stopped, complete image can instead serve as a cold physical backup when downtime and image-level restores are acceptable.

A snapshot captures persisted state on the disks the provider includes. It does not, by itself, coordinate open transactions, database caches, write-ahead logs, tablespaces, or application state. A live image may behave like a sudden power loss: the database might recover normally, but that outcome depends on the engine and on every required file being present at a compatible point in time.

Decide by the recovery you must perform. If you need a whole machine from a known image, a provider snapshot may fit. If you need a portable database, a selective restore, or recovery between scheduled images, choose an appropriate engine-supported method and test it. For a broader inventory of server state, see [what to back up on a Linux server](/blog/what-to-back-up-linux-server).

DigitalOcean describes automated Droplet Backups as crash-consistent images of a live system: data still in memory or cache is not captured. Its guidance recommends application-level backup methods for databases and other heavy-I/O workloads. Do not transfer that description to every provider or snapshot mode; check the documented consistency and disk coverage of the specific service you use.

Hetzner recommends powering off a Cloud server before creating a Backup or Snapshot and does not guarantee data consistency for an image of a running server. Across providers, also verify whether attached volumes are included, whether several disks are captured together, and whether restoring them requires separate actions. The [DigitalOcean backup and snapshot comparison](/blog/digitalocean-backups-vs-snapshots-application-aware-backups) and [Hetzner recovery comparison](/blog/hetzner-backups-vs-snapshots-vs-offsite-backups) develop those provider-specific questions.

A clean shutdown improves the case for an image: if the database stops successfully and every required disk is captured, the result can be a usable cold physical backup. Budget for the downtime, retain the software and keys needed to start it, and prove that the provider can restore the complete disk set.

PostgreSQL documents SQL dumps, file-system-level backups, and continuous archiving for point-in-time recovery. An ordinary filesystem copy requires PostgreSQL to be shut down. Its documented live filesystem-snapshot method requires a consistent snapshot of the complete recovery set, including the data directory and write-ahead log (WAL).

Map the actual paths before relying on a VPS image. If WAL or a tablespace is on an attached volume, capturing only the boot disk is incomplete; capturing disks at different instants can also invalidate the set. PostgreSQL's filesystem-backup guidance calls for simultaneous snapshots when the required files span filesystems. The [PostgreSQL backup strategy](/blog/postgres-backup-strategy) covers how to choose a recovery method for that layout.

A pg_dump artifact can support a selective, relatively portable logical restore, but one database dump does not cover every database or cluster-wide role. A suitable physical base backup plus retained WAL can support recovery to a point between backup events. Neither capability appears automatically when you create a VM image; see [pg_dump versus pg_dumpall](/blog/pg-dump-vs-pg-dumpall) when deciding the logical backup's scope.

MySQL distinguishes logical backups, produced by querying a running server, from physical copies of its files. A physical copy made while the server is active needs an appropriate consistency procedure; merely copying the VM disk does not establish one. Choose the method for the storage engines, workload, and restore granularity you actually use.

MySQL documents logical dumps, cold copies after a clean shutdown, and hot backup approaches for InnoDB. Point-in-time recovery requires a suitable backup and the necessary binary logs. A snapshot may be a component of a coordinated physical procedure, but it is not a substitute for that procedure or for protecting the logs.

Check what cannot be reconstructed from persisted VM blocks, including relevant state in memory or outside the VPS. MySQL notes particular complications for MEMORY tables in physical backup methods. For a concrete logical-backup and restore workflow in a containerized setting, see [backing up MySQL in Docker with mysqldump and restic](/blog/docker-mysql-backup-mysqldump-restic).

A provider image can bring back operating-system configuration, packages, database binaries, and nearby application files without rebuilding a server from scratch. It is also a useful coarse checkpoint before an infrastructure change. A database-aware backup addresses a different task: restoring database state through an engine-supported path.

Use the comparison below as a decision aid, not a promise about a specific provider or backup product. Deployment effort, restore time, storage charges, egress, and operator time depend on the image scope, database size, destination, and tested procedure. Neither approach supplies deletion resistance, alerting, or a usable recovery key merely by existing.

For a short-lived rollback, an image may be the least complicated choice if its limitations are acceptable. For selective database recovery, prefer a suitable logical artifact. For tighter recovery-point needs, investigate an engine-supported physical backup and log-protection design. Keep the image as another recovery layer when rebuilding the host would otherwise slow response.

Review the image and database backup against the service's actual recovery map. A green image job only says that the provider completed its assigned capture; it does not establish that the assignment included everything the application needs. See [why a successful backup can still be unrecoverable](/blog/successful-backup-still-unrecoverable) for the same failure pattern across backup methods.

• An attached disk, container volume, bind mount, or external data store is omitted. Inventory declared and runtime mounts after deployments; [Docker backup coverage drift](/blog/detect-docker-volume-mount-backup-coverage-drift) shows why this can change while jobs stay green.
• Database files, WAL or binary logs, and tablespaces are captured at incompatible instants, or required logs are not retained.
• Image frequency is slower than the recovery-point objective (RPO), the maximum data loss the team accepts.
• Retention ends before corruption or an accidental deletion is noticed.
• The same compromised account or credential can remove production and every recovery copy; an off-site copy still needs a tested access and deletion plan.
• A restored VM boots, but the database cannot start or the application cannot complete a critical transaction.