3 ms·

Also: If you're on AWS/GCP and only backup to S3/GCS, you're doing it wrong. All your backups to setup a new system (even if it takes time) need to be with a di

Also: If you're on AWS/GCP and only backup to S3/GCS, you're doing it wrong. All your backups to setup a new system (even if it takes time) need to be with a different provider.

deelowe 4y ago
Those are different providers. Why would you need a 3rd?
- paragraft 4y ago
  Think they meant "AWS or GCP and only backup to S3 or GCS respectively"
- KhalPanda 4y ago
  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.
londons_explore 4y ago
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.
- quickthrower2 4y ago
  Would have through incremental backup (replication) would be a core feature of most databases.
  - londons_explore 4y ago
    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...
- locutous 4y ago
  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.
philliphaydon 4y ago
> 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.
- quickthrower2 4y ago
  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.
- PeterisP 4y ago
  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.
unity1001 4y ago
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.
buchanmilne 4y ago
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 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.

Also: If you're on AWS/GCP and only backup to S3/GCS, you're doing it wrong. All your backups to setup a new system (even if it takes time) need to be with a different provider.

deelowe 4y ago

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

paragraft 4y ago
Think they meant "AWS or GCP and only backup to S3 or GCS respectively"
KhalPanda 4y ago
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.

londons_explore 4y ago

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.

quickthrower2 4y ago
Would have through incremental backup (replication) would be a core feature of most databases.
- londons_explore 4y ago
  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...
locutous 4y ago
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.

philliphaydon 4y ago

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

quickthrower2 4y ago
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.
PeterisP 4y ago
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.

unity1001 4y ago

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.

buchanmilne 4y ago

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