Your Database Is Corrupted. Your History Is Not.
That line appeared on my screen on a Tuesday morning, eleven minutes before a client call. Everything after it was decided by one question: did I have a copy from yesterday?
Key takeaways
- A corrupted database is a file problem. Lost history is a process problem.
- First hour: stop writing, copy the file and its sidecars, never repair the original.
- Recovery order: export from the copy, then dump, then backup, then archive rebuild.
- A backup you never restored is a rumor, not a backup.
- Prevention is cheap: versioned copies, offline copy, tested restores.
The first hour: stop writing, start copying
Do not reopen the app and hope. Every write to a corrupted file can make it worse. Do not run a repair tool on the original. Do not let a cloud sync client touch it.
Copy the file. Right now, exactly as it is. Copy the database file, and if you see them, the -wal and -shm files next to it. SQLite writes recent committed transactions to the Write-Ahead Log before they land in the main file. Copy only the main file and you may leave yesterday's work behind. Copy the sidecars, and the copy carries the full story.
Never, in the first hour
- Save over the file "to fix it".
- Let a sync client touch it.
- Open it in three programs at once.
- Run repair on the original.
- Delete the -wal file to "simplify" things.
Every one of these turns a file problem into a history problem.
From this moment you work on the copy. The original is evidence, not a workspace. The business can wait one hour. The record cannot wait for a careless write.
I copied the file before trying anything. Two hours later the original was unreadable — my repair attempt had seen to that. But the copy still held every invoice from the previous week. The copy is not paranoia. The copy is the plan.
What actually corrupts a database
SQLite is not fragile. It survives crashes that kill lesser databases. Corruption almost always comes from the environment around the file:
- Power loss or a hard shutdown in the middle of a write.
- A failing disk with bad sectors under the file.
- A full disk that interrupts a transaction.
- Two writers at once — typically a cloud sync client copying the live file mid-transaction.
The last one is the quiet killer. A sync tool does not know your database is in the middle of a transaction. It copies half of one. That is how a healthy file becomes a malformed one. Sync your exports and closed copies, never the live database.
When the corruption is your fault
Most corrupted databases I have met were self-inflicted. A sync client pointed at a live file. An antivirus holding a lock mid-write. A disk that was full on a Friday night. None of that is bad luck. It is configuration. Fix the configuration and corruption stops being a disaster and becomes a footnote.
The recovery order, step by step
Work in this order. Stop at the first step that gives you your data back.
- Open the copy read-only and run an integrity check. If it opens, export everything — CSV, JSON, a full dump — before you touch anything else.
- If it does not open, run a recovery dump on the copy. SQLite can pull readable pages out of a damaged file. Ugly output is still your data.
- If the dump is not enough, restore yesterday's backup to a temp folder and verify it: one client, one invoice, one total.
- If the backup is old, restore it and re-apply the gap from what you have: sent PDFs, CSV exports, the bank statement.
- Only then decide what happens to the original. Keep it. Corrupted files have a way of becoming readable again next year, with better tools.
Three commands. The first tells you what survived. The second extracts it. The third gives you a clean file. That is the whole of SQLite corruption recovery: check, extract, rebuild.
If you reached this article without a tested backup, the fix is small now. After the next failure it is a reconstruction. See how LockMargin keeps the record >
The recovery matrix
| What you have | Realistic outcome |
|---|---|
| -wal file + main file | Recent work recoverable, often in full |
| Yesterday's tested backup | One day of re-entry, nothing more |
| Week-old backup | A gap to rebuild from PDFs and the bank |
| Only sent PDFs + bank statement | An evening of reconstruction |
| Nothing | History becomes archaeology |
| Cause | Typical difficulty |
|---|---|
| Power loss mid-write | Easy — the WAL usually carries you home |
| Failing disk | Medium — copy first, read once |
| Deleted file | Hard — but PDFs and the bank remember |
| Encrypted disk + lost key | Impossible — the key is the business |
When there is no backup
Sometimes there is no backup. Then the evening belongs to reconstruction. Invoices come back from the PDFs you sent. Payments come back from the bank. Clients come back from email.
What does not come back is the connective tissue: why an invoice was split, which rate a client approved, which project an expense belonged to. The numbers can be re-typed. The relationships cannot. That gap is Recovery Debt, and it is the most expensive thing a freelancer can accumulate without noticing.
Rebuild what you can. Write down what you remember. Then fix the process, not the mood.
A backup you never tested is a rumor
A backup you have never restored is a rumor. It claims to hold your business. You have never checked.
The ritual is small and quarterly: restore the latest backup to a temp folder, open it, find one client and one invoice, check one total. Five minutes, once a season. It converts a rumor into a fact. The quiet certainty you get from that test is what I wrote about in the backup problem article.
Verification, not possession. The drive in your drawer does not make you safe. The restore you tested does.
Documents you should never delete
- The sent PDFs. They are the client-facing copy of every invoice.
- CSV exports. They are the plain-text skeleton of your history.
- The bank statement. It is the third witness to every payment.
- Approval emails and chat logs. They are the agreement behind the numbers.
- Old backups, even the "stale" ones. Stale is better than absent.
- The corrupted original. Better tools next year may read what today's cannot.
Keep each of these for as long as you keep the business they describe. Storage is cheap. A missing approval is not.
Make the next corruption a non-event
- Keep three copies, on two media, one offsite. The full argument is in the 3-2-1 write-up.
- Version your backups. An overwritten backup is a single point of failure with extra steps.
- Sync exports and closed copies, never the live database file.
- Keep a plain-text archive: CSV and PDF outlive every tool, including mine.
- Test one restore per quarter. Five minutes, once a season.
Tax authorities do not care which tool you use. They care that you can produce records. The IRS asks you to keep books that show your income and deductions. HMRC asks for records you can supply on request, kept for years. A folder of hopes is not records.
None of this requires a tool. All of it requires a decision, repeated until it is boring. LockMargin's job is to make the decision easy: a local SQLite database, open formats, backups you control. The discipline stays yours. How those automatic backups work under the hood — and why nobody asked for them — is in How We Built a Backup System Nobody Asked For.
The longer version of this argument — why freelancers lose data and how to stop — is in The Freelancer Backup Problem Nobody Talks About. The storage side is in Own Your Data. If a stolen laptop is your version of this story, read what happened to my client data. And the engineered version of "records you can trust" starts with Snapshot Billing and the security overview.
Questions freelancers ask
What is the first thing to do when SQLite says the database is corrupted?
Stop writing. Copy the database file and its -wal and -shm sidecar files to a quarantine folder, then work only on the copy. The original is evidence, not a workspace.
Can a corrupted SQLite database be repaired?
Often, yes. A recovery dump can pull readable pages out of a damaged file, and an integrity check on a read-only copy tells you what survived. But export first, and never repair the original.
Why does cloud sync corrupt a database?
Sync tools copy the live file in the middle of transactions and can write it back from two places at once. They produce half-written copies. Sync your exports and closed copies, never the live database. The Dropbox version of that rule is in should your invoices live in Dropbox.
How often should a freelancer back up a database?
Daily is enough for most freelance businesses, versioned rather than overwritten, with at least one offline copy. The honest rule: back up as often as you can afford to lose work.
Is an automatic backup enough?
No. A backup you have never restored is a rumor. Restore it to a temp folder once a quarter and check one client, one invoice, one total. Verification, not possession.
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 →
Ready to own your freelance data?
Own your tools for $49 once → Read the Manifesto →Get the Client Data Protection Checklist — PDF, no email required.
Not ready to own yet? Start is free — 5 clients, 5 projects a month, unlimited invoices.
No subscription · No account required · Your data stays yours forever