The 3-minute test that predicts whether your SME will lose all its data (and why “backup completed” means nothing)

What actually happened (in 2 levels)

The technical case is simple when you strip the jargon. SQLite is, literally, an internal address book used by thousands of applications — from the app on your phone to internal business systems — to write and read data. That address book has a mechanism called “WAL” (which stands for “write-ahead log”): imagine every time someone writes something in the book, a backup copy is first made on a separate sheet, so you don’t lose what’s already there.

Tailscale, the company that builds one of the most-used VPNs by SMEs so their employees can work from outside the office, discovered that a fragment of that mechanism had been misbehaving for 16 years: when the system restarted at certain moments, the backup copy got “stuck” at a previous state. The system kept working. The logs said “OK”. But the copy was out of date. And when someone tried to restore from it, they received incomplete data or simply empty data.

The critical thing is not the bug itself. It is that:

• The system reported “all OK” for years.
• The backup log marked every night “completed” successfully.
• The first real warning came when someone needed the data and it wasn’t there.

This is what cybersecurity calls a “silent failure”: it doesn’t warn, it doesn’t beep, it doesn’t show up in any dashboard. It only manifests itself when it’s already too late.

Why your SME (almost certainly) has the same pattern

Your SME probably doesn’t use Tailscale, nor SQLite directly. But the pattern is identical to that of any cloud service you have contracted: the CRM where you store your customer data, the billing software, the online appointment tool, the professional email, the server’s cloud backups. Each one of them has, hidden somewhere, its own “WAL” — its own internal protection system — that:

• Restarts periodically (provider updates, nightly maintenance, power failures).
• Has a backup that gets overwritten every night.
• Tells you “OK” because the file exists, but doesn’t verify that valid data is inside.

According to public cloud industry statistics, between 30% and 40% of European SMEs discover their backup is broken only when they try to use it. It’s not a rare case. It’s the most common data incident pattern in SMEs.

The Sunday restore test (5 steps, 3 minutes)

You don’t need technical knowledge. You need 3 minutes on a Sunday afternoon — when nobody bothers you — and a coffee. These are the 5 steps:

1. Ask your provider for the latest backup. An email like: “Hi, could you send me the latest complete backup of my account, in a format I can open on my computer?” If they say “we can’t” or “you have to pay”, you have a root problem.
2. Open the file they send you. If it’s a spreadsheet: open it and check it has real rows (clients, invoices, products). If it’s a database: open it with the tool you usually use and verify that data appears.
3. Count 5 records and compare them with your current system. For example: take the last 5 clients you have. Are they in the backup? With the correct data (phone, email, address)? If any is missing, the backup is incomplete.
4. Verify the date. The backup should have data no more than 24-48 hours old. If they tell you “the last backup is from last month”, you have a bigger problem: nobody knows what’s happened in your system since then.
5. Take a screenshot of the file open and save it. This is your “evidence that the backup works”. The day you have a real incident, that screenshot will be the difference between recovering your business or losing weeks of work.

If any of these steps fail, don’t panic: it means you have a silent problem, but you’re still in time to fix it. A backup that’s never been verified is not a backup: it’s a hypothesis.