Show HN: Oops Backup – Simple off-site backups for your databases
oopsbackup.com
oopsbackup.com
The Problem: Most indie devs rely on provider snapshots. But if your cloud account is locked or a provider has a major outage, your snapshots go with it.
The Solution: Oops Backup provides an automated, managed second layer. It doesn't matter if your DB is in Docker, on a VPS, or bare metal. If it's accessible via the internet, we can secure it.
The Tech:
Native Backups: We use native tools (Postgres, MySQL, MongoDB) to ensure data integrity.
Security: All backups are encrypted using AES-256-GCM before storage.
Flexible Destinations: You can use our managed storage (Oops Storage on R2), your own S3 bucket, or your own server via SFTP.
Simple Pricing: $12/mo flat for 32-day retention on our managed storage.
I'm building this in public and would love your feedback on the feature roadmap or our security approach!
> 1. Connect your database. Add your database connection string.
^ does this mean client's database must be accessible from public internet, and Oops Backup needs to be given read access to it?
It would be good to have docs going in precise detail of how backups will work. If these docs exist, don't put them behind login wall.
> Each account comes with 2GB of high-speed storage. This is enough for most SaaS databases, blogs, and side projects.
Is this per backup, or total? If total, then with 32-day retention there's only ~60MB per backup, which is tiny.
You don't need to open your DB to the entire internet. We provide a static IP for you to whitelist in your firewall. And yes, the connection string is used to create a restricted 'read-only' user for the backup process.
Valid point on the docs. I will change it definitely. You shouldn't have to create an account to see our security posture.
For storage, you’re right on the raw numbers, but in practice, database dumps compress incredibly well. We use Gzip compression so a 100MB SQL dump typically ends up around 15-20MB on disk. For a side project or a small SaaS with a few hundred MBs of data, 2GB actually provides a very comfortable ceiling for a 32-day rotation.
To be clear, Oops Backup is not an enterprise solution. If you’re managing a multi-terabyte production cluster with strict compliance needs, we aren't your tool. We built this for indie hackers, hobbyists, and small-to-medium side projects where a 2GB total footprint is the norm, not the exception. It’s for the person who just wants to spend 2 minutes setting up a safety net for their $20/month VPS database.
OK, in that case, I think marketing it as "Zero-knowledge" and "end-to-end encryption" is misleading. Oops Backup sees the data, and the client has to trust Oops Backup to handle the data with care.
An example of actual end-to-end encryption would be a cron job doing "pg_dump ... | gpg --encrypt ... | s3cmd put ..." (with some more arguments of course). The database backup is compressed and encrypted on the database host itself, and sent directly to S3.
"End-to-End" usually implies the encryption happens on the client's infrastructure before it ever touches ours. Since Oops Backup handles the "dump" process via a connection string, we do technically see the data in transit before it is encrypted and moved to storage.
And I should have been more precise. The "Zero-Knowledge" refers to the at-rest storage. Once the backup is encrypted on our end, we don't hold the keys to decrypt it in the storage bucket.
Your pg_dump | gpg | s3 example is exactly what someone should do if they want true E2EE. Oops Backup exists for the indie dev or hobbyist who doesn't want to manage their own backup scripts, GPG keys, and cron jobs, and is willing to trust a managed service with the in-flight transition in exchange for a 2-minute setup.
I'll update the landing page copy to ensure we aren't misrepresenting the architecture. I appreciate the call-out—it’s an important distinction.
You’re 100% right on the terminology. The pg_dump | gpg flow is definitely the correct way to achieve true E2EE.
The trade-off I made with Oops Backup was purely about eliminating the agent or script management. For many of the indie devs I'm targeting, setting up and maintaining that cron job/script is the hurdle that prevents them from having backups at all.
By handling the connection string on our end, we provide a 2-minute set and forget experience, even though it means we have access in-flight before the data is encrypted at rest.
Honestly, I built this because I was tired of managing custom backup scripts for my own side projects and just wanted a easy safety net.
I’m updating the site to remove the 'End-to-End' claim. I definitely don't want to mislead anyone on the architecture. It’s 'Zero-Knowledge' for the stored data only.
Thanks for the catch and for keeping the bar high.