Backing Up My Thesis and Research

A working backup routine takes twenty minutes to set up and can save you months. Here is how to do it properly on Windows, Mac, or Linux — and, more importantly, why the obvious approach is not enough.

...but Word saves automatically, doesn't it?

...how do I make sure Word documents in particular get backed up?

Word's own features are not enough (see above), so the job falls to the system-level tools on this page — but there are two Word-specific steps worth taking.

First, turn on "Always create a backup copy" in File → Options → Advanced → Save. It keeps only the single previous version, but that single version has saved people from a bad save, and it costs nothing.

Second — and this is the reliable one — make sure your dissertation folder is inside whatever versioned backup you set up below (File History, Time Machine, Déjà Dup). That is what gives your `.docx` files real version history: not Word's doing, but the operating system's, sitting underneath Word and catching every saved version regardless of what Word itself does.

If you want belt-and-braces, third-party tools such as Duplicati or Macrium Reflect (Windows) and restic or Duplicacy (cross-platform) can back up your document folders on a schedule, encrypted, with deep version history, to a local drive or a cloud target. These are more than most candidates need, but if you have been burned before, they are worth the small amount of time it takes to set one up. The principle is the same as everything else on this page: something outside Word must be keeping dated, restorable versions of your file.

...should I just use LibreOffice? It's free.

LibreOffice is genuinely excellent, and for a document you control from start to finish it is a fine choice. But there is a specific, painful trap that we have watched catch candidates at the worst possible moment, and you need to know about it before you commit.

University dissertation templates are frequently complex, fragile, Word-specific files — and third-party word processors, including LibreOffice, usually break them. These templates lean on exactly the features where LibreOffice and Word diverge: custom named styles that do not map cleanly, nested tables, automatic fields, section breaks with linked headers and footers, embedded fonts, and precise page-layout rules that your institution's formatting reviewer will check line by line.

Open such a template in LibreOffice, work in it for weeks, save it back to `.docx`, and sometimes the damage is obvious. More often it is invisible to you and glaring to your reviewer: heading styles subtly renumbered, the table of contents miswired, margins or line spacing shifted, a landscape section gone portrait. You did nothing wrong. The two programs simply render these fragile constructs differently, and the round-trip through `.docx` does not survive intact.

Our practical advice:

• If your institution provides a mandatory Word template, use Word for the final document. This is the one situation where we do not recommend LibreOffice, and the stakes — a formatting rejection at School Review, days before your deadline — are too high to gamble on compatibility.
• If you strongly prefer LibreOffice, write your content in it, but move into the official Word template late, in Word, and do your final formatting there — then never round-trip it back to LibreOffice. Keep the two jobs separate: LibreOffice for drafting if you like it, Word for the template-bound final.
• Whichever you use, if you are handed a template, test it early. Put a page of dummy content through the full formatting requirements weeks before submission, not the night before, so any breakage surfaces while there is still time to deal with it.

There is one more version of this trap that catches people by surprise: collaboration. The moment your template-bound document passes between two people using different software — you in Word and an editor in LibreOffice, or the reverse, or two people on different LibreOffice versions — every round-trip is another chance for the fragile formatting to shift. This matters directly when you are choosing who to work with. Some low-cost and offshore editing operations run entirely on LibreOffice, and a complex university template handed to such an editor can come back subtly broken, with neither of you aware until a reviewer flags it. If you are sharing a template-bound document with anyone, agree on a single program and a single version before a word is exchanged, and keep one person as the authoritative holder of the master file. (For what it is worth, this is one of many reasons we work in whatever environment your institution requires rather than whatever is cheapest for us. By default, for dissertations and professional writing, we use MS Word.)

A note for Linux users specifically.

...stop 'wining' and start writing...

If you run Linux and have leaned on — or are thinking of leaning on — LibreOffice only because you assumed Word was not an option, that assumption may be wrong. Given the template risks above, we do, sadly, recommend MS Word — especially if your institution provides templates whose use is compulsory. So what are your alternatives?

Traditionally the best two were to dual-boot with Windows (an approach we ourselves used for many years) or to run a Windows compatibility layer such as Wine — the classic option, but at a real cost in efficiency and with less than full functionality. In more recent years, some ran a whole Windows virtual machine just to reach MS Office, which works but is heavy.

Now there is a far more elegant answer, and it is the one we use: run a headless container with a legal copy of MS Word (or MS Office) inside it. It allows file sharing from within Linux, it looks and behaves like a native Linux window, and on a reasonably specced laptop or workstation performance is excellent — close to native. One firm caveat: it must be a distinct, separately licensed copy, not one shared or re-used from another machine. Doing it right means doing it licensed.

If the container route appeals but the setup is beyond you, ask us — walking candidates through exactly this kind of hard-won technical detail is part of what we do.

This is exactly the kind of avoidable, structural problem that stalls a submission at the last moment — and exactly the kind of thing an advanced editor catches, because it lives in the whole document's construction, not in any single sentence.

...isn't my work already safe in OneDrive / iCloud / Google Drive?

...how do I back this up properly? (the principle)

...on Windows

1. Connect an external drive (a cheap USB drive is fine; keep it plugged in or reconnect it regularly).
2. Open Control Panel → System and Security → File History (menu current at time of writing).
3. Select your external drive and turn File History on.
4. In Advanced settings, set how often it saves (hourly is a sensible default) and how long to keep versions (until space is needed, or a fixed period).

File History now keeps versioned copies automatically. To restore an older version: right-click the file or folder → Restore previous versions.

Off-site copy — OneDrive:

OneDrive is free with a Microsoft account, which is also free, and gives you 5GB. Five gigabytes is more than enough for any dissertation project. A Microsoft 365 subscription raises that to 1TB. In Settings → Accounts → Windows Backup, enable folder backup for Desktop and Documents. Note OneDrive's own version history: right-click a file on the OneDrive website → Version history lets you roll back individual files, and its Recycle Bin holds deleted items for 30 days on a personal account — 93 days on most institutional ones.

Together, File History plus OneDrive gives you all three copies.

...on macOS

Version history on a local drive — Time Machine:

1. Connect an external drive, ideally one dedicated to backups.
2. Apple menu → System Settings → General → Time Machine (menu current at time of writing).
3. Add your drive as the backup disk.

Time Machine then keeps hourly, daily, and weekly versions automatically. To restore: enter Time Machine and step back through time to the version you want.

Off-site copy — iCloud:

iCloud Drive with Desktop and Documents sync keeps your files across devices and in the cloud. Be clear about its limits, though: it is a sync service, not a backup — deletions propagate, and it only covers iCloud-designated folders. Apple does not permit Time Machine backups to be stored in iCloud. So on a Mac, Time Machine is your real versioned backup and iCloud is your off-site sync — you want both, doing different jobs.

...on Linux

The friendly option — Déjà Dup:

Déjà Dup (Backups) is the simplest tool and is in most distributions' software centers, or install via your package manager. It does encrypted, incremental, versioned backups to an external drive, a network share, or a cloud target, with simple daily/weekly scheduling. Point it at your Documents folder and a destination, turn on automatic backups, and it handles the rest. Restoring is a matter of picking a date.

If you want more control — rsync:

For those comfortable in a terminal, a scheduled `rsync` to an external drive gives precise control, and combined with `--backup` and dated directories it produces real version history. A cron job or systemd timer automates it.

Snapshots — Timeshift:

Timeshift is excellent for snapshotting your whole system, and superb for recovering from a bad update. But its default purpose is system files, not your documents. Configure it to include your home directory, or run it alongside Déjà Dup, which is document-focused by default. Left on its defaults it will not protect your thesis.

Off-site copy:

Sync your backup destination or your working folder to a cloud service. Most cloud providers have Linux clients or work via rclone, which now supports a wide range of providers including iCloud, OneDrive, and Google Drive.

...on your phone and tablet

The failure that actually happens:

You open the chapter on your phone in a waiting room, fix a sentence, and close it. Two days later you cannot find the paragraph you rewrote on your laptop on Tuesday. Nothing was deleted and nothing crashed. Your phone had an older version cached, opened it, saved it, and the sync obediently pushed that version everywhere. This is the single most common way we see recent work disappear, and it does not look like a disaster at the time — it looks like you misremembered.

What to do about it:

Do not treat a phone as a place to work. Read on it freely. Comment on it if the app supports comments rather than edits. Make substantive changes on a machine with a real keyboard and a real backup behind it.

If you must edit on a phone, open the file only when you have a signal, so it fetches the current version rather than a cached one, and let it finish syncing before you close the app. Half a sync is worse than none.

Device backup is not document backup:

iCloud Backup and Google One back up your device, not your dissertation. They will restore your phone if you drop it in a river. They will not give you last Tuesday's version of chapter three, which is the thing you will actually need. Version history lives in your document service — OneDrive, Google Drive, Dropbox — and it is worth finding out today where yours is and how far back it goes.

Photographs of whiteboards, notes and interview recordings:

These are research data and they are usually the least backed-up thing a candidate owns. Interview audio in particular often exists in exactly one place, on the phone that recorded it. Get it off the phone the same day, into the same backed-up folder as the rest of your material — and if it is participant data, into wherever your ethics approval says it must live.

...what if it is already too late?