Unit 11: Backups and recovery · Lesson 4 of 4 · 22 min
Case file: running a restore drill
A shipping giant rebuilt thousands of servers in days. Drill a full restore of the web root and write the report.
mission
- You are
- You are running web01's first restore drill.
- Situation
- Nobody has ever restored the web root. You restore the last clean snapshot in full and check every file.
- Goal
- Restore, verify against the baseline and record the gaps you found.
- Hand in
- A drill report in ~/drill.txt.
case file
Maersk and NotPetya
A.P. Moller-Maersk · 2017
In June 2017 the destructive NotPetya malware, spread initially through a compromised update of Ukrainian tax software, tore through networks worldwide and crippled shipping giant Maersk. Maersk reinstalled about 4,000 servers, 45,000 PCs and 2,500 applications in roughly ten days while running much of its business manually. The company estimated losses of $250 million to $300 million, and its chairman described its prior security as 'basically average'.
What went wrong
A flat, highly connected Windows network where self-propagating malware could spread rapidly, combined with dependence on systems that had to be rebuilt from scratch.
What would have stopped it
- Segment networks so that a compromise in one country or business unit cannot spread globally.
- Maintain offline/immutable backups of critical systems, including identity infrastructure such as domain controllers, and test full rebuilds.
- Patch SMB vulnerabilities and restrict administrative credential reuse to limit lateral movement.
- Practice manual business continuity procedures for a total IT outage.
What defenders could have seen
- Sudden spike in SMB connections and remote service creation across many hosts.
- Mass endpoint alerts for disk-encryption or MBR-modification behavior.
- Credential-dumping tool detections followed by rapid lateral logons.
sourcessecurityweek.comitpro.com
A restore drill
- Restore everythingFrom the last clean snapshot
- Verify every fileAgainst the baseline
- Note the gapsWhat came back that should not, what did not come back
- Write it downDate, time taken, fixes
Restore everything
export RESTIC_REPOSITORY=/srv/backup/restic-web RESTIC_PASSWORD_FILE=/srv/backup/.restic-pass restic restore --no-lock --no-cache 47b49379 --target ~/drill 2>&1 | tail -n 1 Summary: Restored 12 files/dirs (545 B) in 0:00
you should see Every file from the 13 October snapshot.
Verify every file
cd ~/drill/var/www/html && sha256sum -c /srv/baseline/www.sha256
./.git/config: OK
./assets/css/site.css: OK
./assets/js/app.js: OK
./index.html: OK
./robots.txt: OK
you should see Every file matches the baseline, index.html included.
Spot what should not be there
A drill also shows what your backups include that they should not, and what they miss.
ls -a ~/drill/var/www/html . .. .git assets index.html robots.txt du -sh ~/drill/var/www/html/assets/site-backup.tar.gz 2>/dev/null || echo 'site-backup.tar.gz not in backup' site-backup.tar.gz not in backup
you should see The exposed .git folder came back too. The big site backup archive was never in the snapshots.
Write the report
printf 'Drill 2026-10-22\nsnapshot: 47b49379\nresult: restored, all baseline hashes OK\ngaps: no runbook, .git restored into web root, app config not backed up\n' > ~/drill.txt cat ~/drill.txt Drill 2026-10-22 snapshot: 47b49379 result: restored, all baseline hashes OK gaps: no runbook, .git restored into web root, app config not backed up
you should see Short, dated and honest about the gaps.
defender tip Time every drill. The number you can promise the business is the slowest drill, not the plan.
What a defender takes away
- 1Restore fully, on a schedule, and verify.
- 2A drill finds gaps a review cannot.
- 3Write down the time it took; that is your real recovery time.
Questions
0 of 2 solved
Answer each one from what you find on your lab machine.