Most small SaaS teams think they have backups. Fewer have ever restored one. A backup you have never restored is a guess, not a plan. Here is a simple setup for a small app with one main database, written for founders and web developers who want to sleep well without building a whole ops team.

Start with two questions

Before you pick any tool, answer these in plain words:

  1. How much data can I lose? If the database died right now, would losing the last 24 hours be fine, or would losing one hour already hurt your users?
  2. How long can the app be down? Ten minutes, one hour, or one day?

Your answers decide how often you back up and how fast your restore needs to be. A weekend side project and a paid B2B app will answer very differently, and that is fine.

Know what your host already does

If you use a managed database, it may already take automatic backups. Open the settings page and check three things:

  • How often backups run
  • How many days they are kept
  • Whether you can restore to a point in time, or only to a daily snapshot

Write the answers down in your project notes. Many people assume they have point in time restore and find out on a bad day that they only had a daily snapshot, or that old backups were removed after a short time on their plan.

Even with good host backups, keep one extra copy that you control. If your account gets locked, your billing fails, or someone deletes the whole project by mistake, the host backups can go with it.

A simple extra copy with pg_dump

If you use Postgres, a nightly logical dump is a good second layer. It is slow for huge databases, but for most early SaaS apps it is perfect.

# custom format, compressed, easy to restore selectively pg_dump --format=custom --no-owner \ --file="backup_$(date +%Y%m%d).dump" \ "$DATABASE_URL"

Then copy the file somewhere outside your main provider, like object storage in a different account. Keep a small rotation, for example the last 7 daily files and the last 4 weekly files. Old files should be cleaned up by a rule, not by memory.

A few habits that save pain later:

  • Encrypt the file before it leaves the server if it contains user data.
  • Never commit dumps to your git repo, even a private one.
  • Store the credentials for the backup bucket separately from your app credentials, so one leaked key does not expose both.

The part everyone skips: the restore test

Once a month, put a short reminder in your calendar and do this:

# create an empty scratch database, then restore into it createdb restore_test pg_restore --no-owner --dbname=restore_test backup_20261101.dump

Then check that the restore actually makes sense:

  • Count rows in your most important tables and compare with production
  • Open the newest record and make sure it is from the time you expect
  • Point a local copy of your app at the restored database and log in as a test user

Time the whole thing. If the restore takes two hours and you said you can only be down for thirty minutes, you just learned something important on a calm day instead of during an outage.

Drop the scratch database when you are done so you do not leave a copy of user data lying around.

Write a one page runbook

When something breaks, you will be stressed and tired. Write a short page now that answers:

  • Where the backups live and how to reach them
  • The exact commands to restore
  • Who has access, and what to do if that person is not around
  • How to tell users what happened

Keep it next to your code, in plain text. A runbook that lives only in your head is not much help to anyone else on the team, or to you at 3 AM.

Backups do not replace care

Backups protect you after a mistake. A few small habits stop many mistakes from happening at all:

  • Run destructive migrations on a copy of production data first
  • Use a read only database user for analytics and admin dashboards
  • Turn on deletion protection if your host offers it
  • Be careful with scripts that run DELETE or UPDATE without a WHERE

A quick checklist

  • I know how much data I can afford to lose
  • I know what my host backs up and for how long
  • I keep one extra copy in a place I control
  • I restored a backup in the last 30 days and timed it
  • My runbook is written down where the team can find it

None of this needs fancy tools. It needs one evening to set up and thirty minutes a month to test. That is a small price for knowing your users' data will still be there tomorrow.

Written by the team behind PeekLaunch, a weekly launch board for SaaS makers.