An empty log meant two things at once. One good, one fatal

The script watching my off-site backup has two paths. The first: "the copy is stale, making a new one" — leaves an entry in the log. The second: "the copy is current, doing nothing" — used to end without a trace.

For months I saw no problem in this. I saw it on 16 August 2026, when reviewing my whole set of backups I opened this log and understood what I was actually looking at.

Two situations, one screen

An empty log meant two things at the same time:

No backup was needed, because the previous one is fresh.
The job never started at all.

The first is fine. The second means that since some unknown day I have had no off-site copy — the one that survives a fire or a theft. Everything separates them. The screen separates them in nothing.

This is the core of what I started calling a false zero: a healthy result and a failed measurement produce the same number. Zero errors. Zero entries. Zero alerts.

A false zero is more dangerous than an ordinary error, because zero errors is exactly the result you want. Nobody digs into good news. A broken measurement disguises itself as the success of the thing being measured, and can stand like that for months — exactly as long as it stood for me.

The fix is not measuring more carefully

It is adding a third state. Not "fine / broken", but "fine / broken / don't know".

Since 16 August the script logs every run, including the ones that do nothing. One line per run, even when the run consists of concluding there is nothing to do. An empty log now has exactly one meaning: the job did not start.

The same pattern showed up the same day in a second place. Checking drive health on my home server needs a tool that only reads it with administrator rights — and a background task has no way to supply a password. Until I configured that, the script did not pretend the drives were healthy. It wrote ?? SMART unavailable and raised no alarm over it. Same third state, same rule: no reading is not a good reading.

What I did not do

I did not give the background task full administrator rights, even though that was the shortest path and tempted me the most — one line and the problem disappears. Instead the permission covers only the disk-health read tool, which writes nothing. The read runs in a mode that never asks for a password, so a missing configuration doesn't hang the background task forever — it just gives that honest question mark.

I also did not turn the "don't know" itself into an alert. A notification for every unavailable measurement would have taught me to ignore notifications — and then I would have stopped reading the real ones too.

It works the other way too

A broken measurement can produce a false alarm, and the same day handed me exactly that gift. On the first attempt at a restore test, 22 files from one office suite appeared to be missing. None were actually missing. The mounted snapshot was an older one, from 12:06, instead of the newest — I was comparing a state from hours earlier against the current one.

The number 22 was real. It just answered a different question than the one I asked.

The proper test, run against the newest copy, came out like this: 54 files, 52 byte-for-byte identical, 0 missing. The two mismatches were working files of a photo database that change during use — a mismatch there is normal. Comparing the whole system copy showed 26 differences, all in build directories, deliberately excluded. Zero differences in the data that is mine.

Three things I take from this

Zero is not a result — it is two different results that look the same. Before I trust a zero, I need to know whether the measurement happened at all.

Every automated job needs a third state. An explicit "don't know" is worth more than a false "fine" and cheaper than a false alarm.

Check what you're actually looking at. My 22 missing files did not exist. Before drawing a conclusion from a number, make sure it comes from the source you think it does — because the number is rarely wrong, but the question very often is.

All numbers come from a review and restore test carried out on 16 August 2026 on my own hardware. None of the numbers here are illustrative.