Exporting and backing up your manuscript

A web serial is a strange kind of property: the chapters are public, the manuscript is not, and the whole thing lives on whatever server your writing tool or platform happens to run on. Platforms merge, change their terms, lose their funding or delete accounts by accident. The craft answer to that fragility is boring and essential: own your files. This guide is about what owning them means, what a Markdown export is worth, what a real backup contains, and what cadence makes the habit stick.

Why ownership matters more for serials

A serial author publishes before any whole-book revision exists. Your early chapters are already out, already on readers' shelves, and the source of record for the whole story is whatever your tool holds. If you cannot get it out, in a format you control, your negotiating position with that tool is zero at exactly the moment you need it most: when you want to move platforms, publish an ebook, or simply keep writing after a price change. The first question in how to choose novel-writing software is where your manuscript lives; this guide is that question's working answer. Where you post, in turn, should be chosen with portability in mind; see the serial platform landscape.

What Markdown export gives you

Markdown is "a plain text format for writing structured documents" (CommonMark), and plain text is the most durable format computing has produced: readable by any editor on any system, diffable, greppable, and convertible to essentially anything else. An exported Markdown manuscript is not an archive of your tool's database; it is the book itself, in a shape built to outlive the tool. One honest caveat from the format's own history: because the original specification left room for interpretation, Markdown implementations "have diverged considerably" over the years, which is why CommonMark exists as a standard. Stick to standard constructs, headings, paragraphs, lists, and the file converts cleanly everywhere.

In Kanonara, export means the whole readable manuscript as one Markdown file: title and synopsis, then every chapter with its scenes in order. It is deliberately the readable book, not the database.

What a backup is, beyond the export

An export loses everything that is not prose: your characters and their states, relationships and their history, locations, timeline events, story facts, rules, secrets, issues and their evidence. For a long serial that material is months of your judgment, and losing it sets the story back further than losing text does. A full backup captures it. Kanonara's backup is a single versioned JSON snapshot of the entire project, story bible and continuity record included, restorable as a new project whenever you need it.

The distinction to hold onto: export is for reading and moving; backup is for recovery. You need both, and one does not substitute for the other.

The 3-2-1 rule

CISA's guidance is the standard formulation: keep "3 copies of important files", on "2 different types of storage media (like a hard drive and the cloud)", with "1 copy stored off-site". For a writer that translates directly: the copy in your writing tool, a Markdown export on your own disk, and the full backup somewhere at least provider-wise separate from the tool. CISA also says to "test backup procedure to make sure your team can rapidly restore data", which for one author means: open last month's backup file and check that it contains the chapter you remember writing. An untested backup is a hope, not a backup.

A cadence that follows the serial

• At every chapter milestone, export fresh Markdown. It is one file; the cost is seconds, and keeping the exports in version control makes the history of the book inspectable.
• On a weekly rhythm, take the full project backup, name it with the date, and store it somewhere the manuscript does not already live.
• At every arc boundary, test-read one restore. Restoring creates a new project and overwrites nothing, so the test costs only attention.
• Before big canon changes, back up first. A deliberate retcon (see retcon vs continuity error) deserves a "before" snapshot the same way code does.

Tie the habit to your release schedule rather than to memory: the same moment you publish, you export. The habit pays a second debt, too. A trail of dated exports is evidence of your authorship and your choices, which matters in the copyright questions that come with AI-assisted writing.