Re: No file exists...
I was bitten, hard, by a similar file system problem.
The standard Unix file system (BSD FFS, Berkeley Fast File System) put all of its effort into metadata consistency, and none in to file data consistency. When sometimes had the effect of "correcting" corrupted directory entries to point to zeroed blocks if they were invalid. While in some cases it wasn't entirely silent about doing this, it wasn't a fatal file system check error. The messages looked the same as and were buried among the many others in the boot log after an unexpected shutdown.
The result was that the data directory looked entirely correct, with no indication of a problem. File permissions, timestamps and sizes were correct. But some the file contents were zeros. Which were dutifully backed up, overwriting the incremental and then staggered backups. A few weeks later when this was discovered, there was no backup, on-site or off-site, that contained the data.
Ironically, this was in the middle of BSD Unix fans slagging the Linux file system designers on how "unreliable" it was by not implementing continuous metadata consistency. A Linux crash would often result many more metadata inconsistency problems, but almost never file data corruption. And especially not the horrendous silent data corruption when the directory structure appeared consistent (because the file system programmers cared about "their" directory structure and performance benchmarks, but not the user's data).
The point here is that you can have a sophisticated, responsible backup scheme and still lose data. Saying that "the harm wasn't our fault because they should have had backups" misses the point.
Biting the hand that feeds IT
