How does Delta Restore work?

[Haloes]

Although I've been using backup/restore software for decades (Macrium and Hasleo) I'm puzzled about how Delta Restore works.
I only use Full Backup and therefore Full Restore options since my current C: is only a 512GB SSD.
Backup takes < 5 minutes writing to an external SSD.

So Delta Restore only restores the changes in the file system.
After a backup, and before the restore, a file system will have had many changes including sector positional changes.
How does it know which sectors haven't changed.

Can anyone enlighten this "relative" newbie?
Thanks.

[CDC9762]

From their site:
Delta Restore in Hasleo Backup Suite is a smarter and more efficient data restoration technology. It works by comparing the data in the historical backup with what currently exists in the original location, retaining all unchanged data and only restoring the changed parts.
Obviously, a comparison basis makes sense and also this is why changes in the size of partitions from the image to the current partition will not permit a delta restore.

[Haloes]

Thanks @CDC9762.
I was wanting a more detailed description which I really should have done before posting.
I'll dig deeper and see what I can find.
One thought was that since writes to SSDs take a lot longer than reads then I can see how the Delta Restore method should speed up restores, i.e. 2 reads when the "data" matches as opposed to 1 read and 1 write when the "data" needs updating.

[Froggie]

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!

[Haloes]

Thanks Froggie, yes that helps a lot.
I assume then that each timestamp is unique for each block.

[Froggie]

That is correct.  The block size varies depending on the formatting of the FileSystem (default for NTFS is 4K <8-sectors>).  When each block is changed, an entry is journaled into the metadata with the change date/time.  The comparison between the last imaged metadata and the current on-disk metadata is made and blocks are selected (only changed blocks) for imaging accordingly.  A restore will put back only the blocks in the image than are different than the on-disk metadata (newer or older depending on the image used for restore)... basically only changed data blocks will be restored (AKA "DeltaRestore").

It truly is a "time machine" of sorts" 

[Froggie]

The actual detailed process is most likely a bit more complicated, but I'll leave that up to the Developers to expound on if they feel it's required or necessary (Intellectual Property ya know ).