upvote
A backup that isn't offline is not really a backup as it far too easy to destroy it even by accident/carelessness/lack of understanding.

When I was responsible for backups we kept the tape cartridges in a fire safe in a different building. We took a full backup weekly and moved the tape from the robot to the firesafe as soon as the backup was complete. Only the daily incremental backups stayed in the robot for more than a day.

reply
> has entire infra in code

> spinning up a new shard takes a quarter

Both can be true

reply
That sounds good, but wouldn’t you worry that the same hackers will let themselves in via the same route again?

You would need to understand first how they gained access and verify that they can’t do the same again. That in itself could take days if not weeks. Then of course they might have found new vulnerabilities while they were in, so you would need to worry about that too.

reply
Only if you routinely test it, and if that kind of access to the offline backup is low friction enough to be doing that monthly, it might not be enough of a redundancy.
reply
> Recovering could be measured in hours.

Yes, even hundreds of them sometimes.

The most time consuming part of recovering from an attack is validating everything. It takes more than a few hours to validate the infra that stays put isn’t compromised, the IaC code itself isn’t compromised, deploy the infra, bring a copy of the offline backup of your data (your IaC can’t drive to another site and bring the backups, then make a copy, unless tou are really sure you removed any trace of compromise), validate that the backup is sound, then restore it.

In some cases the infrastructure part is the least time consuming. Some platforms are straight forward enough that even manual deployment is fast. But after a hack you can’t trust anything so you need to do the slow validation that takes longer than your projected “hours”.

reply
> The most time consuming part of recovering from an attack is validating everything. It takes more than a few hours to validate the infra that stays put isn’t compromised, the IaC code itself isn’t compromised, deploy the infra, bring a copy of the offline backup of your data (your IaC can’t drive to another site and bring the backups, then make a copy, unless tou are really sure you removed any trace of compromise), validate that the backup is sound, then restore it.

> In some cases the infrastructure part is the least time consuming. Some platforms are straight forward enough that even manual deployment is fast. But after a hack you can’t trust anything so you need to do the slow validation that takes longer than your projected “hours”.

Your IaC is supposed to be on those offline backups too, and should be able to do everything from clean hardware.

The most time consuming part is to identify what caused the compromise. After that, you can put everything back online and then at the same time start to analyse who did it/what they did and so on. If the root cause for the breach is identified, you also know the time most likely and can trust the offline IaC backup.

reply