Recovery Copies: Source, Image, Working Copy and Destination
These roles stay distinct even when the files all sit on the same healthy storage. The source keeps its original state; the acquisition master is the best readable representation obtained so far, together with its map and log; a working copy is a controlled, disposable experiment; the export destination holds extracted objects. The number of physical drives involved doesn't have to equal the number of roles — what matters is which role can be recreated and which can't.
- Source, acquisition master, working copy and destination are separate roles with different rules.
- Protect the master from auto-mount, writes and log replay; record its hash once it is closed.
- A full duplicate is logically independent; shared storage still shares failure risks. Overlays depend on their backing master.
- Keep each copy's map, log, offsets and dependencies together with that copy.
- Plan storage space and keep every experiment in its own identifiable work area.
Four roles, with different permissions and lifetimes
The source is the device or storage object recovery is trying to preserve. An acquisition in progress may update previously unresolved ranges as further reads succeed; its output and map remain changing artifacts until a coherent version is closed and recorded as a master. A working copy is a controlled space for analysis or repair experiments. The recovered-file destination holds extracted objects, separate from all of the above. Four roles don't require four physical drives, and a closed master isn't the same state as an ongoing acquisition that happens to be using the same output file — closing a master records a documented version, complete or partial, not a claim that every file on it has been verified.
Scroll horizontally to see the full diagram →
Scroll horizontally to see the full table →
| Object | May change? | Typical protection | Depends on | What verifies it |
|---|---|---|---|---|
| Original device | Should not, once preservation begins | Write-blocking or an equivalent controlled access path | Starting source; its access may depend on controller, bridge or keys | Its own identifiers and reported state |
| Ongoing acquisition output | Yes, legitimately, while resuming | Access limited to the acquisition tool itself | The original device, for as long as it's still being read | Progress and map state at a given point in time, not a final hash |
| Closed master | No, once closed | Access policy against auto-mount, write or replay; recorded hash/version | The acquisition that produced it | Its recorded hash and version, checked against the same documented scope |
| Full duplicate | Only if deliberately written to | Same access discipline as a master, if it's meant to stand in for one | Nothing at the logical file level, once made | A completeness check against the master it was copied from |
| Overlay | Yes, by design — that's its purpose | Isolation of writes to the overlay layer only, if the tool guarantees it | Its backing master; not independent of it | That the base remains unmodified underneath it |
| Recovered files | Not after export, ideally | Ordinary file permissions on healthy destination storage | The copy or master is its provenance, not necessarily a runtime dependency of the already-exported file; an application object may have its own separate dependencies | Content or application-level checks appropriate to the file type |
| Maps / manifests | Only together with the output they describe | Kept paired with their exact output version | The specific acquisition generation they document | Consistency against the output they're paired with |
Protect the master, not just the original device
Once a master is closed, protect it with an access policy that avoids automatic mounting, writing or log replay against it, and record its hash and version once closed, including the maps and logs that belong with it. A read-only attribute on a file or volume is not a whole-system guarantee against every write path — name a specific filesystem, tool and version for any concrete read-only recipe rather than assuming one universal mount command excludes all writes and replay. Analysis may read the master directly only where that access is genuinely protected from writes; anything that needs to write stays on a separate, writable copy.
A full duplicate and an overlay solve different problems
A full duplicate is independent at the logical file level once made; a copy-on-write overlay (see qemu-img's backing-file chain documentation) depends on its backing master and is not independent of it. A snapshot kept on the same storage as its source is not an independent backup. A hard link is the same underlying file object, not a working duplicate at all. A filesystem-level copy-on-write clone or reflink can isolate logical edits from the original, but it still shares the same device and fault domain as what it was cloned from — it should not be marketed as an independent preservation copy.
Scroll horizontally to see the full table →
| Arrangement | Useful for | Remaining risk | Redundancy? |
|---|---|---|---|
| Separate directories on the same disk | Keeping roles organized and easy to find | One disk failure affects every role on it | No |
| Full duplicate on the same disk | A disposable copy for one experiment at a time | Same single point of failure as the master it duplicates | No, against disk failure |
| Verified duplicate on independent storage | Protecting against loss of the original disk holding the master | Doesn't cover every administrative, ransomware or shared-power-event risk | Yes, against that specific shared-device risk |
| Overlay on its master | Reversible, low-overhead experimentation | Entirely dependent on the master; not a backup of it | No |
| Snapshot on the same storage | A quick rollback point for minor, same-session mistakes | Shares the same storage fate as what it snapshots | No |
Keep acquisition maps and dependencies with the right copy
Keep each copy's map, log and configuration, its scope and offset information, its acquisition version, any virtual-machine parent chain it depends on, and its encryption metadata together with that copy. Key material itself should be protected separately; a manifest can reference where it's kept without recording the secret itself.
Plan space and destinations before experiments
Before starting, account for logical byte size versus the actual allocated size on sparse or compressed storage, the master itself, a potential full duplicate or a bounded overlay, exported data, logs, and a reserve margin. There is no universal rule that a working copy needs twice the master's size — sparse and overlay storage can grow unpredictably as an experiment proceeds, and nothing here guarantees an experiment stays within a few gigabytes. Hashing a readable master is additional load placed on healthy destination storage; it is not a requirement to reread a failing original. Physical-clone capacity and file-image storage behave differently and shouldn't be planned as if they were the same thing.
As an illustration only, with dummy identifiers rather than any real case:
Scroll horizontally to see the full table →
| Path | Role |
|---|---|
| case-001/acquisition/source-A.img | Closed acquisition master |
| case-001/acquisition/source-A.map | Acquisition map for that master |
| case-001/acquisition/manifest.md | Scope, offsets and acquisition details |
| case-001/work/experiment-01/ | Writable duplicate or overlay for one experiment |
| case-001/output/ | Extracted, recovered files |
| case-001/checks/ | Validation reports |
A directory layout like this is a convenience for keeping track of roles — it is not a security control by itself. If an image depends on a parent chain (as a virtual-disk image can), list those parents and their immutable paths explicitly rather than assuming the layout alone documents the dependency.
Make experiments reversible and identifiable
Keep each experiment in its own separate work area, and record what changed. Restoring from a failed experiment normally means discarding that work area and recreating it from the protected master — not assuming a repair tool has its own working undo. A protected base plus a disposable overlay is reversible as a local experiment only if the tool genuinely writes solely to the overlay; a commit, merge, rebase or flatten operation is a separate write or derivation step, and none of them should modify the sole base as part of what's called a "rollback." Effects outside the experiment itself — such as an application writing elsewhere during a test — are not undone simply by deleting the overlay.
Verify copies and recovered files for different reasons
A hash confirming that two files are the same artifact is a different check from confirming guest-visible equivalence across two different container formats or representations — the first is an identity check, the second is a behavioral or content check, and neither establishes that the original source was completely captured. Keep the read/coverage map as a separate piece of evidence from any hash. Checking recovered files means checking against the content or application requirements that actually matter for that file type, not just confirming that export completed without an error. A simple sample check does not prove a full byte-for-byte match; a claim of "verified byte-for-byte duplicate" needs a correspondingly complete check across the healthy copies involved, with its scope stated plainly — and none of this requires rehashing a failing original.
Retain what cannot safely be reacquired
A degraded original, a source that's no longer available, or a master that was costly to obtain are all reasons an independent, verified replica can be justified, on storage separate from the master. Keep whatever candidate or working versions are actually needed to explain a result, and only discard a temporary copy once the required result and its dependencies are safely retained elsewhere.
The four training scenarios below work through specific copy-management situations in more detail.
Training scenario: an NTFS repair experiment changed directory entries
A repair utility run against a working copy modified directory entries in ways that weren't fully anticipated.
This is exactly what a disposable working copy is for — the repair's outcome does not change the protected master underneath it.
Close and retain whatever useful results came from the repair; discard the affected working copy; recreate a fresh working copy from the protected master if further experiments are needed.
Validate the master's identity (its recorded hash) and the specific outputs kept from the experiment, separately from each other.
Training scenario: a VM overlay was copied without its parent
A virtual-machine overlay file was copied for analysis, but its parent (backing) disk was left behind.
The overlay file being present does not mean the dataset is complete — an overlay without its parent chain is not a usable, self-sufficient copy.
Preserve and copy the full referenced parent chain together with the overlay; test the guest-visible data on an isolated copy of the whole chain.
Confirm the chain opens and behaves as expected on the isolated copy before relying on it; never merge any changes back into the sole master as a shortcut.
Training scenario: the master and its duplicate share one physical drive
A master image and its full duplicate both live on the same physical drive, for convenience.
Accidental edits to the duplicate are reversible by recreating it from the master, but a failure of that one physical drive loses both copies at once — the duplicate adds no protection against that specific risk.
Where the source can no longer be reacquired, create a verified, independent replica on genuinely separate storage, not just a second file on the same drive.
Verify the replica as its own artifact copy; this does not require rereading the original source, which may no longer be available or safe to read again.
Training scenario: a partial acquisition was resumed later
An interrupted acquisition was resumed in a later session; the output and its map both changed as a result.
The old hash, taken before the resume, is now obsolete for this output — it describes a previous, different generation of the same file.
Track versions explicitly; close a new coherent output/map pair once the resume is done; update the manifest and current hashes to match that closed pair.
Keep the historical record of the earlier, superseded generation only if it's actually needed to explain the case — but never present it as the current closed master.
Technical references: QEMU: qemu-img — backing-file chains and the caution around modifying or committing an active image, referenced in the overlay-dependency section; specific commands here should not be read as a generic recipe for every format and version, which should be checked individually. GNU ddrescue manual and the author's manpage, as packaged by Debian — resuming against a matching output/map pair, referenced in the ongoing-acquisition section; detailed semantics for edge cases can vary by version, so confirm them against the manual for the version in use.
Related: What a Disk Image Preserves — and What It Does Not · Disk Imaging vs. Cloning · Repair vs. Recovery · Write Blocking · Live Systems and Consistent Copies · How to Validate Recovered Data · Data Recovery Workflow: Source to Validation