The best way to back up PostgreSQL on a VPS

Q: pg_dump cron vs point-in-time recovery: what's the difference?

A cron pg_dump gives you a copy as of each run. Point-in-time recovery keeps a base backup plus every WAL segment, so you can restore to any second in the window, for example just before a bad migration.

Use continuous WAL archiving so you can restore to any moment, keep encrypted copies off the server, and test a restore on a schedule. You can build that yourself with pgBackRest, WAL-G or Barman, or use a service such as Rowsafe that sets it up and tests it for you. A nightly pg_dump is a useful extra, but on its own it can lose a day of writes.

Updated September 24, 2026. Written by the team behind Rowsafe, so we say where it fits and where it doesn't.

The short answer

Turn on WAL archiving with a tool built for it, such as pgBackRest, WAL-G or Barman, so you can restore to any moment, not just last night. A nightly pg_dump alone can lose up to 24 hours of writes.
Store backups off the server, in object storage you control (an S3-compatible bucket at another provider or in another region), encrypted before they leave the server. Keep the encryption key somewhere other than the server.
Test a restore on a schedule. A backup that has never been restored is a guess; integrity checks such as pgbackrest verify don't show that PostgreSQL starts on the result.
Alert on failures. Stopped WAL archiving or a missed backup should reach you the same day, not during an outage.
If you'd rather not build and maintain this yourself, Rowsafe sets up pgBackRest WAL archiving to your own bucket (up to about a minute of writes at risk), restores a full copy every week and alerts you, free for one server. If you don't want to run the server at all, a managed PostgreSQL service is the simpler choice.

The options, compared

Categories, not every product. Facts about other products come from their own docs; sources are at the end.

Ways to back up PostgreSQL on a VPS, compared
Approach	Data you can lose	Restore to a moment	Restores tested for you	Your work	Cost
pg_dump + cron	Up to 24 hours with a nightly job	No	No	A script, off-server copies, encryption and alerts you build	Free, plus storage
Hosted dump services (SnapShooter, SimpleBackups)	Everything since the last backup; schedules down to every 5 minutes on some plans	No: `pg_dump` or logical backups	No automated restore tests documented	Connect the server and pick a schedule	Free plans; paid from $14/month (SnapShooter) or $49/month (SimpleBackups)
pgBackRest, WAL-G or Barman on your own	A few minutes or less, depending on your settings	Yes	No: integrity checks only; you script restore tests	Configuration, schedules, retention, monitoring, alerts and restore tests	Free software, plus storage and your time
Databasus (open source, self-hosted)	Continuous WAL streaming on PostgreSQL 17 and newer; since the last `pg_dump` on older versions	Partial: PostgreSQL 17 and newer	Yes: restore verification in a throwaway container on an agent you run	Host and maintain the Databasus server	Free software (Apache-2.0), plus storage and hosting
Rowsafe	Up to about a minute on a quiet database	Yes, to the second or to a named Mark	Yes, a full restore every week (Proof)	One command and one PostgreSQL restart	Free for 1 server, 3 databases; from $39/month. Plus storage
Managed PostgreSQL (RDS, DigitalOcean, Supabase, Neon)	Minutes, depending on provider (RDS uploads logs every 5 minutes; Supabase PITR up to 2 minutes)	Yes, within the provider's window (an add-on on Supabase)	Mostly not documented; AWS Backup can schedule restore tests for RDS	Migrate your data to the provider	Priced per instance and storage

What a good setup has, whatever you use

Tools differ. These properties are what make a backup worth having.

Point-in-time recovery: Most real restores are about a mistake, not a dead disk: a bad migration, a DELETE without WHERE. You want to restore to the second before it, which needs a base backup plus archived WAL (archive_mode=on and an archive_command).
Copies off the server, and off the provider: A backup on the same disk, or only in the same provider's snapshots, goes down with the server or the account. Use object storage you control, ideally at another provider or in another region.
Encryption with a key you hold: Encrypt before upload, so the bucket only ever holds ciphertext. Keep the key in a secret manager and one more place: without it, nobody can restore.
Retention longer than it takes to notice: Silent data damage is often found days later. One to two weeks of point-in-time recovery is a sensible minimum; keep a longer-term copy (for example a monthly dump) if you need to go back further.
A restore test on a schedule: Restore the latest backup and archived WAL into a scratch copy, start it, check every database is there, and record how long it took. Weekly is good; monthly is the least you should do.
Alerts, and a written restore procedure: Alert on stopped archiving, missed backups and failed restore tests. Write down the restore steps and practise them once, before you need them.

What we would pick, and when

A side project, and losing a day of data is fine: A nightly pg_dump (plus pg_dumpall --globals-only) to object storage at another provider, encrypted, with a heartbeat alert when the job doesn't run. Restore it by hand once a month.
Production data, and you're comfortable operating PostgreSQL: pgBackRest or WAL-G with WAL archiving to an S3-compatible bucket, retention of at least a week, a scripted restore test on a schedule, and alerts on archiving and backups. Barman if you want a central backup server.
Production data, and you'd rather not maintain the backup system: Rowsafe: one command sets up pgBackRest WAL archiving to your own bucket, Proof restores a full copy every week, Pulse alerts you when something slips, and AI agents can save a Mark before risky changes. Free for one server and three databases. PostgreSQL 13 and newer on Debian or Ubuntu, or Docker.
Many kinds of things to back up: If you also need files, whole servers, MySQL, MongoDB or SaaS apps backed up in one place, a hosted backup service such as SimpleBackups or SnapShooter covers that breadth. For PostgreSQL point-in-time recovery, add WAL archiving alongside it.
You don't want to run a database server: Use managed PostgreSQL such as Amazon RDS, DigitalOcean, Supabase or Neon. Backups and point-in-time recovery come with it (an add-on on Supabase), and so do failover options.

Questions

Is pg_dump enough to back up PostgreSQL on a VPS?

Only if losing the writes since the last dump is acceptable. A dump restores to the moment it ran, so with a nightly job that is up to 24 hours. For anything you can't recreate, add WAL archiving for point-in-time recovery, and test restores.

Are my VPS provider's snapshots a good PostgreSQL backup?

They help against losing the whole server, but they are usually taken daily, so they can't restore to a moment in between, and they live with the same provider. PostgreSQL's docs note that a snapshot is only safe when every volume (data, WAL, tablespaces) is frozen at the same instant. Use them as an extra, not as your only backup.

pg_dump cron vs point-in-time recovery: what's the difference?

A cron pg_dump gives you a copy as of each run. Point-in-time recovery keeps a base backup plus every WAL segment, so you can restore to any second in the window, for example just before a bad migration.

Is there a service that tests my PostgreSQL backups automatically?

Rowsafe restores a full copy of each database every week on your own server, checks every database is there, and alerts you if it fails. Databasus, an open-source self-hosted tool, can verify restores in a throwaway container. AWS Backup can schedule restore tests for RDS, with data checks you write.

How do I protect my database from AI coding agents?

Keep point-in-time recovery on, and make the agent save a named restore point before every migration or destructive statement, so you can rewind to exactly that moment. Rowsafe's Guard does this through an MCP server and a Claude Code hook; with plain PostgreSQL you can call pg_create_restore_point() yourself, as long as WAL is archived.

Where should I store PostgreSQL backups?

In object storage off the server, ideally at another provider or region: Cloudflare R2, Backblaze B2, Amazon S3, Wasabi or similar. Encrypt before upload, and don't let a bucket lifecycle rule delete files your backup tool still needs.

What are the alternatives to SnapShooter and SimpleBackups for PostgreSQL?

If you need point-in-time recovery for PostgreSQL on your own server: pgBackRest, WAL-G or Barman on your own, Databasus (self-hosted, PostgreSQL 17 and newer for point-in-time recovery) or Rowsafe (hosted control plane, open-source agent, weekly restore tests). If you mainly need scheduled dumps of many databases and files, those services remain a good fit.

Sources

Facts about other products come from their own public pages, checked on September 24, 2026. Products change: if something here is out of date, tell us at [email protected] and we will fix it.

Comparisons

Protect your first database today.

Free for one server and three databases. Upgrade when you add more.

Start free