The only recovery copy of an application is a nightly backup. Nothing is running at the second site until that backup is restored, and the rebuild takes a full day. The business wants the service back the same morning. Which disaster-recovery pattern is this, and why does it miss that recovery time?
Select an answer to reveal the explanation.
Short Explanation
You have a spare set of blueprints in a drawer and an empty lot: with backup and restore, nothing runs at the second site until you restore the nightly backup and complete the day-long rebuild. Pilot light keeps the core data tier running, warm standby keeps a reduced stack running, and active/active has both sites serving production, so none matches your empty second site.
Full Explanation
Backup and restore is the right pattern because you keep a copy—the nightly backup—but build the environment only after a failure. Nothing runs at the second site until restoration begins, and the rebuild takes a full day, so you cannot meet the business’s same-morning recovery target. The long wait is inherent in this setup: service recovery must wait for the restore and rebuild. Pilot light does not fit because its core data tier is already running before failover, with the application launched when failover is declared; your second site has no running core tier. Warm standby does not fit because a reduced copy of the stack is already running and is scaled up to carry production; there is no reduced running copy here. Active/active does not fit because both sites already serve production traffic, allowing recovery through a traffic shift; your second site cannot serve traffic before restoration and rebuilding. Exam caveat: a warmer pattern requires keeping something running at the second site before a failure; taking the nightly backup more often does not, by itself, change the recovery pattern. Practical check: identify what is actually running at the second site before a failure, and confirm that nothing is running until the restore job starts.