Recovery methodsTechnical

PST and OST Internal Structure Recovery

PST and OST files are database containers built around two internal B-trees — repair can restore structural consistency by discarding whatever block it cannot read, so preservation and a server-state comparison belong before ScanPST ever runs.

PST recovery is database-structure recovery

Microsoft's own PST specification describes a Node Database (NDB) layer consisting of a header, file allocation information, blocks, nodes, a Node B-tree (NBT) and a Block B-tree (BBT). Reaching a message or folder means the NBT first indexes the logical node, which yields block IDs, and the BBT then locates the physical bytes of those blocks. PST recovery is database-structure recovery in a fairly literal sense — it is not generic email-file parsing, and treating it that way misses exactly the structures that actually determine what survives.

NBT and BBT answer genuinely different questions

The Node B-tree maps node IDs to logical node records and their parent relationships; the Block B-tree maps block IDs to the physical blocks that actually store bytes. A message or folder node existing in the NBT does not by itself guarantee its block IDs still resolve correctly in the BBT, and corruption in either tree independently can make otherwise-intact data completely unreachable.

Several logical layers sit above the raw NDB

Above the Node Database layer, the PST format also defines higher logical structures including the LTP layer, Heap-on-Node, Property Context, Table Context and the messaging-layer objects that actually represent folders and items. A message is not one record sitting at a single offset — it can involve node metadata, property structures, subnodes, several blocks, and separate attachment-related data, all held together by these higher layers. This is exactly why partial block loss can produce oddly specific symptoms: an attachment can disappear while its message survives, a message body can vanish while its headers remain, or a folder's index entry can be lost while the orphaned item underneath it is still technically present.

ScanPST prioritizes structural validity over preserving every message

Microsoft explicitly documents that ScanPST checks the B-trees and reference counts, that its low-level structural view does not understand message semantics, and that when a block is unreadable or corrupt, ScanPST can simply remove it — at which point whatever Outlook item depended on that block can disappear along with it. ScanPST's actual goal is a structurally valid PST, not maximum preservation of every damaged message; preserve an untouched copy of the file before ever running it.

A “successful” repair can still rearrange reachability

Microsoft documents that ScanPST can rebuild folder structures, place recovered orphaned folders or items into a generated recovery folder, and produce a .bak copy of prior content. A repair reported as successful can still change the folder hierarchy and which objects are actually reachable afterward — recovery assessment should compare the original file, the repaired copy, and any available server or archive sources side by side rather than trusting the repaired copy alone.

PST and OST carry very different recovery priority

A PST can be an archive, a POP3 mailbox's only local store, an exported mailbox, or otherwise the sole copy of its content anywhere. An OST is normally a local cache of a mailbox that actually lives on Exchange, Microsoft 365 or an IMAP server — so the recovery approach differs by design: a PST should be preserved as potentially authoritative from the start, while an OST should be preserved too, but only after first comparing it against the server's authoritative state.

“OST is cache” is a workflow default, not a rule without exceptions

Real edge cases can make an OST genuinely unique: unsynchronized drafts, locally cached items that were never actually uploaded, a deleted server-side mailbox, an inaccessible account, an old workstation carrying historical cached data no longer present anywhere else, or retention loss on the server side. “OST is cache” is a correct workflow principle for deciding priority, not permission to delete an OST before actually comparing it against server state.

Truncation is a storage problem, not a B-tree problem

A PST truncated partway through — a 20 GB file cut down to 8 GB, say — is not primarily a B-tree repair problem, even though it will present with similar-looking symptoms. Establishing the full expected file length, whether reads are stable, filesystem allocation state and timestamps, and whether truncation actually occurred should come before any structural repair attempt, since the underlying storage or filesystem layer may be the real point of failure.

Practical rule

Preserve a copy of the PST or OST before running ScanPST, and for a corrupted OST, check the server mailbox first — rebuilding a cache from an intact server is almost always safer than repairing the local file.