Recovering data after a power cut or a corrupted recording

Three things that are all called "corrupted"

Before anything technical, it is worth separating three situations that get the same word and need very different answers.

1. The session was never closed. Power disappeared while the recorder was writing. The data is on the medium; what is missing is the structure that says where it is.
2. The medium is physically damaged. Fire, crush, immersion, or simply age. Some of it is readable and some of it is not, and no software changes that ratio.
3. The structure is corrupted. Blocks are present but the map is wrong — a bad write, a controller fault, a file system that was interrupted mid-update.

The first is the common one and the most recoverable. The third is rarer and usually recoverable too. The second is the one where the answer depends on physics rather than on software, and where the honest report is a percentage.

Why an unclosed file is not a lost file

When a recorder loses power mid-flight, the last thing it did not do is close the file: write the final index, update the directory entry, mark the session complete. Everything it did before that is still on the medium, exactly as written.

Whether that matters depends entirely on the container. If the recording is a sequence of self-contained blocks, each carrying a synchronisation pattern, its own length, its own channel and its own date, then the file structure was never load-bearing: it was a convenience. Rebuilding it is a matter of scanning the medium and reading what is there.

If instead the format put its index at the end, or only became valid on a clean close, the same power cut destroys a recording that is physically intact. The data is present and unreachable, which is the most frustrating failure in the whole field.

How a low-level scan rebuilds a recording

Recovery software does not open the file. It reads the medium sector by sector, ignores the file system entirely, and searches the raw bytes for the block synchronisation pattern.

Each candidate is then validated rather than trusted: does the header parse, do the declared lengths point at a plausible next block, does the channel number exist in the setup record, does the checksum pass, is the date consistent with its neighbours? A block that fails is discarded; a block that passes is a fact.

This is where the length of the synchronisation pattern stops being an academic detail. A sixteen-bit pattern occurs by chance roughly every sixty-five thousand bytes of random data, so a scan produces thousands of false candidates that validation has to reject. A pattern several words long essentially never occurs by accident, and the scan becomes reliable rather than statistical.

With the valid blocks in hand, the timeline reassembles itself: each block knows its channel, its sequence number and its date, so the recording can be rebuilt in order, with the gaps where blocks are missing — and those gaps are documented rather than smoothed over.

What the container makes possible

• A per-block date means the timeline survives even when a third of the blocks do not. Without it, a gap desynchronises everything after it.
• A per-channel sequence counter means you can prove what is missing, not just suspect it. That number belongs in the recovery report.
• A checksum means a recovered block is either good or rejected, rather than good-looking.
• An index that is written progressively rather than at the end means the scan has a head start.
• And encryption means the recovery needs the key. If the key management was casual, the recovery ends there — which is a decision made at configuration time, not at recovery time.

A damaged medium: what comes back

A crash-protected module that has been through the qualification sequence is designed so that the memory dies survive. Recovering from one is a laboratory operation: the module is opened, the dies are read directly if the interface no longer works, and the raw contents are imaged before anything else happens.

From there it is the same scan, with a worse input. Some regions are unreadable, and the result is partial by nature. That is not a failure of the method: an investigation is usually interested in the last minutes, and the last minutes are the blocks most likely to be intact because they were written last and never overwritten.

The honest limits

It is worth being explicit about what does not come back, because optimism here wastes weeks.

• An overwritten block is gone. If the medium wrapped around and rewrote the beginning, the beginning does not exist.
• A medium that was cryptographically erased is gone, deliberately and completely. That is the feature working.
• A destroyed die is gone. Physical destruction is not a software problem.
• And a recording with twelve percent of its blocks missing is a recording with twelve percent missing. Recovery restores what was written; it does not interpolate, and a tool that quietly filled the gaps would be worse than one that reports them.

Which is why the deliverable of a recovery is two things and not one: a file, and a report of what is not in it.

How not to need any of this

Most recoveries trace back to a decision that could have been taken earlier, and none of them is expensive.

1. Choose a container built from self-contained, self-dating blocks. This is the single decision that determines whether a power cut costs you seconds or everything.
2. Keep the write path short — small buffers, frequent commits — so the amount in flight when power disappears is a fraction of a second.
3. Specify a medium with power-loss protection, so a block being written is not corrupted on the way down.
4. Run the post-flight integrity check before the aircraft flies again, so a truncated file is found while it can still be re-flown rather than three weeks later.
5. And download. A recording still on the medium is a recording exposed to the next sortie.