Verify the output, not the report. Especially before a delete
Exit codes, summaries, and "9 files matched" are reports. The file on the drive with the right checksum is the output. Tools that summarize will summarize wrong in exactly the cases that matter, and the cases that matter are the destructive ones.
Where it bit
A background shell wrote to the archive drive, exited 0, and had written nothing, because background bash cannot write to mounted volumes on that machine. An earlier pass claimed nine exports matched by checksum; a later pass found two were not on the drive at all, and all fourteen were re-hashed before anything was deleted.
The practice
Archive, verify in directory mode with itemized output, checksum the files themselves, then delete. Never in the reverse order and never on a summary. Measure with the tool that reads the object (md5, ffprobe, a real request), not the tool that reads the log.
Check it
rsync -rcni SRC/ DEST/ | grep -v "^\.d" | head # anything printed is a difference md5 -q SRC/file DEST/file
Get this check as a script you can run tonight
What to do with this
If you run a business on something AI built and the checks came back with more than you expected, that is worth a conversation.
We do a free 30-minute Health Check for service businesses that want to know exactly where their biggest leaks are. No slide deck. No pitch. We ask questions, find the gaps, and tell you what we see. If there is no obvious fix, we will tell you that too.
Blinkz finds what is broken in how a business runs, then fixes it. AI only where it earns its place.