It's close. Most of the stuff found recently are really edge cases and the Devs are jumping on them very quickly. A lot of this stuff would never be found using an internal Beta test team like they did prior to v7... the "by invitation" public Beta period has found a lot of issues, some at the nit-picking level, and has created a lot of dialog about changing Engineering design decisions via open team discussion. Although it's taking just a bit longer than they planned... I think you're gonna get a great product... just like they did when v6 was released.
According to their site, Version 7.0 was released in February 2017 http://updates.macrium.com/reflect/v7/v7.3.5758/details7.3.5758.htm
OK, a more general question... what kinds of features/options would excite you after 4+ years as far as v8 would be concerned. Reflect has been a fairly good product over those years... what does it need to do to make it GREAT...??
Not sure what you’re seeing in that log to give you that impression. As TheRollbackFrog said, the beta period has resulted in a variety of bug reports and enhancement suggestions. Some have been important, some have been minor but will still be nice to have fixed/implemented, some are likely to be relevant to a larger population, and some may only ever be relevant to smaller populations or edge cases. The log is definitely long — this is easily the longest beta period and the greatest number of beta releases I’ve seen out of the five Macrium betas I’ve been involved with thus far — but that’s a testament to the beta testers and Macrium’s responsiveness to their findings and suggestions. And one thing that’s easy to miss when reviewing the entire log in one stretch as shown on that page is how closely spaced the releases are. Macrium iterates VERY quickly on their betas, and V8 has been no exception. The only times there have been a longer gap between V8 releases — and “longer” is very much a relative term here — have been when the next release contains a more significant new feature or change, like Macrium TbFAT or the redesigned Logs interface. But apart from those, a quick review of the release dates makes it clear that neither Macrium nor the beta testers are exactly sitting around.
Acronis has one useful feature that other Programs do not have. This is a very simple, standalone MBR repair command. Macrium also repairs MBR, of course. ... but only complete with partition recovery. I think it will be useful if in the Macrium program MBR recovery will be a separate command, as in the Acronis program. Please do not think that I am promoting Akronis ... Today Akronis has turned into a monster, although 6-8 years ago it was a good program.
Just that there appears to be quite a list of changes in a short period of time. Not an insult to their efforts. Just that it looks like there is some work left to be done Despite the internet claiming this was going to release last month. And yes, I understand it was not the company that made this claim. @TheRollbackFrog I certainly don't want Acronis like features coming to this product. I feel the feature set is pretty good. As long as the product is reliable and effective I am good with it.
Hm, I was confident that when restoring a boot, there was no need to restore the entire system https://knowledgebase.macrium.com/display/KNOW72/Fixing Windows boot problems As well.
@yoorrik - MBR repair is not a very common occurrence. The last time I saw a need for it was when I was a Rollback RX user years ago... it was needed a lot with that application's failures . Other than that, not so much. There are many standalone apps that perform that function (BOOTice, etc.) and some partition mgmt apps (Partition Wizard, etc.) that do the same. Since I need partition mgmt. more than MBR repair, I just use that app when MBR work is needed. Adding that function to an imaging program (especially one that repairs the MBR with the image restoration process) just starts its way down the ol' Acronis trail, which I, personally don't think is healthy. @imdb - Reflect could be a bit faster but relies on Window's disk I/O APIs to do it's DATA movement. Apps that use Linux I/O seem to b e a bit faster doing the same function. Reflect hasn't "parallelized" it's code beyond available processor cores, it doesn't use threads to assist in its compression work. If it did it may get some additional time back in that area. But threads cannot assist in doing any of the I/O, they must check out of their process and jump into a QUEUE for the Cores since only Cores can do i/O functions within the processor. Sure, other imaging apps have been faster but that slight additional speed while imaging has never been enough for me to abandon the RDR function developed in v6. To my knowledge, the are only (2) imaging apps currently available that use an RDR-like approach to restoration... Reflect & Image For Windows (IFW), both work very well. As far as size is concerned, a different compression algorithm would have to be chosen, and for that to work to your advantage you would need a much faster processor and target disk to insure the timing remains the same and doesn't get slower... you just have to choose your poison IFW does give you many more compression options than Reflect, some are more helpful than others depending on the resources your System has available.
Given that UEFI, which uses GPT disks, became the norm on new PCs about 10 years ago now, I wouldn’t anticipate a lot of new development in the MBR space. I realize that MBR non-OS disks exist, but those are limited to 2TB and Windows has supported GPT on non-OS disks since XP 64-bit and Vista, so there’s really no good reason to use them anymore. Reflect also specifically bills itself as a backup and restore application, NOT a partition management utility. Even the “MBR repair” you’re referring to as as part of a restore is actually just resorting the MBR in the image, not technically a repair. And if Reflect starts dabbling in partition management functionality apart from actual restore operations, then people will start saying, “MiniTool Partition Wizard can do X. Reflect should add that.” And then Reflect might end up bloated like you just said Acronis already is. Sometimes it’s good to pick the right tool for the job, not expect some other tool to take on that role.
In terms of compression speed and disk image file size, Acronis is definitely the king. It always produced the smallest image file in shortest time period. Terabyte IFW produced a slightly larger sized image file with ~20-30% longer imaging time; or you can chose a compression level to favor shorter time - but in this case the image file will be larger. Macrium is pretty weak in these aspects. It produced much larger, often ~40% larger image files with similar disk imaging time, as compared to Acronis. Even the tiny Drive Snapshot does much better than Macrium in these aspects. All tested on the same hardware. So Macrium definitely need a new compression algorithm.
also true for me. not true for me. mac-ref performs both backup and restore operations faster on my rigs.
The fact that the beta has come a long way in a short period of time doesn't necessarily mean there's still a long way to go.
