Published on September 16, 2026 · 4 min read
I encrypted my off-site backup and nearly made it useless
On 16 August 2026 I encrypted the drive that holds my off-site backup. An in-place conversion, no data wiped: about seven minutes, 68.8 GB before and 68.8 GB after. A dry-run read test passed through all six directories without an error. Since that day all three layers are encrypted: the computer's own disk, the local backup, and the off-site copy.
Closing this gap took fifteen minutes. Understanding what I nearly broke while doing it took longer.
Why an off-site backup exists at all
A backup on a drive sitting next to the computer protects against a deleted file and against the system drive failing. It protects against nothing that concerns the whole room: fire, flooding, theft.
An off-site backup exists for exactly one circumstance — that the computer is gone. That is its entire purpose and the only scenario in which anyone ever reaches for it.
And that's exactly where the trap sits. An encrypted drive opens with a password. The most convenient place to keep that password is the computer's own keychain, because then nothing has to be typed by hand. Except the keychain is in the computer. If the password lives only there, then in the one situation this backup was built for, I have an unreadable piece of plastic.
An off-site backup whose password stayed at home isn't an off-site backup. It's a backup kept at home, stored somewhere else.
The other side of the same problem
The instinct says: fine then, don't remember the password on the computer, type it in by hand.
I checked what that does to the automated job — and this is the part I would not have guessed from a desk. The backup to this drive starts the moment the volume gets mounted. An encrypted drive only mounts after it's unlocked. So without the password in the keychain, the drive never mounts, the event never fires, the backup never runs — and I would feel like everything's fine, because after all I plug the drive in every week.
I would have noticed after 14 days, because that's the age threshold for this backup in my monitoring. Two weeks of silence that means nothing, in exchange for a convenience I didn't actually want.
So the conclusion runs opposite to intuition. The password has to be in the keychain — otherwise there's no backup. And it has to live outside this computer — otherwise there's no point having it. This isn't a compromise between two options, it's two independent requirements that both have to be met. For me that means a password manager plus a paper copy kept somewhere other than the computer.
What I did not do
I did not leave the drive unencrypted, even though that's the simplest fix for the password paradox — no password, no paradox. The thing is, this is the one drive in the whole set that by design leaves the house — the only one that can realistically get lost or stolen. Of all three layers, it needed encryption the most.
I also did not consider the matter closed after the conversion itself. An encrypted drive that disconnects the automated job is worse than an unencrypted drive with a working backup, because it gives peace of mind without the coverage behind it.
What I checked before calling it done
The whole chain, in order, that same evening: plug in the drive → automatic unlock → a log entry at 18:16:08, coming from the task triggered on mount. Encryption did not change how the job runs.
Separately, a restore test from the now-encrypted drive: 54 files, 52 byte-for-byte identical, 0 missing. The two mismatches were working files of a photo database that change during use. I repeat this test once a quarter, because a file recovered today proves nothing about the backup six months from now.
Three things I take from this
A safeguard has to be tested against the scenario it was built for. An off-site backup only works if it works without this house — including the password, the key, and everything needed to open it.
Check what a change does to the automation around it. Encrypting the drive touched the mechanism that starts the backup on connection. Nothing reported this; it only surfaced by walking the whole path by hand.
Done means tested end to end. Not "the drive is encrypted," but "I plugged it in, it unlocked itself, the backup ran, a file could be read back, and it matched byte for byte."
All numbers — conversion time, size before and after, the restore test result, and the log entry's timestamp — come from a single session carried out on 16 August 2026 on my own hardware.

Patryk Piecyk
Warsaw · junior implementation consultant · available now
For seven and a half years I worked at a German company, five of them running its office: orders, invoices, complaints, ERP. Since June 2026 I have been building my own tools for that same work — I am not a programmer by training; the code is written together with an AI assistant, while the design, the decisions and the testing are mine. These notes describe what broke in those systems and what came out of it.
Got a question about this piece?
Write to me →