3 ms·
interesting find! I wonder what would be a good safeguard to this. I feel like just backing up your data would offer something - but a file could silently chang
by meesterdude 10y ago
interesting find! I wonder what would be a good safeguard to this. I feel like just backing up your data would offer something - but a file could silently change and become corrupted in the backup too.
- ralfd 10y agoHm. You could make two backups and checksum each file and safe the checksum. Then you could compare regularly file contents with the initial checksum, if there is a mismatch copy from the other backup.
- icebraining 10y agoGit-annex is nice for this; the fsck command will check the file against a checksum and request a new copy from other node automatically if the check fails.
- heinrich5991 10y agoYou could use ZFS, then the file cannot silently become corrupted.
- dpedu 10y agoYes it can. ZFS will only notice next time you scrub or read the sector.
- db48x 10y agoSure, but your ZFS pool will have redundancy, and ZFS will know which block was corrupted. This lets it recover from the error.
- ianhowson 10y agoIf the corruption occurred on disk, yes. If it occurred in memory then it will write multiple incorrect copies to disk.
- X86BSD 10y agoThis is why ECC is important. Many many people poo poo the idea that it's needed. But by not having it you have left a single vital part of the data path unprotected. And ram and disk is cheap, losing your data is not. The risk simply isn't worth it to save literally a few dollars.
- db48x 10y agoThat's no argument against ZFS, or backups, or any other form of redundancy. Only the insane would buy computers without ECC.