| 1 |
Rich Freeman wrote: |
| 2 |
> On Tue, Apr 12, 2022 at 1:08 PM Dale <rdalek1967@×××××.com> wrote: |
| 3 |
>> I remounted the drives and did a backup. For anyone running up on this, |
| 4 |
>> just in case one of the files got corrupted, I used a little trick to |
| 5 |
>> see if I can figure out which one may be bad if any. I took my rsync |
| 6 |
>> commands from my little script and ran them one at a time with --dry-run |
| 7 |
>> added. If a file was to be updated on the backup that I hadn't changed |
| 8 |
>> or added, I was going to check into it before updating my backups. |
| 9 |
> Unless you're using the --checksum option on rsync this isn't likely |
| 10 |
> to be effective. By default rsync only looks at size and mtime, so it |
| 11 |
> isn't going to back up a file unless you intentionally changed it. If |
| 12 |
> data was silently corrupted this wouldn't detect a change at all |
| 13 |
> without the --checksum option. |
| 14 |
> |
| 15 |
> Ultimately if you care about silent corruptions you're best off using |
| 16 |
> a solution that actually achieves this. btrfs, zfs, or something |
| 17 |
> whipped up with dm-integrity would be best. At a file level you could |
| 18 |
> store multiple files and hashes, or use a solution like PAR2. Plain |
| 19 |
> mdadm raid1 will fix issues if the drive detects and reports errors |
| 20 |
> (the drive typically has a checksum to do this, but it is a black box |
| 21 |
> and may not always work). The other solutions will reliably detect |
| 22 |
> and possibly recover errors even if the drive fails to detect them (a |
| 23 |
> so-called silent error). |
| 24 |
> |
| 25 |
> Just about all my linux data these days is on a solution that detects |
| 26 |
> silent errors - zfs or lizardfs. On ssd-based systems where I don't |
| 27 |
> want to invest in mirroring I still run zfs to detect errors and just |
| 28 |
> use frequent backups (ssds are small anyway so they're cheap to |
| 29 |
> frequently back up, especially if they're on zfs where there are |
| 30 |
> send-based backup scripts for this, and typically this is for OS |
| 31 |
> drives where things don't change much anyway). |
| 32 |
> |
| 33 |
|
| 34 |
|
| 35 |
My hope was if it was corrupted and something changed then I'd see it in |
| 36 |
the list. If nothing changed then rsync wouldn't change anything on the |
| 37 |
backups either. I'll look into that option tho. May be something for |
| 38 |
the future. ;-) I suspect it would slow things down quite a bit tho. |
| 39 |
|
| 40 |
Dale |
| 41 |
|
| 42 |
:-) :-) |
Archives