There is no "matching" of DATA... that was a very old approach used in delta restore's infancy when developers first started working with this stuff (AX64 and Terabyte unlimited). Each block of DATA has a time stamp as to when it was last modified (FileSystem metadata). A reasonable DeltsRestore process only needs to look at the metadata TimeStamps to determine whether a block of DATA needs to be restored... it doesn't need to compare the DATA. That's the main method used for today's DeltaRestore for "supported" FileSystems. When imaging unsupported FileSystems (ext<n>, etc.), different methods are used depending on the apps knowledge of the unsupported FileSystem (used sectors, special metadata available, etc.)
Advancing on that principle, apps like Macrium REFLECT add a special driver and disk sector map (CBT option) to assist in marking actual changed sectors rather that the full block journaled by the metadata System. This allows REFLECT to restore only the actual changed sectors rather than the entire data block... a tiny bit faster than metadata block refresh for normal usage, much faster for large database users.
As expected, during a LIVE imaging event (running under the OS), any data change between the actual beginning of the taking of the image (frozen FileSystem) and the restore time will be lost in the process. If the image is taken using the Recovery Environment, no changes are being made between the taking of the image and the immediate recovery due the inactive OS partition being imaged,
Hope this helps!
Advancing on that principle, apps like Macrium REFLECT add a special driver and disk sector map (CBT option) to assist in marking actual changed sectors rather that the full block journaled by the metadata System. This allows REFLECT to restore only the actual changed sectors rather than the entire data block... a tiny bit faster than metadata block refresh for normal usage, much faster for large database users.
As expected, during a LIVE imaging event (running under the OS), any data change between the actual beginning of the taking of the image (frozen FileSystem) and the restore time will be lost in the process. If the image is taken using the Recovery Environment, no changes are being made between the taking of the image and the immediate recovery due the inactive OS partition being imaged,
Hope this helps!