Finding or confirming absence of corrupted data in MongoDB
demux finishing (err:corruption found in archive; I/O error reading length or terminator ( gzip: invalid header ))


This error message refers to processing of the gzip archive rather than the BSON data within. Your test with gzip -t implies that the contents are likely OK and the error may be due to ignorable padding at the end of the archive (see: gzip complains with trailing garbage ignored).


  All but one are getting loaded properly. That one reproducibly hangs (indefinitely)


If the problem is easily reproducible, I would raise a bug report in the MongoDB Jira TOOLS project including more details such as the specific versions of mongodump and mongorestore and command line parameters used as well as how long you waited. It seems reasonable for mongorestore to have some sort of timeout or error handling for this case rather than hanging indefinitely; I also wouldn't expect mongodump to create files that the same version of mongorestore cannot handle.


  Now I find myself with some indication that a file I have loaded may have been corrupt, or at least had a corrupt header. Issuing realistic queries to the collection in question and its indices returns results that look reasonable.
    How can I definitively detect or rule out "corruption" of this type?  What indeed does "corrupt" mean in this context? Can I expect to find it in the database, or only within the zip file?


It's unlikely that you would be able to restore corrupt BSON documents into MongoDB, but there may be some nuances depending on how/where data is corrupted. In most cases invalid data will trigger an exception/assertion when the server attempts to read the BSON, but valid BSON does not necessarily mean that the field contents are as expected.

To be entirely certain you would have to compare the document counts or checksums of the restored data against the original data (assuming you still have a copy other than the gzip archive).