rsync does not protect you from bitrot unless you have some script that specifically collects the rsync log and tracks when existing files change, and you somehow know every file that should not have changed and get alerted that a file changed when it shouldn't have.
Even with that, that is still just 2 equally authoritative copies, without any way to know which one suffered the bitrot.
Ok the tie-breaker data could come from history. Yesterdays log and the day before gives you the extra data points to say which side changed. As long as the log itself is somehow above reproach.
Except this script is a myth anyway. You would still need to have something where you tag files as "this file shall never change again, so if it ever appears to, tell me so I can ok or reject the change." and you would have to actually do that tagging and reviewing.
> rsync does not protect you from bitrot unless you have some script that specifically collects the rsync log and tracks when existing files change, and you somehow know every file that should not have changed and get alerted that a file changed when it shouldn't have.
You're right and that's the big thing most are missing. Name your files and write your scripts accordingly I'd say.
My rsync backup'ing script first does a dry run and then serious analyses on the result of the dry run is done. If anything looks out of the ordinary, the script refuses to go ahead and warns me.
rsync silently copying bitrot to backups is the stuff nightmares are made off.
> Even with that, that is still just 2 equally authoritative copies, without any way to know which one suffered the bitrot.
I personally have a sizeable percentage of my files (like, say, family pictures) that have part of the checksum in the name of file:
dsc003784-b3-79a7208c51.jpg
This means that file should have it's Blake3 checksum beginning with 79a7208c51. And these have been vetted, so in case there's a mismatch, the authoritative file is the one with the proper checksum.
And the system/disk that gave back a bogus checksum has explanations to give ; )
> Except this script is a myth anyway. You would still need to have something where you tag files as "this file shall never change again, so if it ever appears to, tell me so I can ok or reject the change."
I don't think it's a myth. My script does that with the checksum as part of many filenames: if during the dry run the script notices a file with such a checksum is present but different on both systems, I know immediately that something is off.
Even with that, that is still just 2 equally authoritative copies, without any way to know which one suffered the bitrot.
Ok the tie-breaker data could come from history. Yesterdays log and the day before gives you the extra data points to say which side changed. As long as the log itself is somehow above reproach.
Except this script is a myth anyway. You would still need to have something where you tag files as "this file shall never change again, so if it ever appears to, tell me so I can ok or reject the change." and you would have to actually do that tagging and reviewing.