Why Versioning Saves More Files Than Backups Do

Tuesday, 16:05, at Stonebridge Insurance. Jonah in underwriting has just opened the quarter's blank pricing template and chosen "save as". He has typed the name of the live motor book pricing workbook over it. That is because the two files sit next to each other and the names begin the same way. The live workbook, with a day of rate changes from four people in it, is now a blank template. The backup ran at eleven last night. Aisha on the desk knows the backup will give her yesterday's workbook. She knows that yesterday's workbook is missing exactly the day Jonah's team spent building. She also knows the file lives on the file service, and she opens its version history before she opens anything else.

Version history is a record of earlier copies of a file, kept automatically by the file service each time the file is saved. That way, any previous state can be opened or brought back without asking anyone. It is the nearest of the layers around a file and the one that rescues the most common loss of all, the overwrite. A backup rescues that badly or not at all. This article is part of our Deleted Files & Recovery Requests series. It argues one thing: on an ordinary desk, version history quietly saves more work than the backup does. The desk's job is to know where it exists, teach users to use it, and stop trusting it where it is not.

It covers what version history is in plain words, then the overwrite and why a backup cannot rescue it well. Next come where version history exists and where it does not, and teaching users to find it themselves. The sync-folder caveat, the file services that lack history and what to do instead, and what version history is not follow. The desk's one page of places and protections, a short war story, and the versioning guide for users to copy come next, in that order.

What Version History Is, in Plain Words

When a file lives on a file service or a document service that keeps versions, every save makes a new copy and keeps the old one. The old copy is labelled with the time and usually the person. The file the user sees is the newest copy. The older ones sit behind it, out of sight, for a set number of versions or a set length of time. Opening the history shows the list, newest first. Any entry can be opened on its own, downloaded as a separate file, or made the current version again. Nothing about this needs a technician, a request, or a wait. The service did the work at every save, and it did it whether or not anyone was thinking about it.

The physical picture is a stack of carbon copies under the page you are writing on, one for every time you put the pen down, each dated. The backup, by contrast, is a photocopy of the whole filing cabinet taken once a night by somebody in another building. Both are copies. Only one of them has the page as it was twenty minutes ago.

Version history differs from the recycle bin in what it holds. The bin holds files that were deleted; the history holds files that still exist but have changed. A file that is deleted leaves the history behind on many services for a while. That is why the restore workflow checks history even for a deleted file. But the history's real territory is the file that is still there and is wrong. The whole workflow, and the order of the layers, is in The Restore Workflow in Plain Words. This article stays on the nearest layer.

The Overwrite: The Case a Backup Cannot Rescue Well

An overwrite is a file replaced by a different version of itself under the same name. It is the loss that desks see most and talk about least, because it does not look like a loss. The file is there. It opens. It is simply wrong. It could be a blank template where the pricing was, or last week's draft where this week's edits were. It could be a spreadsheet with a tab deleted and saved, or a document with forty paragraphs where there were sixty. The requester often does not notice for hours or days. When they do, the message is not "my file is gone" but "something has happened to my file". That is why the intake question "what exactly" matters so much.

The backup is the wrong tool for the overwrite because of timing. A backup is a copy from a moment, and the moment is usually last night. Everything between last night and the overwrite is in neither the backup nor the current file. At Stonebridge, the workbook was overwritten at 15:40 on Tuesday. The backup held it as of 23:00 on Monday. The version history held it as of 15:38 on Tuesday, two minutes before the damage, with the whole day's work in it. Aisha downloaded that version into a side folder, Jonah checked it, and the live file was replaced with it by 16:14. The backup restore, had she asked for it, would have arrived on Wednesday morning with Monday's figures.

The slow overwrite is worse for the backup and better for the history. A document that somebody has been quietly damaging for a week, a paragraph lost here, a column there, is already wrong in last night's backup and in the backup before that. The copy wanted is from eight days ago, and only a history that reaches back that far, or a snapshot, can produce it. The same applies to the sync conflict, where two people edit the same file on two computers and one copy wins. It also applies to the "select all, delete, save" that happens when a keyboard shortcut lands in the wrong window. Each of these is a file that exists and is wrong, and for each the first question is "what does the history say?" (The second question is how long the history goes back, which the desk should already know.)

Where Version History Exists and Where It Does Not

Version history is a property of the place the file lives, not of the file. The desk's most useful piece of knowledge on this subject is a plain list of its places and which ones keep versions. The table below is the general shape; the right-hand column is what the desk fills in for its own services. The point of the table is that a user who saves to a place with no history has no nearest layer at all. A desk that does not know which places those are cannot tell them.

Two of these rows catch desks out. The first is the cloud file service that keeps versions but only where somebody switched them on for the share or the library. As a result, half the organisation's folders have a nearest layer and half do not, with no visible difference to the user. Check every share, not the service. The second is the older file server, still common and still trusted, that has a bin and a nightly backup and nothing in between. So an overwrite at four in the afternoon is lost back to the previous night, every time, by design. The desk that knows this can say so before the overwrite instead of after, and the saying is the subject of the next section.

Teaching Users to Find It Themselves

Version history is the one layer that most users can reach without the desk. A user who knows it exists will rescue their own overwrite in a minute instead of raising a ticket, waiting, and losing the afternoon. The desk's job is to tell them, and the telling is harder than it sounds. That is because the feature is invisible until needed and nobody retains instructions for a thing they do not yet need. The telling has to happen at the moment it matters, which is immediately after a rescue. The article Teaching Prevention After the Rescue is about that moment. Here is what to tell them.

The instruction is one paragraph and three actions, written for the desk's own service in the desk's own words. Say where the history is opened from (the file's own menu, in the place the file lives). Say what the list shows (versions, newest first, with times and names). Say what to do with an entry (open it to look, download it as a copy to be safe, or make it current if you are sure). Say which places have it and which do not, by name, so that the user learns where to save at the same time as how to recover. Say how far back it goes, roughly, so that a user who notices a week-old overwrite knows to hurry. And say what to do if the history is empty or missing: raise a ticket, with the file name and the time it was last right. In that case, the desk goes to the next layer.

Write it as a knowledge base article that anyone can read, not one tucked behind the desk's sign-in. The user who needs it is not a technician and will search for it on a bad afternoon. The craft of an article a stressed reader can follow is in One Action Per Step. The version history article is a good first test of it, since it is short and the reader is always in a hurry. If you run QuerySolv, the knowledge base can hold an article visible to everyone, not just to agents. In that case, the link in the after-rescue message goes straight to the steps. Whatever the tool, test the article by asking someone outside the desk to recover a file from history using nothing but the page. If they phone you, the page is not finished.

Then measure it the simple way. Count the overwrite tickets before and after the article went out, over a few months. Count the replies that say "found it in the history, thanks, no ticket needed". Both numbers are small and both are real. The second is the one that tells you the article is being read.

The Sync-Folder Caveat

A sync folder is a folder on the user's computer that a client program keeps mirrored to a cloud file service. That way, the files appear in both places and a change in either is copied to the other. It is convenient and it is where a good share of recovery requests now come from, because its protections are easy to misjudge. The version history, the bin and everything else live on the service side. The folder on the computer is just a local copy. What is on the service is protected by the service; what is only on the computer is protected by nothing.

Three things go wrong. The first is the deletion that syncs. A user deletes a folder on their laptop to free space, believing the "real" copy is in the cloud. The client faithfully deletes it from the cloud too, because that is what syncing means. The folder is in the service's bin, with its window, and nowhere else. A user who does this a month before noticing may be past the window. The second is the paused or broken client. Files saved into the sync folder on a laptop whose client stopped syncing weeks ago never reached the service. They never got a version, and are lost with the laptop. The third is the conflict copy, where two people edited one file on two computers and the client kept both under slightly different names. As a result, the requester's edits are in a file called something like "conflicted copy" beside the original, unlooked-for.

The desk's response to the sync folder is a short set of checks, in the intake and again at the rescue. Is the client running and up to date on that computer? Does the file appear on the service side when viewed from a browser rather than the folder? Is there a conflict copy beside it? And is the deletion in the service's bin? And the desk's message to users is one sentence, repeated until it sticks: the folder on your computer is a window onto the service, not a copy of it, so deleting here deletes there, and a file that has not finished syncing has not been saved anywhere safe. (The little icon that says it has finished is worth a glance. Nobody glances.)

The File Services That Lack It, and What to Do Instead

Some places will never keep versions, and the desk cannot change that this quarter. Those include the older file server that the finance system depends on, and the local disks of a fleet that was never redirected. They include the line-of-business system that stores only the latest revision of each document. For those places the overwrite is a backup question by default, and the backup is a copy from last night. So the honest statement to users is that an overwrite on that server loses the day. The desk can then do three things, in order of effort.

The first is snapshots, where the server supports them. A snapshot is a scheduled frozen copy of the whole volume, perhaps every few hours during the working day. It is reachable by an administrator and sometimes by users through a previous-versions view. Snapshots are not versions, but for the overwrite they do the same job at coarser intervals. Turning them on is a change to the server rather than a project. The second is a more frequent backup of the places that matter most, so that the day's loss becomes a morning's. The third is the habit: on a server without versions, users are taught to save a copy under a new name before a large edit, with the date in the name. That is the nearest layer rebuilt by hand. It is clumsy and it works.

The longer answer is to move the work to a place that keeps versions, and the desk's recovery tickets are the argument. Every overwrite rescued from a backup with a day's work lost is a line in the case for migrating that share. A quarter's worth of such lines is a case nobody on the finance side will argue with, because the lost days were theirs. Keep the lines. The article on measuring recovery requests is how.

What Version History Is Not

Version history is the nearest layer and not the last one, and a desk that lets it replace the backup in its thinking has made a different mistake. It lives in the same place as the file, so anything that takes the place takes the history. That could be a service outage, an account deleted with its library, a share removed, or a subscription that lapses. Version history has a window, and the window is set by the service and often by whoever configured the share. So a damage noticed late may be past it. It keeps a limited number of versions on some services, so that a file saved every minute by an automatic save can push the version wanted off the end of the list by lunchtime. And it records every change faithfully, including the harmful ones.

That last point matters for security, from the defender's side. When malicious software encrypts files across a share, each encrypted file is a new version, and the history holds the clean one behind it. That makes version history a genuine recovery route in that situation. But a well-prepared attacker may also try to exhaust or remove the history. The history sits on the same service the attacker reached. The desk's role in that event is to recognise it, stop, and bring in the security function. The security function will decide what is restored from where. The route for a desk that sees it begin is in When Someone Clicked. The backup, kept separately and ideally somewhere the service cannot reach, is the layer that exists for the day the service itself is the problem. Version history saves more files. The backup saves the service. Keep both, and never let the first argue you out of testing the second.

The Desk's One Page: Which Places Have What

Everything in this article reduces to one page the desk keeps and every technician can see. It lists each place a file can live at your organisation, whether it keeps versions and how far back, and whether it has a bin and how long. It lists whether the place is snapshotted and how often, whether it is in the backup set, and who to ask for each. It takes an afternoon to build, mostly by asking the people who run the services and by deleting a test file in each place and watching where it goes. It is the page the intake question "where did it live?" is answered against, the page the restore workflow visits in order, and the page the users' version history guide is written from.

Keep it dated and review it when a service changes. Those windows get altered by people who do not think to tell the desk. The desk only finds out when a file falls through one. A quarterly test keeps the page honest: one file deleted from each place and one file overwritten in each, with a note of what could be recovered from where. That quietly tests every layer without waiting for a crisis to do it. The page is dull. It is also the single document that turns a recovery request from an investigation into a lookup.

A Short War Story: The Rate Card at Bellweather Logistics

At Bellweather Logistics, a transport planner called Marta overwrote the drivers' rate card workbook with an empty template at about half past three on a Thursday. The whole card was being updated for new contracts that week. The technician, Owen, went straight to the backup because that was what backups were for. He also chose the backup because the file lived on the company's cloud file service, which he knew was backed up nightly. The backup team restored Wednesday night's copy by Friday lunchtime. Thursday's eighty or so rate changes were missing from it. The planners re-entered them over Friday afternoon from memory and e-mail, getting two wrong. That paid two drivers at the old rate the following week and took a further afternoon to correct. On the Monday, a colleague on the infrastructure side mentioned that the file service kept versions. The colleague said that the planning share simply had never had versioning switched on. That was a setting, not a limitation, and took a minute to change. The cost was a day of planners' time, two wrong pay runs, and a quiet conversation with the transport manager. The lesson was that the nearest layer is checked first and switched on everywhere it can be, because a backup from last night was never going to hold Thursday afternoon.

The Versioning Guide for Users

The guide below is the user-facing page, written to be published in the knowledge base where anyone can read it and linked from every after-rescue message about an overwrite. The desk fills in the blanks once, for its own service, in its own words, with the real names of the places. The desk keeps the steps generic enough to survive a service update. The last block is the single most important part, because it tells the user what to do when the guide does not work. That means asking quickly, with the two facts the desk needs.

GETTING AN EARLIER VERSION OF A FILE BACK — ONE PAGE FOR EVERYONE
Service: ______________________   Last checked by the desk: ____/____

WHEN THIS HELPS
  Your file is still there but something is wrong with it: you saved over
  it, deleted part of it, or an edit went wrong. The file keeps earlier
  copies of itself automatically. You can get one back in about a minute.

WHERE IT WORKS
  Files saved in: ______________________ (yes, kept for about ______)
                  ______________________ (yes, kept for about ______)
  Files saved on: your computer's desktop or documents (NO, unless redirected)
                  a removable drive or a personal device (NO)
                  ______________________ (NO: ask the desk; last night's copy only)

THE THREE STEPS
  1. Find the file where it lives and open its history from the file's own
     menu: ______________________________________________.
  2. The list shows every saved version, newest first, with the time and
     the person. Pick the one from just before the problem.
  3. Download that version as a copy first and open it to check. Only when
     you are sure it is right, make it the current version or copy it over.

THREE THINGS TO KNOW
  - The history only goes back about ______. If you notice late, act today.
  - Saving very often can push older versions off the list; check soon.
  - In a sync folder, the history lives on the service, not on your laptop.
    Deleting in the folder deletes on the service too.

IF THE HISTORY IS EMPTY OR MISSING
  Raise a ticket at ______________________ with two facts:
  the file's full name and location, and the time it was last right.
  Do not keep saving the file in the meantime.

Aisha published the guide the week after Jonah's workbook. The underwriting share and the two document libraries were named in the "yes" lines, and the old finance server in the "no" line. Jonah was the first person to use it, three weeks later, on a different file. He replied to the after-rescue message to say so, which is the only review a knowledge base article really needs. The desk's overwrite tickets fell from a few a month to the occasional one from the finance server. That server is now on a list for migration with a folder of tickets behind it.

Frequently Asked Questions