On Tue, Apr 12, 2022 at 1:08 PM Dale <[email protected]> wrote: > > I remounted the drives and did a backup. For anyone running up on this, > just in case one of the files got corrupted, I used a little trick to > see if I can figure out which one may be bad if any. I took my rsync > commands from my little script and ran them one at a time with --dry-run > added. If a file was to be updated on the backup that I hadn't changed > or added, I was going to check into it before updating my backups.
Unless you're using the --checksum option on rsync this isn't likely to be effective. By default rsync only looks at size and mtime, so it isn't going to back up a file unless you intentionally changed it. If data was silently corrupted this wouldn't detect a change at all without the --checksum option. Ultimately if you care about silent corruptions you're best off using a solution that actually achieves this. btrfs, zfs, or something whipped up with dm-integrity would be best. At a file level you could store multiple files and hashes, or use a solution like PAR2. Plain mdadm raid1 will fix issues if the drive detects and reports errors (the drive typically has a checksum to do this, but it is a black box and may not always work). The other solutions will reliably detect and possibly recover errors even if the drive fails to detect them (a so-called silent error). Just about all my linux data these days is on a solution that detects silent errors - zfs or lizardfs. On ssd-based systems where I don't want to invest in mirroring I still run zfs to detect errors and just use frequent backups (ssds are small anyway so they're cheap to frequently back up, especially if they're on zfs where there are send-based backup scripts for this, and typically this is for OS drives where things don't change much anyway). -- Rich
