Backing Up Everything: The Insurance Policy of Digital Sovereignty

The sovereign builder who does not back up their work is a homesteader who builds a cabin but refuses to insure it against fire. Everything we have discussed in this series — the domain, the hosting, the email list, the membership site, the analytics, the content itself — exists as data. Data that lives in one place is data that can be destroyed in one event. The practice of comprehensive, redundant, tested backups is not an advanced technique. It is the foundation on which every other sovereignty practice depends. Without it, you have built something beautiful on a single point of failure.

Why This Matters for Sovereignty

The sovereignty case for backups is straightforward, but it deserves stating plainly because too many builders skip this step. When you host your site on a platform you control, you accept responsibility for your data. That is the deal. The platform you left — Medium, Substack, WordPress.com — handled backups for you, buried somewhere in the terms of service, managed by engineers you never met. You traded control for convenience. Now that you own the infrastructure, the backups are yours to manage.

This is not a burden. It is the point. The person who controls their backups controls their ability to rebuild. If your hosting provider suffers a catastrophic failure, if your server is compromised, if you make a mistake that corrupts your database — the backup is what separates a minor inconvenience from a genuine loss. The sovereign builder treats data loss the way Thoreau treated fire at Walden: as a foreseeable risk that a deliberate person prepares for before it arrives.

The deeper principle is redundancy. Redundancy is the common thread that runs through every sovereignty practice we advocate. You do not keep all your savings in one bank. You do not rely on a single income stream. You do not store all your data in one location. The sovereign individual builds systems where no single failure — no single provider, no single device, no single decision — can cost them everything they have built.

How It Works

The gold standard for backup strategy has a name: the 3-2-1 rule. It is simple enough to remember and robust enough to protect against nearly any failure scenario. Three copies of your data, on two different types of storage media, with at least one copy stored off-site. If you follow this rule, you can survive a server failure, a provider bankruptcy, a natural disaster at your physical location, or a ransomware attack — any one of these, and in many cases several simultaneously.

What you need to back up is more than most builders realize. The obvious item is your content — the articles, the pages, the posts that constitute your published work. But content alone is not enough. You also need your database, which stores not just your content but your site settings, your membership data, your subscriber information, and the relationships between all of these. You need your files — the images, the theme files, the uploads that give your site its visual identity. You need your configuration: the DNS records, the API keys, the integration settings that connect your various services. And you need a separate backup of your email list, because it is your most irreplaceable asset and should never depend on a single export.

For Ghost users, the built-in export function produces a JSON file containing all your content and settings. This is a good start, but it is not a complete backup. A full Ghost backup includes the JSON export, the content/images directory (every image you have uploaded), the theme files, and the database itself. If you are self-hosting on a VPS, a full server snapshot — available through providers like DigitalOcean or Hetzner — captures everything in one image. Ghost Pro users should supplement their managed backups with regular JSON exports stored locally.

For WordPress users, the plugin UpdraftPlus handles both database and file backups with minimal configuration. The free version is sufficient for most solo builders. Configure it to export to cloud storage you control — your own S3 bucket, your own Google Drive, your own Backblaze B2 account — rather than the plugin provider’s servers. The principle is the same as every other sovereignty decision: if you cannot take it with you, you do not own it.

The Proportional Response

The proportional backup schedule for most sovereign builders looks like this: daily automated backups of your database and content, weekly full backups of all files and configuration, and monthly exports of your email list stored separately from your site backup. Test your restoration process at least once a year — ideally twice. A backup that has never been tested is a backup that might not work, and you do not want to discover that distinction during an actual emergency.

The daily database backup should be automated. Every reputable hosting provider offers this, and if yours does not, that is a reason to reconsider your hosting choice. But do not rely solely on your host’s backups. The host’s backups protect you against hardware failure. They do not protect you against the host itself changing terms, going bankrupt, or suffering a security breach that affects their backup systems. Your own off-site backup — stored on a different provider, ideally in a different geographic region — is the layer that protects against provider-level failure.

For off-site storage, the options are straightforward. Backblaze B2 offers storage at roughly $0.005 per gigabyte per month, which makes it effectively free for most solo sites. Amazon S3 is more expensive but deeply integrated into many backup tools. A simple external hard drive stored at a location other than where your computer lives satisfies the off-site requirement at the lowest possible cost and complexity. The specific tool matters less than the discipline of actually doing it.

Email list backup deserves special emphasis. Your email list is portable, which is one of its greatest sovereignty advantages, but only if you have a current copy. Export your full subscriber list — email addresses plus all metadata (name, subscription date, tags, membership tier) — at least monthly. Store this export in a location entirely separate from your site backup. If your site, your hosting, and your CMS all fail simultaneously, your email list is the one asset that lets you reach your audience directly, explain what happened, and point them to wherever you rebuild.

What to Watch For

The most common backup failure is not technical. It is the failure to test. Builders set up automated backups, see the confirmation emails, and assume everything is working. Then, when they need to restore, they discover that the backup files are corrupted, incomplete, or formatted in a way their current setup cannot import. Testing your restoration process is not optional. Schedule it. Put it on the same quarterly calendar as your analytics review and your security audit. The hour you spend testing restoration is the cheapest insurance you will ever buy.

The second failure is scope. Builders back up their content but forget their configuration. Rebuilding a site from a content-only backup is possible, but it means reconfiguring every integration, every API key, every DNS record, every design customization from memory. Document your configuration — a simple text file listing your DNS records, your active integrations, your API key locations, and your theme customizations — and include it in your backup. This document turns a painful multi-day reconstruction into a methodical few-hour process.

The third failure is assuming your backup provider will always be there. Backup providers, like hosting providers, can change terms, raise prices, or shut down. Your backup strategy should be portable — meaning you can move your backup files to a different provider without losing data or functionality. Proprietary backup formats that only work with one provider’s restoration tools are a form of lock-in, and lock-in is what we are building away from.

The 3-2-1 rule is not complicated. It does not require advanced technical skill. It requires the same quality that every sovereignty practice requires: the discipline to do something unglamorous, consistently, before you need it. Backups are the least exciting topic in this series. They are also, when everything else fails, the practice that determines whether you start over from nothing or rebuild from a position of strength.

This article is part of the Build Your Own Platform series at SovereignCML.

Related reading: Hosting: Where Your Digital Property Physically Lives, The Sovereign Creator Stack: A Complete Setup Guide, Platform Ownership as a Practice, Not a Project