Data Recovery & System Continuity

Continuity opens from a plain assumption: everything above will stop one day. A disk fails, the volume housing the cabinets takes on water, an update leaves a database inconsistent, a user deletes the wrong folder. The design settles not whether this happens but how far back it puts things, and how long the return takes.

Two questions give the measure. The first is acceptable data loss — the gap between the last copy and the moment of failure. The second is acceptable downtime — how long getting from that copy to a working service takes. Together these answers fix backup frequency, retention method and whether a second site is needed; tighten one and the other's cost moves.

A copy is not a recovery

The existence of a backup does not show the service returns. Until a restore has been tried, what is in hand is only a file whose readability is learned at the moment of need. A recovery rehearsal ends that uncertainty: it measures that the data reads, that the application comes up on it, and how long that takes. Downtime quoted without a rehearsal is an estimate, not a measurement.

Where the copy sits belongs to the design. A second disk in the same volume does not survive a fire; a second server reachable over the same network does not survive ransomware. One copy is therefore held at a separate site, in a form that cannot be altered once written. Retention follows how long an incident takes to surface, since a record corrupted weeks ago is put right only by a copy reaching that far back.

Continuity is not limited to data. A UPS covers the gap until the generator picks up; if configuration files, licences and network definitions went unbacked, no replacement hardware brings the service back. Where nobody wrote down who does what in which order, downtime runs far above the figure calculated.