Most of your project is not worth backing up. The code is on GitHub. The dependencies reinstall from package.json. The built site rebuilds in ninety seconds. All of that you can recreate from a laptop you have never used before, in an afternoon.

Three things you cannot recreate at all. Those are the backup, and everything else is noise.

The idea

A backup is a copy of the state that only exists in one place, kept somewhere that will survive whatever destroys the original. That last clause does most of the work. A copy on the same server is not a backup, because the thing that kills the server kills the copy. Restoring is the actual product; making copies is just the part that is easy to automate and therefore the part people stop after.

code
  can rebuild from source            cannot be recreated
  -----------------------            -------------------------------
  src/  and the whole repo           the database rows
  node_modules/                      user uploads (S3 / Supabase Storage)
  .next/  the built output           /etc/myapp/env   (the secrets)
  the deploy config                        |
                                           v
                                   back up these three,
                                   off this server,
                                   on a schedule

How it works

The database is dumped, not copied. For Postgres that is pg_dump, which writes the whole database out as a single file you can load back with psql. Hosted providers do this for you: Supabase takes daily backups on its paid plans, and Neon and Railway have their own schemes. Free tiers often keep nothing, so check rather than assume.

Uploaded files live in object storage (an S3 bucket, Supabase Storage, Cloudflare R2). These are not in your database and not in your repo, so a database backup alone leaves every user's avatar and every uploaded PDF unprotected. Most providers offer versioning or a scheduled bucket copy.

Secrets are the ones nobody thinks about. Your API keys, database URL and signing keys live in a file on the server or in a hosting dashboard, and they exist nowhere else. If that box dies you have your data and no way to connect to it. A password manager entry is enough. Never a git repository.

The schedule is a judgement about loss. A nightly backup means you can lose up to a day of work. Ask what you would say to a user who lost their last twenty-four hours, and pick the interval from that answer rather than from whatever is convenient.

What to do

  1. Write down the three copies: database, uploads, secrets. Name where each backup goes and how often it runs. If any line says "I think the host does it", go and confirm today.
  2. Automate the database dump. A daily cron job running pg_dump into a different provider's storage costs almost nothing, and Claude Code will write the script and the cron entry in one session.
  3. Do a restore drill. Take last night's dump, load it into a fresh empty database on your own machine, and run the app against it. Put a note in the repo with the date you did it and how long it took. Repeat it every few months.

Where it breaks

Backups faithfully copy corruption. If a bad silently blanks a column on Monday, by Friday every nightly backup contains the blank column and the good data is gone. Keeping a few older copies, a weekly and a monthly rather than only seven dailies, is what saves you from a slow failure instead of a sudden one.

Restores are also slower and stranger than you expect. Version mismatches, missing extensions and permissions problems all show up for the first time under pressure, which is why the drill matters more than the schedule. A backup you have never restored is a hypothesis.