Show HN: PGBackup.com, Postgres backup as a service

&gt; A dedicated, virtual server that runs your postgres version in replica mode. It continuously receives changes from your primary database server, becoming an off-site backup.<p>This isn&#x27;t an offsite backup. This an offsite replica that will faithfully replicate a &quot;DELETE FROM account WHERE true&quot;.<p>Marrying that with a scheduled logical pg_dump and&#x2F;or physical pg_basebackup that runs against the local copy (for performance and not impacting the master) would create a true offsite backup.<p>Until then, it&#x27;s just one more place that will get wiped out when the source data is accidentally destroyed.

I would pay for this.<p>The product you should be building is replication (what you have actually built) and wal-e configured to backup to amazon s3 (where I provide the bucket).<p>you guarantee that the backups are happening, build in some intelligence to make sure catastrophic &quot;DELETE&quot; statements would trigger a backup first, etc.<p>Give me the ability to spawn a replica using the exact backup that I choose, etc.<p>This is something I could totally pay for!

Instead of terming it &quot;backup&quot;, won&#x27;t &quot;replication&quot; be more appropriate?

Seeing a service like this makes me wonder if Postgres could support encrypted replication. That would allow using a service like this to provide reliable backup without having to trust it with customer data.

Don&#x27;t show an actual password in your examples unless you want hundreds of people using it.

Author here, To quote from the FAQ:<p>&gt; Why did you build PGBackup?<p>&gt; We were tired of constantly configuring a postgres replica for each (small) project. And then being pretty unsure if the backup would still be up-to-date by the time the primary server crashes.<p>&gt; When talking with other postgres users about backups, we also found that primary and backup servers often run in a single data center or at a single (budget) provider. In effect, exposing these users to non-neglible risk of loosing database+backup.<p>There&#x27;s some - obvious - challenges in getting new users to trust you enough to send them their database copy. At the same time, people host very sensitive data at (virtual) budget servers without thinking twice. What do you think?

Great feedback here, but also through the on-site chat. Again, the current version is built with very limited resources mainly to check if&#x2F;how the idea would resonate.<p>- We will try to add Point-in-time-recovery asap (saving base backups+xlogs). These would run of the replica, not putting load on your database server. As koolba correctly points out, this will make it more &quot;backup&quot; than &quot;replica&quot;. Will have to figure out how this fits in the pricing model.<p>- I would personally love to offer better (guarantees of) encryption of the backups, ideally encrypt the data pages on the primary server. We would have to see how this would technically work.<p>- First couple of backups are currently replicating :)!!<p>Thanks, HN!

Not sure if the cost of this is worth it. I set up WAL-E (<a href="https:&#x2F;&#x2F;github.com&#x2F;wal-e&#x2F;wal-e" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;wal-e&#x2F;wal-e</a>) to do server-side encrypted backups (it does a daily base backup + continuous WAL delivery) in about half a day. If you setup lifecycle rules on the S3 bucket you can have an automatic deletion policy handle cleanup.

Do you expect us to open the port on public interface?