← VCE Data Analytics U4O2

Disaster recovery plan feature: testing

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

Understanding Disaster recovery plan feature: testing in VCE Data Analytics U4O2

What it does: Reviewing and updating the plan turns test results into improvements, so the plan stays effective. Comparing the measured restore time with the target reveals that the plan is too slow and must be fixed. A plan only on paper is unproven. Drills and test restores show whether the steps and backups work in practice. A backup that has never been restored might be corrupt or incomplete. A test restore proves it can be used when needed. The point of testing is to find weaknesses. Each problem found should lead to a fix and an updated plan. Systems, staff and threats change over time. Regular testing keeps the plan accurate and effective.

Common mistakes: 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). 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).

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

This module's key terms are also in a printable crossword (Modules 80–113) and word search (Modules 44–113).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
Which approach best shows that a disaster recovery plan will really work?
Write the plan down and file it awayRun a drill and do a test restore from a backup
Matches
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.
Applying
Meanings
Term
Testing a recovery plan
Meaning
Running drills and test restores to check a disaster recovery plan really works, then fixing any gaps found and updating the plan.
Practice
backup ← "Monday_full"
Testing
Gaps
result ← (backup)
Check Answer
Spots
1backup ← latest_backup()
2restore(backup, live_server)

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Octopus' badge — Multi-Tasker, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Quick Questions

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
A plan only on paper is unproven. Drills and test restores show whether the steps and backups work in practice.
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
A backup that has never been restored might be corrupt or incomplete. A test restore proves it can be used when needed.
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
The point of testing is to find weaknesses. Each problem found should lead to a fix and an updated plan.
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 ✓
Systems, staff and threats change over time. Regular testing keeps the plan accurate and effective.
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 ✓
Changes to systems, data or staff can make a plan out of date. Storage location alone does not mean it is outdated.

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.

Key Term

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.

Fill in the Blanks

1. result ← test_restore(backup) IF result = FAIL THEN fix_gaps(plan)
Hint: Type the function name that tries to restore data from a backup to check it works.
2. IF result = FAIL THEN fix_gaps(plan) END IF
Hint: Type the keyword that starts a decision, so a failed test restore leads to fixing the plan.
3. findings ← run_drill(plan) update_plan(plan, findings)
Hint: Type the variable name that stores what the drill found, so the plan can be updated with it.
4. FOR EACH backup IN backups test_restore(backup) END FOR
Hint: Type the loop keyword that tests every backup in the list, not just one.
5. drills ← 0 run_drill(plan) drills ← drills + 1
Hint: Type the variable name that counts how many drills have been completed.

Spot the Error

Question 1
A backup ← latest_backup()
B restore(backup, live_server)
C IF files_match() THEN
D result ← PASS
Line 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).
Question 2
A drill ← new_drill(plan)
B run(drill)
C log ← delete_results(drill)
D review(log)
Line 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).
Question 3
A rto ← 4
B taken ← run_test_restore()
C IF taken > rto THEN
D mark_plan_as_passed()
Line 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.
Question 4
A gaps ← run_drill(plan)
B FOR each gap IN plan
C update_plan(gap)
D version ← version + 1
Line 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.
Question 5
A test_date ← today()
B next ← test_date + 10 YEARS
C schedule(next)
Line 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.

Student with a class code? Join your class →