Why I stopped trusting my own backup scripts (and built a SaaS instead)

Source: Dev.to

The “Oh S***” Moment

We’ve all been there. You have a side project running on a $5 VPS. You wrote a quick bash script to run pg_dump or mysqldump every night at 3 AM, added it to crontab, and felt responsible—and safe.

Six months later you actually need that data. You go to your backup folder and see:

• File size: 0 KB.
• Or worse: the file is there, but restoring it fails because you never tested the restore command and version mismatches throw errors everywhere.

This is exactly why I started building Oops Backup.

As developers we obsess over the backup part—“Is the data saved?”—but we rarely obsess over the restore part—“Can I get this app back online in 5 minutes if the server catches fire?”

My collection of haphazard shell scripts and cron jobs had three major flaws:

1. No Visibility – If a backup failed silently (disk full, credentials changed), I wouldn’t know until it was too late.
2. Storage Hell – Storing backups on the same server as the database is a recipe for disaster. Moving them to S3 via scripts is annoying to maintain.
3. Restore Anxiety – Restoring a database usually meant SSH‑ing in, finding the file, unzipping it, and praying the import command worked.

Building The Solution (And Learning to Say “No”)

I decided to build a tool that treats backup and restore as first‑class citizens, not afterthoughts.

• I’m a huge fan of keeping infrastructure simple. Oops Backup runs cleanly in Docker containers, managed with Portainer, and feels native to my stack.
• Automated Scheduling – No more manual cron editing.
• Storage – Native integrations for S3‑compatible storage (AWS, Cloudflare R2, Backblaze B2), Oops Storage, or SFTP transfer.
• One‑Click Restore – Browse your backups and restore them to a specific database instance via the UI.

Feature Pruning

Building in public means admitting when you’re wrong. Initially I wanted to support everything: MongoDB, PostgreSQL, MySQL, and Microsoft SQL Server. Last week I officially dropped support for MSSQL.

Why? Supporting the Windows‑heavy MSSQL ecosystem inside a lightweight tool was bloating the project and distracting me from the core user base. About 95 % of indie hackers and devs I know run on the “LAMP” or “MERN” stack equivalents. By cutting MSSQL I could double down on making the Postgres, Mongo, and MySQL experience flawless. Sometimes you have to cut a feature to save the product.

I’m currently finalizing and polishing the UI. I’m sharing the journey on X, Threads, and Bluesky.

If you’re tired of trusting a backup.sh file you wrote three years ago, check out what I’m building:

Oops Backup

I’m looking for brutally honest feedback. What’s the one feature your current backup solution is missing?