When It Cannot Be Recovered and How to Say So

Friday, 15:50, at Harbourview Clinic. Femi has spent most of the afternoon on ticket 3362. Ruth, the practice manager, built the infection control audit workbook over six weeks. It lived on the desktop of her old laptop, which the desk swapped for a new one on Tuesday. The old laptop was wiped for reissue on Wednesday. The desktop on that model was never redirected to the file service. Ruth's recycle bin went with the disk. There is no version history because there was never a service. The backup set covers shares and not laptops. The last copy she e-mailed to anyone was a skeleton from week one. Femi has checked every layer twice. The audit is due to the regulator in nine days. He now has to tell Ruth that the file is gone, and that the desk's own swap process is part of why.

A file is unrecoverable when no layer of protection holds a usable copy of it. That means not version history, not any recycle bin, not a snapshot, not the backup, and not another person. The ticket that reaches this point is rare, uncomfortable, and more important than its count suggests. How the desk handles it decides whether the requester trusts the desk afterwards and whether the same loss happens to the next person. This article is part of our Deleted Files & Recovery Requests series. The layers themselves, and the order they are visited in, are in The Restore Workflow in Plain Words. This article begins when the last layer has come back empty.

It covers the five shapes of unrecoverable, and being sure before you say it. Then come the honest message and what it contains, saying it at the right time, and what can still be salvaged. Next come the manager conversation, the one thing to change so it does not happen again, and closing the ticket honestly. It ends with a short war story and the cannot-recover message to copy, in that order.

The Five Shapes of Unrecoverable

Files become unrecoverable in five ways, and knowing which one you have matters. Each has a different thing to check before you give up and a different change to make afterwards. The first is the file that was never saved. It could be hours of work in a window that closed, or a document that lived only in the application's memory. It could be a form filled in on a web page that timed out. No layer ever saw it. The second is the file that is outside every window. It was deleted long enough ago that the bin has emptied, the snapshots have rolled over and the backups have aged out. That is the shape most people picture when they imagine a lost file and the one the desk sees least.

The third is the file that lived on a local disk or a personal device that nothing protected. Examples are the laptop desktop that was never redirected, the phone, the removable drive in a coat pocket, the home computer. The fourth is the file in a place that the backup set did not include. Examples are the share created after the backup job was configured, the folder someone excluded to save space, the service nobody told the backup team about. These two look the same to the requester: "it was on my computer" or "it was on the drive". They differ completely in whose decision caused the gap. The fifth is the file that was recovered but is damaged. The restore produced a copy that will not open, is empty, or is a conflict copy with half the content. The only other copies are the same.

The sixth shape is not a shape, and it is worth saying: the file that was recoverable and was reported as lost because somebody stopped looking. That is the one this article exists to prevent before anything else, and the next section is about it. Telling a requester their work is gone is a sentence you get to say once. It had better be true.

Be Sure Before You Say It

Before the word "unrecoverable" goes into a ticket, every layer has been checked and recorded, including the ones that could not possibly hold the file. A second person must also have looked at the list before that word goes in. The record from the restore workflow is the evidence. Version history is checked on the file and the folder. Every bin is checked: the user's, the service's, the administrator's. The snapshots are stepped through to the last one that could reach the window. The backup set is confirmed to include or exclude the path, in writing from whoever runs it. "I checked the backup" is not a layer result. "The backup team confirmed the laptop was not in the set" is. A second pair of eyes on the list catches the bin nobody knew about and the snapshot that was one step further back than the first technician went. That second look costs ten minutes.

Then the other-copy question gets its second pass, wider than at intake, because this is the point where a stale copy is a gift. Search the requester's sent items for the file's name and for any phrase from inside it. Search the mailboxes of the people it was shared with, with their permission. Check the download folders of anyone who opened it. Check the source. If the file was built from a system, an export, a database, a form, the data may still be there. If the data is there, the file can be rebuilt faster than anyone fears. Check for a printout, a photograph of a screen, the version pasted into a message. A great many "unrecoverable" files turn out to be recoverable to last Tuesday, and last Tuesday is a long way from nothing.

For the never-saved file and the local disk, two careful checks remain. Many applications keep temporary or automatic copies of open documents in a folder of their own. A file that was never saved by the user may have been saved by the application a few minutes before the window closed. Look there, with the operating system's built-in tools, before concluding. And where a file was deleted from a local disk and the bin is empty, the data may physically remain until something overwrites it. In that case, a disk recovery utility is a last, low-odds try. That is only if the computer is taken out of use immediately so that nothing more is written. Where there is any sign that the loss is part of a security event, stop. That includes files altered or encrypted across a share rather than one file missing. In those cases, do not attempt recovery, and bring in the security function at once. That path belongs to the security tickets the desk will see, not to this article.

Femi did all of this. The old laptop had already been wiped and reissued, so there was no disk to try. The application's temporary folder had gone with it. The sent items held the week-one skeleton and nothing later. Ruth's deputy had a printout of one tab from week four. By a quarter to four he was sure, and a colleague who read the list agreed. That is the standard: not "I could not find it", but "here is everywhere it could have been, and here is who confirmed each one".

The Honest Message: What It Contains

The message that says a file cannot be recovered has six parts. The order matters because the requester will stop reading at the first sentence that answers their question. It names the file and what was lost, specifically, so that there is no doubt which thing is being discussed. It says, in one sentence, that the desk cannot recover it. It lists what was tried, layer by layer, in plain words. That way, the requester can see the work and will not spend the weekend wondering whether someone checked the bin. It says why, in one sentence, without blame. It says what can still be done: the older copy, the partial, the rebuild, the help on offer. And it says what happens next, including who the desk has told and who will be in touch.

The reason is the sentence that goes wrong most often. "Because you saved it on the desktop" is a fact and an accusation in the same breath, and the requester hears only the second half. "Because the desktop folder on that model was not set up to copy to the file service, so there was never a protected copy" is the same fact with the cause in the system, where it belongs. Where the desk's own process contributed, say so plainly: "and the laptop swap did not check for local files before the old machine was wiped, which it should have". Owning the desk's share is not weakness. It is the only version of the story that the requester will believe, and it is the one the manager conversation will need anyway. The discipline of naming the impact without flinching is the subject of Acknowledging Impact Honestly. This message is its hardest case.

Leave out three things. Leave out the lecture about where files should be saved. It will be true next week and it is unbearable today. Teaching Prevention After the Rescue explains when it lands. Leave out speculation: no "it might be possible to", no "there are companies that", unless the desk has actually arranged it. And leave out the apology that is really a defence, the paragraph that explains at length how reasonable the desk's process was. One sentence of regret, one of ownership where it is owed, and then the useful part. The requester does not need to feel better about the desk. They need to know what they have left.

Saying It at the Right Time

Say it as soon as you are sure, by voice if the loss is large, and in writing afterwards in every case. The temptation on a Friday afternoon is to send the e-mail at five and let the weekend absorb it. The result is a requester who reads it at half past five, cannot reply to anyone, and spends two days building the loss up in their head. A three-minute call is kinder and shorter than the e-mail it replaces. It says: "I've checked everywhere, I'm afraid it's gone, here is what we do have, I've written it all up and I'll be in on Monday". It lets the requester ask the one question they have, which is nearly always "is there really nowhere else?" The written message follows the call, so that the list of what was tried exists somewhere the requester can reread when they are calmer.

Do not say it early to be rid of it, and do not say it late to avoid it. A technician who announces a file lost after checking two layers has lied by accident. The file that turns up in the administrator's bin on Monday does not repair the trust. A technician who sits on a confirmed loss for three days because the conversation is unpleasant has spent three days of the requester's deadline. The right moment is the one at which the list is complete and a second person has read it. That moment is usually within a working day of the quick wins failing. Femi called Ruth at ten past four. She asked whether there was really nowhere else. He read her the list.

What Can Still Be Salvaged

Almost no loss is total, and the message is far easier to send when the salvage is in it. The older copy is the commonest salvage: the version from the sent items, the colleague's download, the draft shared for comment. It carries most of the structure and some of the content and turns "rebuild from nothing" into "redo three weeks of entries". The partial is the next: one tab printed, one section pasted into a message, the figures that were sent to finance on the Tuesday. The source is often the largest. A workbook built from a system's reports can be rebuilt from the same reports. A document assembled from e-mails can be reassembled from the same e-mails. The desk can help by pulling the exports again, which is work the requester may not know is possible.

Offer the salvage as a plan, not a list. "We have the week-one skeleton with the structure, the printed week-four tab that Anita kept, and the system can re-export the attendance figures for all six weeks; together that is the frame and about a third of the content, and I can have the exports in a folder for you by Monday morning." That is a sentence a requester can plan around, and it gives them something to do that is not grieving. It also makes the next conversation, about how long the rebuild will take and who will do it, a conversation about a known gap instead of an unknown one.

The Manager Conversation

When the loss costs more than an hour or two to rebuild, or puts a deadline at risk, the requester's manager needs to know. The right way is with the requester, not behind them. The purpose of the conversation is not to assign blame. It is to let the organisation decide how to absorb the cost. That is a decision the desk cannot make and the requester should not have to make alone. The rebuild may need two people for a week. The deadline may need to be moved, or the regulator told, or a reduced version submitted. Those are the manager's calls. They can only be made by a manager who has the facts on the day rather than on the day the deadline is missed.

The desk brings three things to the conversation: what happened, what was tried, and what it will cost to rebuild, all in plain words and in writing. The ticket is the record. If you run QuerySolv, the ticket's complete event history shows each layer checked in order, with its result and its time. That is the account the manager conversation rests on. In any tool, the restore record on the ticket should let a manager see in a minute that the desk did everything it could. The rebuild cost is the desk's honest estimate in hours from the salvage plan, stated as a range. "With the exports and the skeleton, Ruth estimates four to six days to bring it back to where it was". The desk does not minimise the cost to look better and does not inflate it to look thorough.

Where the desk's own process contributed, the desk says so in the conversation, first, before anyone else has to. "The laptop swap did not check for local files before the old machine was wiped, and it should have; we are changing the checklist this week." A manager who hears that from the desk hears a team that can be trusted with the next problem. A manager who finds it out later hears something else. (They do find it out. They always find it out.) The rest of the conversation is about the rebuild. The desk's part in it is to offer the help it can: the exports, a loan of time, and a second pair of hands on the mechanical parts. It can also offer a check at the end that the rebuilt file is somewhere with layers around it.

The One Thing to Change

Every unrecoverable file points at exactly one gap, and the desk's lasting job is to close that gap, not to improve everything at once. The never-saved file points at automatic saving being off. The file outside every window points at a window that is too short for how the organisation actually works. The local-disk file points at redirection not being standard, or at a swap and wipe process that never asked about local files. The share not in the backup set points at a share creation step that does not tell the backup team. The damaged restore points at a restore that was never opened before it was called done. Pick the one your ticket points at. Write it down as a problem to be fixed, with the ticket as its evidence, and get it to whoever owns the change.

Resist the urge to fix five things, because five things take a quarter and none of them get done, while one thing takes a week. Harbourview's one thing was the swap checklist. Before any computer is wiped, the technician checks the desktop and documents folders for anything not on the file service. Before the wipe, the technician copies it to a side folder on the share and tells the user where it is. Redirection on that model was the second thing, and it went on the list for the next month. A change that touches how computers are built or how shares are created is a change in the ordinary sense, with a record and a reviewer. The one-page version of that record is in The One-Page Change Record. Keep the record short and keep the ticket number on it. The ticket is the argument.

Watch for the gap that is systemic rather than single. One laptop desktop lost to a swap is a checklist. Six in a year is a model that was built without redirection and a fleet that needs it. That is a project, and a project is far easier to get approved with six tickets behind it than with one. The count of unrecoverable files by shape, small as it is, is the single most persuasive number the desk produces about its own protections. The article on measuring recovery requests says how to keep it.

Closing the Ticket Honestly

The ticket for an unrecoverable file is resolved, not closed quietly and not left open in the hope of a miracle. Its resolution note says plainly that the file was not recovered. The note records the five shapes' worth of evidence. It records each layer and its result, the other copies sought and found, the salvage provided, and the manager told and when. It also records the rebuild estimate and the one thing raised for change with its reference. The outcome is recorded as "not recovered" in whatever way the desk tracks outcomes. A ticket marked "resolved" with no outcome recorded will be counted next month as a success. In that case, the desk will have taught its own numbers to lie. The general practice for resolving a ticket whose problem is not fixed is in Closing the Ticket You Cannot Fix. The recovery ticket follows it exactly.

Tell the requester the ticket is being resolved and why, and leave the way back open. If a copy turns up next month in a colleague's folder, the requester replies, the ticket reopens, and the outcome is corrected. If the rebuild reveals that part of the data is irrecoverable after all, the same ticket carries that too. What the requester must not experience is the ticket vanishing from their view on a Friday with "resolved" on it and no sentence from a person. To someone who has lost six weeks of work, that reads as the desk moving on.

Finally, keep the salvage folder and the restore record where the next technician can find them. Put a short line in the knowledge base if the shape of loss is one the desk will see again. "Laptop desktops on model X are not redirected; check before wipe" is a sentence that will save another Ruth. It is the sort of knowledge that is captured while the ticket is still open or not at all. The lesson was expensive. Spending it twice would be careless.

A Short War Story: The Tender Share at Larkspur Architects

At Larkspur Architects, a project associate called Callum set up a new share for a hospital tender, because the practice's main share was crowded. Over five weeks the tender team filled it with drawings, cost schedules and the written submission. Nine days before the deadline a colleague tidying folder names deleted the submission folder. The bin on that share had been set to a short window by whoever created it. When the technician, Jo, asked the backup team for a restore, the reply was that the share had never been added to the backup set. Nobody had told them it existed. There were no snapshots on that volume. Three people rebuilt the submission over a weekend from e-mailed drafts, printed review copies and memory, about forty hours of work in all. The tender went in on time with one section visibly thinner than the others. The lesson was the one change. Every new share joins the backup set on the day it is created, as a step on the share creation ticket. A share that nobody backs up is not storage. It is a place to lose things slowly.

The Cannot-Recover Message

The message below is the written version that follows the call, or the only version for a small loss. The first block goes to the requester, and every bracket is filled with the specific fact. A message of this kind with a generic phrase in it reads as a form letter. The requester deserves better than a form letter today. The second block is the note to the requester's manager, sent with the requester copied, when the rebuild cost or the deadline justifies it. The third block is the desk's own record, which closes the ticket and opens the change.

CANNOT-RECOVER MESSAGE — REQUESTER, MANAGER, RECORD
Ticket: ________   Requester: ______________   Technician: ______________

1. TO THE REQUESTER (after the call, or alone for a small loss)
   Subject: ______________ (file or folder name) — what I found

   I have finished checking every place a copy of ______________ could be,
   and I am sorry to say we cannot recover it.

   What I checked, in order:
   - version history on the file and the folder: ______________
   - the recycle bins (yours, the file service's, the administrator's): ______________
   - snapshots back to ____/____: ______________
   - the backup, confirmed by ______________: ______________
   - other copies (sent items, colleagues, downloads, source system): ______________

   Why there was no protected copy: ______________________________________.
   [Where the desk contributed:] Our ______________ process should have
   ______________ and did not; we are changing it this week.

   What we do have:
   - ______________ (from ____/____), which holds ______________
   - ______________ (from ____/____), which holds ______________
   I have put these in ______________ and can ______________ by ____/____.

   I have let ______________ know, with you copied, so that the time to
   rebuild can be planned. If anything turns up anywhere, reply to this
   message and the ticket reopens.

2. TO THE MANAGER (requester copied; when the rebuild is hours or a deadline is at risk)
   ______________'s file ______________ cannot be recovered; the ticket
   holds the full list of what was checked. From the copies we do have,
   the estimate to rebuild it is ______ to ______ hours of ______________'s
   time, and the deadline affected is ____/____. The desk can help with
   ______________. The gap that allowed the loss was ______________, and
   the change to close it is ______________, owned by ______________.

3. DESK RECORD (internal note; resolve the ticket with outcome "not recovered")
   Shape of loss: never saved / outside every window / local or personal device /
                  not in backup set / recovered but damaged
   Layers checked and by whom: ______________________________________
   Second reader of the list: ______________ at ____:____
   Salvage provided: ______________________________________
   Manager told: ______________ at ____/____ ____:____
   Rebuild estimate: ______ to ______ hours
   One change raised: ______________ reference: ________ owner: ______________
   Knowledge base line added: yes / no

Ruth rebuilt the audit in five working days from the skeleton, the printed tab and six weeks of re-exported attendance figures. Femi had those figures in a folder by Monday morning. Ruth submitted the audit on the day it was due. The practice's operations lead, told on the Friday with Ruth copied, moved two of Ruth's other deadlines without being asked. The swap checklist changed the following Tuesday. The first laptop wiped under the new step turned up a quarter's worth of someone's expense claims on a desktop nobody had thought about. The audit workbook now lives on the file service, with four layers around it. Ruth checks its version history more often than anyone at Harbourview has ever checked anything.

Frequently Asked Questions