A failed laptop is only one way to lose work
Files are often lost through an accidental overwrite, a broken synchronisation, damaged storage, inaccessible accounts or an unnoticed format problem. Ransomware can encrypt every connected drive. Theft can take both the laptop and a portable disk stored in the same bag. A backup may appear to exist while its job has been failing for weeks or the recovered format no longer opens.
Inventory the project before choosing a tool. Include the thesis text, reference library, consent records, collection files, transcripts, code, figures, outputs and configuration. Mark items that cannot be recreated and those that require special protection. An application can normally be reinstalled; a unique recording or a documented coding decision cannot. Give the irreplaceable material the shortest backup interval.
Use independent failure paths, not merely extra folders
The 3-2-1 rule is a useful planning heuristic: a working copy and two backups, across at least two storage types, with one copy off-site or logically isolated. A student arrangement might combine an institutionally managed drive with version history, an encrypted external solid-state drive and the local working folder. Independence matters more than counting brand names.
Two folders on one physical disk do not protect against disk failure. Two cloud folders that immediately mirror the same deletion are not fully independent either. One backup should not remain permanently writable from the computer. Check the provider's version retention, storage location, access controls and permitted data classes. Confidential participant data should not be placed in a personal consumer account without institutional approval.
Create a version trail that a tired writer can understand
Use unambiguous names and distinguish milestones from automatic backups. 2026-09-04_chapter-3_v07.docx communicates more than final_really_final2.docx. Git can give code and plain text a meaningful history, but a local repository still needs an independent backup. Large binary files usually depend on storage snapshots, service version history or dated archive copies.
Set a retention rhythm: daily states for a short period, weekly milestones for longer, and formal submission packages under the institution's retention rules. Avoid multiplying uncontrolled copies of sensitive data. Availability should not widen access. Document who holds encryption recovery material and how it can be reached in an emergency without exposing passwords in the project folder.
A restore test is the evidence that matters
Every month, or before a milestone, select representative items: the latest chapter, part of the raw data, the reference database, one analysis script and a generated output. Restore them from each backup into a new empty folder. Open them in the intended software, check size and modification time, and compare checksums for critical files. Do not quietly repair the restored copy before recording the result.
Simulate loss of the main machine. Can you retrieve account access, the second authentication factor and encryption recovery keys? Are installation steps available? Could a trusted person find the institutional support route without knowing your passwords? Log the date, source, destination, items tested, result and any corrective action. A failed rehearsal is valuable when it exposes the gap before a real incident.
Contain damage before attempting recovery
If files disappear, pause synchronisation before the deleted state spreads. Avoid writing to a potentially failing device. Record the time, last known good edit and messages shown. From a trusted machine, inspect version history, recycle bins and backup logs. If confidential data may have been exposed or the account compromised, contact the responsible institutional team promptly.
Do not overwrite the only surviving backup during recovery. Work from a duplicate or read-only copy where policy permits. After restoration, compare the inventory and checksums and document any gap. Then correct the backup design. The guide to building a thesis reproducibility package explains how to turn a stable submission state into an inspectable archive.
Make the routine fit ordinary working days
Automate the daily job, but perform a visible weekly check. Create a named milestone before interviews, large recoding operations, software upgrades and submissions. A calendar event can cover restore testing, free space and account permissions. Keep a short offline incident card listing services, support contacts and recovery order, but never plain-text passwords.
Remember that continuity and confidentiality must be designed together. Encrypt portable media, restrict access to administrative records and securely retire obsolete copies under institutional policy. If a collaborator leaves, transfer ownership of shared storage before disabling the account. A technically sound backup that nobody can lawfully access is not a workable continuity plan.