Backups to another provider are very costly for most users due to egress bandwidth pricing.

Most backup systems can't do efficient incremental diffs either - so you end up sending your companies entire database every 12/24 hours, burning through a lot of bandwidth.

Would have through incremental backup (replication) would be a core feature of most databases.

I think the problem is that replication alone isn't enough. You also need to support snapshots for backups because you don't want to replay years worth of replication logs to do a restore.

And when you support snapshots in your backup software, it's very tempting to then drop support for replication...

Replication logs also have another problem - since they include every data change, certain types of database updates, for example a large field that changes hundreds of times per second, can work out far less bandwidth to just snapshot periodically.

Overall, all this stuff is a lot of complexity most businesses don't want to have. They just want to have a simple backup solution and get back to building their product. And that usually involves using some managed database where backups are just an option in the control panel. Or a self-managed database where backups are disk snapshots. Or a script that copies a database dump to S3 every day. But it hardly ever involves streaming change logs...

I use borg backup for this very use case.

Not free, certainly. But it's a system requirement there to be able to rebuild the system in a non AWS environment.

You don't need to use a separate provider to address the problem here, where using a separate provider may not address the problem at all:

> "We're fully redundant across AZs, regions, and even cloud providers!" crows the engineer with a single corporate credit card backing the entire house of cards.

https://twitter.com/QuinnyPig/status/1288275701389389825

You could backup to a different account, possibly in a different region, with the same provider, as long as the other account has a different payment method. Using one provider would in most cases reduce the amount of effort to get back up and running.

The key piece would be how DNS is structured and hosted/billed.

> If you're on AWS/GCP and only backup to S3/GCS, you're doing it wrong.

If that’s how you feel then you should be applying that logic to any provider. Even if you rent rack space in a data center. Because unless you own everything through and through. This could happen anywhere.

I agree with this premise. Backup to another provider, and also make sure it is in a different physical location - different city. In the old days you would pay a company to take a tape backup offsite so why not keep to that idea.

Of course you should be applying that logic if you rent rack space in a data center - your backups should definitely be outside of that data center somewhere else.

You can get some cheap storage from Hetzner and also back up there. With their !sane! egress transfer costs compared to the lunacy that plagues Google, AWS etc, accessing the data wont ever be problem either.

Those are different providers. Why would you need a 3rd?

Think they meant "AWS or GCP and only backup to S3 or GCS respectively"

I think they’re saying only backing up _data_ is not enough (S3, GCS). You need to be able to roll out infrastructure elsewhere to, in order to have somewhere to restore said data.