Macrium Reflect

Scott, there is no "track." Once Reflect has made up its mind on what to backup, it uses the exact same type of I/O for all its imaging... Full, Diff or Inc. As mentioned in my post, they have added some logic to v7 to pick the fastest I/O method to use with each device it writes to initially.

I'm not sure what times you are measuring, but DEFAULTs have Reflect doing a mini-Chkdsk process which I'm sure both IFW and DS do not do. I'm sure that adds some time to the process. Their compression algorithms are most likely much different than IFW (who's worked on different methods for years) and most likely different than than DS as well.

I do not hold imaging time against any imaging program, especially if it gives me excellent results... IFW and Reflect both have done that for me (never used DS for very long). If the difference was major (comparing apples to apples) I would suspect it would be noticed and really make a difference in product selection by users... I haven't seen this happening.

What should really be "fast tracked" by any imaging solution is reliability, and both Reflect and IFW have done that as far as imaging and restoration are concerned. Of recent, IFW has entered the DELTA IMAGING arena previously held almost exclusively by Macrium since v6. It's exciting to see products take quantum leaps like that... that's the major thing that got me on-board originally with Reflect v6 (after having been an IFW user for many years).

 

Yes, that's also my experience. The difference is bigger with Image for Linux, which is faster than IFW.

 

I don't think I'll ever fully understand and appreciate the prevalent obsession with speed for a backup program that, unlike ISP HTTP/FTP transfer speeds, curtails no other ongoing observations or activities during the process. Backups can run in the background with whatever relative priority level the user chooses to assign and/or they can be scheduled to run during idle times. Is it because people actually think that they must just sit and watch doing nothing else throughout backup operation run-times to completion? (Some I know used to do that with disk defrags.) Backup "speedometers" (at least any I've seen including Macrium's) are highly questionable indicators of true performance anyhow.

 

It seems evident that the more frequent one backs-up the more important backup speed becomes. Of course, that should never come about by compromising reliability (and in that regard it's been my experience that DS, IFW/IFL, and MR are equally reliable)!

 

I don't see why unless you want to set the time interval between backups to less than the time required for each one.

 

I suspect that was exactly the point. Some folks do it frequently, though I am not one of them.

 

Verifications of DIFFs and INCs are a very quick process, FULL verifications can be extensive... but why anyone would want to do successive FULLS in that amount of time I don't understand.

Heck even Rollback RX snapshots (providing no System disaster protection) are Incremental in nature... fast successive FULLs just don't seem to make sense to me at all for quick System imaging snapshots.

 

@Peter2150 -- To avoid any possible misunderstanding, my own comment was not in any way intended to disparage any user (typical or atypical) who is satisfied with a backup program that is sufficiently "speedy" to accomplish, as in your case, what that user actually wants and needs to accomplish. I was just agreeing with Froggie about the suggestion that Macrium should "fast track" the speediness of its full backup operations in particular. To me, "fast tracking" suggests assigning a higher priority to that speed issue than to other considerations (not specified), and it is that kind of "shopping list" prioritization that I would regard as inappropriate.

How much speed would ever be enough for those who regard it as a high backup software priority? Would even hourly backups be regarded as sufficient? How about every thirty minutes, and why not full backups of the entire system each time, or even the backup software equivalent of full redundancy hardware RAID? If it's a question of Macrium "fast track" priorities, I think Froggie's unfulfilled suggestion about continuous incrementals would make much greater sense to me. But that's nothing more than my own opinion, of course. Certainly not intended to discourage anyone else who may prefer to shop for backup software on the basis of its "fast tracking" of full backup speed.

 

Many of us have different backup plans based on our beliefs, concerns and other variables. I happen to prefer creating full backups weekly followed by twice daily differentials because it's my belief that the larger an incremental chain becomes the greater the risk of an unsuccessful restore. No argument, reliability does trump speed, but I still prefer faster backups so that my CPU spends less time backing up and more time running my productivity apps and databases.

 

If concern about possible interference with other active applications is the main issue, you probably want the backup application to run with the lowest priority option available set relative to others. But if you do configure it that way, or have done so already, it's certainly not going to produce the fastest possible run-time results for your backup operations. There's almost always some trade-offs involved. At least Reflect currently, unlike some others, allows each individual user to make that choice for each defined backup task.

 

I understand all of that and I do value Macrium - after all I do use it (along with DS & IFW). I'm just wondering why it's so much slower (creating full backups) than DS and IFW (not to mention Acronis, which leaves them all 'in its dust').

 

@Scott W -- Dunno for sure, but Acronis (among others) has always installed its own proprietary kernel mode drivers used as upper and lower device class filters for both the {4d36e967-e325-11ce-bfc1-08002be10318} disk device class and the {71a27cdd-812a-11d0-bec7-08002be2092f} volume device class.

They did that even before Microsoft introduced its VSS service for "snapshot" captures. I suppose that might have some advantageous impact on overall performance as, unlike services provided by Macrium's new single "Changed Block Tracker" filter driver, application of the Acronis services doesn't appear to be restricted to some multiple incrementals and differentials only.

That's nothing more than a guess however, and certainly not an endorsement of those Acronis modifications to the operating system -- or anyone else's for that matter.

 

Speaking of interference, what about say that the imaging occurs when some major change is in progress on your system? For example, a virtual disk snapshots merge.

Sure you can cancel either task or make a new image, but would there be corruption if you restore that?

 

There is no way for an application making a major change in some System/file structure to allow itself to be made consistent in its operation unless it has declared itself as a VSS WRITER when it starts up... that's application dependent, AND it only applies to a VSS System Lock operation... no other lock type operation (ie PhyLock used in IFW). Many non-declared applications will have incomplete DATA structures when a VSS System Lock is granted to a VSS requester (Macrium Reflect).

The VSS System Lock is designed to allow those types of applications to continue their process while the FileSystem is locked and a snapshot is created to allow imaging operations (and others) to do their thing. That particular image will have an incomplete DATA structure for any active non-declared application but will have a complete structure available at the next imaging time. The interaction of the two processes should not interfere with each others task but will produce an incomplete DATA structure in the snapshot requested.

There's no other way to do this other than LOCK the entire Volume (all active operations complete and Volume, basically, shut down) you want to image... this cannot be done on a LIVE OS Volume. As a result, VSS was developed to do this in the cleanest way possible.

 

There would be no corruption in the backup image nor in its restoration unless corruption already existed in the VSS system "snapshot" that was created at the moment in time when that backup operation was initiated. However, any changes made at any time subsequent to that initial VSS "snapshot" capture would not be included in the backup image. If you want to avoid the issue completely, backup operations can be run while booted to the WinPE environment where no such reliance on VSS "snapshots" is involved at all.

__
P.S.: Just in case there may be some confusion about it, I should add that VSS "snapshot" capture and usage is unrelated to the setting of Reflect's relative operational priority that was mentioned in the comment to which you replied.

 

Would a Macrium verify catch this type of corruption?

 

The Reflect VERIFY option does nothing more than, basically, CheckSum the image DATA file being written, then goes back and re-reads that DATA file re-calculating its CheckSum, then comparing that re-calculation to the original one written. If the image DATA was affected by DATA path inconsistencies (in either direction) or by retrieving bad DATA from a faulty disk, the VERIFY operation would detect that type of problem.

If the DATA in the VSS snapshot was not consistent, VERIFY will not detect that anomaly.

 

No because, as far as Macrium Reflect is concerned, it has faithfully reproduced in its backup image exactly what it was given to reproduce by the system "snapshot" created by Windows VSS at that moment in time. Reflect itself has no way to know or discover whether or not that "snapshot" includes any pre-existing system corruption. It can only verify that it has done its own job of exact reproduction correctly.

 

Ok so I have a question. I installed the latest Windows insider version and it messed up Virtual Box and so I restored an image of Windows version 226.
I had installed Ublock Origin on the latest version and to get VB working again I restored my 226 version, where I never had Ublock Origin installed but after Reverting back to 226 I found out I still had Ublock Origin installed for Edge. My question is how is this possible when I did not have it installed in 226?
This makes me think MR doesn't make an exact image.

 

MR has no independent decision making powers of its own and is generally quite obedient to user instructions. Where (on what partition) is Ublock Origin installed and was that partition included in the backup/restore operation?

 

I'm still with v6 and now don't know whether I'll ever end up using v7.

The product seems to be getting more invasive (CBT immediately comes to mind) (and otherwise worrisome) with no justifying benefits, for me at least. Maybe time to start considering an alternative product.

Terabyte's Image for Windows seems to enjoy an excellent reputation among those here whose opinions I value. I'd be interested if anyone could tell me how IFW might be inferior or superior to Reflect, without taking up too much of people's time.

 

AlphaOne, why would you consider an alternate product at this stage? CBT is an OPTION and can be turned off. If that's the main offense, it's handled in the product. What might you be looking for in a new imager?

IFW has just implementeded FileSystem metadata in an optional use with its Differentials and Incrementals... Reflect has done it for a few years. Does one product do it better than another... time will tell. IFW will require a much bigger learning curve than Reflect... it's just not as "easy" to use for "standard" users as Reflect is... but they can both do the same thing now. Sounds like v6 is handling your needs very well. Is there something that "excites" you as far as a "next step" for either of those imagers

 

I've been forming my opinion from casually following this forum, and once in a while looking at the Macrium forum. In regards to CBT, I read there:

"You may think that you're "staying away from CBT", but unless you uninstall it using MrCbtTools.exe as I mentioned above, it's installed, loaded and active as a Windows device class filter service by default. As the MrCbtTools utility will clearly show, that filter service remains in place regardless of whether Reflect advanced defaults are set to actually make use of it or not."

Doubts are being raised in my mind, but was interested in the more experienced views of others like yourself.

There's really nothing else I want that's not in v6, but v6 is going to be unsupported next year and I'm looking ahead. (With the current chaos at Macrium, I'm not even confident that they won't break v6 in some update.)