Every other repair guide starts with the scan. This one starts earlier - with the step that decides whether a failed repair is an inconvenience or a disaster.
ScanPST is not a viewer; it is a surgeon that cuts. When it repairs, it rewrites your PST file in place and discards every item it cannot fit back into the structure. On a healthy copy that is exactly what you want. On your only copy, one bad pass can permanently delete mail that a different approach would have saved. The rule is absolute and takes three minutes: ScanPST never meets the original file. Here is the routine that enforces it.
A PST stores mail in a tree of internal tables. Corruption means some of those tables point at data that no longer lines up - and ScanPST's repair strategy is to rebuild the tree and drop whatever cannot be reattached. Dropped items are not quarantined; they are gone from that file. Worse, a repair on a severely damaged file can occasionally leave it in a state Outlook likes even less than before.
None of this makes ScanPST a bad tool. It makes it a tool whose work must happen on a file you can afford to lose - because you still hold the original.
A sloppy copy made while Outlook still holds the file open can itself be corrupt, so the order matters:
OUTLOOK.EXE has exited - a PST being written to does not copy cleanlyC:\Users\YourName\Documents\Outlook Files or the AppData Local folder)ScanPST has its own seatbelt, and it is off the obvious path. After a scan finds errors, the repair dialog offers a checkbox: Make backup of scanned file before repairing. Tick it every single time.
With it ticked, ScanPST first saves the working copy's current state as a file with the same name and a .bak extension, in the same folder. If that pass makes things worse, renaming a copy of the .bak back to .pst restores the pre-pass state. Understand the layering: your Explorer copy protects you from everything; the .bak protects you from the last pass only.
By the second pass your folder holds four relatives and mistakes get easy:
If names blur together, rename the working copy with the date in it. Five seconds of naming discipline beats an hour of archaeology.
Only promote the repaired copy to daily duty after it earns it:
Even then, keep the original somewhere cold for a few days. Disk space is cheap; a mailbox is not.
See the copy and repair done on a live file in the video, then follow the same discipline on yours.
Watch Full VideoRoughly, yes - the copy is a full duplicate, ideally on a different drive. If the system drive is nearly full, use an external drive for the copy. That fullness may itself be part of how the file got corrupted, so freeing space is repair work too, not just housekeeping.
No. The .bak is the state of the working copy just before that one repair pass. Your separate File Explorer copy is the untouched original. Both matter: the .bak rolls back a single pass, the original rolls back everything.
Renaming does not protect the contents - ScanPST rewrites whichever file you point it at, whatever its name. Work on a duplicate file, not on a renamed original.