Since we have all of the documents that get restored, mongorestore could do a pared-back

We can also use this to provide a cheap verification for existing mongodump archives:

• Retain document IDs as we restore them.
• Every 100 restored documents or so, fetch those documents and add them them to a CRC64/ECMA hash. (Clear the cache of retained documents.)
• When we get namespace-eof, compute the hash.

If the newly-computed hash matches the archive’s hash, then show:

Restored documents’ checksum matches archive. Restore verified!

If they mismatch, we show:

Warning: restored documents’ checksum differs from that in the archive. The newly-restored documents may not be exactly the same data that mongodump archived.

While it’d obviously be better to point out specific mismatches, it is at least better to say “something could be wrong” than to say nothing at all. And, in the (presumed) majority of cases where we can say “Restore verified!”, users will enjoy additional assurance about their data’s integrity.

Notes:

• This is split out from the Atlas dump/restore verification project because this improvement targets fully user-driven backup & restore.
• This would only apply to --archive restorations. Backups to a directory don’t include the CRC.
• For oplog replays: we could still do the CRC check, but it’d have to be before the replay of the oplog. So the “success” message is less meaningful: “documents restored correctly, but note that oplog replay is unverified; sorry”. Still better than nothing.