The Recovery Request: What to Ask First, and Why

Monday, 09:40, at Redbrook Engineering. Ticket 2231 arrives from Dana in the drawing office with the subject line "URGENT all my files are gone" and a body that says, in full, "Everything in my project folder has disappeared. I need it for the client call at 11. Please help." Ola is in his second month on the desk. He has restored a file from a backup exactly once, with someone watching. He is now looking at a ticket that could mean anything from a dragged folder to a wiped share. He has eighty minutes, one requester who is frightened, and no idea yet what is actually missing.

A recovery request is a ticket asking the desk to bring back a file or folder that the requester can no longer find, open or trust. The first job on every one of them is not restoring anything. It is finding out what happened, because "my files are gone" covers at least six different events. Four of them are fixed in under five minutes without touching a backup. This article is part of our Deleted Files & Recovery Requests series. The series covers the request, the restore, the file that cannot be recovered, versioning, prevention and measurement. This article is about the first ten minutes.

It covers what "gone" usually means, and the five questions and why their order matters. It covers each question in turn, with what it rules in and out. Then come the quick wins to try before any restore and writing the answers down for whoever does the restore. It ends with a short war story and the intake questions to copy, in that order.

What "My Files Are Gone" Usually Means

The sentence "my files are gone" describes the requester's experience, not the event. The events behind it are more varied than most new technicians expect. The file was moved, by a slipped mouse, into the folder next door. The file was deleted, on purpose or by a tidy-up that went one level too deep. The file was overwritten, usually by saving the wrong thing under the right name. The file was never saved at all, and lived for three hours in an unsaved window that closed with the laptop lid. The file is exactly where it always was. The requester is looking in a different place. That could be a different account, a different computer, a sync folder that has not caught up, or a shortcut that now points nowhere. Or the file is there and the requester's permission to see it is not, after somebody tidied the group memberships on Friday.

Each event has a different rescue, and the rescues cost wildly different amounts. The moved file costs a search. The deleted file costs a trip to the recycle bin. The overwritten file costs a look at version history, the subject of Versioning Saves More Than Backups Do. The permissions case costs a conversation with whoever changed the group. Only the file that has fallen through every nearer layer costs a backup restore. That is the slow one, the one that needs another person, and the one Ola was dreading. Finding out which event you have is therefore the whole of the first ten minutes. A backup restore for a file that was dragged into the wrong folder is a long walk to fetch something from your own pocket.

The requester cannot tell you which event it was, and it is not their job to. What they can tell you, if asked well, is a handful of facts from which the event can be worked out. That is what the five questions are for. They are the same shape as the general intake discipline in Gathering the Right Information Up Front, asked once, in one message or one call. They are written down where the next person can find them.

The Five Questions, and Why the Order Matters

The five questions are: what exactly is missing; where did it live; when was it last seen whole; who else had a copy; and how urgent is it, honestly. They are asked in that order because each answer narrows the next. "What" tells you whether this is one file or a folder, which decides whether you are looking at a slip or an event. "Where" tells you which layers of protection exist at all. A file on a local disk and a file on the file service have completely different rescues. "When" tells you which of those layers can still reach it. "Who else" may end the ticket outright. "How urgent" decides whether the slow rescue starts now or after the quick wins are exhausted.

Ask all five in one go, in one message, even when the first answer would let you start. A technician who asks "what is the file called?" and waits, then asks "where was it?" and waits, has turned a ten-minute triage into an afternoon of e-mail. The requester, who is already anxious, experiences each question as a delay. Put the five in a numbered list, say why you are asking in one sentence, and promise what happens next. The reply arrives faster when the requester can see the end of the list.

Where the request comes in by phone or at the desk, ask the same five out loud and type the answers into the ticket as they are given. The order holds; the method does not matter. What matters is that the answers end up in the ticket. That is because the person who performs the restore may not be the person who took the call. A restore performed on a half-remembered description recovers the wrong thing surprisingly often.

Question One: What, Exactly, Is Missing

The first question establishes the thing itself. Ask for the file's name as closely as the requester remembers it and the kind of file it is. Ask roughly how big or how old, and for a phrase from inside it that would be unusual enough to search for. The name matters because the quickest rescue of all is a search by name across the places the file could have gone. The kind of file matters because a spreadsheet and a drawing have different version histories and different autosave behaviour. The phrase from inside it matters for the day the name is wrong, which is most days. Requesters remember what a file was about far more reliably than what it was called.

Establish also whether "files" means one file, a folder, or everything. One file missing is nearly always a slip: moved, overwritten, or saved somewhere else. A whole folder missing is usually a drag, and sometimes a deletion. Everything missing, across the drive, is rarely a deletion at all. It is far more often a permissions change, a disconnected drive mapping, a different account or a sync folder that has not finished. In a small number of cases it is a security event that needs the security function told at once. "Everything is gone" is the answer that should make you slow down and look at the computer before you look at any backup.

Dana's answer to Ola was "the whole Harbour Bridge folder, about forty drawings and the specification document, the one with 'revision C' in the title". That is a folder, not a file, with a name and a searchable phrase. In fifteen seconds it has ruled out the overwrite and the never-saved cases and made a drag or a deletion the likely story. Three of the six events are already gone, and nobody has opened anything yet.

Question Two: Where It Lived

The second question establishes the file's address, because the address decides which protections exist. Files live in one of three kinds of place. The first is the file service: the shared drives and shared folders that the organisation keeps on its own server or its chosen cloud file service. Most organisations back it up. Many snapshot it, and some version it. The second is the local disk of the requester's own computer, including its desktop and documents folders unless the desk has arranged for those to live on the file service instead. The local disk is usually backed up by nobody. The third is the sync folder, a folder on the local disk that a client program keeps mirrored to a cloud file service. The sync folder has the protections of the service for anything that finished syncing and the protections of the local disk for anything that did not.

Ask for the path, the full address of the folder as the requester sees it. Ask them to read it from the address bar rather than from memory. A requester who says "it was on the shared drive" may mean a mapped drive letter, a shortcut on their desktop that pointed at the file service, or a folder in their sync client. They may also mean a folder that a colleague once shared with them and has since un-shared. Each of those is a different place with different rescues. The shortcut is the trap that catches most new technicians. A shortcut on the desktop that stops working looks, to the requester, exactly like a deleted folder. The folder is usually fine. (It has not moved. The arrow pointing at it has.)

When the answer is "my desktop" or "my documents", find out before anything else whether those folders are redirected to the file service on that computer. The whole shape of the ticket depends on it. If they are, the file service's layers apply and the rescue is probably quick. If they are not, the only copies that ever existed were on one disk. In that case, the nearest rescue is the local recycle bin followed by a sharp drop into the territory of When It Cannot Be Recovered. Ask the question gently. The requester did not choose the desk's folder policy.

Question Three: When It Was Last Seen Whole

The third question establishes the last moment the file was known to be complete and correct. That matters because every layer of protection reaches back a fixed distance. The answer tells you which layers can still reach the file. Ask two things: when did you last open it and see it right, and when did you first notice it was gone. The gap between them is the window inside which the event happened. The first date is the version you are trying to get back to. "I worked on it until about four yesterday and it was gone when I logged in this morning" gives you a sixteen-hour window and a target: the state at four o'clock.

The answer sorts the layers. A file last seen whole an hour ago is almost certainly inside the version history and the recycle bin. A file last seen whole three weeks ago may be past the recycle bin's window and inside the snapshots. A file last seen whole at Christmas is a backup question, and possibly a question with no answer, depending on how far back the backups go. The windows differ for every service and every desk. At Redbrook, as it happened, the file service kept deleted files for a few weeks and snapshots for a few months. That is a comfortable arrangement and not a universal one. Find out your own windows and write them where the desk can see them. A technician who does not know them cannot answer this question's most important follow-up: "is it too late?"

Be alert to the honest "I don't know". Requesters often last touched a file months ago and only noticed its absence today, and the true window is enormous. That is not a failure of the requester; it is a fact about how files are used, and it means the search starts wide. It also means the fourth question, the one about other copies, becomes the most likely route home.

Question Four: Who Else Had a Copy

The fourth question asks whether the file exists anywhere other than the place it went missing from. That is because the fastest recovery of all is a copy that was never lost. Files travel. A document sent to a client as an attachment is in the sent items. A spreadsheet shared with a colleague for comment is in the colleague's download folder, slightly out of date and still a better starting point than nothing. A drawing issued for review is on the review system. A report generated from a database can be generated again from the same database, often in less time than a restore takes. The requester, in the state of someone who has just lost a week's work, will not think of any of these. Ask.

Ask specifically, not generally. "Did you e-mail it to anyone, upload it anywhere, print it, or build it from something that still exists?" gets answers; "is there another copy?" gets "no", because the requester is picturing the folder, not the world. The attachment in the sent items is the single most common rescue for a file that is past every window. It is found by a search of the requester's own mailbox that takes a minute. It is not the version from four o'clock yesterday. It is the version from last Tuesday, which the requester would have taken gladly at 09:40 and will take with slightly less grace at 10:50 after a backup restore has failed.

Where another copy exists, the ticket may be finished before the restore workflow starts. That is a success to log, not a short cut to apologise for. Note in the ticket that the file was recovered from the colleague's copy or the sent items. The count of recoveries by source is one of the few useful numbers this kind of ticket produces, as Measuring Recovery Requests explains.

Question Five: How Urgent, Honestly

The fifth question asks when the file is needed and what happens if it is not there by then. It is asked last because the answer changes what you do with the first four, not whether you ask them. A file needed for a client call in eighty minutes gets the quick wins tried immediately. If they fail, the slow rescue starts in parallel while the requester is helped to find a workaround for the call. A file needed by the end of the week gets the quick wins now and the slow rescue in the normal queue. A file that "would be nice to have back" gets the quick wins, a note, and an honest statement of how far the desk will go.

"Honestly" is in the question because every recovery request arrives marked urgent, and the word has stopped carrying information. Ask for the deadline and the consequence instead: "when do you need it, and what is it for?" The requester who says "the board paper is due at two" and the requester who says "I'd like it back before my appraisal next month" have both said urgent. Only one of them has a two o'clock. The general discipline for separating urgency from volume is in The Everything-Is-Urgent User. Here it is enough to get the deadline and the stakes in the requester's own words and put them in the ticket.

The deadline also decides whether to start the slow rescue early. A backup restore that needs another team can take hours to arrange. A technician who waits until every quick win has failed before asking for it has spent the deadline on the easy things. When the stakes are high and the window is short, ask for the backup restore at the same moment as the quick wins begin, and cancel it if the file turns up. Nobody who runs backups has ever minded a cancelled restore request. The ones that arrive at 13:40 for a 14:00 deadline are the ones they remember.

The Quick Wins Before Any Restore

With the five answers in hand, the next ten minutes go on the rescues that cost almost nothing, in order of cost. Most recovery requests end somewhere in this list. The table below is the list. Each row names the quick win, where to look, which of the six events it rescues, and roughly how long it takes on an ordinary day. Work down it. Stop when the file turns up. Write down what you tried, including the rows that found nothing. The next person needs to know not to try them again.

Two of these deserve a word of caution. The recycle bin on a file service is often separate from the bin on the computer. Sometimes there are two on the service, one the user can reach and one only an administrator can. A technician who checks only the first and reports "not in the bin" has checked a third of the bins. And the permission check belongs at the end not because it is unlikely but because it needs another person. It is worth exhausting the one-person rescues first. When a whole department reports everything gone on the same morning, move it to the top. Twenty people have not all dragged their folders at once.

If the quick wins fail, the ticket moves to the restore proper. That is a different discipline with its own order of layers, side locations and confirmation. It is the subject of The Restore Workflow in Plain Words. The five answers and the list of quick wins already tried are what that workflow starts from. A restore that starts without them starts by asking the same questions again, a day later, of a requester who has already answered them once.

Writing It Down for the Person Who Restores

The intake answers go in the ticket, in a fixed order, as a note that a stranger could restore from. That is because the restore is often performed by a different person, sometimes in a different team, and always later. The note names the file or folder exactly, the path it lived on, the last-seen-whole time, and the first-noticed time. It also gives the deadline and stakes, the other copies checked, and each quick win tried with its result. It does not contain the requester's password, their sign-in session, or any content from inside the file that should not be in a ticket. It contains the name of the file and a phrase to search for, nothing more. The standard for a note that survives its author is in Notes for the Stranger. Recovery requests are the tickets that test it most, because the stranger is so often real.

Where the desk takes recovery requests by a form, the five questions can be the form. In that case, the answers arrive with the ticket instead of a day after it. Many desks put a short recovery form under the department that owns the file service, with the five questions as fields and the quick wins as a note beside them. If you run QuerySolv, a department can carry its own form and mailbox. That means the file service team's form can ask these questions while the general one stays short. In any tool, the test is whether the first message the desk sends on a recovery request is a question or an answer. The desks that have the form send answers.

One more line belongs in the note from the start: the time the request was first seen by the desk. Recovery requests are among the few tickets where the clock genuinely runs against the file, because windows close, bins empty and snapshots roll over on their own schedule. A request that sat unread for three days may have crossed a window while it waited. That is not a reason to panic every time one arrives. It is a reason to triage them on the day, and to know, from the date rule in question three, when the day matters.

A Short War Story: The Vanished Quarter at Tollgate Foods

At Tollgate Foods, a planner called Ines raised a ticket on a Thursday saying the whole "Q3 forecasts" folder had vanished from the shared planning drive. A technician called Ben, keen and new, went straight to the backup team with a restore request for the folder as of Wednesday night. That was because the ticket said "urgent" and "vanished" and he had been told backups were for vanished things. The backup team restored it to a side folder by late Friday afternoon, after a queue of other work. Ines found that Thursday's edits were missing from the restored copy. She spent Monday morning redoing them. On Monday afternoon a colleague in the next pod mentioned, in passing, that she had a "Q3 forecasts" folder sitting inside her own "Q2 reviews" folder. She had been meaning to ask about it. The folder had been dragged one row down in a file list on Thursday morning and had never left the drive. The cost was a day of the backup team's queue, a morning of Ines's re-entry, a weekend of her worry, and a Friday on which Ben learned what a search by name is for. The lesson was the order of the list. The five questions and the quick wins come before any restore, because a restore is the slowest answer to a question that is usually small.

The Recovery Intake Questions

The sheet below is the one Ola now pastes into every recovery request, as a reply when the ticket arrives bare and as a note when the answers come by phone. The first block is sent to the requester as it stands, with the technician's name and a promised time. The second block is the technician's own record of the quick wins, kept in the ticket as an internal note. That lets whoever performs the restore see what was tried, what was found, and what is left. The last line is the handover to the restore workflow or the closing note if a quick win found the file.

RECOVERY REQUEST — INTAKE QUESTIONS AND QUICK WINS
Ticket: ________   Requester: ______________   First seen by desk: ____/____ ____:____

1. TO THE REQUESTER (one message, all five at once)
   Thanks, I am looking into this now. To find the fastest way back, please answer:
   1) What exactly is missing: the file or folder name as you remember it,
      the kind of file, and a phrase from inside it I could search for.
      ______________________________________________________________
   2) Where it lived: the full folder path, read from the address bar.
      Shared drive / my desktop or documents / sync folder / other: __________
      ______________________________________________________________
   3) When you last saw it complete and correct: ____/____ ____:____
      When you first noticed it missing:          ____/____ ____:____
   4) Any other copy anywhere: e-mailed to someone, uploaded, printed,
      shared for review, or made from a system that still has the data?
      ______________________________________________________________
   5) When you need it and what it is for: ____/____ ____:____  ______________
   I will reply by ____:____ with what I have found.

2. DESK RECORD (internal note; tick each as tried, write what was found)
   [ ] Search by name across the share, the computer, the sync folder ........ ______
   [ ] Search by the phrase inside it ......................................... ______
   [ ] Recently opened list in the application and the operating system ....... ______
   [ ] Parent folder and siblings, sorted by date modified ..................... ______
   [ ] Requester's recycle bin on the computer ................................. ______
   [ ] File service recycle bin(s) for the share, user's and administrator's ... ______
   [ ] Version history on the file or folder .................................. ______
   [ ] Other copy: sent items / colleague / downloads / source system .......... ______
   [ ] Other account or computer; sync client finished ......................... ______
   [ ] Permissions on the folder and the requester's groups (with owner) ....... ______

3. OUTCOME
   Found by quick win: ______________  at ____:____   -> confirm with requester, close
   Not found: handed to restore workflow at ____:____, target state as of ____/____ ____:____
   Backup restore requested early because of deadline: yes / no   Requested at ____:____

Ola sent Dana the five questions at 09:44 and had answers by 09:51. It was a folder, on the project share, last seen whole at half past five on Friday. The specification had also been sent to the client as an attachment the week before. The search by name found "Harbour Bridge" inside "Harbour Bridge Phase 2", one folder up, where it had been dropped by somebody tidying on Friday evening. He moved it back, opened one drawing to be sure, and replied at 09:58 with where it had been and what he had done. The client call went ahead at eleven. The backup was never asked for anything, which is the best thing a backup can be asked.

Frequently Asked Questions