The short answer

If you build a web app by yourself, you do not need an enterprise backup plan. You need three habits: back up the database, back up the files your server changes at runtime, and keep secrets and config in a place that survives the box. Everything else — source code, dependency lists, OS images — is either rebuildable from scratch or cheap to recreate.

The real question is not “what is the best backup tool?” It is how much downtime and data loss can your project tolerate, and what is the cheapest routine that meets that bar? That bar is what changes everything else.

Start with risk, not tools

Most backup advice for small businesses is written for offices with shared drives and compliance audits. That framing creates two traps for indie developers: it makes the problem sound scarier than it is, and it pushes you toward solutions that cost time you do not have.

Skip the spreadsheets. Ask yourself three questions instead:

  • If my server vanished tonight, how long could the site be down? A weekend side project and a paying SaaS with five customers give very different answers.
  • What is the most data I could afford to lose? An hour of new posts is annoying. A day’s worth of customer orders is a refund queue.
  • What would I actually need to put the service back up? A fresh server, a database dump, your domain records, and the environment variables that connect them.

Once you answer these honestly, the right backup approach usually appears on its own.

What is worth backing up

Not every byte on your server deserves the same treatment. Sort your project’s data into tiers based on how painful it would be to recreate.

Tier 1 — Cannot lose

This is the data you could not recreate at all, or only by harassing customers and integrations.

  • Production database. User accounts, orders, content written by users, anything transactional. This is almost always your single most important backup target.
  • User-uploaded files. Profile images, attachments, exports. Whatever users hand you, treat it like their data.
  • Secrets and credentials. API keys, signing secrets, OAuth client secrets, database URLs. Lose these and your stack may not start at all.

Tier 2 — Painful to lose, but rebuildable

  • Application config that is not in version control. Environment-specific settings, third-party webhook URLs, anything that lives in a .env file you have not committed.
  • Server-side caches or queues. Redis dumps, job queues, build artifacts. Losing these costs time, not revenue.
  • Email lists and analytics archives. You can rebuild some of this, but a stale export saves a real afternoon.

Tier 3 — Rebuild from source

  • Source code. Your repository already is the backup, provided you push regularly to a remote host like GitHub or GitLab.
  • Operating system and packages. Document the install steps; treat the server itself as disposable.
  • Static assets shipped from your repo. Logos, fonts, front-end bundles — already covered by git.

A useful rule of thumb: if deleting it would make you message a customer or apologize, it belongs in Tier 1. If it would cost you an afternoon, Tier 2. If you can reinstall it in ten minutes, you probably do not need a dedicated backup for it at all.

Automated cloud backup vs. manual routine

This is the comparison that actually matters, and the honest answer is that both can work. The right choice depends on what you can stick to.

When manual backups make sense

Manual routines are underrated for very small projects. A weekly pg_dump scripted into a cron job, copied to an offsite bucket, costs nothing to set up and almost nothing to run. For a low-traffic site with infrequent writes, this can be perfectly adequate for months.

The catch is human. A manual routine depends on you remembering to run it, noticing when it fails, and verifying that the file is actually restorable. If your project is a side thing between consulting gigs, that is a real failure mode.

When automated cloud backup earns its cost

Automation is worth the small monthly bill the moment any of these become true:

  • The database holds customer transactions or paid content.
  • You have paying users who would notice an outage longer than a workday.
  • You cannot honestly commit to checking backup status on a schedule.
  • You run in a single cloud region and want a copy that survives a regional incident.

A managed backup service or a scheduled snapshot policy on your block storage turns backup from a chore into background plumbing. The trade-off is cost — usually small, but it scales with storage volume — and a small amount of vendor trust.

A simple way to decide

If you can write down a recovery plan that says “if the server dies on a Saturday morning, I can be back up by Saturday evening,” a manual or lightly scripted setup is probably fine. If you cannot write that plan without hand-waving, that is the signal to automate.

The 3-2-1 rule, adapted for solo builders

The classic 3-2-1 rule — three copies, two media types, one offsite — was written for offices. The spirit still applies: do not keep your only backup on the same machine as the thing it is backing up.

For an indie project, a practical version looks like:

  1. The live data on your primary server or managed database.
  2. A local or snapshot copy taken frequently, ideally through your cloud provider’s built-in snapshot tools.
  3. An offsite copy in a different provider or region. Object storage buckets with versioning turned on are the most common way to do this cheaply.

That is it. You do not need tape rotation or a second physical site.

A practical setup for most solo SaaS projects

A sensible baseline for a small paid web app looks roughly like this. The exact numbers depend on your traffic and budget.

  • Database: automated daily logical backup (dump), kept for around a month, plus point-in-time recovery if your managed database supports it. Customer and order data falls here.
  • User files and volumes: snapshot or file backup every few hours, kept for about a month.
  • Application config and secrets: stored in a secrets manager or an encrypted vault, with the encryption keys held somewhere separate from the backups themselves.
  • Source code: pushed to a remote git host on every commit.
  • The server itself: a weekly snapshot is usually enough, because it is reproducible from your provisioning script.

Run a restore drill at least once a month. A backup you have never tried to restore is a guess, not a plan.

Common mistakes to avoid

  • Backing up the server but not the database, or vice versa. Each must work independently.
  • Keeping the backup on the same disk as the live data. A full account compromise or hardware failure takes both.
  • Encryption keys stored next to the encrypted backups. If a bad actor gets both, encryption does not help.
  • Never testing a restore. You will discover the missing step during the actual incident.
  • Over-engineering. Daily snapshots of an OS image you could rebuild in 20 minutes waste storage and money.

Frequently asked questions

Do I really need backups if my hosting provider already has redundancy?

Provider redundancy protects against hardware failure, not against accidental deletion, bad deploys, ransomware, or a leaked credential. You still own the responsibility of having a copy you control.

What is a reasonable retention period for a small SaaS?

A month is a common baseline for database backups on a small project. Longer retention is fine, but most incidents are caught within days, and storage costs add up.

Is the free tier enough for backups?

Often, yes — for a small database and modest file volume. Object storage free tiers and a daily scheduled dump can cover a solo project comfortably. Watch the egress and request limits as your project grows.

How do I know my backup actually works?

Restore it somewhere else. Spin up a throwaway instance, load the dump, and confirm the app starts. Until you have done that, you have a hope, not a backup.

A sensible next step

If you do nothing else this week, do this: schedule a daily database dump, write it to an object storage bucket in a different region from your app, and once a month restore it into a fresh environment to confirm it works. That single habit covers the majority of real-world loss scenarios for a solo project, and it costs less than the coffee you would drink while recovering from not having it.

Sources