I haven’t used monitoring tools to look at this, but I believe it determines which blocks need to be written by analyzing the index data in the various backups, and in RDR scenarios, by analyzing the current state of the target. If Reflect had to write each backup sequentially, restores would take noticeably longer, and RDR wouldn’t even be a thing. That said, SSD wear seems to be a hugely overblown concern. The 1TB Samsung 970 Evo Plus that I use in my everyday laptop has an endurance rating of 600 TBW, and based on metrics I can see in Samsung Magician, I won’t get there for about 75 years. Smaller capacity SSDs often have lower ratings, but that seems like plenty of headroom.
Thanks. I assumed Reflect did something like that, but I didn’t see a step in the restore logs where it read the index of each image before starting the restore. It just listed each image once for each partition and says when it's looking for RDR changes.. I guess it doesn’t list everything it does.
Apparently a private (by invitation only) BETA for Macrium REFLECT (v9...?) seems to be in the works for start up. That usually means a new major ALPHA version is ready for multi-user testing. I have no details beyond that (product or otherwise)... just wanted to let everyone know that the process appears to be beginning. Keep an eye on those wallets
