| 1 |
Am Tue, Apr 12, 2022 at 05:03:01PM -0500 schrieb Dale: |
| 2 |
> Rich Freeman wrote: |
| 3 |
> > On Tue, Apr 12, 2022 at 1:08 PM Dale <rdalek1967@×××××.com> wrote: |
| 4 |
> >> I remounted the drives and did a backup. For anyone running up on this, |
| 5 |
> >> just in case one of the files got corrupted, I used a little trick to |
| 6 |
> >> see if I can figure out which one may be bad if any. I took my rsync |
| 7 |
> >> commands from my little script and ran them one at a time with --dry-run |
| 8 |
> >> added. If a file was to be updated on the backup that I hadn't changed |
| 9 |
> >> or added, I was going to check into it before updating my backups. |
| 10 |
> > Unless you're using the --checksum option on rsync this isn't likely |
| 11 |
> > to be effective. |
| 12 |
|
| 13 |
> My hope was if it was corrupted and something changed then I'd see it in |
| 14 |
> the list. If nothing changed then rsync wouldn't change anything on the |
| 15 |
> backups either. I'll look into that option tho. May be something for |
| 16 |
> the future. ;-) I suspect it would slow things down quite a bit tho. |
| 17 |
|
| 18 |
The advantage of an integrity scheme (like ZFS or comparing with a checksum |
| 19 |
file) over your rsync approach is that you only need to read all the datas™ |
| 20 |
from one drive instead of two. Plus: if rsync actually detects a change, it |
| 21 |
doesn’t know which of the two drives introduced the error. You need to find |
| 22 |
out yourself after the fact (which probably won’t be hard, but still, it’s |
| 23 |
one more manual step). |
| 24 |
|
| 25 |
-- |
| 26 |
Grüße | Greetings | Salut | Qapla’ |
| 27 |
Please do not share anything from, with or about me on any social network. |
| 28 |
|
| 29 |
“An itching nose must be scratched.” … Kosh (Star Wreck) |
Archives