Writing · 2026-06-23Tokyo · Incoming Cambridge HSPS

your offline backup is not your source of truth

A backup you write to is just a second thing to keep in sync; a backup you only read from in a disaster actually saves you.

your offline backup is not your source of truth. it is your insurance. that distinction sounds small until you watch a local encrypted mirror slowly take on a life of its own. people make a copy of critical data, feel safer because the copy lives somewhere else, and then start treating that copy like the real system. once that happens, the backup stops being a quiet safety net and starts becoming another place where decisions can drift.

the problem is simple and expensive. when two places both feel important, they begin to disagree. a change lands in one place, another change lands in the mirror, and now there is no clean answer to which version deserves trust. the moment you start writing to the mirror, you have created two active records that need to stay aligned. every edit adds one more chance for mismatch, and every mismatch makes the mirror harder to trust when you actually need it.

the rule i use now is direct. pick one canonical source and keep it that way. the mirror lives somewhere else, gets refreshed on a schedule, and stays quiet until the primary is gone. that gives each copy a job. one place is where work happens. the other place is where recovery happens. when those roles stay separate, the backup remains simple enough to trust.

the mechanism matters here. a backup that you write to is a second thing to keep in sync. that means every update has to be correct in both places, every time, or the two copies drift apart. once drift starts, the mirror becomes a competing version of the truth. by contrast, a backup that you only read from in a disaster never has to compete with day-to-day edits. it can stay stale on purpose, because its job is to exist when the primary is gone.

that shift changes the way the whole system feels. you stop asking whether the mirror is current enough to use as working storage, and you start asking whether the refresh schedule is good enough for recovery. you stop editing wherever a copy happens to be handy, and you keep the real source in one place. the mirror becomes boring, which is exactly what you want from insurance. it is there, it is separate, and it does its job only when the primary cannot.

if you keep a local encrypted mirror, treat it as a recovery asset. decide which place is canonical, write your changes there, and refresh the mirror on a schedule that fits your risk tolerance. then leave it alone unless the primary is gone. that one rule keeps the backup from becoming a second source of truth. it also makes disaster recovery cleaner, because the copy you reach for in the worst moment is the copy you trained to be read-only in normal life. that is the whole point of insurance: it stays in the background until the day you need it.

More writing