Backups are not a failover plan

A backup restored in another region does bring the service back, but slowly, and with data only as fresh as the last backup.

GitHub's MySQL backups ran every four hours, and restoring multiple terabytes during its 2018 incident took hours, mostly spent transferring, decompressing, checking and loading files onto new servers. That is a legitimate plan with a large RTO and RPO, and a different claim from tolerating an outage (RTO and RPO name the two costs of an outage).

AWS adds that restoring from backup is a control-plane operation, and suggests restoring on a schedule so a usable copy exists even if that operation is unavailable when needed (Control planes fail differently from data planes).

The reverse holds too. Replication is not a backup: a bug that deletes the wrong data is carried to every copy (Replication copies your mistakes too). Only a copy from before the mistake helps, so a design needs both and should say which failure each covers.

Backups belong somewhere isolated from production, such as a separate account, and count only once restored. A backup nobody has restored is in the same position as a failover nobody has run: Test the failover or you have not got one.