An untested backup is an act of faith
I used to think backup was a solved problem. You keep more than one copy, you keep them in more than one place, and you sleep soundly. It took a series of mishaps – some small, some larger, some mine, some watched from the sidelines – to work out that this is not backup. It is the feeling of backup, which is a different and more dangerous thing.
The trouble is that "data loss" is not one problem. It is several, and they fail in different directions, and the measure that saves you from one does nothing for the next. You cannot buy your way out with more copies. You have to know which failures you are actually afraid of, because the failures do not resemble each other and the defences do not overlap.
Here are the ones that taught me.
The corruption you cannot see
When I set up my current system, a batch of InDesign files refused to copy. Not "copied with errors" – they simply failed. When I went to open them at source, they would not open either. The copies on another machine were fine, and I restored from those. No harm done, in the end.
But sit with what happened. These files had degraded without changing their size or their modification date. Apparently InDesign files are prone to this. To any synchronisation tool – mine is Syncovery, which I otherwise rate highly – a file whose size and timestamp are unchanged is, by definition, unchanged. It will not be re-copied. Which means the good version elsewhere never gets refreshed, which proved helpful for recovering the files, but it also means that the rot sits in the corrupted copy invisible and waiting until you need the files.
I got lucky twice over: the corruption happened to surface during a copy operation to generate an additional backup layer, which is really a full read, and an independent untouched copy still existed (see above). Independence saved me – not redundancy, and certainly not the sync, which by its own honest logic could not see a thing wrong. If you take one point from this: a synchronisation that compares only size and date is blind to what is inside the file. It is a filing system, not a guardian.
The corruption that looks like work
The microscopy files were worse, and instructive precisely because they failed the opposite way.
I went to look at some imaging data – just to see what I had done – and it would not open. Not in NIS Elements, not in ImageJ. Dead in both, so not some application sulking. Genuinely gone. And here independence was no help at all, because this time every copy was equally dead. Whatever had happened to them, it had registered as a legitimate change: sizes and timestamps updated, the sync duly noticed a modified file and did exactly what it is built to do: it propagated the damage faithfully to every copy I owned.
This is the mirror image of the InDesign problem, and the pairing is the whole point. One corruption was invisible to the sync and survived because an untouched copy existed. The other was fully visible to the sync and was lost because every copy updated in lockstep. The thing that saved the first – an independent, unmodified copy – is exactly what the second destroyed. No single strategy caught both. Independence answers one; it is useless against the other, which only history – a version from before the damage – could have saved. If I ever need these microscopy data in the future I need to perform the experiments again.
The version you were right to throw away
Not all lost data is corrupted. Some of it you discard on purpose, correctly, and then the ground shifts under you.
Writing the equivalent of a Master's thesis, I had a chapter my supervisor asked me to cut. He was right; it did not belong. Later the work took a turn where that same section suddenly made a great deal of sense, and I wanted it back. Word in those days was famously unstable, so I had some older versions, but not all, and reconstructing the chapter cost me time I should not have had to spend.
The lesson here has nothing to do with corruption or hardware. It is that you cannot know now which version future-you will need. The chapter was not lost to damage – it was lost to a perfectly sound decision that a later decision reversed. Versioning is usually sold as insurance against catastrophe. It is also insurance against your own present judgement, which is a subtler and more frequent problem, because judgement about what matters is exactly the thing that changes. I have kept dated manual versions of anything important every working day since. I do not think I have lost data to my own edits in the years since I started. However, I have discovered that sometimes sections I had written for one purpose and subsequently edited out became useful for a completely different purpose down the line, even though I admit that it is somewhat boring to work through a dozen or so different files before finding the version that contains everything I needed later. It is still easier than writing it all from scratch again, and in contrast to writing it can be done over a glass of wine.
The safety net nobody had checked
At Nottingham, years ago, a critical hard drive failed. Routine enough – that is what backups are for. Except that when we went to restore, we discovered the institutional backup had failed weeks earlier. No error surfaced to anyone. No notification. It had simply stopped, quietly, and no one knew because no one had cause to look until the day it mattered. A specialist recovery firm got some of the data back. Not all of it.
I want to be fair about this, because it is tempting to make it a story about institutional incompetence and it is not. It is structural. Centrally managed backup with limited retention is built for one scenario – the disk dies, the building floods – and it is often decent at that. But a backup is only ever proven by a restore, and if restores only happen in emergencies, silent failure may remain invisible until the day the backup is actually needed. If nobody has restored from the institutional backup to check it is working (and some institutions do check) then nobody finds out it stopped until they need it and it is already too late. An untested backup is not a safeguard. It is a hypothesis you have chosen to believe.
The stakes, briefly
Lest any of this sound like a connoisseur's fuss over checksums and file histories: a student here lost a hard drive three days before submitting her Final Year Project. No backup. A recovery company could not save it. Together with some other issues triggered by this problem it meant that she was unable to graduate. She had to transfer to another university to repeat her final year. All good in the end, but it cost her a year.
It would be easy to file this under bad luck, or to expect the institution to make an exception. It did not, and I am not sure it should have. Computer problems were explicitly excluded from Exceptional Circumstances at the time, and the reason that exclusion is defensible is precisely that the remedy is so trivial. A second independent copy would have cost her nothing and saved her a year of her life. The responsibility was hers. That is an uncomfortable thing to say about someone who was genuinely unlucky, but pretending otherwise helps no one who might read this in time.
So what actually protects you
Nothing single. That is an important conclusion, and it is less bleak than it sounds, because once you stop looking for the one measure that saves you, and start matching measures to failures, the picture becomes almost manageable. Each of these disasters has a defence. They are just different defences, and the trick is having the right one in place before you find out which failure you drew.
Take them in turn.
The InDesign files – silent corruption, invisible to size and date – are defeated by verification: something that reads the content rather than trusting the metadata. In practice that means an occasional full copy rather than a sync (a full copy is also a read test, which is exactly how I caught them), or a periodic checksum pass, which, incidentally, the Syncovery software can do. It just takes time. There are also filesystems that scrub their own blocks in the background. Anything that actually reads the file at least tests something a metadata-only sync never does.
The microscopy files – damage that propagated because it looked like legitimate work – are defeated by versioning with depth: keeping enough past states that at least one predates the corruption. Independence cannot help here, because every current copy is legitimately, identically dead. Only reaching backwards in time recovers you, which means a backup that keeps history, not one that mirrors the present.
The thesis chapter – a version discarded on purpose and later needed – is defeated by the same versioning, used differently: keep your own dated snapshots of anything that matters, and never assume that today's judgement about what is worth keeping will survive contact with next month's problem. This one costs almost nothing. A "save as" with the date in the filename, at the beginning of each day before you start work and done as a habit, is most of the answer.
The Nottingham failure – the institutional safety net that had quietly stopped – is defeated by testing and independence: actually attempting a restore now and then rather than assuming, and never letting a single system, however official, be your only line. If you have never restored from your backup, you do not have a backup – you have a hypothesis wearing a backup's clothes.
And the student's dead drive is defeated by the most trivial measure of all: a second copy, anywhere else. Not clever. Not layered. Just somewhere other than the one disk that can die.
Notice what this list does not require. It does not require the expensive tier, the exotic filesystem, or six-hour rituals you will quietly abandon – I ran a full checksum pass exactly once, took six hours over it, and have no intention of pretending I do it monthly. It requires, in ascending order of effort: a second copy somewhere independent; dated versions of what matters; the occasional full read rather than a metadata sync; and, once in a while, actually testing that the thing you are trusting works. Four modest habits, each aimed at a specific failure, none of them heroic.
What this looks like on a Saturday
I am conscious that most biologists are not, by inclination or training, computer people, and that "keep versioned snapshots with periodic content verification" is the sort of sentence that makes eyes glaze. So here is the concrete version, the one you could actually do this weekend with no software you do not already have.
First, an assumption. I am taking it for granted that you already keep a second copy of your day-to-day work somewhere – a drive you sync or copy to routinely, so that if your laptop dies you have not lost the week. If you do not have even that, stop reading. Now, this second, before you forget. Buy an external drive and start copying your work onto it, because nothing else in this post matters until you have cleared that lowest bar.
What I am describing now is a second drive – and the fact that it is separate is the entire point, because separateness is what lets you leave it alone. Your everyday drive is in constant use: synced, overwritten, updated, exposed to whatever goes wrong on your machine. A drive that is doing a job cannot also be a frozen record. Only a drive with no daily role can be, because only that drive can sit untouched for months without anyone needing to write to it.
So: buy a second external drive. Nothing special – capacity is cheap now, so get one comfortably larger than the data you care about. This drive has exactly one job, and it is not the drive you work from and not the drive you sync to.
Every so often – the end of a project, the day a paper goes off, the start of a new term, whatever rhythm you will actually keep – make a new folder on it named with today's date. 2026-09-07, say, so they sort themselves in order. Copy everything that matters into that folder. Then close it, unplug the drive, and leave it alone. You do not open that folder again. You do not tidy it, sync it, or update it. It is a photograph of your data as it stood on that day, and its whole value lies in never changing.
Next time, you make a new dated folder alongside the old ones. You do not overwrite the previous one – that is the single most important rule, and the one people break to save space, which is a false economy when a drive costs less than an afternoon of your time. Over a year you accumulate a handful of these frozen snapshots, each one a day you can return to.
That is it. And look at what that plain second drive would have caught. The InDesign corruption: because you copy the files in full onto it rather than syncing, the copy is itself a read – a rotted file would likely have choked on the way across, and you would have found out then. It will not catch every failure – silent logical corruption can still copy perfectly happily – but an earlier folder holding a clean version protects against both. The microscopy files: the corruption that overwrote every synced copy could never have reached a dated folder you never sync to, so an older snapshot would still be sitting there, openable. And the central-backup disaster: a drive of your own, that you can plug in and actually open, is not a hypothesis the way an institutional system you have never restored from is. A drive of your own lets you actually test the thing: periodically open files from it, rather than merely trusting that a backup job reports success. One cheap second drive, and a habit of dated folders, covers three of the four failures in this post. It requires nothing more sophisticated than making folders and dragging files into them.
If you want to go one step further, keep two such drives and store them in different places. This is important for several reasons. A second independent physical copy protects you from one backup drive itself failing, it is off-site protection against theft/fire/flood and, importantly, it provides more historical depth. A drive that has sat in a drawer since spring also cannot be attacked by something harmful that arrived in summer (virus, ransomware). This is not a guarantee, but it moves the odds a long way in your favour, which is the most any of this ever does. Still: start with one. One is enormously better than none, and none is where most people are.
That is the useful shape of it. You cannot solve data loss by feeling safe, and you cannot solve it by buying more copies of the same thing. But you can solve most of it, cheaply, by knowing which failures exist and keeping one defence for each in your back pocket. Three copies is not an answer. Three copies, one of them independent, some of them old, occasionally read in full, and once in a while actually tested – that is beginning to be one.
Similar and related blog posts: