Recover an Interrupted InDesign Treatment Without Replacing the Last Good File

An interrupted session hands you a second document, not a verdict. The recovered file may be better than what you saved, worse, or a mix of both, and nothing about its name or timestamp tells you which. So the job breaks into three moves: keep every original and every piece of recovery material where it is, save the recovered candidate as its own file, then compare that candidate against your last known good version item by item before anything becomes current.

That is the whole method. The rest of this article is about doing it without erasing the evidence you need, and about what to do when the comparison comes back short.

Define "last known good" before you need the phrase

The last known good file is the most recent version you saved and have actually opened and checked — not simply the newest thing on disk, and not the file you were midway through rewriting when the session died.

In practice this is usually a file with a version marker in its name and a saved date you can point to, plus, if you're careful, an exported PDF from that state. That export matters more than people expect. A PDF from a saved version gives you a fixed picture of page count, page order and text endings that doesn't move when someone edits a frame. It is a cheap reference, and it's the thing you'll compare against when a candidate looks plausible but you can't remember whether page 3 ended with one paragraph or two.

So the first productive act after an interruption is not opening anything. It's writing down five facts while you still remember them:

• Which file was open, and where it lives.
• When you last saved it.
• What changed after that save.
• Where the recovery material is, if you can see it.
• What time the interruption happened.

That list is the ledger you'll use later. Building it from memory ten minutes after the crash is easy. Reconstructing it tomorrow is guesswork.

Stop the actions that erase the evidence

Recovery goes wrong less often from a missing technical step than from a tidy reflex. Clearing caches, resetting preferences, emptying a recovery folder, deleting "duplicate" files with odd extensions, renaming things so the folder looks orderly — each of those is a reasonable-sounding cleanup that can remove the only copy of the thing you're trying to get back.

Recovery data is usually small. A copy costs you disk space. Deleting it costs you the material.

Two rules cover most of it. Do not delete anything you haven't copied first. And do not rename an uncertain file into a confident one: a recovered draft called final is a recovered draft with a misleading label, and the label will outlive your memory of why you chose it.

If you want more safety than that, copy the whole project folder to a second location before you troubleshoot. Then work in one copy and leave the other untouched.

Recovery data is not a backup

These two things get treated as synonyms and they are not.

Adobe's Recover documents page, updated June 2, 2026, describes automatic recovery as working from temporary data kept separately from the original file, producing a document that appears marked as recovered and that you then have to save yourself. The same page makes the boundary explicit: this is not a historical backup service. It's a rescue of an in-progress state, assembled from whatever happened to be captured.

A backup, by contrast, is a state you deliberately kept. It exists because someone decided that this version was worth holding onto, at a known moment, with a known name.

The difference changes how you weigh a candidate. A recovered document competes with your saved file as a possible current version; it does not outrank it. Recovery may well contain more work than the file you last saved — that's the point of it. But "may" is doing real work in that sentence, and the only way to convert it to "does" is to open the candidate and check.

Save the candidate as its own file

When a recovered document opens, resist the reflex to save it back over the original path. Use Save As and give it a name that says what it is and when it arrived:

Ridge_Treatment_v4_RECOVERED_2026-09-18.indd

Keep it in the project folder, or in a clearly named recovery subfolder inside it, so the candidate travels with the project and doesn't become an orphan on the desktop. Put the date in the name rather than "v5", "new" or "final" — a date records where the file came from, which is exactly what you're unsure about.

Alongside the file, record three lines somewhere you'll find them again: which file was open when the interruption happened, which file the candidate was derived from, and roughly when the interruption occurred. That note is what stops a week-old recovery folder from becoming a mystery.

One caution while you're here. Do not read the candidate's timestamp as evidence that it contains your most recent approved text, pages or links. Timestamps record when a file was written, not what a collaborator agreed to.

Compare content, not plausibility

A recovered treatment can look right on screen and still be missing a paragraph. The first page is one page of evidence.

Before opening the candidate, pull up the ledger you wrote at the start. Then work through checks that rule out different kinds of damage:

1. Page count and page order. A missing or duplicated page shows up fast. But a candidate can match page for page and still be missing a paragraph inside one of them, so this check can only fail loudly, never pass convincingly.
2. Text flow endings. Go to the end of the last substantial text frame and read the final sentence. Compare it with the ending you remember, or with the exported reference. This is the check that catches a truncated body.
3. Overset text. Look for text that doesn't fit its frame. Overset isn't always damage — it can be an unfinished layout choice — but a block of overset copy in a candidate is something to explain before you trust the file.
4. Linked files. Check the list of linked files and resolve whether anything is missing or pointing somewhere unexpected. Keep this separate in your mind from lost edits: a missing image is an asset problem with its own solution, and it does not mean your text is gone. The two get confused constantly, usually in whichever direction produces the most panic.
5. A representative export. Export a PDF and look at it away from the layout application. This catches things a quick scroll doesn't.
6. The ledger, item by item. Go through your list of known changes and confirm each one is present, absent or changed. This is the only check that answers the question you actually have.

Keep the results of that last pass in writing, even if it's three words per item.

An invented fixture, with the ledger filled in

The following is a stipulated example, not a recorded one. No document was crashed to produce it, and the details exist so the method has something concrete to work on.

A three-page treatment sits in Ridge_Treatment_v4.indd, saved at 15:40, with a PDF export taken from that same saved state. After 15:40, three changes are made and none are saved:

• The page 1 headline is reworded from "Autumn Ridge" to "The Ridge in Autumn."
• The page 2 hero image is moved from the top of the page to the lower right.
• A new two-sentence closing paragraph is added at the end of page 3.

At 16:35, while that closing paragraph is being typed, the session is interrupted. On reopening, a document marked as recovered appears. It's saved as Ridge_Treatment_v4_RECOVERED_2026-09-18.indd.

Now the comparison runs.

Page count: three. Page order: one, two, three. Both pass, and the 15:40 file would have passed too.

Text flow ending: the candidate ends on the sentence that ended page 3 at 15:40. The new closing paragraph is not there.

Overset text: none.

Linked files: both images resolve, and the hero image links to the same asset as before.

Ledger pass:

Two of three. The candidate captured the headline and the image move and missed the paragraph, which is unsurprising: the paragraph was being written when the interruption arrived, and the recovery data holds what it holds. Nothing here is broken. The candidate is simply not the same as the version you were working toward.

This is the case the whole method exists for. The recovered file is newer than the saved file, looks complete, exports cleanly, and is missing the most recent piece of writing. Had it been saved straight over Ridge_Treatment_v4.indd, the 15:40 state would be gone and the reworded headline and moved image would now be the only evidence that anything changed at all. You'd have lost your fallback while gaining nothing.

You can rehearse this on an expendable file if you want to know how your own setup behaves: copy a document, make three identifiable changes, interrupt the session, and see what comes back. Use a throwaway copy, never a live treatment, and treat whatever you observe as information about your machine rather than a guarantee about the next interruption.

When recovery itself keeps failing

Sometimes the candidate never opens. Adobe's Recover InDesign documents troubleshooting page, also updated June 2, 2026, describes recovery-state problems as distinct from an ordinary reopened document, and warns that repeatedly forcing recovery on a severely corrupted document can cause further loss — the guidance is to work on copies.

That warning matters because looping is the natural response to failure. Close, reopen, watch it fail, close, reopen. Each cycle is a fresh attempt on the same material, and the page's advice is explicitly not to keep doing that.

What to do instead:

• Stop cycling after the second failure. The third attempt is not more likely than the second.
• Copy the recovery material and the project folder before you try anything that clears or resets state.
• Treat destructive troubleshooting as a last route, not a first one, and take it on copies.
• Follow the version-specific route for your release rather than applying a general fix you found somewhere.
• Note what you tried and what happened.

There's a legitimate stopping point here, and it's worth naming as one. If the candidate won't open, or opens without changes you can verify, and you have a preserved fallback, you can stop. Redoing a known set of edits on a file you trust is a real option, and often the faster one. Continuing to prod at an unstable document in the hope that it resolves itself is the option that costs you the clean copy.

Decide which file is current, and say so

Once the comparison is done, you have three honest choices.

• The candidate becomes current. You finish the missing work inside it, confirm the ledger is complete, export again, and retire the old file to a clearly marked backup.
• The saved file becomes current. You accept the 15:40 state and re-apply the changes you'd made since. Slower, sometimes, but the state is certain.
• Both stay open. You keep the candidate for the changes it did capture and hold the saved file as the reference, then decide once you've spoken to whoever needs to be in the loop.

Whichever you pick, write it down where the next person can find it — in the file's notes, in a message to the collaborator, in the filename itself. Unresolved missing edits should stay visible on the list rather than disappearing into an optimistic name.

One boundary is worth holding here. Recovery restores bytes. It does not decide whose edits should win. If the changes made after the last save came from more than one person, a Save command is not the place to settle that, and letting one happen by default hands a collaborative decision to whoever opened the file last. That conversation belongs somewhere else, and the recovered candidate gives you something concrete to have it about.

Finally, don't mistake any of this for a version history. Recovery data is temporary by design and Adobe's page is clear that it isn't a backup service. The durable habit is smaller and more boring: before a round of substantial changes, save a dated copy. Two files and a naming convention will save you more often than any recovery dialog will.

Where this leaves you

At the end of the process you should be holding four things: the original file untouched, the recovery candidate saved under its own dated name, a written comparison of the known changes against what the candidate actually contains, and an explicit decision about which file is current.

If the comparison came up short and you can't complete it, that's a result too — a bounded stop with your fallback intact is a better outcome than a confident overwrite. The recovered label on a document describes where those bytes came from. It says nothing about what's inside them, and it never has.

Frequently asked questions

What should I do first after an interrupted InDesign session?

Do not open or save over anything yet. Preserve every original and piece of recovery material, and write down five facts while they are fresh: which file was open and where, when you last saved, what changed after that save, where recovery material is, and when the interruption happened. Then save the recovered candidate as its own dated file and compare it with the last known good version.

What counts as the "last known good" file?

It is the most recent version you saved and have actually opened and checked—not simply the newest file on disk and not the version you were midway through rewriting. A version marker and saved date help, and an exported PDF from that state gives a fixed reference for page count, page order, and text endings that does not move when a frame is edited.

Why shouldn't I save a recovered document over the original?

Recovery may be better, worse, or a mix, and its name or timestamp does not tell you which. Saving over the original erases the fallback. In the invented fixture, the recovered candidate captured the reworded headline and moved image but missed the new closing paragraph; overwriting would have lost the 15:40 state while gaining nothing.

What checks should the comparison include?

Check page count and order; read the end of the last substantial text frame for truncation; look for overset text; check linked files without confusing missing assets with lost edits; export a representative PDF and view it away from the layout application; then go through your written ledger item by item. Page count can fail loudly but cannot pass convincingly, because a page-for-page match can still miss a paragraph.

What if recovery keeps failing or the candidate will not open?

Stop cycling after the second failure; the third attempt is not more likely than the second. Copy the recovery material and project folder before any troubleshooting that clears or resets state, work on copies, follow the version-specific route for your release, and note what you tried. If the candidate will not open or shows no verifiable changes and you have a preserved fallback, stopping and redoing known edits on a trusted file can be the legitimate, faster option. Recovery restores bytes; it does not decide whose edits win.

Further reading

• Check the Actual Treatment File You Intend to Send — Once you have chosen the current file and need to send it, this walks through inspecting the actual attachment and route, separating material defects from cosmetic issues.