[cuu508]

How are the backups being made and by who?

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

[kovacivan]

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.

[cuu508]

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