How do you back up your manuscript? (paranoid edition)

@margins_mike OP

3mo ago

A friend just lost two months of work to a dead laptop with no backup and I haven't slept since. I want a setup that assumes everything will fail: the drive, the cloud account, me doing something stupid. What does a genuinely paranoid, no-single-point-of-failure backup routine look like for a manuscript?

11 comments

@ananke_writes3mo ago

The framework you want is 3-2-1: three copies of the file, on two different types of media, with one of them off-site. In practice for a writer: the working copy on your laptop, an automatic cloud sync (Dropbox or Google Drive), and a third copy somewhere the sync can't touch, like an external drive or a versioned backup. The off-site one is what saves you from a house fire or a stolen bag.

@stetson_dan2mo ago

Critical addition to 3-2-1 that bites people: a sync is not a backup. If you delete or corrupt the file, Dropbox happily syncs the deletion to every device in seconds. You need version history. Dropbox and Drive both keep old versions for 30 days on free tiers, so know how to reach that 'restore previous version' menu before you need it in a panic.

@margins_mikeOP2mo ago

The sync-deletes-everywhere thing is exactly the nightmare scenario I hadn't thought through. So the cloud copy alone isn't enough even with two of them. Noted, hard.

@midnight_edits2mo ago

On a Mac, turn on Time Machine with any cheap external drive and you've covered the 'versioned local backup' leg automatically. It keeps hourly snapshots, so you can pull back the version from before you butchered chapter nine this morning. Windows has File History which does the same job.

@the_lurker_9992mo ago

My dead-simple, zero-cost off-site copy: email the manuscript to myself at the end of every writing session, subject line with the date. It's ugly but it's a versioned, off-site, timestamped archive sitting on a server I don't own, and I can get to it from any device on earth. Years of dated drafts in one searchable folder.

@cold_open_cora2mo ago

The leg everyone skips: actually test a restore. Once a month, open the cloud version history and the external drive and confirm you can really get a clean file back. A backup you've never restored from is a guess, not a backup. I found out my external had been silently unmounted for six weeks doing exactly this.

@the_lurker_9991mo ago

Building on the test-restore point: keep the file format boring. Export to plain .docx or .rtf or .txt periodically, not only the proprietary project format. In ten years a .txt will open anywhere; you don't want your only copy locked in a format whose app stopped updating.

@kovac_ink2mo ago

For the technically curious, putting the manuscript in a Git repo is the strongest version control there is. Every commit is a restorable snapshot with a message, and pushing to a private GitHub repo gives you the off-site copy for free. Overkill for many, but if you've ever wanted to see exactly what changed between drafts, nothing beats it.

@scrivener_refugee2mo ago

Git plus Scrivener has a catch worth flagging: a Scrivener project is a bundle of many small files, not one document, so Git tracks it but the diffs are unreadable. Works as a snapshot/restore system, just don't expect pretty line-by-line diffs. For real diffs, commit a compiled plain-text export alongside the project.

@deadline_dodger1mo ago

Don't forget the bible and notes, not just the manuscript. I had the novel triple-backed-up and would have lost my entire series timeline and character notes because they lived in a separate app I never thought about. Back up everything the book depends on, not only the prose.

@margins_mikeOP1mo ago

Putting my actual plan here so others can copy it: working file on the laptop, auto-sync to Dropbox, Time Machine to an external for versioned local, plus an emailed .docx to myself every session as the off-site leg, and a calendar reminder to test a restore monthly. Sleeping again. Thank you all.