"Aurora will try to retain enough log information to support that window of time."
It's good to know that Aurora will try. It's not like it needs to be reliable or anything.
It's good to know that Aurora will try. It's not like it needs to be reliable or anything.
And, really, all of this is just servers in a datacenter, so you can have however many 9's of reliability, and still be That Guy that wins the fail lottery.
"Reliable" isn't a binary concept. There's no service that is 100% reliable.
Having a solution that works 99.99% of the time (which is "only" four nines) is probably good enough that people are willing to use it as a last-resort. (From what it seems, it's included for free, so it's not like this costs you anything anyway - at worst, you end up where you would be if they hadn't released this).
1. Writes to fail and your production service goes down because you couldn't guarantee Backtrack.
2. Your service stays up and you lose some amount of emergency undo ability.
https://www.allthingsdistributed.com/files/p1041-verbitski.p...
And the docs
There are actually two backup/restore methods.
1) Point In Time - streamed to S3. Guaranteed restore to a new cluster with less than 5 minutes data loss
2) Aurora Backtrack - On cluster buffer, up to 24 hours retention (no guarantee). "Instant" restore to the same cluster
So you should feel safe using the service (up to the 5 minute worst case scenario).
Obviously no one would ever want to use either backup method. However previously disaster recovery would involve spinning up a new cluster, deploying application changes with the new endpoint (or in a best case repointing a dns entry), waiting for the cache to warm up again. Now it becomes a 1 click fix through the UI with no application changes.