I'm most interested in the delta copying. After a little bit of research in the forums I'm guessing you save block hashes of full copies and then compare the source blocks to the block hashes and copy only if they differ.
Or does the app install a driver to get the changed blocks in files without rereading the whole file?
It's former. It splits files into blocks (defaulting to 32KB, but that's configurable), computes hashes (two separate hashes per block) and stores them in a file in the backup config directory. These are used to detect modified blocks. It also computes a hash of an entire file and stores it in the same hash file. This is used to hedge against false negatives with modified block detection. The original version (from '09) didn't use the full-file hash, so it resorted to re-copying files in full after several incremental updates.
Is the full-file hash actually faster than re-copying the whole file?
Re-calculating a full-file hash will require reading the whole file anyway. Which will take around the same amount of time as re-copying the whole file, since the sequential write speeds of most HDDs and non-entry-level SSDs are similar to their sequential read speeds. The only benefit would seem to be that your SSD might last a bit longer... but how many consumers use SSDs to store their backups?
VSS Writers may include this information for their files. So it is probably available for e.g. a Exchange database. The examples on the page are VMWare and TrueCrypt and I don't think they register VSS Writers.
It's been too long since I've actually worked with it, but it is how Win8 does file history and wbackup uses it to make its differential backups, of all files, not just log like files.
