A backup you can restore: testing recovery with real checks

“Backup completed” reports one stage of a process. Before depending on that copy, you still need to know whether you can find it, access it and recover the required version in a usable form. A restoration exercise turns that expectation into an observable result.

We will do this with a fictional text file: preserve one version, change only the working file, restore the preserved version into another folder and verify its content. The exercise keeps the originals intact and produces a short record against criteria defined beforehand.

How a copy can fail alongside the original

In a ransomware incident, an attacker may locate accessible backups and delete or encrypt them. The joint CISA/FBI/NSA/MS-ISAC guide recommends offline, encrypted backups and regular availability and integrity tests. It also warns about synchronization propagating changed files to cloud copies.^[1]

The underlying issue is a shared dependency: original and copy may rely on the same account, storage device or failure condition. Ask both “where is the backup?” and “what will still let me reach it if the primary environment fails?”.

Synchronization and version history are different capabilities. In our example, if an update replaces the only preserved copy, the earlier version is no longer available through that path. Check the behavior of your chosen product; “cloud” does not describe its retention or recovery policy.

Define what returning to operation means

Two objectives help describe the requirement:

These are objectives based on needs, not automatic properties of backup software. If the latest recoverable version is two hours old, the example’s one-hour RPO has not been met. If copying is fast but nobody can open the file, useful recovery is still incomplete.

For a business, defining these goals involves process owners, priorities, applications and dependencies. In the lab below, you will check a single text file. What you observe in that exercise does not demonstrate restoration of a database or an entire computer.

Prepare the lab

To practice, use Windows with PowerShell, File Explorer and a text editor. You will keep track of each copy in separate folders. Create a new folder called ctw-restore-lab, outside working folders and automatic synchronization. Inside it, create work and restored.

On a removable drive you own, create a new CTW-LAB folder with a backup subfolder. Do not format the drive or replace existing folders. If you have only one disk, use a third local folder and record that the exercise tests the logical procedure, without testing survival of that disk’s failure.

Use fictional data exclusively. A USB folder does not itself implement encryption, retention or access protection; those controls need separate selection and testing before storing real data.

In your editor, save order.txt inside work with this content:

VERSION A
Items: 3
Status: checked

Show file extensions in File Explorer to ensure the name has not become order.txt.txt. Open PowerShell in the ctw-restore-lab folder. The commands below only read files and compare values; adapt paths where indicated.

Preserve a reference before changing anything

1. Open the working file. Check the three lines and close the editor. Record that this is version A, the version you intend to recover.
2. Calculate the content reference. Run:

$ctwReferenceHash = (Get-FileHash -LiteralPath '.\work\order.txt' -Algorithm SHA256).Hash
$ctwReferenceHash

Get-FileHash calculates a digest of the content. We use SHA-256 to compare the file before and after; its filename alone is insufficient.^[4] Save the value in your record and keep this PowerShell session open throughout the exercise.

3. Copy rather than move. Using File Explorer, copy order.txt to the backup folder on your test drive. Open the copy and check its lines.
4. Check the preserved copy. This example uses drive E:; replace the path with the actual path you just verified:

(Get-FileHash -LiteralPath 'E:\CTW-LAB\backup\order.txt' -Algorithm SHA256).Hash -eq $ctwReferenceHash

The expected result is True. If an error occurs or the result is False, stop and check the path and content before continuing. Once correct, eject the drive through the operating system. Do not depend on a copy you have not checked.

Restore without overwriting current work

1. Create a controlled difference. Edit only work\order.txt, replacing VERSION A with VERSION B and Items: 3 with Items: 4. Save and close the editor. This represents work performed after the backup, not simulated malware.
2. Start recording time. Note when you begin looking for version A. Reconnect the test drive and locate the preserved copy.
3. Recover to a separate destination. Copy the file from backup to ctw-restore-lab\restored. The working folder retains version B.
4. Verify the restored content. Open restored\order.txt and check for VERSION A, three items and the status. Close the editor and run:

(Get-FileHash -LiteralPath '.\restored\order.txt' -Algorithm SHA256).Hash -eq $ctwReferenceHash

5. Complete the functional check. The expected result is True, and version A should be readable in the editor. Record the finishing time, copy location, recovered version and any difficulty. Count the time spent locating, copying and verifying the file. If you did not track the duration, record “not measured” and time a future attempt so that you can compare.

Compare expectations and results

This table is illustrative, with no real measurements or guaranteed outcomes. Fill the observation column with your own exercise results.

Interpret failures before repeating

The hash differs: confirm the folder, version and whether the editor saved a change. Do not automatically copy the working file over the backup; that could replace the version you intended to recover.

The command cannot find the file: check the extension, drive letter and path. A read error is an incomplete test, not a successful comparison.

The variable disappeared: if you closed PowerShell, retrieve the reference recorded before the modification. Do not calculate a new reference from version B and then call it version A.

The content matches but the file will not open: check the application and permissions. Matching hashes do not test the operating environment, provenance or absence of malware; they support a content comparison against the chosen reference.

Close the exercise and improve the plan

Eject the drive, leave version B intact and remove only the fictional lab folders when you no longer need them. Record untested dependencies, such as recovery without the original computer, key availability or application restoration.

A restoration during an actual incident must also avoid reinfecting recovered systems.^[1] This exercise is preparation in a known environment, not a complete ransomware response procedure. To explore another common recovery dependency, read about accounts, sessions and permissions.

References

1. CISA; FBI; NSA; MS-ISAC. #StopRansomware Guide. Version 3.0, October 2023. Part 1, “Preparing for Ransomware and Data Extortion Incidents”; part 2, step 19. Source. Accessed 17 October 2026. ↩ ↩²

2. NIST. Recovery Point Objective — CSRC Glossary. Definition attributed to SP 800-34 Rev. 1. Source. Accessed 17 October 2026. ↩

3. NIST. Recovery Time Objective — CSRC Glossary. Definition attributed to SP 800-34 Rev. 1. Source. Accessed 17 October 2026. ↩

4. MICROSOFT. Get-FileHash. Windows PowerShell 5.1 documentation. Description, LiteralPath parameter and comparison examples. Source. Accessed 17 October 2026. ↩