This answer is a combination of that of @lechlukasz and @db48x, also incorporating some points made in comments as well as some of my own thoughts.
The simple path forward is a combined file-system and separate-metadata approach.
By using a file system that does on-the-fly data hashing and validation, such as ZFS or Btrfs (do note that although great advances have been made, Btrfs is not considered ready for production use at this time), you can be reasonably sure that if the data can be read off the disk without the operating system erroring out, then the data read was written to disk in the way intended by the file system. By running periodic "scrub" operations, all data is read and verified against the file system's idea of what it should be.
However, that only protects against on-disk corruption (unreadable blocks, outright hardware write errors, invalid writes that corrupt parts of the data directly on the block device, etc.). It does not protect against a software bug, incorrect user operation, or malicious software which works through the intended operating system facilities for working with files, assuming that those facilities are free of such bugs.
To protect against the latter, you need another layer of protection. Checksumming or hashing data from a user application's perspective will help protect against many of the above-mentioned risks, but needs to be performed separately (either as a built-in process action in the software, or as a completely separate process).
With today's hardware and what's practical for storing large amounts of data (spinning platter hard disks as opposed to solid-state disks/SSDs), even complex hashing algorithms such as SHA1 will be largely I/O-bound -- that is, the speed at which the data is hashed will be a function of the storage system's read speed, rather than the ability of the computer's processor to calculate the hash. I did an experiment with running a user-space MD5 hashing process over approximately 150 GB of data on what in 2012 was a mid-tier consumer PC, and it finished after exercising the disk basically without interruption for about 40 minutes. Scaling those figures up 100-fold, you'd get the MD5 hashes of a 15 TB collection in about three days' time on that same hardware. By adding read transfer rate (which can be easily accomplished e.g. using RAID; RAID 0 for example is striping without redundancy, commonly used to achieve higher read/write performance possibly in combination with RAID 1 forming RAID 10), the time to completion can be lowered for the same amount of data.
By combining the two, you get the best of both worlds: the file system gives you assurance that what you received when reading the file is what was actually written, and a separate fixity-checking process can run over the entire collection ensuring that the data stored still matches what was ingested into the archive. Any inconsistency between the two (file system says the file is OK, fixity checking says it's not) will indicate a file that has been modified outside of the archive's intended mode of operation but from within the operating system's facilities, prompting a restore from a secondary copy (backup). The fixity check can thus run at a longer time interval, which becomes essential for very large archives, but any online accesses are still guaranteed to not be corrupted on the hardware if the reads succeed. In principle, the archive software could rely on the file system to report inconsistencies as read errors, and perform a separate fixity check in the background as the user is working with the file and displaying an appropriate message should that indicate that the file does not match what was ingested into the archive. Using a block-hashing file system, such a scheme would have minimal impact on perceived performance while still providing assurance that the content is correct.