Data recovery: an archaeologist looking for lost documents

The Central Document Warehouse, named after its Manager, survived the fire. Well, the company did, thanks to the accountant's backup drive hidden beneath her socks. The RAID was rebuilt, backups were organised, and the manager solemnly declared the end of all data problems. The very next morning, a scream came from his office that frightened even the printer. Welcome to digital archaeology: data recovery.

Chapter one: the manager deleted something very important

— FRANK! MY FILE IS GONE!
— Which file?
— A VERY IMPORTANT ONE!
— What was it called?
— “NEW DOCUMENT (FINAL) (FINAL 2)”.
— Where was it stored?
— On the desktop.
— And what were you doing before it disappeared?
— CLEANING UP! I DELETED EVERYTHING THAT LOOKED USELESS!
— We'll check the Recycle Bin.
— I TOOK OUT THE RUBBISH! I EMPTIED THAT TOO!

🤣🤣🤣

Data recovery means trying to regain access to information that has been deleted, damaged, lost or become inaccessible. Sometimes all you need is the Recycle Bin's Restore button. Sometimes you need a backup. And sometimes the hardware itself is damaged, and each careless operation makes things worse.

Here's an important distinction: restoring from a backup uses a copy you prepared earlier. Recovering data from a storage device means trying to salvage what remains on the disk or another medium. The first is generally more predictable. The second offers no guarantee.

Chapter two: the three most expensive words — “I've fixed it”

— What did you do after deleting it? — asks Frank.
— INSTALLED FIVE RECOVERY PROGRAMS!
— On which drive?
— THE ONE THAT LOST THE FILE!
— And then?
— DOWNLOADED A VIDEO TUTORIAL!
— Onto that drive too?
— WHERE ELSE WAS I SUPPOSED TO DOWNLOAD IT?!
— ...
— FRANK, STOP LOOKING AT ME LIKE I'M A HARDWARE FAILURE!

🤣🤣

When data may have been accidentally deleted, the first priority is to minimise further writes to the affected device. Don't reflexively install new programs, download files onto the same drive, format it or run repair tools just because the computer offers to. New writes may overwrite the very information you're trying to recover.

If a disk shows symptoms of physical failure — clicking, disappearing, becoming abnormally slow or reporting increasing errors — stop using it. Repeated startups or scans of a mechanically failing disk can reduce recovery chances. If the data matters, a specialist recovery lab may be a better option than experimenting.

An important exception to “turn everything off”: situations involving active ransomware, mounted encrypted volumes or business services may require a different incident-response procedure. There is no universal command for every data-loss event. When you're unsure, avoid random experiments and first determine whether you're dealing with deletion, hardware failure, filesystem corruption or a security incident.

Chapter three: check the drawers before digging for fossils

— BOSS, DID YOU CHECK THE RECYCLE BIN?
— EMPTY!
— Document version history?
— WHAT HISTORY?! THIS ISN'T A HISTORY LESSON!
— The cloud service's deleted-files folder?
— THE CLOUD HAS A BIN TOO?!
— Yesterday's backup?
— ...
— Boss?
— PLEASE TELL ME I DON'T HAVE TO ASK THE ACCOUNTANT FOR HER SOCKS AGAIN!

🤣🤣

Begin with the least invasive recovery options: your operating system's Recycle Bin, application trash folders, document version history, cloud recovery tools, application autosaves, backups and any available snapshots. Remember that retention periods for versions and deleted items vary by service and configuration.

Direct recovery from physical media can be more dangerous and time-consuming. If the document is safely waiting in a version from an hour ago, there is no reason to start archaeological excavations on an SSD.

Chapter four: deleting a file doesn't always erase it instantly

— FRANK, IF I DELETED THE FILE, WHERE IS IT NOW?!
— Depends on the filesystem and drive type.
— I ASKED ABOUT MY FILE, NOT PHILOSOPHY!
— In many cases deleting the file removes the information used to find it, while some of its content may remain in storage.
— THEN CALL IT BACK!
— The problem is that new data can take its place.
— PUT UP A SIGN THAT SAYS “OCCUPIED”!

🤣🤣

In simplified terms, deletion often changes the structures that organise data rather than instantly erasing every stored bit. But that doesn't guarantee recovery. The outcome depends on the filesystem, device condition, later writes, encryption, snapshots and free-space management.

Recoverable fragments may survive without original filenames or directory paths. A tool might find an image but no longer know it lived inside “Holiday Photos 2014”. That's why a program claiming “100% of files recovered” means little until the files are checked for completeness and actually opened.

Chapter five: HDD versus SSD — an unpleasant surprise

— I'VE BOUGHT MODERN SSDs! NOW RECOVERING FILES WILL BE EASIER!
— Not necessarily.
— WHAT DO YOU MEAN?!
— SSDs commonly use TRIM and internal memory management.
— WHAT DOES TRIM DO?!
— It can tell the drive which blocks are no longer needed. Along with the controller's behaviour, that may prevent later recovery.
— SO I PAID MORE TO MAKE MY FILE DISAPPEAR MORE THOROUGHLY?!

🤣🤣

On a traditional HDD, content may remain in physical sectors after deletion until overwritten. There's still no guarantee, and no reliable safe time window. On an SSD, TRIM, controller behaviour and garbage collection can make recovering deleted data much harder, or impossible. The outcome also depends on the system, controller and configuration.

SSDs are excellent for everyday work. But they're a good reminder that backups matter more than hoping to recover a deleted file later. The same goes for encryption: if vital keys are lost, data may remain physically present yet be computationally inaccessible.

Chapter six: the drive clicks and the manager tries persuasion

A steady “click, click, click” comes from the server room.

— FRANK! MY HARD DRIVE IS CLICKING!
— Turn it off and don't restart it.
— BUT WHAT IF I SWITCH IT ON THREE MORE TIMES AND IT CHANGES ITS MIND?!
— This isn't a negotiation, boss.
— WHAT IF I TAP IT GENTLY FROM THE OTHER SIDE?!
— Definitely not.
— PUT IT IN A FREEZER?!
— No. No home experiments.

🤣🤣

With suspected mechanical HDD failure, repeated power cycles, long scans and improvised treatments such as freezing, shaking or opening the enclosure are risky. Problems with heads, platters or electronics aren't repaired by folk remedies from online forums. Professional labs use specialised equipment and controlled conditions, but even they cannot recover everything in every case.

A damaged partition table or filesystem on otherwise healthy hardware is a different situation. First, however, you must work out which problem you actually have.

Chapter seven: image first, experiment later

— FRANK, I'VE FOUND SOFTWARE THAT FIXES EVERYTHING!
— Let's not run it on our only copy of the data.
— THEN WHERE?!
— If the device is stable enough, we can first create a sector-by-sector image on a separate healthy drive.
— WHY?!
— To analyse the copy instead of risking the original.
— SO WE BACK UP THE DRIVE THAT'S ALREADY FAILING?!
— In some situations, yes — carefully, and not always by ourselves.
— GENTLEMEN, I'M BEGINNING TO UNDERSTAND WHY IT PEOPLE OWN SO MANY DRIVES!

🤣🤣

Data recovery often uses a sector image, a copy of the storage medium's contents from which analysis can proceed without modifying the original. This isn't the same as copying the files you can see in a file manager. Working with an image reduces the chance of a failed repair destroying the only available version of your information.

However, you shouldn't image every faulty disk yourself. A drive with major physical problems may deteriorate simply from being read. A specialist should then determine the next step. And on a stable drive, carefully identify source and destination: copying in the wrong direction can irreversibly overwrite what you're trying to save.

Chapter eight: “repair disk” isn't always good advice

— THE COMPUTER SAYS I SHOULD REPAIR THE FILESYSTEM!
— First let's preserve the data and find out what's wrong.
— BUT THERE'S A BUTTON THAT SAYS “REPAIR”!
— Some tools fix filesystem consistency by discarding damaged entries.
— SO THE DISK GETS REPAIRED BUT MY FILE GETS LEFT IN THE WOODS?!
— That's one possibility.
— GENTLEMEN! REMOVE THE “REPAIR” BUTTON AT ONCE!

🤣🤣

Tools such as CHKDSK, fsck and similar utilities aim to restore filesystem consistency. That isn't the same as maximising the recovery of every missing piece of information. Repair operations can change metadata, detach damaged directory fragments or remove invalid references.

If recovering lost data is the priority, the safer sequence is usually: stop unnecessary writes, identify the type of failure, preserve the source or an image, and only then consider repair. Don't run destructive operations blindly.

Chapter nine: RAID returns like a recurring nightmare

— FRANK! BUT WE HAVE RAID!
— Yes, boss.
— THEN MAKE RAID RECOVER MY FILE!
— RAID can protect against certain drive failures. It doesn't automatically reverse logical deletion.
— THEN WHY DO I HAVE RAID?!
— So services can keep running through some kinds of hardware faults.
— DOES IT UNDELETE THE FILE ON ALL THE DRIVES?!
— No. The deletion generally propagates through the array.
— DIDN'T WE DISCUSS THIS BEFORE THE FIRE?!
— We certainly did.

🤣🤣

RAID is not a backup. That matters for recovery too. In a suitable RAID configuration, redundancy can help tolerate one or more device failures. But accidental deletion, file encryption, a database overwrite or an application bug doesn't magically get reversed.

Recovering a damaged RAID array can also be more complex than recovering a single drive: member order, metadata, stripe layout, RAID level and the condition of each device all matter. Don't recklessly initialise or rebuild the array if your data is at stake.

Chapter ten: backups versus recovery — two rescue teams

The accountant raises her hand.

— Why not just restore yesterday's backup?
— BUT I WANT TODAY'S VERSION! — protests the manager.
— Yesterday's copy is verified. We can look for today's edits in version history.
— AND IF THEY'RE NOT THERE?!
— Then we assess how much work is missing and whether media recovery makes sense.
— SO BACKUP IS PLAN A AND ARCHAEOLOGY IS PLAN B?!
— Usually, yes.

🤣🤣

Where a verified backup exists, restoring it is often simpler and safer. Check its age, though, and take care not to overwrite newer, unrelated data during restoration. It can be wise to restore files into a separate folder, compare versions, then decide which to keep.

Databases and applications can require a different procedure: one file copied from a running application isn't necessarily consistent. Transaction-aware backups, change logs, correct restoration order and validation may be necessary. That's one reason to plan recovery before something disappears.

Chapter eleven: the cloud remembers — but not forever

— FRANK! MY FILE HAS DISAPPEARED FROM THE CLOUD TOO!
— Synchronisation may have carried the deletion across.
— SO THE CLOUD HAS BETRAYED ME?!
— Let's check its version history, deleted-files area and archived recovery points.
— WHAT IF IT'S NOT THERE?!
— We turn to other copies.
— ...
— CALL THE ACCOUNTANT. TELL HER NOT TO THROW THE SOCKS AWAY YET!

🤣🤣

Cloud services may provide version history, deleted-file recovery, retention periods and restore features. Their extent varies with plan, settings and how long ago the event occurred. Synchronisation isn't the same as an independent backup. Even when a provider allows recovery of deleted files, it's wise to maintain an isolated copy that automated deletion or compromised credentials cannot reach.

If the cause is account theft or ransomware, first secure access and prevent further unwanted changes. Restoring files before containing the incident can mean watching them disappear all over again.

Chapter twelve: DIY recovery or a professional lab?

— BOSS, HOW VALUABLE IS THIS DATA?
— PRICELESS!
— How many independent copies do we have?
— ZERO!
— Is the drive working properly?
— IT CLICKS LIKE AN OLD TRACTOR!
— Then let's not experiment.
— BUT AN ONLINE FORUM SAID TO PUT IT IN A FREEZER!
— Another forum said not to listen to that one.
— WHICH FORUM IS RIGHT?!
— Neither is a replacement for diagnosis.

🤣🤣

DIY recovery may be reasonable with low-value data, a stable drive and a clear logical problem, ideally after taking a safe image and with an understanding of the risks. With physical failure symptoms, damage from water or fire, serious electronic problems or exceptionally valuable information, consider a professional data recovery lab.

No credible lab should promise universal success. Ask about diagnostics, handling of the device, fees, confidentiality and how recovered data is delivered. Sensitive data may require additional care when entrusted to an outside provider.

Chapter thirteen: the manager writes a list of things not to do

A board appears on the new warehouse wall. The manager writes in enormous letters:

— “DON'T OVERWRITE!”
— Good, boss.
— “DON'T FORMAT IN A PANIC!”
— Very good.
— “DON'T RUN RANDOM REPAIR TOOLS!”
— Excellent.
— “CHECK THE BIN, VERSIONS AND BACKUPS!”
— Brilliant.
— “DON'T PUT DRIVES IN FREEZERS!”
— Essential.
— “CALL FRANK BEFORE I DO ANYTHING!”
— That's the best rule — says Frank.
— **AND DON'T TOUCH THE ACCOUNTANT'S SOCKS!**
— That may be a separate security policy.

🤣🤣🤣

Core rules: stop activities that could change the missing data; start with the bin, version history and verified backups; find out whether the hardware is healthy; don't experiment on the only original; seek specialist advice for serious failures; and after recovery, verify that the files actually work.

Recovery isn't magic. Sometimes you can save everything, sometimes only part, and sometimes nothing at all. The best time to prepare a data recovery plan is before data loss.

Finale: the archaeologist who didn't have to dig

— FRANK! DID YOU FIND MY DOCUMENT?!
— Yes. In the application's autosaved version history.
— WITHOUT OPENING THE DRIVE?!
— Yes.
— WITHOUT A LAB?!
— Yes.
— WITHOUT A FREEZER?!
— Definitely.
— THEN WHY DID I READ ALL THOSE TUTORIALS?!
— So you'll check version history first next time.

The accountant looks into the office.

— Yesterday's backup completed too.
— MARVELLOUS! NOW WE CAN STOP WORRYING AGAIN!
— We can stop panicking. We can't stop checking the backups.
— GENTLEMEN! CAN YOU GO JUST ONE DAY WITHOUT MENTIONING BACKUPS?!

🤣🤣🤣🤣

Remember: after losing data, the first job isn't to “fix something right now”. It's to avoid destroying your last chance of recovery. And if you have a verified backup, all that archaeology is often unnecessary.

The Central Document Warehouse declares success. The manager recovered his document. Frank recovered his peace of mind. The accountant recovered her socks — without specialist software.