> Speculation: corrupting input, either international or North American? E.G. UTF-8, SQL escape, CSV quoting.
I read it as filesystem corruption from a bad disk, coupled with redundancy that doesn't actually work.
I would not expect a disk failure to replicate to the backup.
Edit: Should add "won't be silently propagated"
Comprehensive DR testing is really difficult. Many orgs settle for “on paper,” or “in theory” substitutions for real testing.
They do it right; no problem.
Doing it right, though … there’s the rub …
But they said nothing about it being bad drive, just corrupted data file, which very well might be software bug or operator error
It's not typically a performance concern because computing checksums is fast on modern hardware. Besides, historically IO was much slower than CPU.
It is expensive. It might be prohibitive in a very competitive environment. This is hardly the case here. Safety first!
There are databases that maintain redundant copies and can tolerate disk / replica failure. e.g. Cassandra.
That's different from filesystems that do checksumming (zfs, btrfs). Those can detect corruption.
In any case, if you use a database it handles these things by itself (see ACID). However I don't believe they can necessarily detect disk corruption in all cases (like checksumming file systems).
Oh you mean they should be testing/validating the generated backup db file before replicating it to long-term archive ...
No, Restore is a use case.
(Replace "use case" with "requirement" or "user story"...)
That said, I do remember this being an issue even with plain text.