How to Back Up Your Encrypted Notes Without Breaking Zero-Knowledge

Losing three years of notes is the kind of thing that happens once and changes how you work forever. A dead SSD, a stolen laptop, a sync that quietly overwrote the good version with an empty one. If your notes actually matter to you, you need copies. The catch: the moment you copy encrypted notes somewhere, most people accidentally undo the very privacy they signed up for. They screenshot a page into their camera roll, drag a plain export into Google Drive, or email a document to themselves. Now a readable copy of their private life sits on someone else's server, keys and all.

This guide is about how to keep real backups of your notes and files without that happening. The goal is simple: end up with copies you can restore from, that survive a disk failure or a house fire, where nobody but you can ever read what is inside. I will use Filarr for the concrete steps because that is what I build, but the principles apply whatever tool you use.

Quick Answer: To back up encrypted notes without breaking zero-knowledge, keep the data encrypted the whole way from your disk to wherever it lands. In practice that means three things. First, use an encrypted export (in Filarr, Settings has a vault export that packages everything into a single AES-256-GCM ZIP protected by a password you choose). Second, store that encrypted file anywhere you like, including plain cloud drives, because it is already unreadable noise to them. Third, keep your recovery phrase and recovery password somewhere offline and separate from the backup, because a backup you cannot decrypt is not a backup. Never rely on screenshots or plain-text exports, and never let a service hold both your data and your keys.

Why backing up encrypted notes is its own problem

Backing up ordinary files is easy because you do not care who can read them. Backing up encrypted notes is harder because the whole point was that nobody could read them, and a backup is, by definition, another copy somewhere less controlled than your main device.

There are two failure modes, and they pull in opposite directions. The first is losing the data: no copies, one disk, one accident away from gone. The second is leaking the data: copies everywhere, but in a form somebody else can open. A good backup strategy has to solve both at once. You want more copies and more privacy, not one traded for the other.

The trap most people fall into is solving the first problem in the laziest way. They turn on "sync my notes folder to Dropbox" or paste text into a cloud doc. It feels like a backup, and technically it is, but they just handed a readable copy to a company that can be hacked, subpoenaed, or simply curious. If you want the deeper version of why that matters, I wrote a full breakdown of what actually changes when your data leaks from a plain cloud versus a locally encrypted store. The short version: in a breach, one leaks your readable documents and the other leaks unreadable garbage.

So the rule that runs through everything below is this: the data must be encrypted before it leaves your control, and the keys must never travel with it. That is the entire game.

The three kinds of backup, and which ones keep zero-knowledge

Before the steps, it helps to see the landscape. There are roughly three ways people back up notes, and they are not equal.

Plain copies. Screenshots, exported Markdown or PDF, pasting into another app. These are convenient and completely readable. They break zero-knowledge the instant they leave your disk. Useful only for things you would not mind a stranger reading.

Encrypted archive backups. A single file that contains your whole vault, encrypted with a password only you know. You can drop this anywhere and it stays private. This is the workhorse of a private backup strategy and what I recommend as your baseline.

Zero-knowledge cloud sync. Continuous backup where every file is encrypted on your machine before upload, and the server only ever stores opaque blobs. This gives you off-site protection without you lifting a finger, as long as the sync is genuinely zero-knowledge and not just "encrypted at rest" marketing. If you are unsure of the difference, it is worth understanding what zero-knowledge encryption actually means before you trust any provider's claim.

A solid setup usually combines the last two: sync for the everyday, always-on off-site copy, plus a periodic encrypted archive you control end to end. Let me walk through each.

Step 1: Make an encrypted archive backup you fully control

This is the backup I trust the most, because I do not have to trust anyone else for it. In Filarr you make one from Settings.

Open Settings and find the vault export option. You will be offered two modes: plain and encrypted. Choose encrypted. Under the hood this builds a ZIP of your entire vault (your files put back into their real folder structure, your notes exported both as human-readable Markdown with frontmatter and as full-fidelity JSON that can be restored exactly, plus a manifest that records your tags, folders, and the graph links between notes), and then encrypts that whole archive with AES-256-GCM using a password you type in. The manifest even records the encryption algorithm so a future you knows what they are looking at.

When it asks for a password, pick a strong one and do not reuse your device login. This password is the only thing standing between the archive and anyone who finds it. If you want to understand why AES-256-GCM specifically is a sound choice and not just a buzzword, I explained what each part of AES-256-GCM means and why the GCM mode matters in a separate piece. The one-line version: it encrypts and authenticates at the same time, so a tampered backup fails to open instead of silently returning corrupted data.

The file you get out is named something like filarr-export-encrypted-2026-08-28.zip. Here is the important property: that file is unreadable without the password, so where you put it barely matters for privacy. You can:

• Copy it to an external drive that lives in a drawer.
• Upload it to Google Drive, iCloud, or Dropbox. They store ciphertext. They cannot read it.
• Keep one copy at home and mail one to a family member's house for fire and theft protection.

That last point is the quiet superpower of encrypted archives. Because the file is already noise to everyone but you, you get to use cheap, convenient, untrusted storage without giving up privacy. You are borrowing their disks, not their trust.

Do this on a schedule that matches how much work you would hate to redo. For most people, monthly is fine, weekly if you write a lot. Keep the last few archives rather than overwriting a single one, so a corrupted or half-written export never becomes your only copy.

Step 2: Turn on zero-knowledge sync for the always-on copy

Manual archives are great, but you will forget to make them. That is human. This is where continuous sync earns its place: it gives you an off-site copy that updates itself, so even if your last manual archive is three weeks old, the cloud has yesterday.

The non-negotiable requirement is that the sync must be zero-knowledge. In Filarr, files are encrypted on your device with per-file keys before anything is uploaded, and the backend (Cloudflare R2) only ever receives already-encrypted blobs. Your password and the keys derived from it never reach the server in a form it could use. I walked through the actual code that makes this true in a separate deep dive on how Filarr's optional cloud sync stays zero-knowledge, including exactly what the server can and cannot see (which is almost nothing: sizes and timing, not content).

A detail worth understanding: the reason a leak of that cloud storage would be harmless is the key hierarchy. Each file has its own file key, and those keys are themselves wrapped by a key derived from your password, never stored in the clear on the server. That per-file design is what stops one compromised key from unlocking everything, and I broke down the whole KEK and FEK two-layer key model if you want to see why one global key is dangerous.

If you would rather not use Filarr's hosted storage at all, there is a bring-your-own-storage option: point sync at any S3-compatible bucket you own. The encryption happens the same way on your side, so the bucket still only ever holds ciphertext. This is the sweet spot for self-hosters who want both off-site backup and full control of the physical storage.

One honest caveat: sync is a backup against hardware failure and theft, but it is not a backup against yourself. If you delete a note and the deletion syncs, it is gone from the cloud too. That is exactly why Step 1 still matters. Archives are snapshots frozen in time; sync is a mirror. You want both.

Step 3: Protect the keys, because that is the real backup

Here is the part people skip, and it is the part that actually saves you. An encrypted backup is only as good as your ability to open it later. If you lose the password or the recovery method, your backup is a brick, cryptographically indistinguishable from random data even to you.

Filarr gives you two things to safeguard, and they are not the same.

Your recovery phrase. When you set up an encrypted vault, you get a 24-word BIP-39 recovery phrase. This is the master fallback for your account and keys. Write it on paper. Not a screenshot, not a note inside the very vault you are trying to protect (think about that loop for a second), not an email to yourself. Paper or a metal seed plate, stored somewhere physical and safe. Two copies in two locations is not paranoid, it is proportionate to how unrecoverable this is if it is gone.

Your recovery key file. Separately, Filarr lets you generate a recovery key from Settings, protected by its own recovery password (deliberately different from your vault password) with an optional plain-text hint like "office safe" to jog your memory. This produces a file you download and store somewhere safe, separate from your device. It exists precisely so that forgetting your vault password does not mean losing your data.

The principle tying these together is separation. Your backup file and the thing that unlocks it should never live in the same place. If they do, then anyone who steals the drive gets both, and you are back to plain-text backups with extra steps. Store the encrypted archive in the cloud and the recovery phrase on paper at home. Store the external drive in a drawer and the recovery key file in a password manager. Cross them, never stack them.

If the whole topic of recovery phrases, threat models, and secure sync is new to you, my broader practical guide to encrypting your notes covers the fundamentals that sit underneath this backup workflow.

Step 4: Test a restore before you need one

An untested backup is a hope, not a plan. The number of people who discover their backups were empty, corrupted, or unopenable at the exact moment they needed them is depressingly high.

So do the boring thing. Once you have an encrypted archive, actually restore it. In Filarr, use the import vault option and feed it the encrypted ZIP and its password. It will decrypt the archive with AES-256-GCM, read the full-fidelity notes JSON, rebuild your folders and tags from the manifest, and put your files back. Confirm your notes came back with their formatting, that linked notes still link, that a few real files open correctly.

Do this on a spare profile or a test machine if you are nervous about overwriting your live vault. The point is to prove the round trip works: encrypt, store, retrieve, decrypt, read. If any link in that chain is broken, you want to find out on a calm Tuesday, not the day your laptop dies.

Re-test after any major version upgrade or after you change your password or recovery method. Backups made under an old key are only useful if you can still reach that key.

Pitfalls and good practices

The screenshot reflex. Screenshotting a note to "save it somewhere" is the single most common way people leak private notes. That image lands in your camera roll, which syncs in plain form to a cloud you do not control. If a note is worth backing up privately, back it up privately, not as a photo.

One copy is zero copies. A backup that exists only on your main machine is not a backup, it is the original. The classic rule still holds: three copies, two different media, one off-site. An encrypted archive on an external drive plus zero-knowledge sync gets you most of the way there almost for free.

Overwriting the only archive. If your backup script or habit writes to the same file every time, a failed or truncated export can destroy your only copy. Keep the last few, dated. Storage is cheap; regret is not.

Keys stored with the data. Putting the archive password in a text file next to the archive, or the recovery phrase inside the vault, defeats everything. Separate the lock from the key, physically.

Trusting "encrypted" without checking who holds the key. Plenty of services encrypt your data and also hold the key, which means they can read it and so can anyone who breaches them. That is not the same as zero-knowledge. The distinction is subtle and worth internalizing; I laid out the precise difference between end-to-end and zero-knowledge encryption so you can tell real privacy from marketing.

Forgetting mobile and other devices. Your notes may live on more than one machine. Make sure your backup captures the authoritative copy, and that a second device that is behind on sync cannot resurrect deleted content or overwrite newer edits.

FAQ

Does a plain export break zero-knowledge? Yes, the moment it leaves your device. A plain ZIP, Markdown file, or PDF is readable by anyone who gets it, including whatever cloud you store it on. Use it only for content you would not mind being public. For private backups, always choose the encrypted export.

Where is it safe to store my encrypted backup file? Almost anywhere, which is the beauty of it. Because a Filarr encrypted archive is AES-256-GCM ciphertext protected by your password, services like Google Drive or Dropbox only ever hold unreadable noise. Store it on external drives, in the cloud, or both. Just keep the password somewhere separate.

What happens if I lose my backup password or recovery phrase? The data is unrecoverable. This is not a policy choice, it is math: without the key, AES-256-GCM ciphertext is indistinguishable from random data. That is why you keep the 24-word recovery phrase on paper and generate a separate recovery key file, both stored offline and apart from the backup itself.

Is cloud sync enough on its own, or do I still need archives? You still need archives. Sync protects against hardware loss and theft, but it faithfully mirrors your mistakes too: delete a note and the deletion propagates. Periodic encrypted archives are frozen snapshots that let you go back in time. Use sync for continuity and archives for history.

Can I back up to my own storage instead of Filarr's servers? Yes. Filarr supports bring-your-own-storage against any S3-compatible bucket. Encryption still happens on your device before upload, so your bucket only ever contains ciphertext. It is a good fit if you want off-site backup and full control of the physical storage.

How often should I make an encrypted archive? Match it to how much work you would hate to lose. Weekly if you write daily, monthly for lighter use. Keep the last several dated archives rather than overwriting one, and test a restore at least once so you know the round trip works.

Conclusion: back up like the data is yours, because it is

A private backup is not complicated once you hold the one idea steady: keep the data encrypted from the moment it leaves your disk, and keep the keys somewhere the data never goes. Everything else is logistics. Make an encrypted archive from Settings and stash copies wherever is convenient, because they are noise to everyone but you. Turn on zero-knowledge sync so there is always a fresh off-site copy without you thinking about it. Write your recovery phrase on paper and store your recovery key file apart from everything else. Then, this week, actually restore one backup and watch your notes come back intact.

Do that, and you get the thing people assume they have but usually do not: notes that survive the worst day, that nobody but you can ever read, and that you can always get back. That is what backing up encrypted notes without breaking zero-knowledge really buys you, peace of mind that does not cost you your privacy.