6.6.5 Recoverability measures

What this heading covers

Recovery has two dimensions: time and data. A service can return in seconds and lose an hour of transactions, and the measure has to say which objective was met. The recovery point objective and the recovery time objective belong in the definition, and so does the scenario: a restart is not the same as a restore from backup. The measure should be taken from an exercise, because a backup that has never been restored is a hope.

Record position: family 20 of 40 in clause 6, under 6.6 Reliability, which carries 4 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.6.5 in the public contents; the text behind it is not public.

How a measure for this family is built

Compare the observed recovery time with the recovery time objective, and the observed data loss with the recovery point objective. Count exercises that met both as the numerator over the exercises run. Record the scenario, the operator and whether the exercise was announced.

What to put in place before publication

1. Run a restore exercise, not only a backup job check.
2. Record the data loss, in records or in time, not only the service return.

Evidence to keep

Two questions to ask

• What are the recovery time and recovery point objectives for this scenario?
• Was this a real restore, and how much data was lost?

Where teams usually fall short

• A backup success report presented as recoverability evidence.

What the number cannot tell you

It cannot tell you whether the backup is complete. A restore that meets the time objective can still lose data the objective allowed.

What happens next

The security families come next, and they share the operational evidence base with reliability.