{"id":76,"date":"2026-10-23T06:23:58","date_gmt":"2026-10-23T06:23:58","guid":{"rendered":"https:\/\/thenovelistapp.com\/blog\/?p=76"},"modified":"2026-10-23T06:23:58","modified_gmt":"2026-10-23T06:23:58","slug":"how-to-back-up-your-novel","status":"publish","type":"post","link":"https:\/\/thenovelistapp.com\/blog\/how-to-back-up-your-novel\/","title":{"rendered":"How to back up your books beyond autosave"},"content":{"rendered":"\n

When I started thinking of how I could back up my novel, I asked a very simple question that no ‘autosave’ feature can answer: what would I open if my current manuscript disappeared tomorrow?<\/em><\/strong> A saved document is reassuring while everything works, but the same file can still be overwritten, deleted, corrupted, or lost with the computer that holds it. What then?<\/p>\n\n\n\n

I’ve worked as a freelance developer for almost two decades, and coding for most of my life has changed how I see and handle my personal data. For starters, having a solid backup routine that gives me a way back to my work is the first step I take. The second is making sure that I also have an earlier version of that backup in case the last one is broken.<\/p>\n\n\n\n

As a writer and the developer of The Novelist<\/a>, I also think beyond the manuscript itself. A novel can depend on character profiles, research, location notes, reference images, and the connections that hold a fictional world together. My goal is to protect that work without turning the end of every writing session into a complicated maintenance job.<\/p>\n\n\n\n

My answer: a separate copy, a history, and a way back<\/h2>\n\n\n\n

Every single day that I write, make changes, or adjust my chapters, at the end of it, I keep a fresh backup of everything. This backup is then copied onto a secondary disk that I have and uploaded to my Proton Drive account. That way, whatever happens, and even if both drives die for some sudden reason, I still have them stored in a privacy-focused cloud storage provider.<\/p>\n\n\n\n

For many, the schedule may depend on how much they’re writing and how much they can afford to lose, but I’d highly suggest backing up after any meaningful writing session. By the way, that includes major revisions or new chapters \u2014 you know, things that take time to rewrite.<\/p>\n\n\n\n

Why I do not treat autosave as a backup<\/h2>\n\n\n\n

I want autosave enabled because it reduces the amount of writing I might lose between saves, but it usually updates the project I am already editing. If I remove a scene and the application saves that change, the current file may faithfully preserve a decision I later regret. If that file lives on a failing drive, saving it more frequently does not create an independent copy somewhere safe.<\/p>\n\n\n\n

I separate the question \u201cHave my latest changes been saved?\u201d<\/em> from \u201cCan I recover my work after something goes wrong?\u201d<\/em> The first matters during the writing session; the second matters when the current project is no longer available or no longer contains the version I need. Some applications include their own history or backups, but I still check where those copies live, what they contain, and whether they survive after losing the original device.<\/p>\n\n\n\n

Layer<\/th>What I want it to do<\/th>What I still need to check<\/th><\/tr><\/thead>
Autosave<\/strong><\/td>Keep current edits in the working project.<\/td>Whether an earlier state can be recovered.<\/td><\/tr>
Project backup<\/strong><\/td>Preserve the writing workspace at a particular time.<\/td>Whether it includes media and restores correctly.<\/td><\/tr>
Manuscript export<\/strong><\/td>Give me text I can read or edit elsewhere.<\/td>Which project details are absent.<\/td><\/tr>
Cloud synchronization<\/strong><\/td>Make selected files available across locations or devices.<\/td>Deletion propagation, history, and recovery limits.<\/td><\/tr>
Independent off-site copy<\/strong><\/td>Survive losing the computer and nearby storage.<\/td>Access, encryption, completeness, and restore procedure.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

What I include when I back up a novel<\/h2>\n\n\n\n

I begin with the manuscript, but I also check what I would miss if I had to continue in a clean installation. Character histories, chapter notes, timelines, research, maps, cover artwork, and reference images can represent substantial work even when none of them appears in the final book. A text export may preserve the prose while leaving much of that surrounding project behind.<\/p>\n\n\n\n

My preference is to keep both an application-native backup and a separate manuscript export. The native backup is the recovery copy for the workspace; a DOCX<\/code> or Markdown<\/code> export gives me another route to the text if I need to read or edit it in a different tool. I treat that export as an additional layer, rather than assume it can rebuild every relationship, note, and setting in the original application.<\/p>\n\n\n\n

I also check for resources stored outside the project. If a document links to an image elsewhere on my computer, I cannot assume that backing up the document copies the original artwork. I keep those source files with my project archive or back them up separately, with enough organization to recognize which book they belong to later.<\/p>\n\n\n\n

Why I distinguish cloud sync from cloud backup<\/h2>\n\n\n\n

I see cloud synchronization as a convenience with specific recovery features, rather than an automatic substitute for a backup plan. A synchronized folder can propagate a deletion or an unwanted edit, while a service\u2019s version history may provide a route back. I check the actual retention period, deleted-file recovery, account access, and whether recovery works for the files my application uses. The presence of a cloud icon does not answer those questions.<\/p>\n\n\n\n

With a database-backed writing application, I would also avoid assuming that a cloud folder makes simultaneous editing on two computers safe. Copying or synchronizing files while an application is updating them can introduce consistency problems, and a generic storage service does not automatically understand the application\u2019s project structure. I prefer transferring a completed, app-created backup unless the writing application explicitly documents a supported live synchronization workflow.<\/p>\n\n\n\n

In The Novelist, a folder managed by my own cloud-storage service does not provide built-in cloud sync. I would not open separate synchronized copies on two computers and treat them as one shared live library. The current workspace-storage guide<\/a> explains that distinction, which is important when moving between machines.<\/p>\n\n\n\n

How I back up a novel in The Novelist<\/h2>\n\n\n\n

I built The Novelist as a privacy-focused and local-first app<\/strong>, with the writing workspace stored on the computer. That gives me control over where the project lives, but I still need independent copies. The Free version includes the backup and restore workflow<\/strong>, alongside core writing, story-world organization, and DOCX<\/code> and Markdown<\/code> exports. You do not need Pro to take the basic steps described here.<\/p>\n\n\n\n

I start by finishing the current edit and allowing automatic saving to complete. Then I open Settings \u2192 General \u2192 Backup & restore<\/strong>, choose Create backup<\/strong>, and wait for the success message before checking the new entry\u2019s name and date.<\/p>\n\n\n\n

\"The\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n

Creating the backup is only the first part of my routine. I choose Export<\/strong> beside the intended entry, select a destination on another disk, and check that the completed copy is there. New backups are folders with names ending in .novelist-backup<\/code><\/strong>; I keep the entire folder and everything inside it together. I would not select only the database file from inside it or rename individual pieces to make the folder look cooler.<\/p>\n\n\n\n

The current backup format includes the writing and workspace files such as locally stored media and covers. Resources linked from elsewhere on the computer still need their original files preserved separately. Older supported .db<\/code><\/strong> backups contain the writing library without the accompanying media folders, so I would keep any associated files I still had rather than assume an older database backup held everything.<\/p>\n\n\n\n

The backup schedule I would start with<\/h2>\n\n\n\n

I would choose a schedule based on the amount of work I am willing to recreate. If losing an afternoon of revisions would be painful, a weekly copy is too infrequent for that project. My starting routine would be an end-of-session backup, a separate snapshot before a structural change, and a regular off-site copy. Automation can make that easier, but I still need to confirm what the automated job includes and when it last completed successfully.<\/p>\n\n\n\n

When<\/th>My action<\/th>Reason<\/th><\/tr><\/thead>
After a meaningful writing session:<\/td>Create and export a dated project backup.<\/td>Limit how much recent writing I could lose.<\/td><\/tr>
Before major revisions, imports, or updates:<\/td>Keep a separate pre-change snapshot.<\/td>Preserve a clear return point.<\/td><\/tr>
At least weekly while actively drafting:<\/td>Refresh the protected off-site copy.<\/td>Reduce dependence on one physical location.<\/td><\/tr>
After a completed chapter or milestone:<\/td>Keep a DOCX or Markdown manuscript export.<\/td>Maintain another readable route to the prose.<\/td><\/tr>
After setting up or changing the routine:<\/td>Test recovery in an isolated workspace.<\/td>Check the files and the procedure together.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

For a personal retention policy, I would begin with recent daily snapshots, several weekly copies, and milestone copies for completed drafts or major revisions, then adjust according to storage and project activity. I would name exported copies with the date, workspace, and milestone so I could distinguish them later. I would also avoid repeatedly overwriting one file called \u201clatest backup,\u201d because that removes the history I may need when I discover a problem days afterward.<\/p>\n\n\n\n

How I test a backup without replacing current writing<\/h2>\n\n\n\n

I regard a successful backup message as useful evidence, but not the whole recovery test. I want to know that the saved copy contains a recognizable book, recent writing, notes, and important images, and that I understand the steps needed to recover it. A folder that exists but cannot be opened is not the result I am looking for.<\/p>\n\n\n\n

In The Novelist, I take the replacement behavior seriously: restoring a backup replaces the contents of the current workspace; it does not merge libraries<\/strong>. Before attempting any restore, I create and export a backup of the current workspace. For a recovery test, I use a separate test workspace created through Settings \u2192 General \u2192 Workspaces \u2192 Create workspace<\/strong>, confirm that it is the active destination, and only then import the backup I want to test.<\/p>\n\n\n\n

I open Backup & restore<\/strong>, choose Import backup<\/strong> if the copy is not already listed, and check the selected folder and date. Importing adds a copy to the list and may offer to restore it immediately, so I read that prompt carefully. I proceed with Restore only when I am certain I am in the intended test workspace and have read the replacement warning.<\/p>\n\n\n\n

After the restore, I inspect several chapters, including a recent passage, along with notes, covers, and images that matter to the project. I return to my original workspace when the test is finished and confirm that the expected library is active before writing again. If an import or restore reports an error, I preserve the original backup and current workspace, stop further restore attempts, and contact support rather than experiment with the only copies I have.<\/p>\n\n\n\n

How I protect unpublished writing in backup storage<\/h2>\n\n\n\n

A local-first workspace lets me decide where my writing starts, but I also need to consider where each backup ends up. If I choose cloud storage for the off-site copy, I review the service\u2019s privacy and security arrangements and consider encrypting the archive before uploading it. I keep the password or recovery key securely outside the backup itself, because an encrypted copy is of little use if its only key disappears with the original computer.<\/p>\n\n\n\n

I apply the same care to removable storage. I keep the drive somewhere secure, disconnect it when the backup is complete, and avoid sharing a project archive through a public link. These are choices about my backup arrangement, not claims that a local-first application automatically encrypts every exported file or protects a cloud account I choose to use.<\/p>\n\n\n\n

\n

I always encrypt my backups with VeraCrypt<\/a>. That way, even if a hacker gets access to them, they won’t be able to decrypt them.<\/p>\n<\/blockquote>\n\n\n\n

Where exports and The Novelist Pro fit into my routine<\/h2>\n\n\n\n

I would start with The Novelist Free<\/a> and use its backup tools together with DOCX<\/code> and Markdown<\/code> exports. That already gives me a capable drafting and worldbuilding workspace, an application-native recovery copy, and a separate way to access the manuscript text. My backup routine should work before I consider adding more tools.<\/p>\n\n\n\n

When I want additional reading or sharing formats, The Novelist Pro<\/a> adds HTML<\/code>, PDF<\/code>, and EPUB<\/code> exports, alongside Graph View, full Stats & Journey, Grammar & Clarity, and optional AI tools. A PDF<\/code> or EPUB<\/code> can be a useful milestone reading copy, but I would keep the native workspace backup regardless. I would choose Pro for those workflow benefits when they become useful, while keeping recovery grounded in the backup tools already available in Free.<\/p>\n\n\n\n

The question I want my backup routine to answer<\/h2>\n\n\n\n

I want to be able to name the copy I would recover from, identify where it is stored, and explain how I would open it without sacrificing newer writing. If I cannot answer those questions, I have more checking to do even if autosave is enabled and several folders contain the word \u201cbackup.\u201d The point is to preserve a route back to the work, not simply accumulate files.<\/p>\n\n\n\n

My next step would be small and concrete: create a fresh project backup, export the complete copy to another disk, keep a protected off-site copy, and test recovery in a separate workspace. Once that routine works, I can give the manuscript my attention again, with a clearer understanding of which version I could return to and what I would need to recover it.<\/p>\n","protected":false},"excerpt":{"rendered":"

My practical backup routine for protecting a novel, its story world, and its research, with current instructions for The Novelist and advice on testing recovery.<\/p>\n","protected":false},"author":1,"featured_media":136,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-76","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-writing-guides"],"_links":{"self":[{"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/posts\/76","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/comments?post=76"}],"version-history":[{"count":2,"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/posts\/76\/revisions"}],"predecessor-version":[{"id":138,"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/posts\/76\/revisions\/138"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/media\/136"}],"wp:attachment":[{"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/media?parent=76"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/categories?post=76"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/thenovelistapp.com\/blog\/wp-json\/wp\/v2\/tags?post=76"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

I make an independent backup for each workspace I want to preserve. Since a workspace can contain several books, I first check which workspace is active instead of assuming that each novel has its own separate library. I also export a fresh backup before installing an update, following the current update guide<\/a>, even when an installation flow includes its own protective checks.<\/p>\n\n\n\n