dd or any other application does not have “some kind of built in verification” in the sense you're probably thinking of: it doesn't read back the data from the storage medium to compare with what was written. That's the job of the operating system.
It is not really possible to do a read-verify down to the hardware from an application. It would work in some scenarios, but in most cases it would achieve nothing. The application could read back what it just wrote if it's writing directly to a storage medium, but that would typically read back from an in-memory cache, which wouldn't give any useful assurance. In the example you cite,
dd is writing to a pipe, and in that case it has no control over what happens to the data further down the line. In your rsync example, a second pass of
rsync --checksum is pointless: in theory it could catch an error, but in practice, if an error does happen, then the second pass would probably not report anything wrong, so you're wasting effort on something that doesn't actually give a useful assurance.
However, applications do verify what happens to the data, in the sense that they verify that the operating system has accepted responsibility for the data. All system calls return an error status. If a system call returns an error status, the application should propagate that error to the user, generally by displaying an error message and returning a nonzero exit status.
dd is an exception: depending on the command line parameters,
dd might ignore some errors. This is extremely unusual:
dd is the only common command with this property. Use
cat instead of
dd, that way you don't risk corruption and it may well be faster.
In a chain of data copying, two kinds of errors can arise.
- Corruption: a bit is flipped during the transfer. There is no way to verify this at the application level, because if that happens, it's due to a programming bug or hardware error that is highly likely to cause the same corruption when reading back. The only useful way to verify that no such corruption happened is to physically disconnect the media and try again, preferably on a different computer in case the problem was with the RAM.
- Truncation: all the data that was copied was copied correctly, but some of the data was not copied at all. This one is worth checking sometimes, depending on the complexity of the command. You don't need to read the data to do that: just check the size.