Why turning on backup isn't optional in Fenzly
The last post ended on a line worth taking seriously: strong keys are worth nothing if they’re lost. This one is about the uncomfortable flip side of everything we’ve described so far.
A blind server means we can’t read your data. It also means we can’t give it back to you. If you lose your phone and you haven’t set up a backup, your account is gone and there is no support ticket, no exception, no “let me check with the team” that changes it.
That sounds harsh. It’s the direct, unavoidable cost of the guarantee.
The thing no support ticket can fix
In a normal app, losing your phone is a nuisance. You buy a new one, log in, and everything reappears because the company had your data all along, on their servers, in readable form. The “recovery” you’re used to only exists because someone else holds a copy of your life.
Fenzly doesn’t have that copy. Your private encryption keys, the ones that unlock every sealed envelope addressed to you, live on your phone and nowhere else. Our server has never seen them. So when the phone goes, the keys go, and what’s left on the server is a pile of blobs nobody on Earth can open.
We’re not refusing to help in that scenario. We’re unable to. There’s no master key we’re withholding out of principle; there’s simply no master key. That’s the whole architecture, working as designed.
Losing a phone is more ordinary than you think
It’s tempting to file this under unlikely disasters, theft, a phone in a lake. In practice, the most common way people lose their keys is completely mundane: they buy a new phone. They trade the old one in, wipe it, hand it to a family member, and only then discover the keys never made the trip.
Water, drops, dead batteries, factory resets, a device that just stops booting one morning. None of that is exotic. The backup isn’t insurance against a rare catastrophe; it’s insurance against an ordinary Tuesday.
A backup we also can’t read
Here’s the tension we had to solve. A backup is, by definition, a copy of your data somewhere other than your phone. Park a readable copy on our server and we’ve just quietly undone the blind server, the thing the whole app exists for.
So the backup is encrypted too, with a key we don’t hold. The interesting question isn’t how the data gets encrypted; it’s who holds the key, and where the copy lives. Fenzly gives you two answers, to pick based on your situation.
By default, the copy lives in your own cloud, Google Drive on Android, iCloud on iOS, and the key is split in two. Half sits on our server, half next to the backup in your cloud. Neither half is worth anything alone: our server’s piece is meaningless without yours, and the piece in your cloud is meaningless without ours. Only your phone ever brings them back together. You don’t have to remember anything, and neither we nor Google nor Apple can open the backup unilaterally.
The alternative, if you have no Google or Apple cloud, or yours is full, is to host the copy with Fenzly. The blind server still holds: what we store is ciphertext we can’t open, and the key is derived from a 30-digit recovery code generated on your phone, which we never see. Write that code down: it is the only way to open this backup. And if you’d rather not rely on a piece of paper, an optional setting saves the code in your personal Google or Apple account (we still never see it), so that when you set up a new phone with that same account, Fenzly retrieves it for you automatically.
One last word on silent failure, because a backup that quietly stops succeeding is as dangerous as no backup at all: if yours starts failing, cloud full, account signed out, Fenzly says so with a banner on every screen, and switching to Fenzly-hosted storage is one tap away. For the cautious, an encrypted file export exists too, to keep wherever you like.
What actually gets saved
A backup has two layers, and they matter differently.
The essential layer is tiny, under a kilobyte, and it holds your encryption identity. This is the irreplaceable part: it’s what makes you you to everyone you’ve ever exchanged a message with. It’s refreshed on every backup and it must succeed.
The full layer is your actual history: messages, places, trips. It’s larger, and Fenzly keeps the last few versions rather than a single copy, so a corrupted or half-written backup can’t take your only lifeline with it.
If everything else fails, the essential layer alone lets you keep your identity and your account. You’d lose history; you wouldn’t lose you.
The honest limits
Two things a backup won’t do, because pretending otherwise would be dishonest.
It isn’t a perfect time machine. Restoring rewinds your encrypted conversations to the moment the backup was made, and a handful of messages sitting right at that boundary can become permanently unreadable, you’ll see a placeholder where they were. That’s an intrinsic consequence of the Double Ratchet’s forward secrecy, the same property that makes yesterday’s messages unrecoverable to an attacker. It cuts both ways, and we’d rather tell you than surprise you.
And if you use the recovery code without saving it to your Google or Apple account, and you lose it, nobody is coming. We mean that literally.
Two minutes in the settings today, or an unrecoverable account later. It’s an easy trade, but only if you make it before you need it.
Next: Swiss data sovereignty, what hosting in Switzerland actually buys you, and what it doesn’t.
Updated September 2026: the first version of this article described a separate “manual” mode. It has since been replaced by the Fenzly-hosted, recovery-code option described above, and the article now reflects current behaviour. The encryption engine also changed from a Signal-protocol library to Olm (Double Ratchet, the same protocol family); nothing here depends on that.