Business Continuity

A realistic pattern is a desktop walkthrough a few times a year and a technical failover at least annually, with any service that changed materially tested after the change. Frequency matters less than honesty. An exercise designed to succeed teaches you nothing; the useful ones surface a broken step.

Those are business decisions with a price attached, not technical defaults. Near-zero data loss and minutes of downtime are achievable and cost accordingly. Four hours costs a fraction of that. The workable method is to state what each level costs, let the service owner choose, and then design to the choice.

Backup is one part of recovery and the part most often mistaken for all of it. A backup tells you the data still exists. It does not tell you how long a restore takes, whether the target environment exists, or in what order services must return. Untested restores are the most common gap we find.

Not by itself, and assuming otherwise is dangerous, because replication faithfully copies encrypted data to the secondary site. That case needs immutable or otherwise isolated copies, with a retention window longer than the time it typically takes to notice an intrusion. It is a different design from availability replication, and both are usually needed.

That is precisely the question an exercise answers, and the answer is often at reduced capacity. A secondary sized for a subset of load is a legitimate choice when it is a stated one, because then the plan says which services get shed. The problem is a secondary assumed to be equal that has never carried full load.

A named role, with the authority written down in advance and a deputy for when that person is unreachable. The expensive delays in real incidents are usually decision delays rather than technical ones. The plan should also state what evidence triggers the call, so the threshold is not being invented while the clock runs.