Comment by kovacivan | Hacker News Reader

Comment by kovacivan | Hacker News Reader

Parent Full thread

Great questions.

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.

> And yes, the connection string is used to create a restricted 'read-only' user for the backup process.

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.

Fair point, and you're technically correct.

"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.

Wait, you are the Healthchecks.io founder? Big fan of your work!

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.

Reply on news.ycombinator.com