Thanks. I will keep that in mind. I have a solid backup so I don't mind to play with it for a while (for testing purposes). I noticed that once installed it removed Macrium from the Boot Menu (usually the official releases updated it and not removed it completely from the BCD). This is probably related to the changes described on the page for this build. I was even able to register it with Macrium using the e-mail form they provide. Really weird.
It seems that many users are using the new builds of Windows 10 even before their official publication
Maybe so, I used MR 6 free version and it never failed, now I've been using for over a month version 7 with CBT and it works great, speed is just amazing...
CBT only eliminates the "Looking for changes" step that would otherwise occur when creating a Diff/Inc image. It does not increase data transfer speeds or improve performance in any other way. If you're seeing a data transfer speed improvement after moving to V7, it might be because on V7, the first time each destination is used, Reflect benchmarks two file write methods, namely file system cache and direct disk I/O, and then uses whichever one is faster every time that destination is used going forward. V6 also supported both of those write methods, but you could only choose one method application-wide and it always defaulted to direct disk I/O rather than determining which was faster. I believe one of the main reasons this dynamic decision was introduced in V7 was because it became clear that certain AV solutions would interfere with one write method but not the other, but different AV worked differently, so there was no clear "better" solution for everyone. If you want to see these benchmarks and defaults per destination, click the Backup menu (not the Backup tab) and select Disk Write Performance. In my own case, the "Looking for changes" only takes about 30 seconds on a partition with about 1.5 TB in use, but since Incremental backups of that partition typically take takes a few hours, CBT just didn't offer enough value for me to justify the risk. But others here capture backups every 15 minutes, so it definitely makes sense for them.
Thanks jphughan I didn't know this about the two (possible) file write methods by MR. PS: I found the KB article : https://knowledgebase.macrium.com/display/KNOW72/Disk Write Performance dialog
Turns out that's not quite the case. If I have to I will explain (it's a bit deep in details) but suffice it to say that not only the "Looking for changes" is eliminated by CBT, but also when the image is being created, the disk "block" ( a file for instance) that's been marked as "dirty" (changes in there somewhere) is being read in its entirety and only the clusters within that block that have changed are actually being written into the image being taken. In the case of CBT, only the changed clusters are being read from the disk block and written into the image. Using CBT seriously reduces the reading of the changed SOURCE partition but doesn't change the actual image being taken.
The kind I described a few days ago in this post in this thread. If you open the Reflect V7 release notes page here and search "CBT" or "Changed Block Tracker", you'll see that there have been quite a few fixes relating to BSoDs and other adverse behavior related to CBT, on top of the brief image corruption issue. I try to keep my systems as simple as possible to generally minimize risks of issues and simplify troubleshooting. CBT is a driver that operates persistently at a low level of the OS, which inherently carries some risk, and from the moment it was introduced I decided that eliminating the time taken by the "Looking for changes" step wasn't enough of a value proposition to justify that inherent risk. At least in my case, that seems to have paid off, because an extra 30 seconds on a multi-hour backup job that runs overnight is nothing, but my systems may well have been affected by the stability and image corruption issues that have come to light over CBT's lifespan thus far. Where did you find that mentioned? I haven't seen that anywhere, and I'm curious to read the technical details if they're available somewhere. My understanding of file system IO is that when you're operating through the file system, the minimum unit that can be requested to be read is a file system cluster, the size of which is determined when the partition is first formatted and the file system established. In addition, no more than one file can occupy a file system cluster, even if the file is smaller than the cluster size. These two factors come into play when tuning file systems, because if your partition will store a lot of large files, then a larger cluster size results in better performance because fewer read requests are required in order to access the entire file. However, if the partition will store a lot of smaller files, then a smaller cluster size is generally preferable, because with a large cluster size you'll end up with a lot of wasted space in the unused portions of clusters that are storing files smaller than the cluster size. And below the file system level, the minimum unit size that can be read is a disk sector, which is fixed for a given disk. So I'd be curious how all of this relates to CBT. To my knowledge, non-CBT Diff/Inc images do not have to read all file system clusters or disk sectors that comprise a file in order to determine what changed, but maybe I'm wrong.
I hope v8 is amazing and not too expensive an upgrade. When it eventually comes. Reliability is most important, followed by speed. v6 was reliable. Zero issues. v7 is less so. This is the product I choose for our company to use at work. A fail counts against me personally. Sometimes people lose their job over a big enough fail. We've not had one big enough that I could not recover from it but the issues we have had have cost several hours that should not have been lost. It's been ok recently. I hope there are no more issues.
If you're making "corporate" decisions both in the OS area as well as System integrity (imaging, file backup, etc.), I wouldn't touch any product UPGRADE until it's proven itself in the field. If you have a stable System environment that's working well, and don't absolutely REQUIRE features being made available in any product upgrade, then don't upgrade. UPDATEs are different and tend to fix/repair issues found in current releases. They need to be looked as just as carefully to insure they're dealing with issues you are experiencing... if not, why update. With personal/home Systems that you can afford to "play" with... feel free to jump in. Just make sure you have a way out that you know works for you. This is why I have been cautioning users on this Forum about using unreleased versions of Macrium Reflect (which are getting posted a little too much lately). Just because they have "corporate" LINKs associated with their availability doesn't mean they're "good" at this point. They may be BETA releases, they may be non-regression tested as of yet, they may even have bugs in them which you may not see until you try and restore older images. If you just don't care about the risks... jump in. Otherwise, at least wait for "ofishul" releases from the author... a prudent thing to do.
It doesn't seem to be "officially" released. Where do you find links to those unofficial patch details?
v4425 IS NOT an official release! Neither was v4414 or v4398... pls avoid them all for your System's safety. Why do you think they keep changing before they're released... because they're flawed and contain issues. Please stay away from them!
^ Amen! The upcoming release does seem to have some useful changes, but I don’t think it’s worth running these non-release builds even if you can find a way to download them, unless MAYBE you absolutely need these changes now, although even in that case I would be cautious because I wouldn't count on receiving support from Macrium for these builds. But on the subject of the changes, it’s nice to see that the USB driver copy will become an option since forcing it on seemed to create new problems for some people even as it solved problems for others. I reported the VSS log purge issue (and BRIEFLY ran an unofficial build to confirm the fix), and I wonder about the manage-bde fix. I haven’t noticed it being broken, and I also wonder how that even would have happened....
Thanks, TRF for posting about these releases. Sometimes folks become too anxious to update and mess their pc's up.
I have been using Excubits Pumpernickel to protect images on external USB drives but I'm not really one for fiddling with drivers, no GUI, etc. so I thought I may try MIG if you haven't had problems. An advantage of Pumpernickel, the abandoned Secure Folders, and even RansomOff Folder Protection is the ability to protect images and data by other backup programs.
Knew you'd say that! Just trying RO with only Folder Protection component on that Win10 instance ... but I'll see if it's too much of a sledgehammer to crack a nut.
