According to the experts, it's better to wait a bit to update the rescue media just in case the bootable rescue media might have problems. I always test straight away the bootable rescue media, backup and restore...
Thanks Froggie! I'm still not completely understanding it, but that certainly helps. Are we talking here about, for example, this situation: A person was previously using PE 5 and then decided to use PE 10. Is that the context in which I have to understand it? (BTW I did make that change a few months ago). PS: About why I wrote about my poor English. At first I really was thinking: staging? Something about stage? Shakespeare; Fiddler on the Roof? Stage combined with volume: maybe about the sound level with the Stones back-stage? I cannot help it; those were my first thoughts. Anyways, back to topic.
Staging ... good call on the interpretation. "Staging" in that vernacular means like a pre-setup area, a place to put the pieces together before the final assembly is done... kinda like a SCRATCH area. If you didn't have any build issues when you made the PE5 to PE10 transition, you were not affected by the potential bug. Since the fix, nobody should be.
It might help to see things for yourself, so I'll try that approach. When you have Reflect build Rescue Media, it actually generates all of the Rescue Media files on your system first and then COPIES them onto whatever Rescue Media device you selected -- and then it keeps those Rescue Media files on your system as a cache. By default, those files are stored on your C drive, specifically at C:\boot\macrium\WAxxxFiles\media. The "xxx" part of the WAxxxFiles path will depend on the WinPE/RE version(s) you are using. But as you can see, that folder contains the same files that end up on Rescue Media when you create it. And if you use the Windows Boot Menu option, then that option just adds a boot option to your Windows boot menu that points to those cached files, so when you boot from the Reflect Rescue boot menu option, it's using those cached files. Reflect allows you to tell it to store those Rescue Media cache files on another drive. You can do this in Reflect under Edit Defaults > Advanced > Macrium Reflect PE files. If you choose to start using another drive, then Reflect is supposed to delete the files on the drive you were using up until that point, but apparently that did not always happen. And that issue was apparently fixed.
Seriously. I hope Macrium officially drops support for XP in Reflect V8. Even in Reflect V7, NONE of its major new features work under XP (CBT, MIG, viBoot), so I can't help but think that continuing to expend effort to test releases on XP and debug XP-specific issues is engineering effort that could otherwise be spent on delivering other improvements that would be relevant to people not still using an ancient and now horrifically insecure OS. But Macrium relatively recently posted that they still have a large chunk of customers running Server 2003, which uses the XP kernel, so that might be driving this.
Anyone else seeing the behavior I just discovered and wrote up in this thread? Basically, since updating to 7.2.4859, the scheduled task that runs my backup is showing that it's running successfully even though Reflect isn't actually running a backup. Reflect displays the postponement dialog at the scheduled time, but after that goes away, nothing further happens. This has happened twice in a row. Seems like this could catch people out, especially if they don't regularly check their backups. And if they only have email notifications enabled for failures, those would NOT be sent because the job isn't even starting in the first place -- which incidentally is why I strongly recommend that people enable email notifications for both failures AND successes. While it might be irritating to receive those emails, you simply cannot safely assume that "radio silence" means that everything is operating properly, since it might be that nothing is happening at all. You need positive confirmation of success. (And honestly, if you don't want those emails cluttering up your Inbox, just set up a rule on your mailbox to put them into a folder and check that folder periodically.)
No, I am not seeing this, jp. I do have success and failure messages, and check my overnight backups daily. All my scheduled backups are still working as expected with v7.2.4859, on two laptops.
Well, good to know it may not be a widespread issue. Although that of course begs the question of what's going on in my case. I have a fairly straightforward system, without any background applications that attempt to block activity or otherwise "meddle". Just as a data point, did you restart your systems between updating to 4859 and your first post-update scheduled backup?
I did not need to restart the systems if I recall, which I think is not usually the case? I am pretty sure I also did not restart either (or at least onbne system), for any other reason.
Ok, well hopefully more information will become available somehow. If you have CBT installed, then you'd need to restart for every update that includes an updated CBT driver, and CBT gets updated quite a bit. This particular update didn't have a CBT update (assuming you were running the immediately preceding release), but I don't have CBT installed at all.
I may have misread your earlier post. When you said, “I did not need to restart the systems if I recall, which I think is not usually the case?”, I thought you meant that being prompted to restart after a Reflect update was pretty common. It is if you use CBT, but if you don’t have it installed, then I wouldn’t expect you’d get a lot of restart prompts for Reflect updates. But speaking of restarts, Macrium asked me to restart my laptop to see if that resolved the issue I reported, which it did, although I’m still curious what caused it in the first place.
Thank you Froggie Thank you jp For both of you: apologies for my late reply! I understand it now better. Thanks again to both of you!
Do you guys feel any performance issues if you actually install Macrium Reflect Home with the CBT feature?
If you're asking about CBT imposing a performance penalty, its resource utilization seems to be practically non-existent, even on disk I/O despite the fact that it's tracking changed blocks. See this post from Macrium. My choice not to have CBT installed (except in testing scenarios) is because CBT is a low-level driver that runs persistently in the background, and none of the use cases where it delivers a significant benefit apply to me. That combination meant that when I applied my general principle of keeping my system as simple as possible by avoiding components that are unnecessary for my purposes and/or present an unfavorable risk vs. reward proposition, CBT didn't make the cut. And that has turned out to be a good choice for me, because if you read the V7 release notes, CBT gets updated a lot -- which means you need to restart your system after updating Reflect if you have CBT installed -- and the updates are usually to fix issues like BSoDs, inability to eject disks, etc. And for about a 3-week period, the current production releases of Reflect contained a version of CBT that had a bug that caused EVERY backup that was created using CBT to be corrupt. So from my perspective, keeping CBT off my system hasn't deprived me of any meaningful benefit based on my use case. But it's SAVED me from a bunch of restarts, possibly BSoDs, and corrupted backups. But there are others here who have said that CBT has been a major improvement for them and that they would hate to go back to not having it. The use cases where CBT delivers the largest benefit are a) creating backups very frequently, such as every 30 minutes, and/or b) creating image backups of drives that contain very large files, such as a virtualization host storing virtual disk files for VMs, or a database server with a large databases.
Thanks for the detailed response. In that case then I won't need it because I just make one backup after I've installed Windows/done my tweaks so. Also in the past before CBT, Macrium Reflect was rarely updated. Now the updates are almost weekly it's like a freakin' Antivirus signature and when I read the changelogs as you mentioned it doesn't inspire much confidence after seeing what the new update is fixing.
I got rid of CBT on my computers because I got sick of chasing problems with it. If it wasn't one computer, it was another having issues. In the beginning, Macrium Support would work through the issues and send me links to mrcbt.sys to test. But I got sick of wasting time with something that I don't believe offered me any real benefit. So, I removed it on all computers. No problems now. I bet Macrium Support staff wished they didn't have CBT.
I had thought MR updates, even without CBT, usually required restarts, but I'm sure you are right. I'm glad your issue is sorted though, even though you don't know what caused it. Some interference with a Windows service?
Not once did a Macrium Reflect update want me to reboot unless it was with CBT installed. When the patcher runs it closes any instance of Macrium Reflect, patches it, then relaunches it.
If you don't have CBT or Image Guardian installed, you can do updates without a reboot. I don't use either.
I've had the home edition for about 9 months with CBT, and I have never had a problem...And never had to reboot after an update.
I believe this is correct. Reflect V7 does have some other background applications and a service, but I'm betting those can be restarted without a system restart. Image Guardian initially ran as a service and was then implemented as a driver instead beginning with Reflect 7.2, so it could require restarts after an update. But Image Guardian hasn't been updated nearly as often as CBT (especially recently), and I did choose to install that component because I think that does provide a favorable risk/reward proposition. If Macrium had tried to implement their own comprehensive AV solution, I definitely would NOT have installed that, but instead they built something that was focused solely on protecting files generated by Macrium applications and that took a whitelist approach whereby Macrium applications were trusted (and Robocopy by default, under certain conditions) and everything else was categorically not trusted. That to me seemed a focused and effective approach to adding some additional security to important files without creating an outsize risk of side effects. I realize there are other applications that can do similar things with other files (I think I've seen Pumpernickel mentioned here a few times?), but I don't run those.
