How We Built a Backup System Nobody Asked For

By Vlad (Volodymyr) Shiyan · Published May 27, 2026 · Building LockMargin · 8 min read

Short answer: nobody asked for it. But I needed it.

The Paradox: They Fear Hackers, But Lose Data Themselves

Freelancers rarely or never do backups. I checked — asked on Discord, Reddit, at coffee breaks. Same answers:

"I have iCloud."

"Google Drive, obviously."

"I copy to a flash drive once a month. Well, almost."

Nobody says: "I have a tested recovery strategy." Because they don't. For the step-by-step strategy behind that answer, start with the freelancer backup guide.

Freelancers lose data more often from:

• Disk failure (my case)
• Accidental deletion ("Oops, wrong folder")
• OS updates that "broke something"
• Laptop left in a cafe
• Coffee spilled on the keyboard

Hackers? Yes, scary. But statistically, you're more dangerous to your own data than any hacker.

Why Cloud Sync Is Not a Backup

"I have Dropbox" — the phrase I hear most often.

Dropbox synchronizes. If you delete a file — it deletes everywhere. If a file corrupts — the corrupted version spreads to all devices. Dropbox retains version history and deleted files for a limited time, but this does not replace a proper backup strategy with point-in-time recovery. It's a mirror, not an archive. A mirror shows what is. It doesn't remember what was. If the question is invoices in Dropbox specifically, here is the full answer.

iCloud, OneDrive, Google Drive — same thing. They protect against device loss, not against data loss.

Enterprise solutions? Backblaze, Carbonite — good products. For many independent professionals they may be excessive in cost or setup complexity. Built for companies with IT departments. For one person — overkill and another subscription.

Manual backup to an external drive? I tried. Copied a folder once a month. Then forgot for three months. Then the drive died. Ironic, isn't it?

Constraints: Zero Cloud, Full Autonomy

We built LockMargin without clouds, without accounts, without subscriptions. That's not fashion — that's architecture. But architecture doesn't protect against a dead drive.

Our constraints were strict:

• Zero data leaves the machine without explicit user action
• No recurring infrastructure costs
• Full offline operation

This means: no hidden cloud backup. No "we'll save everything on our servers." The user chooses — and takes responsibility.

The Technical Problem: WAL and "Hot" Copying

LockMargin stores everything in SQLite. SQLite is reliable. But it has WAL mode — Write-Ahead Logging.

In WAL mode, data is first written to a separate file, then moved to the main database. If you copy the .db file without closing transactions — you get a corrupted copy. If you copy both .db and .db-wal — they can desynchronize within milliseconds.

Naive file copying either misses the WAL file, losing transactions, or copies the database mid-write, guaranteeing corruption.

I learned this by copying a "working" database and trying to open it on another computer. Error: "database disk image is malformed." Tea went cold.

Why VACUUM INTO, Not Simple File Copy

SQLite's VACUUM INTO command creates an atomic, consistent snapshot of a live database. It compacts the database, resolves all pending WAL transactions, and writes a single portable .db file.

Unlike file copying, VACUUM INTO:

• Handles WAL safely — no lost transactions
• Produces a corruption-free snapshot every time
• Creates a single file — no .db-wal dependencies
• Works on a "hot" database — no need to close the app

It's the difference between photographing a moving train and waiting for it to stop.

The Solution: Three-Level Local Backup

We built a system of three levels. All local. All automatic. All transparent.

Level 1 — snapshots/            VACUUM INTO before every destructive op
Level 2 — backup-2026-07-12.db  on every launch, 30-day rolling window
Level 3 — export.aes256         user click, AES-256-GCM, goes anywhere

Level 1 — Transactional Snapshots.

Before any destructive operation — deleting a client, changing currency, bulk update — LockMargin creates an atomic snapshot in .lockmargin/backups/snapshots/. SQLite command VACUUM INTO creates a consistent copy of the live database. No WAL problems. One file — one transaction.

Level 2 — Daily Rotating Backups.

On every app launch, VACUUM INTO creates a dated copy. Rolling window: 30 days. Old backups are deleted automatically. The user sees a list: "backup-2026-07-12.db", "backup-2026-07-11.db" — and picks where to roll back.

Cost: $0. Infrastructure: $0. Because these are just files on disk.

Level 3 — User-Initiated Encrypted Export.

The user clicks Export. LockMargin creates a single file encrypted with AES-256-GCM using the same key as the main database. The file can be copied to USB, NAS, Dropbox — if they want. Or put in a safe. Or emailed to themselves. Their choice. We don't see the file. We don't know where it goes.

Traps We Fell Into

"What if the backup is on the same disk?"

The user chooses the backup folder. If they pick drive C: — we show a warning: "If the disk dies, the backup dies with it." We don't prohibit. We warn. Adults.

"What if the backup is corrupted?"

Every backup runs PRAGMA integrity_check after creation. If the check fails — the backup is deleted, the user gets a notification. We don't keep broken copies. And if corruption still reaches a live file, this recovery walkthrough is the order I used.

The Dropbox Trap.

Users put the .lockmargin folder in Dropbox. SQLite + cloud sync = significantly increased risk of corruption within weeks. We added detection: if the backup folder is inside a synced directory — warning. We don't prohibit. We warn.

Immutability Guard: Backup as Data Property

The most important insight: backup isn't a feature. It's a property of the data model.

We made destructive operations reversible. Delete a client — don't delete, mark with a deleted_at flag. Change an invoice — the old version stays in invoice_revisions. This isn't backup. This is architecture.

Immutability Guard eliminated most need for emergency recovery. Because most "data loss" isn't disk death. It's "oops, I clicked the wrong thing." If "wrong" can be undone — backup isn't needed.

The Lesson I Didn't Expect

Backup is fundamentally a trust problem, not a technical task.

Users who don't trust the cloud also don't trust us to do backups automatically in the background. They want to see files. Want to open a folder and see: "backup-2026-07-12.db". Want to know we're not hiding their data inside the app.

We gave them visible and auditable control. SQLite files with timestamps in an accessible folder. One click — open folder. Two clicks — copy to flash drive. Three clicks — restore.

Support tickets about data loss dropped dramatically.

Not because the backup got better. Because users stopped being afraid.

Three Questions for Your Backup Strategy

1. Automatic or manual? Manual = you'll forget. Automatic = works until it doesn't.
2. Local or cloud? Cloud is convenient, but it's someone else's server. Local is your control. Ideally both, but local first.
3. Have you tested recovery? A backup you can't restore is not a backup. It's hope. Test it. Today.

FAQ

P.S. — My old Dell Inspiron now sits on a shelf. I look at it sometimes. Not as an enemy. As a reminder. Backup isn't about technology. It's about what you're willing to lose. I was willing to lose three years. I'm not willing anymore.

About the Author

Vlad (Volodymyr) Shiyan — Founder & Developer, Kharkiv, Ukraine. Building LockMargin since December 2025. Offline-first invoicing for freelancers who are tired of subscriptions. Standard is $49 one-time. Read more about Vlad →