A ledger application must be able to recover recent writes. Its only backup is a snapshot taken once a day, and that misses the recovery point the application requires. What should change?
Select an answer to reveal the explanation.
Short Explanation
A photo taken once a day cannot show you the ledger lines written after the shutter clicked. You shorten the backup interval or turn on point-in-time restore so recent writes can be recovered. Multi-AZ and a read replica keep a current copy, and they do not replace a backup of those writes.
Full Explanation
A snapshot taken once a day can restore only that daily point, so writes made after the snapshot are gone if the database is lost or damaged. That misses a recovery point measured in recent writes. Taking snapshots more often shortens the gap, and point-in-time restore, from automated backups, can recover to a recent time within the backup window instead of only to last night's snapshot. Keeping the daily snapshot and restoring yesterday's copy accepts the miss. It does not recover the recent writes. Multi-AZ maintains a current standby for failover. A bad change or a dropped table is on the standby too, and failover does not return an earlier copy of the ledger. A read replica is also a current copy. Promoting it gives you another current database, not a substitute for a backup of writes made since the daily snapshot. Caveat: point-in-time restore creates a new instance. It does not roll the existing instance backward in place. Operational check: after automated backups are enabled, confirm the latest restorable time advances, and test a restore to a new identifier that includes a write made after the daily snapshot.