Last time I checked, the discussion about how to best detect affected files was still going on. IIRC having a null-byte prefix may be caused by the special scr

Last time I checked, the discussion about how to best detect affected files was still going on. IIRC having a null-byte prefix may be caused by the special scripts to artificially and forcefully trigger the bug. In naturally corrupted files, the position of null bytes may be more random than that. New tests reveal the IO load may matters a lot: if you kept your IO low, you may have as few as 0.01% corrupted files. All this brings me back to my original idea: the best solution may be using metadata from old backups (ctime, checksum) and looking for discontinuities (same ctime, different checksum) like an IDS would, as checking for null bytes would require too much calibration. This method will require acquiring this metadata from old backups to figure which file got corrupted when, and what's the best backup to restore it from