Lately I’ve been following more and more full-time authors on Twitter and several of them mentioned the dubious practice of emailing themselves the current version of their manuscript, as backup. And sure, it works. The same way an open fire in your backyard works as a source of heat for regular daily cooking when you’ve got a perfectly functional stove in the kitchen.
Before we get into the methods of backing up your manuscript, please consider the following safety tips:
Divide and conquer
The larger your manuscript is, the more likely it is to get corrupted. I assume most authors use Word for their writing but this applies to any large document. If there’s no compelling reason to use a single file (for example, continued numbering of figures and tables in non-fiction manuscripts), one practice that will immediately make your work safer is to divide and conquer. Write each chapter/scene in a separate file.
Use Scrivener
Scrivener is an app developed specifically for creating and organizing long written works. It’s highly customizable, remarkably stable and packed with incredibly useful features. That makes it a bit daunting at first glance, but you can get started by just creating a blank document and typing, and then learn the other things on a need-to-know basis.
Scrivener assumes and encourages the divide and conquer strategy. Every scene or chapter goes into its own document that you can create a synopsis for, label and color-code. The files are kept under the hood: you do all the management inside Scrivener and interact only with the main project file outside of it. This keeps your work tidy and it’s fairly fool-proof.
Another relevant feature is a built-in versioning system. You can at any point create a named snapshot of any document, which comes in handy when making big changes to existing text. It’s a copy of your document that you can come back to later, and to a degree serves as a backup. Since it’s a part of the Scrivener file system, it won’t create clutter and you can have as many snapshots as you need.
Of course, the above won’t help if your computer catches fire. Here are some ways to back up your manuscript without emailing different versions of it to yourself, in order of growing sophistication:
1. Use dedicated backup software
You can make regular, automated backups of your manuscript to an external HDD, USB or cloud using dedicated backup software. It’s fairly straight-forward to set up:
- Choose the folder(s) you wish to back up
- Choose the device or service providing the storage space
- Set the frequency of backups (weekly, daily, hourly)
- Set a limit in terms of time (when can old backups be overwritten? after a week? month? year?), number of copies (save only N last backups, then overwrite the oldest one) or storage space (save copies until the backup reaches a certain size, then overwrite the oldest one)
— and you don’t ever need to think about it again. I haven’t much experience with this as most my projects are under version-control (covered below), but I’ve been recommended the Todo Backup which has a fully functional free tier.
2. Use a cloud storage service
I personally use OneDrive, but the most popular is Dropbox. Both offer limited storage (5 and 2 GB respectively) for free. OneDrive might be especially interesting to people who use Office, as some types of Office licenses/subscriptions unlock as much as 1 TB of OneDrive storage at no additional cost.
Cloud services come with desktop and mobile apps that facilitate access to your files. The desktop app will create a special folder for your cloud storage. Anything you put in it is automatically saved in the cloud. The only way to lose a file in cloud storage is to manually delete it (which admittedly might happen unintentionally, but so could deleting that email you sent to yourself). OneDrive has a recycle bin that allows you to recover an accidentally deleted file within a month.
Cloud services also keep a history of file changes by default. Every time you save your document, a copy of the old version is discretely created in the cloud. On OneDrive, this is viewable from the web-interface as a list of versions and dates of their creation.
A very useful side-effect (for some it might be the main point) of using cloud storage is that your files become available to you online and on different devices with little to no hassle. Just install the app on all your devices and the cloud service will keep your files synced everywhere.
3. Use SVN
Things get a little more complicated here but learning about dedicated version-control systems is well-worth the effort. SVN is one of many such systems in existence. I only have experience with one other (Git, covered next), but once you’ve grasped the basics of one, you’ll have grasped them all.
In a way, this too is a form of cloud storage, tailored specifically for version-control, and with more control over the synchronization between local and remote files. With cloud storage, the service creates a special folder and anything you put in it gets synchronized automatically. With SVN, you designate a folder for your project on the remote server (the repository) and synchronize it manually with a local folder on your computer (the working copy). After the initial setup, working with SVN comes down to a couple clicks before and after a work session. Typically you start by updating your working copy so that it picks up the latest versions of all your files. Then you do your work of changing, adding or deleting files and folders. When you’re done, you review and commit the changes, so that the repository will now contain the new versions of your files.
You can view all the changes ever committed to the repository in a tidy log. You can at any time open an old version of a file to inspect it, compare it to the current version, save it as a separate file or restore it, overwriting the current version. All these things are done in the working copy, so there’s very little chance of messing anything up. Even if you do mess up, you’re not obliged to commit the mess: you can at any time revert any file, folder or the whole project to the state found in the repository, or check out a fresh working copy and delete the messed up one with no worries. Nothing syncs unless you want it synced.
SVN is just as convenient when you switch computers as cloud storage, as long as you always remember to commit your work when you’re done on one device, and update the working copy on the other before starting to work there.
But SVN is much more convenient than cloud storage when collaborating with other people on the same project. This isn’t a situation one often sees in writing, but it’s not unheard of either. Everyone involved gets their own credentials for the remote server and can check out their own working copies of the repository. SVN is usually smart enough to be able to merge changes made by two or more people on the same document, as long as the changes don’t overlap, in which case a human must resolve the resulting conflict.
The repository will continuously grow and store all versions of all your files ever committed to it. If you delete a bunch of files and commit those changes, these files will no longer appear in that version and onward, but they’ll still be present in all the previous versions. There are no time limits, and nothing is ever truly lost. It is really quite hard to do permanent damage to a project under SVN.
There’s a very nice app for SVN on Windows — TortoiseSVN. It integrates into the right-click context menu so that the update/commit commands are literally at your fingertips.
SVN is my backup-version-control system of choice. I use it for all my writing projects, and for many of my work projects. But since I use SVN that’s hosted at my workplace, I haven’t any experience with SVN hosting available online and can’t make reliable recommendations. I know that SourceForge offers free SVN hosting, but one can’t have a private project there for free. Search the web for free private SVN and try out some services with toy projects before you decide which one to use.
Assuming you found a SVN service and installed TortoiseSVN, follow these steps to get started:
Initially:
- Create a repository for your project on the remote server.
- Create an empty folder on your computer, and check out a working copy of the repository by right-clicking the folder and selecting “SVN checkout…” You’ll need to enter the address of your SVN server, the name of your project and your credentials.
- Copy all your work into this new folder. This is a good time to divide your manuscript into separate files if you haven’t already, and to come up with a naming scheme if you care for such things.
- Commit your stuff to the repository by right-clicking the folder and selecting “SVN Commit”. It is a good practice to write a brief description of the changes associated with each commit. For the first one, it might be something like “Initial commit”, or whatever you like.
Regularly:
- Before you start to work on your files, always update the working copy by right-clicking the folder and selecting “SVN Update”.
- Do your work, make some changes, delete or create new files and folders, all the stuff you normally do inside any folder. Everything you do before the next step only exists locally on your computer and doesn’t affect the repository. If you delete files by mistake or make other unwanted changes, no permanent damage is done.
- When done, always commit your changes just like in step 4 of initial setup.
- Right-click your working-copy folder and select “Show log” from the “Tortoise SVN” submenu to see the history of your project.
Here‘s a tutorial with screenshots.
I realize this may look daunting to people who see it the first time, but I promise it’s very easy to get used to. And once you do get used to it, you’ll never go back.
4. Use Git
Git is like a super-charged version of SVN. It has the same basic features and works much the same way: you have a remote repository and a local working copy, and you sync them manually. But its capabilities (and complexity) surpass SVN. It would probably be overkill to use Git for writing, but I mention it anyway because:
- You may have heard of it. It’s more popular than SVN because it’s better suited to the needs of software development. Sites such as GitHub revolve entirely around the use of Git version control.
- I happen to know of an excellent online service that offers free Git hosting for private repositories: Azure DevOps.
- Git also has a Tortoise app for Windows: TortoiseGit.
- Everything I wrote about SVN applies to Git. The steps to find free services, set it up and use it are the same, except that in Git terms, the update operation is called pull, and the commit operation is called push.
- Every working copy of a Git repository contains the entire repository and can therefore act as additional backup.
You can learn more about Git here.