Restore files and recover data safely

A user calls at 10:15: a folder deleted twenty minutes ago has to come back. At 14:30 another user’s laptop clicks and then shows “Operating system not found”, and in the evening every file in a shared folder ends in .encrypted, next to a note that demands payment. All three calls are data loss, and each needs a different first move: the wrong one can destroy the data you are trying to save.

By the end you will know where a deleted file survives and for how long, how to restore it without overwriting newer work, when a drive must be imaged before anything else touches it, how to handle ransomware without paying or destroying evidence, and how to prove that a restore is complete.

Restore to an alternate location first

At 11:00 a user saves over a quote and asks for the 09:00 version. Restore the old copy on top of the current file and every edit made since 09:00 is gone for good: Microsoft’s File History page warns that its Restore button replaces the current version and that the replacement can’t be undone. The same page offers the safe route, Restore to…, which writes the old version to a folder you choose.

That is an alternate-location restorealternate-location restore: A restore that writes the recovered copy to a different folder than the file's original one, so it can be compared with the current file before anything is replaced., and it is the default for every restore in this lesson. Put the recovered copy in a separate folder, such as one called restored on the desktop or a folder on another drive, open it beside the current file, check dates and content with the user, and only then move it into place. The one exception is a file taken back out of the Recycle Bin or the Trash: nothing of that name is left at its original path, so it can go straight home.

Step through the flow below. The branch from “User decides” back to the start is the call where the restored version turns out to be the wrong one, and you look for an older copy instead.

Whatever the source, a bin, a backup or a cloud history, the stages stay the same: find the newest good copy, restore it beside the current file, compare, and replace only after the user confirms.

Deleted files wait in bins, backups and the cloud

A file deleted in File Explorer goes to the Recycle BinRecycle Bin: The Windows holding folder for files deleted in File Explorer, called the Trash on a Mac. A file stays there until the bin is emptied, and restoring it returns it to its original folder., and one deleted in the Finder goes to the Trash. Both are holding folders: the file stays until someone empties them, and restoring it returns it to its original folder.

A file that skipped the bin, because it was deleted with Shift + Delete or from a terminal, or a bin that was emptied, sends you to the backups. File HistoryFile History: A Windows feature that copies your libraries, the Desktop and any folders you add to an external drive or a network location, so that earlier versions of files can be restored. copies your libraries, the Desktop and any folder you add to a library, onto an external drive or a network location, and lists each saved copy on the folder’s Previous VersionsPrevious Versions: The Windows tab that lists the copies of a folder File History saved, opened with Restore previous versions. It can open a copy, restore it in place or restore it to another folder. tab. Time Machine on a Mac backs up every hour and thins the history as it ages: one copy an hour for a day, one a day for a month and one a week after that, with the oldest removed once its backup disk is full.

Cloud storage keeps its own bin. OneDrive’s recycle bin holds deleted items for 30 days on a personal account; on a work or school account it holds them for 93 days, unless an administrator changed that setting. An item deleted from that bin cannot come back. Microsoft 365 subscribers can also restore an earlier version of a file from its version historyversion history: The list of earlier saved versions of a file that OneDrive and SharePoint keep, from which an older version can be restored., or roll a whole OneDrive back to any point in the last 30 days.

Read the table from the top when a call comes in: the first row that still holds the file is the quickest restore, and the last column tells you whether its time has already run out. A row only holds the file if someone switched that source on, which is the work of setting up File History, Time Machine and OneDrive; this lesson starts where one of them already has a copy.

Each source has its own restore command

The commands differ by source, and some of them restore in place, so know which one you are about to click:

• Recycle Bin or Trash. Open it, select the file, right-click and choose Restore on Windows or Put Back on a Mac. The file returns to its original folder.
• File History. In File Explorer, right-click the folder that held the file and choose Restore previous versions. Pick a version from before the loss: for a file deleted today, yesterday’s version of the folder should hold it. Open in File History shows what is inside, Restore to… writes it elsewhere, and plain Restore replaces what is there now.
• Time Machine. Open a Finder window for the folder, enter Time Machine and step back with the arrows or the timeline on the right. Select the file and click Restore: it returns to its original location, so move a newer file of the same name out of the way first.
• OneDrive. On the OneDrive website, select Recycle bin in the navigation pane, tick the files and choose Restore.

The program below applies these rules to ten calls a support desk gets. Read the Target line of each plan: only the bin restore and the Mac case go back to the original folder, because nothing of that name is there to overwrite.

"""
Restore plan: choose a source, target and steps for ten loss scenarios.

Each scenario describes what was lost and when. The plan names the
newest good copy, where it goes first and the steps in order: only a
file taken back out of a bin returns straight to its original folder,
because nothing is there to overwrite; every other copy lands in a
separate folder or system first and replaces anything only after a check.
"""

from dataclasses import dataclass

@dataclass
class RestorePlan:
    source: str
    target: str
    steps: list[str]
    reason: str

def plan_restore(scenario: str) -> RestorePlan:
    """Return the restore source, target and ordered steps for a loss scenario."""
    scenarios = {
        "file_deleted_20_min": RestorePlan(
            source="Recycle Bin (Windows) or Trash (Mac)",
            target="Original location",
            steps=[
                "1. Open the Recycle Bin or the Trash",
                "2. Find the file by name and deletion date",
                "3. Right-click: Restore (Windows) or Put Back (Mac)",
                "4. Verify the file opens correctly"
            ],
            reason="Deleted under an hour ago: the bin still has it"
        ),
        "onedrive_folder_3_weeks_work": RestorePlan(
            source="OneDrive recycle bin (work account, 93-day retention)",
            target="Alternate folder first, then original",
            steps=[
                "1. Open OneDrive in a browser",
                "2. Go to Recycle bin on the left",
                "3. Select the folder and choose Restore",
                "4. Compare the restored folder against any local copies",
                "5. Move files to original location after confirmation"
            ],
            reason="Work OneDrive keeps deleted items for 93 days by default"
        ),
        "file_overwritten_today": RestorePlan(
            source="File History (Windows) or Time Machine (Mac)",
            target="Alternate folder (e.g., Desktop/restored/)",
            steps=[
                "1. Right-click the folder, choose Restore previous versions (Windows)",
                "   or open the folder and enter Time Machine (Mac)",
                "2. Select a version from before this morning",
                "3. Windows: Restore to... another folder, never plain Restore",
                "4. Compare both versions with the user",
                "5. Replace original only after user confirms"
            ],
            reason="Plain Restore replaces today's file, and that cannot be undone"
        ),
        "laptop_drive_clicking": RestorePlan(
            source="A backup if one holds the data, else a data-recovery lab",
            target="Lab-provided media, or a replacement drive",
            steps=[
                "1. Power off the laptop and leave it off",
                "2. No disk checks, repairs or recovery software on it",
                "3. Look for the files in backups and cloud storage",
                "4. Nothing there: get the owner's go-ahead for a lab",
                "5. Ship the drive in anti-static, padded packaging"
            ],
            reason="A mechanical fault gets worse each time the drive runs"
        ),
        "ransomware_note_on_share": RestorePlan(
            source="Clean offline backup after incident response",
            target="Rebuilt or verified-clean system",
            steps=[
                "1. Disconnect the device from the network immediately",
                "2. Leave it running; do not wipe it or pay",
                "3. Report to IT security or incident-response team",
                "4. Wait for forensic analysis and root-cause removal",
                "5. Restore from offline backup known to predate infection"
            ],
            reason="Restoring before removing the cause re-infects the data"
        ),
        "phone_dropped_in_water": RestorePlan(
            source="iCloud or Google backup, then recovery lab if needed",
            target="Replacement or repaired device",
            steps=[
                "1. Do not charge it or switch it on to test it",
                "2. Check the date of its last cloud backup from another device",
                "3. Recent backup: restore it to a replacement phone",
                "4. No backup: take the phone to a repair or recovery lab"
            ],
            reason="Power on a wet circuit board can finish it off"
        ),
        "mac_file_deleted_trash_emptied": RestorePlan(
            source="Time Machine backup from before the deletion",
            target="Original folder (nothing of that name is there now)",
            steps=[
                "1. Open a Finder window for the folder that held the file",
                "2. Enter Time Machine and step back with the arrows",
                "3. Select the file in a backup from before the deletion",
                "4. Click Restore: it returns to its original folder",
                "5. Open it with the user before closing the call"
            ],
            reason="Time Machine keeps hourly, daily and weekly backups"
        ),
        "database_file_on_server": RestorePlan(
            source="Server backup (last verified backup before corruption)",
            target="Test database on separate instance",
            steps=[
                "1. Identify last known-good backup timestamp",
                "2. Restore database file to a test server, not production",
                "3. Run integrity checks on the restored database",
                "4. Compare row counts and recent transactions",
                "5. Swap into production only after validation"
            ],
            reason="Restoring directly to production risks data mismatch or downtime"
        ),
        "photo_on_sd_card": RestorePlan(
            source="SD card (original media, read-only mode)",
            target="Local hard drive folder",
            steps=[
                "1. Write-protect the SD card immediately",
                "2. Image the card to a file using a tool like ddrescue or disk imager",
                "3. Run recovery software on the image, not the card",
                "4. Save recovered photos to a hard drive",
                "5. Verify photos open before formatting the card"
            ],
            reason="Working on an image protects the card from further writes"
        ),
        "pc_reset_accidentally": RestorePlan(
            source="File History external drive or cloud backup",
            target="Alternate folder on fresh install",
            steps=[
                "1. Complete the fresh Windows setup",
                "2. Connect the File History backup drive",
                "3. Restore files to a new folder (not original user profile)",
                "4. Move files to Documents, Pictures, etc., after review",
                "5. Reinstall applications from original installers"
            ],
            reason="A reset wipes the profile; cloud and external copies survive"
        )
    }
    return scenarios.get(scenario, RestorePlan(
        source="Unknown",
        target="Unknown",
        steps=["Contact support for guidance"],
        reason="Scenario not recognised"
    ))

def main():
    print("Restore plan for ten common data-loss scenarios\n")
    print("=" * 60)
    
    cases = [
        ("file_deleted_20_min", "File deleted 20 minutes ago"),
        ("onedrive_folder_3_weeks_work", "OneDrive folder deleted 3 weeks ago (work)"),
        ("file_overwritten_today", "File overwritten this morning"),
        ("laptop_drive_clicking", "Laptop drive making clicking sounds"),
        ("ransomware_note_on_share", "Ransomware note found on shared folder"),
        ("phone_dropped_in_water", "Phone dropped in water"),
        ("mac_file_deleted_trash_emptied", "Mac file deleted, Trash emptied"),
        ("database_file_on_server", "Database file corrupted on server"),
        ("photo_on_sd_card", "Photos lost on SD card"),
        ("pc_reset_accidentally", "PC reset without backup warning"),
    ]
    
    for scenario_id, description in cases:
        plan = plan_restore(scenario_id)
        print(f"\nScenario: {description}")
        print(f"  Source: {plan.source}")
        print(f"  Target: {plan.target}")
        print(f"  Steps:")
        for step in plan.steps:
            print(f"    {step}")
        print(f"  Reason: {plan.reason}")
        print("-" * 60)

if __name__ == "__main__":
    main()

Restore plan for ten common data-loss scenarios

============================================================

Scenario: File deleted 20 minutes ago
  Source: Recycle Bin (Windows) or Trash (Mac)
  Target: Original location
  Steps:
    1. Open the Recycle Bin or the Trash
    2. Find the file by name and deletion date
    3. Right-click: Restore (Windows) or Put Back (Mac)
    4. Verify the file opens correctly
  Reason: Deleted under an hour ago: the bin still has it
------------------------------------------------------------

Scenario: OneDrive folder deleted 3 weeks ago (work)
  Source: OneDrive recycle bin (work account, 93-day retention)
  Target: Alternate folder first, then original
  Steps:
    1. Open OneDrive in a browser
    2. Go to Recycle bin on the left
    3. Select the folder and choose Restore
    4. Compare the restored folder against any local copies
    5. Move files to original location after confirmation
  Reason: Work OneDrive keeps deleted items for 93 days by default
------------------------------------------------------------

Scenario: File overwritten this morning
  Source: File History (Windows) or Time Machine (Mac)
  Target: Alternate folder (e.g., Desktop/restored/)
  Steps:
    1. Right-click the folder, choose Restore previous versions (Windows)
       or open the folder and enter Time Machine (Mac)
    2. Select a version from before this morning
    3. Windows: Restore to... another folder, never plain Restore
    4. Compare both versions with the user
    5. Replace original only after user confirms
  Reason: Plain Restore replaces today's file, and that cannot be undone
------------------------------------------------------------

Scenario: Laptop drive making clicking sounds
  Source: A backup if one holds the data, else a data-recovery lab
  Target: Lab-provided media, or a replacement drive
  Steps:
    1. Power off the laptop and leave it off
    2. No disk checks, repairs or recovery software on it
    3. Look for the files in backups and cloud storage
    4. Nothing there: get the owner's go-ahead for a lab
    5. Ship the drive in anti-static, padded packaging
  Reason: A mechanical fault gets worse each time the drive runs
------------------------------------------------------------

Scenario: Ransomware note found on shared folder
  Source: Clean offline backup after incident response
  Target: Rebuilt or verified-clean system
  Steps:
    1. Disconnect the device from the network immediately
    2. Leave it running; do not wipe it or pay
    3. Report to IT security or incident-response team
    4. Wait for forensic analysis and root-cause removal
    5. Restore from offline backup known to predate infection
  Reason: Restoring before removing the cause re-infects the data
------------------------------------------------------------

Scenario: Phone dropped in water
  Source: iCloud or Google backup, then recovery lab if needed
  Target: Replacement or repaired device
  Steps:
    1. Do not charge it or switch it on to test it
    2. Check the date of its last cloud backup from another device
    3. Recent backup: restore it to a replacement phone
    4. No backup: take the phone to a repair or recovery lab
  Reason: Power on a wet circuit board can finish it off
------------------------------------------------------------

Scenario: Mac file deleted, Trash emptied
  Source: Time Machine backup from before the deletion
  Target: Original folder (nothing of that name is there now)
  Steps:
    1. Open a Finder window for the folder that held the file
    2. Enter Time Machine and step back with the arrows
    3. Select the file in a backup from before the deletion
    4. Click Restore: it returns to its original folder
    5. Open it with the user before closing the call
  Reason: Time Machine keeps hourly, daily and weekly backups
------------------------------------------------------------

Scenario: Database file corrupted on server

Every plan that lands somewhere new, a folder, a test server or a replacement phone, ends with a check before anything replaces the original.

A failing drive is imaged before recovery

Back to the 14:30 call: the laptop clicks and will not start. Every attempt to read a failing drive, a disk check, a repair or a recovery scan, may be the one it does not survive. The GNU ddrescue manual is blunt about repairs: a file system on a drive with I/O errors must never be repaired, because the attempt will probably lose even more data.

So the drive is read once, by an imaging tool, and every recovery attempt works on the copy. Disk imagingdisk imaging: Copying a whole drive, sector by sector, to a file or another drive, so that recovery work runs on the copy instead of the original. copies the whole drive, sector by sector, to a healthy drive. GNU ddrescueGNU ddrescue: A GNU tool that copies a failing drive to an image, reading the easy areas first and the failed ones later sector by sector. It records every block's state in a map file, so a rescue can resume. does it in phases: it copies the easy areas first in large reads, then returns to the areas that failed and reads them sector by sector, and it records the state of every block in a map filemap file: The text file in which GNU ddrescue records the position, size and state of every block of a rescue: finished, non-tried, non-trimmed, non-scraped or bad sector.. Run the same command again with the same map file and the rescue resumes where it stopped, without reading the rescued areas twice. The manual names five block states:

• ? non-tried: not read yet; the copying phase reads it next.
• * non-trimmed: a large read failed there; trimming reads its edges one sector at a time.
• / non-scraped: trimmed, but its middle still waits for the scraping phase, sector by sector.
• - bad sector: tried as a single sector, and the read failed. These are the bad sectorsbad sector: A sector of a drive that cannot be read reliably. GNU ddrescue marks a sector bad only after a single-sector read of it, outside a large read, has failed..
• + finished: copied to the image.

The program below reads a sample map file from a lab rescue of a failing 500 GB drive, written into the program as text, and adds up each state:

"""
Read a ddrescue map file and add up what each block state covers.

The map below is a labelled sample from a lab rescue of a failing 500 GB
drive, embedded in the program as text: nothing here reads a real disk.
The block states are the ones the GNU ddrescue manual lists in its
chapter "Mapfile structure".
"""

# A sample map file, saved while the first copying pass was still running.
# A real map file also records the start time and the time it was saved in
# its heading comments; this sample leaves those two lines out.
SAMPLE_MAP = """\
# Mapfile. Created by GNU ddrescue version 1.29
# Command line: ddrescue -d /dev/sdb rescue.img rescue.map
# Copying non-tried blocks... Pass 1 (forwards)
# current_pos  current_status  current_pass
0x5D220B9C00     ?               1
#      pos        size  status
0x00000000  0x3A35294000  +
0x3A35294000  0x00008000  -
0x3A3529C000  0x000F8000  /
0x3A35394000  0x00200000  *
0x3A35594000  0x22ECB25C00  +
0x5D220B9C00  0x174EB4C400  ?
"""

# Block states, in the order ddrescue's phases deal with them.
STATES = {
    "+": ("finished", "never read again"),
    "?": ("non-tried", "copying reads it next"),
    "*": ("non-trimmed", "trimming: its edges"),
    "/": ("non-scraped", "scraping: sector by sector"),
    "-": ("bad sector", "retried only on request"),
}


def parse_map(text):
    """Return (status line, blocks) where blocks is a list of (pos, size, state)."""
    lines = [line.split("#", 1)[0].split() for line in text.splitlines()]
    lines = [parts for parts in lines if parts]
    status_line, block_lines = lines[0], lines[1:]
    blocks = [(int(pos, 16), int(size, 16), state) for pos, size, state in block_lines]
    # The blocks of a map file are contiguous and never overlap.
    for (pos, size, _), (next_pos, _, _) in zip(blocks, blocks[1:]):
        assert pos + size == next_pos, "blocks must be contiguous"
    return status_line, blocks


def size(n_bytes):
    """Decimal units (1 GB = 10**9 bytes), as drive makers and ddrescue count them."""
    for unit, scale in (("GB", 10**9), ("MB", 10**6), ("kB", 10**3)):
        if n_bytes >= scale:
            return f"{n_bytes / scale:.2f} {unit}"
    return f"{n_bytes} B"


def main():
    status_line, blocks = parse_map(SAMPLE_MAP)
    total = sum(n for _, n, _ in blocks)
    by_state = {state: 0 for state in STATES}
    for _, n, state in blocks:
        by_state[state] += n

    print(f"Sample map: {len(blocks)} blocks, {size(total)} in all")
    print(f"Status line: phase '{status_line[1]}', pass {status_line[2]}")
    print()
    for state, (name, next_step) in STATES.items():
        print(f"{state} {name:<12} {size(by_state[state]):>10}  {next_step}")
    print()
    rescued = by_state["+"]
    tried = by_state["*"] + by_state["/"] + by_state["-"]
    print(f"pct rescued: {100 * rescued / total:.2f} %")
    print(f"tried, not yet rescued: {tried:,} bytes")
    print(f"  = {tried // 512:,} sectors of 512 bytes")


if __name__ == "__main__":
    main()

Sample map: 6 blocks, 500.11 GB in all
Status line: phase '?', pass 1

+ finished      400.00 GB  never read again
? non-tried     100.10 GB  copying reads it next
* non-trimmed     2.10 MB  trimming: its edges
/ non-scraped     1.02 MB  scraping: sector by sector
- bad sector     32.77 kB  retried only on request

pct rescued: 79.98 %
tried, not yet rescued: 3,145,728 bytes
  = 6,144 sectors of 512 bytes

Partway through the first copying pass, 79.98 % of the drive is already safe in the image, while the failed areas add up to just 3,145,728 bytes. That is why ddrescue leaves the slow, sector-by-sector work for last: the good data comes off the drive before the drive has to struggle with its bad areas.

The drive being rescued must not be in use while it is copied: the manual warns that a copy of a partition mounted for writing may be useless, and that the drive is best not mounted at all. In practice that means starting the computer from a Linux USB stick, or connecting the drive to another computer, and running ddrescue there.

A lab is for broken hardware, not deleted files

A data-recovery labdata-recovery lab: A specialist service that opens failed drives in a clean room and reads them with its own hardware. It is costly, promises nothing, and is for hardware faults whose data exists nowhere else. can open a drive in a clean room and read it with its own hardware, which no software can do. It also costs far more than any restore and promises nothing, so it is the right call only when the hardware itself has failed and no other copy of the data exists. The table sorts the calls you will meet:

Ask the data owner, or the manager who holds the budget, before a drive goes to a lab, and record the decision in the ticket.

Ransomware: isolate and report before any restore

Ransomwareransomware: Malware that encrypts the files on a device so they cannot be used, then demands a ransom for decryption. Many groups also steal the data first and threaten to publish it. encrypts the files on a device so they cannot be used, then demands a ransom for decryption, and CISA notes that many groups also steal the data first and threaten to publish it. The evening call, a shared folder full of .encrypted files and a note demanding payment, is therefore a security incident, not a restore job, and the order of the first moves matters. CISA’s response checklist, as a service desk applies it:

1. Isolate. Unplug the network cable or turn off Wi-Fi on every affected device. If many devices are hit, the network team takes the network offline at the switch.
2. Keep it running. CISA advises powering a device down only when it cannot be disconnected, because shutting it down loses the evidence held in memory.
3. Report at once, by phone. CISA suggests phone calls and other channels outside the network, so that attackers who read email do not learn they have been found. In India, organisations must report ransomware incidents to CERT-InCERT-In: The Indian Computer Emergency Response Team, India's national agency for cyber security incidents. Its directions require listed incidents, ransomware among them, to be reported to it within 6 hours of noticing them. within 6 hours of noticing them, so the escalation cannot wait for the end of a shift.
4. Preserve. Leave the ransom note and the encrypted files where they are. The incident team uses them to identify the strain, and CISA advises asking law enforcement whether a decryptor exists for it.
5. Restore last. Only after the team has removed the cause and rebuilt or cleaned the systems does data come back, from offline, encrypted backups, onto clean systems. This is the call that an offline copy in the backup plan is kept for.

Restoring early is the classic mistake: while the malware is still on the network, it encrypts the restored copies as well, and the whole restore has to be done again. Step through the flow: the restore is its last stage.

Files that lived in OneDrive have one more route back: once the devices are clean, Microsoft 365 can roll the whole OneDrive back to a point before the encryption, within the last 30 days.

A restore is done when hashes and the user agree

A copy that finished without an error message can still be the wrong version, or a file that lost its last lines. Two checks close a restore: the file’s hash matches the one recorded at backup time, and the user opens the file and confirms it is the one they need.

A hash manifesthash manifest: A list of files with the hash of each, written at backup time, against which restored copies are checked. Lines of the form hash, two spaces, file name are what sha256sum -c reads. makes the first check possible. At backup time it records each file’s SHA-256 hash, a 64-digit hexadecimal fingerprint that changes completely when even one byte of the file changes. After the restore you hash the restored copies and compare. The program below writes a manifest for three sample files, then checks a restore in which one file lost its last line and another had one character changed:

"""
Check a restore against the hash manifest written at backup time.

Three small sample files live in this program as bytes, so nothing on
this computer is read. At backup time the program writes a manifest of
their SHA-256 hashes, one "<hash>  <name>" line per file (the format
sha256sum -c reads). After the restore it hashes the restored copies and
compares them with the manifest, and with the sizes alone.
"""

import hashlib

BACKED_UP = {
    "budget.csv": b"item,amount\nrent,41000\npower,3850\nwater,1250\n",
    "minutes.txt": b"Team meeting\n- move the NAS to rack 2\n- test one restore a month\n",
    "logo.svg": b'<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 8 8"><circle cx="4" cy="4" r="3"/></svg>\n',
}

# The restored copies: logo.svg is identical, budget.csv lost its last
# line, and minutes.txt has one character changed (rack 2 became rack 3).
RESTORED = {
    "budget.csv": b"item,amount\nrent,41000\npower,3850\n",
    "minutes.txt": b"Team meeting\n- move the NAS to rack 3\n- test one restore a month\n",
    "logo.svg": BACKED_UP["logo.svg"],
}


def sha256(data):
    return hashlib.sha256(data).hexdigest()


def write_manifest(files):
    """One line per file, sorted by name: '<64 hex digits>  <name>'."""
    return [f"{sha256(data)}  {name}" for name, data in sorted(files.items())]


def check(manifest, sizes, restored):
    """Yield (name, size check, hash check) for every file in the manifest."""
    for line in manifest:
        expected, name = line.split("  ", 1)
        data = restored[name]
        yield name, len(data) == sizes[name], sha256(data) == expected


def main():
    manifest = write_manifest(BACKED_UP)
    sizes = {name: len(data) for name, data in BACKED_UP.items()}
    print("Manifest written at backup time (first 16 of 64 hex digits):")
    for line in manifest:
        digest, name = line.split("  ", 1)
        print(f"  {digest[:16]}  {name}")
    print()
    print(f"{'After the restore':<20}{'size':<8}SHA-256")
    failed = 0
    for name, size_ok, hash_ok in check(manifest, sizes, RESTORED):
        failed += not hash_ok
        print(f"  {name:<16}  {'same' if size_ok else 'DIFF':<6}  {'match' if hash_ok else 'MISMATCH'}")
    print()
    print(f"{len(manifest) - failed} of {len(manifest)} files verified; {failed} need another restore")


if __name__ == "__main__":
    main()

Manifest written at backup time (first 16 of 64 hex digits):
  ec5fca37182f898f  budget.csv
  5f796d50a3a905f3  logo.svg
  205cf5ec1bfa801d  minutes.txt

After the restore   size    SHA-256
  budget.csv        DIFF    MISMATCH
  logo.svg          same    match
  minutes.txt       same    MISMATCH

1 of 3 files verified; 2 need another restore

Look at minutes.txt: its size is the same as at backup time, so a size check passes it, but its hash does not match. Only the hash catches a change that keeps the size. The manifest lines use the format that sha256sum -c reads, and MySmartCoPilot’s hash generator computes SHA-256 for files in the browser and checks them against an expected hash.

The checklist that closes every restore:

1. Open the file and confirm it displays correctly.
2. Check when it was last changed: is it the version the user expected?
3. Compare its hash with the manifest, where one exists.
4. Ask the user whether this is the file they needed and whether everything is there.
5. Only then move it to its final place, and note the source and the checks in the ticket.

Practise

Put the order of sources into code: the function picks the first place a deleted file can come back from, and it never reads a clicking drive.

def restore_choice(case):
    """Return where to restore a deleted file from first: "bin", "history", "onedrive", "image" or "lab"."""
    return "image"

from restore_choice import restore_choice


def case(drive="healthy", in_bin=False, history=False, onedrive=None, days=0):
    return {"drive": drive, "in_bin": in_bin, "history": history, "onedrive": onedrive, "days": days}


def test_bin_comes_first():
    """takes the file back out of the bin when it is still there"""
    assert restore_choice(case(in_bin=True, history=True, onedrive="work", days=1)) == "bin"


def test_history_before_cloud():
    """uses File History or Time Machine before OneDrive's recycle bin"""
    assert restore_choice(case(history=True, onedrive="personal", days=3)) == "history"


def test_personal_onedrive_keeps_30_days():
    """counts a personal OneDrive recycle bin up to day 30, not day 31"""
    assert restore_choice(case(onedrive="personal", days=30)) == "onedrive"
    assert restore_choice(case(onedrive="personal", days=31)) == "image"


def test_work_onedrive_keeps_93_days():
    """counts a work OneDrive recycle bin up to day 93, not day 94"""
    assert restore_choice(case(onedrive="work", days=93)) == "onedrive"
    assert restore_choice(case(onedrive="work", days=94)) == "image"


def test_nothing_left_but_an_image():
    """falls back to recovery software on an image when no copy exists"""
    assert restore_choice(case(days=0)) == "image"


def test_clicking_drive_is_never_read():
    """skips the bin of a clicking drive and sends it to a lab when no copy exists"""
    assert restore_choice(case(drive="clicking", in_bin=True)) == "lab"
    assert restore_choice(case(drive="clicking", in_bin=True, history=True)) == "history"
    assert restore_choice(case(drive="clicking", onedrive="work", days=40)) == "onedrive"
    assert restore_choice(case(drive="clicking", onedrive="personal", days=40)) == "lab"

Interview questions

Warm-up (fresher to 2–5 years): a user deleted a file from Documents half an hour ago and emptied the Recycle Bin five minutes ago. File History is off and the folder does not sync to OneDrive. The drive is healthy. Where can the file still come from, and what do you do first?

Every quick source is gone: the bin is empty, File History never saved the folder and no cloud copy exists. System Restore will not help either, because it rolls back system files, settings and programs, not documents. What is left is the drive itself, where the deleted file’s data can survive until something new is written over it. So stop using the computer, image the drive and run recovery software against the image, never the drive, saving anything it finds to a different disk. Promise only an attempt, because the tool may find nothing. Once the call is closed, turn on File History or OneDrive folder backup, so that the next deletion has a source.

The next two calls go further, a laptop that will not start and a ransom note on a shared folder. Plan your first three moves for each before you open it:

Key takeaways

• Restore beside the current file first, compare with the user and replace only after they confirm; only a file taken out of a bin goes straight back to its folder.
• A deleted file waits in the Recycle Bin or Trash, then in File History or Time Machine, then in OneDrive’s recycle bin for 30 days on a personal account or 93 on a work one.
• A failing drive is read once, by ddrescue, and every recovery attempt works on the image; the map file records each block’s state so the rescue can resume.
• A data-recovery lab is for failed hardware whose data exists nowhere else, never for a deleted file on a healthy drive or for encrypted files.
• Ransomware response is isolate, keep the device running, report at once, preserve the evidence and restore last from offline backups; official guidance advises against paying.
• A restore is complete when the hashes match the manifest and the user confirms the file.