A disaster recovery plan lists twelve systems but gives no recovery order. During a test, the team restored the application servers first, and they failed because the authentication and DNS services and the database were not yet available. What should the DBA add to the plan?
Select an answer to reveal the explanation.
Short Explanation
Recovering systems out of order is like putting the roof on before the walls; it just falls in. You document dependencies and bring up the foundation, identity and name resolution, then the databases, then the apps that sit on them. Size and speed don't decide order; dependencies do.
Full Explanation
A disaster recovery plan must document recovery priorities and dependencies so systems come back in an order that works. Applications depend on databases, and nearly everything depends on foundational services such as authentication and name resolution. The plan should map these dependencies, often from the system design documentation and a business impact analysis, and specify a sequence: foundational infrastructure first, then data tiers, then application and presentation tiers, with checks at each stage. Restoring everything simultaneously ignores dependencies; systems that start before their prerequisites fail or need restarting, and parallel effort creates contention for the same people and networks. Ordering by size optimizes for duration rather than function; a large reporting database may be low priority, while a small identity service blocks everything. Restoring application servers first repeats the failure seen in the test, because those servers cannot authenticate users or reach their data until the services beneath them are running. Exam caveat: business priority decides which applications matter most, but technical dependencies decide the order needed to bring them up. Operational check: walk through the documented sequence in the next test and confirm each system's prerequisites are running and verified before it is started.