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

The "Oh S***" Moment ## The Problem: Backups are easy. Restores are hard. ## Building The Solution (And Learning to Say "No") ## The Features: ## The Pivot: Killing MSSQL ## Where I am now 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. You put it in crontab. You felt responsible. You felt safe. Then, six months later, you actually need that data. You go to your backup folder. File size: 0kb. Or worse, the file is there, but when you try to restore it, you realize you never tested the restore command, and version mismatches are throwing 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?" I realized that my collection of haphazard shell scripts and cron jobs had three major flaws: No Visibility: If a backup failed silently (disk full, credentials changed), I wouldn't know until it was too late. 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. Restore Anxiety: Restoring a database usually meant SSH-ing in, finding the file, unzipping it, and praying the import command worked. I decided to build a tool that treats Backup & Restore as a first-class citizen, not an afterthought. I’m a huge fan of keeping infrastructure simple. Oops Backup is built to run cleanly in Docker containers. I manage my own infra with Portainer, and I wanted Oops Backup to feel just as native. 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: This is the killer feature. You can browse your backups and restore them to a specific database instance via the UI. 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? Because trying to support the Windows-heavy ecosystem of MSSQL inside a lightweight tool was bloating the project and distracting me from the core user base. 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 building this in public and sharing the journey on X, Threads and Bluesky. If you’re tired of trusting a backup.sh file you wrote three years ago, I’d love for you to check out what I’m building. Check it out at Oops Backup I’m looking for brutally honest feedback. What’s the one feature your current backup solution is missing? Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - No Visibility: If a backup failed silently (disk full, credentials changed), I wouldn't know until it was too late. - 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. - Restore Anxiety: Restoring a database usually meant SSH-ing in, finding the file, unzipping it, and praying the import command worked. - 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: This is the killer feature. You can browse your backups and restore them to a specific database instance via the UI.