Macrium Reflect - why it so slow?

I bought Macrium Reflect based on the super fast imaging speed everyone claims, but it is slower than molasses. Why does it take over 30 minutes to create an incremental image of a disk on which there are have been no changes on the disk? No files moved around, no defrag, nothing, yet it grinds away for over 30 minutes only to produce a tiny little incremental image of only 100 or so MB. It looks like it's reading every single used block on the source disk for the entire time and then burps out a miniscule file for a few seconds at the end. I thought it was supposed to use Windows volume shadowing feature? I like its image management and scheduling features, but the performance is killing me.

 

No idea. I use Macrium Reflect Free and I can image my Win 7 setup in about 8 minutes, and restore in about 6 minutes. And that's on a slow drive... Must be something else going on there....

 

Macrium is anything but slow. Maybe you have an application conflict. You may also want to try the last v4. Several people had some issues with v5.

 

I don't think V4 is compatible with Windows 8 x64. Here's something else I found. The first incremental is extremely slow after a reboot, over 30 minutes to complete to produce a 100 MB change file. After that it takes seconds to produce the same size file. Something is being reset when I reboot my system. As long as I don't reboot between backups Reflect works as advertised.

 

I could imagine that the reflect service isnt shut down porperly when you turn off your system. I know something similar when i used Shadowprotect. Every time i had a BSOD, the incremental after the reboot took the same time as a new image. Wich means that the monitor service wasnt shut down properly and needed to reindex all changes again to make an incremental. Ofc its not the fault of Shadowprotect.
Maybe something similar is happening in your system with Macrium because they use a monitoring service too.

 

I know what you mean. Norton Ghost used to take hours reconciling the next image if my system crashed. However, there doesn't seem to be any Macrium Reflect Service that I can stop.

 

There must be some conflict somewhere.

Check to see if your VSS service is working properly and it is configured to start automatically with windows.

Also, did you install Acronis or Shadowprotect on this same system before installing Macrium? Acronis and Shadowprotect sometime conflict with other imaging softwares if they are not properly and completely uninstalled.

Other than that, the only thing I can think of is that since windows 8 is fairly new, so there may well be a bug in macrium specific to windows 8.

Shadowprotect has processes running in the background that track changes in your hard drive in real time, a hard reboot interrupts them and this is why the next incremental takes very long. Macrium does not have any processes running in real time, so a hard reboot does not effect its incrementals.

 

Macrium has ReflectService.exe always running even the Free version has it. Just check it with Process Monitor. Also if you do stuff with your pc ReflectService.exe is also working nonstop. Obviously its monitoring changes.

 

Reflectservice.exe is just a image mounting service, if you do not use or mount backup images regularly, you can set it to start manually instead of automatically. It will stop starting with windows. I have no process from macrium running on my pc and when I do need to mount an image, I just double click on the image file, Reflectservice.exe is started and the image is mounted as a drive.

 

Ok ty.
How does Macrium check changes for its incrementals wihtout a runing service for this?
Or do the incrementals take the same time like a full new Image because no service is runing for this?
Cheers.

 

I do not exactly know how macrium looks for changes, this information is proprietary. However, if you double click the task bar icon when the incremental is running, the program first spends some time looking for changes and then it backs up the changed sectors. The whole process for me takes 2-3 minutes to complete and this is on my C: system drive. On a data drive where the information does not change, the incremental should be even faster.

 

I took a look at Macrium incremental algorithm and it looks like it's parsing NTFS Master File Table, and getting the list of all changed files from there.
Then it sums up all clusters of all changed files and creating the incremental image. Such approach doesn't require any "monitoring" service.
Regarding the time that such "analysis" phase takes - it depends only on the number of files on the volume.

 

I don't know if this info will help or not, but I upgraded to Win8 (64bit) just over a week ago and haven't noticed anything out of the ordinary with reflect. (I'm using professional edition 5.1.5529.) I took a full image directly after upgrading, but my single weekly incremental was run automatically so I don't really have a "feel" for how fast/slow it was, if that makes any sense.

Per my logs I back up about 300GB over three volumes. I don't think the logs include verification time (?), and all my image files are verified at the time the image is produced. That said, the full backup took 57:11. The incremental image backup ran 2-3 hours later. Though I can't remember for sure, my guess is that I probably rebooted several times in between; I was installing a lot of software that day on my fresh Win8 install.

The incremental took 5:29.

 

Very normal time i would say.
If you dont install much things and dont defrag then incrementals will be a lot faster.

 

Do you know if its safe to disable this service? I never mount my images.

 

Just put it to manual, it will never start unless you manually mount an image. You may disable it too, but why disable when you get the same result by putting it in the manual mode.

 

After much investigation I have found out why Macrium's incrementals are so slow after a reboot.

My system is a member of a Windows HomeGroup and I share my Music, Pictures, and Videos library in it. I have thousands of files in my libraries with a size approaching 750Gb on 2 local disks.

Whenever my system is rebooted, the metadata is updated for every single one of these files. No dates, times, or file contents changes, just other metadata used for indexing. Due to the nature of the way Macrium detects changes in files, it sees the MFT log record for these files has changed and has to scan every one of them to see if any file data has changed, causing backup times to go from 1 minute to over 30 minutes.

This is not specific to my system; Macrium has verified that this will happen to any system that is a member of a HomeGroup.

Since I never used the HomeGroup for much and can live without it, I have dismantled my HomeGroup and now my incremental backups are back to normal.

 

SloPoke,

That's interesting. Does it still happen if the libraries have been moved off the C:\ drive?

 

Yes, my libraries are not on my C drive since they are so large; they are on 2 1TB drives.

 

Thanks. I'm going to leave the HomeGroup for a week and see what happens to my differential image sizes.

 

I don't think the sizes will change much. While Macrium did scan for changes in the data because of the metadata update, nothing had actually changed, so no file data was backed up. However, the the size if image file was slightly large because Macrium backed up the MFT and metadata, but only by a few Mb.

 

I'll let you know what happens.

I like HomeGroups because I use our computers as Media Servers. We can watch video files on our TV over the wireless network.

 

This is quite interesting. Does this happen only with Macrium or will this be a problem with all imaging software? And why does the metadata of your library indexes change every time you reboot?

 

For me a cloning software bogged down to the point of looking like it was going to take 10 hours or longer to finish. I defragmented the hard drive and then it took under 40 minutes. That other software claimed the space between the data was bad sectors, but no such "bad sectors" were reported after defragmenting the drive and none were detected by Check Disk.