4 ms·
> And within the last two weeks, I destroyed many of my oldest snapshots. The goal of this repost is to save some trouble to people who may also delete old sna
by csdvrx 3y ago
> And within the last two weeks, I destroyed many of my oldest snapshots.
The goal of this repost is to save some trouble to people who may also delete old snapshots if they don't understand how they can be impacted by this bug as the original title was very unclear
- gavinhoward 3y agoYes, that was a good idea. Hey, are there any tools to search for all zero blocks? Maybe that might help detect corruption in this case.
- csdvrx 3y agoLast 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