Disaster recovery plan feature: testing

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

1. Which approach best shows that a disaster recovery plan will really work?

A Run a drill and do a test restore from a backup

B Write the plan down and file it away

2. Why should an organisation do a test restore of its backups?

A To confirm the backup files can actually be restored and are usable

B To make the backup files smaller to store

3. A drill reveals that staff did not know who to call during an outage. What should happen next?

A Fix the gap and update the plan's communication steps

B Ignore it because it was only a drill

4. True or false: A disaster recovery plan only needs to be tested once, when it is first written.

A True: once it passes, it never needs retesting

B False: it should be tested regularly

5. Which is a sign that a plan needs reviewing and updating?

A The plan has been stored in the same folder for a year

B The business has moved to a new cloud system since the last test

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left column		Right column
1Test restore		AA plan that is not tested regularly and updated becomes out of date as systems, staff and threats change.
2Recovery drill		BReview and update plan after test
3Testing shows whether the plan really works, so any gaps found must be fixed and the plan updated afterwards.		CTest time: 6 hrs, target: 4 hrs
4Recovery should be timed during a test to check it meets the organisation's recovery time objective.		DBackups can be corrupt, incomplete or unreadable. Without a test restore, the organisation does not know if recovery would work.
5Backups run every night, so we never need to test a restore.		EA practice run where staff follow the disaster recovery plan steps as if a real incident had happened.
6Plan written in 2019. Tested once. Never updated.		FRestoring a backup to a separate system to prove the data can be recovered and is complete and usable.

Definitions

Testing a recovery plan

Fill in the Blanks

Complete each line of code by filling in the missing parts.

result ← ____________(backup) IF result = FAIL THEN fix_gaps(plan)

__ result = FAIL THEN fix_gaps(plan) END IF

________ ← run_drill(plan) update_plan(plan, findings)

___ EACH backup IN backups test_restore(backup) END FOR

______ ← 0 run_drill(plan) drills ← drills + 1

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A backup ← latest_backup()

B restore(backup, live_server)

C IF files_match() THEN

D result ← PASS

Question 2

A drill ← new_drill(plan)

B run(drill)

C log ← delete_results(drill)

D review(log)

Question 3

A rto ← 4

B taken ← run_test_restore()

C IF taken > rto THEN

D mark_plan_as_passed()

Question 4

A gaps ← run_drill(plan)

B FOR each gap IN plan

C update_plan(gap)

D version ← version + 1

Question 5

A test_date ← today()

B next ← test_date + 10 YEARS

C schedule(next)

Answer Key

Disaster recovery plan feature: testing

Section A: Quick Questions

A — Run a drill and do a test restore from a backup

A — To confirm the backup files can actually be restored and are usable

A — Fix the gap and update the plan's communication steps

B — False: it should be tested regularly

B — The business has moved to a new cloud system since the last test

Section B: Match the Pairs

Test restore → Restoring a backup to a separate system to prove the data can be recovered and is complete and usable.

Recovery drill → A practice run where staff follow the disaster recovery plan steps as if a real incident had happened.

Testing shows whether the plan really works, so any gaps found must be fixed and the plan updated afterwards. → Review and update plan after test

Recovery should be timed during a test to check it meets the organisation's recovery time objective. → Test time: 6 hrs, target: 4 hrs

Backups run every night, so we never need to test a restore. → Backups can be corrupt, incomplete or unreadable. Without a test restore, the organisation does not know if recovery would work.

Plan written in 2019. Tested once. Never updated. → A plan that is not tested regularly and updated becomes out of date as systems, staff and threats change.

Section C: Definitions

Testing a recovery plan — Running drills and test restores to check a disaster recovery plan really works, then fixing any gaps found and updating the plan.

Section D: Fill in the Blanks

result ← test_restore(backup)
IF result = FAIL THEN
  fix_gaps(plan)

IF result = FAIL THEN
  fix_gaps(plan)
END IF

findings ← run_drill(plan)
update_plan(plan, findings)

FOR EACH backup IN backups
  test_restore(backup)
END FOR

drills ← 0
run_drill(plan)
drills ← drills + 1

Section E: Spot the Error

B — A test restore should go to a separate test server. Restoring onto the live server could overwrite real data. It should be restore(backup, test_server).

C — The drill results must be recorded so the team can see what failed and fix it. Deleting them wastes the test. It should be record_results(drill).

D — The restore took longer than the target time (rto), so the test shows a weakness. The plan must be flagged as too slow, not marked as passed.

B — The loop must go through the gaps found in the drill, so each one can be fixed in the plan. It should be FOR each gap IN gaps.

B — A recovery plan should be tested regularly, such as every 12 months. Waiting 10 years means problems stay hidden and the plan goes out of date.