We may never know. Reflect performed flawlessly before I patched it and has been performing properly since I restarted after the patch, so if there was interference, I'd be surprised if it could be limited only to the post-update, pre-restart state of Reflect. What's especially weird to me is that the Reflect application itself did still launch, since it displayed the popup dialog giving me the option to postpone the scheduled backup job. It's just that it didn't actually perform the backup job afterward. My guess is that one of Macrium's own background processes or the Macrium Service didn't start up properly after the patch.
CBT was nothing more than an extension of a more efficient imaging process, which many users welcomed. Yes, they've had some issues along the way, but for me it has been fine. MIG was a stretch for me. I agree it was focused at REFLECT and its various DATA sets for protection purposes... but it's really not an extension to the imaging process. It's more of a ferry into the DATA protection area best suited for AV/AM/AR(ansomeware). Some users looked at it as meeting a competition offered by ACRONIS. The problem with that is that ACRONIS, on its way into the DATA protection area (and Cloud Services, etc.) became one of the most bloated, complicated and encumbered imaging solutions offered on the market. Folks like me, when they saw MIG, started shaking in their boots that Macrium was trying a offer similar features to their competition. The main issue is that Macrium as well as ACRONIS are imaging specialists... they are not anti-ransomware, file protection specialists. It seems to me that any foray by either of those companies would start taking away from their imaging specialties... and ACRONIS has proved that. The last really efficient imaging application put out by ACRONIS was v9.1 ECHO. Since then it has all been basically downhill as far as the product is concerned. I guess we just worried that the same thing might be happening to Macrium... I'd hate to see that. Personally I have loved CBT since the BETA at the end of v6... flawless (I'm one of those intra-hourly imaging requirements that would love CBT). Under v7 it has had some issues throughout its development. I guess I want Macrium to remain an IMAGING specialist, and see constant improvements to that specialty (a Macrium produced flexible scheduling System <Windows scheduling is just too flakey> that allows for intra-hourly incremental scheduling <for disaster recovery purposes> as well as scheduled consolidation features that allow the System admin to recover all those myriad of intra-hourly Incrementals maybe by shift or daily or whatever). Maybe a more robust consolidation mechanism that allows for a more efficient Incrementals Forever/general consolidation mode... when those operations are done, they are the components that take the most time. Anyway, that's where I'd like to see their effort in the future... not in the area of anti-anything. Experts exist in those other areas whereby if a user wants to engage in that type of protection, they should choose the appropriate product from the appropriate expert. I WANT GOOD IMAGING (and scheduling)
^ I also normally prefer choosing the best tool for each job because my experience is that typically, a tool that tries to do everything tends not to do anything particularly well. And I certainly agree that CBT is more "in-scope" for Reflect's core purpose than Image Guardian. However, it is also true that ransomware is a significant and growing threat in today's Internet landscape, and for many users, their Reflect backups are particularly valuable among their files because all of that user's eggs might be stored in that Reflect backup file basket. In addition, I suspect relatively few Reflect users even know that these types of "file-level whitelist-based protection" utilities exist, and even fewer would simply imagine that concept and go off looking for one. I didn't know such solutions existed other than the Controlled Folder Access component of Windows Defender, but that is more broadly focused and therefore inherently less secure and more likely to interfere with legitimate activity. But the fact that similar applications already merely EXISTED in the world before Image Guardian isn't enough. If users don't KNOW about them, then they're not benefiting from the existence of such applications. So in my mind, Image Guardian is a net value add for Reflect customers, since it means many of them now have better protection than they had before or ever would have had otherwise, against a very real threat in today's world, for files that for many of those users will be absolutely critical. And the users who already had such protection from another application and/or feel safe going without such protection entirely can of course choose not to install MIG. The question of whether developing and supporting Image Guardian represents the BEST use of Macrium's finite engineering resources is of course much more debatable, and responses will undoubtedly vary based on customers who would personally like to see Macrium develop one feature or another to benefit their own use case. I have my own laundry list of features I'd like to see here, some that I suggested and others that I aggregated from ideas first suggested by others throughout the Macrium forum. But Macrium has said they've already heard from several customers who experienced a ransomware outbreak and whose backups were saved by Image Guardian. I personally think Image Guardian is "justifiable" on the merits of the value that it will add to the average user relative to what they had before, and I don't think this particular feature should be cause for alarm that Macrium is now on an inexorable path toward bloat. But of course time will tell. We'll see what Reflect V8 brings.
I have a question about one of the partitions. I've just upgraded my OS to the new Win 10 - 2004 and when I performed the first backup, the first partition on the table (1-NTFS Primary 490.9 MB/529.0 MB) has got a red bar instead of blue. I guess it means that the partition is almost full. Should I be concerned about it?
Osaban, That is the Recovery partition. Microsoft will create a new partition for you if the current one looks like filling up. Don't be concerned.
Expanding on Brian's correct answer above, there's a decent chance that the next Windows feature release you install will need a larger Recovery partition. At that point, during the upgrade, Windows will shrink your C partition by the amount needed to create a new, larger Recovery partition in that freed up space. And then it will start using that instead. From that point on, if that NEW partition ever needs to be expanded later, Windows will just keep shrinking your C partition as needed in order to allow a larger Recovery partition after it. Once you have a new Recovery partition after C, the Recovery partition that you have now at the beginning of your disk will become dead weight, taking up space that isn't being used for anything anymore but that also can't easily be repurposed elsewhere due to its location on the disk. Note that whenever that new Recovery partition is created, and any time it gets expanded afterward, Reflect will need to create a new Full backup. And if you're using the default "matching backups" setting for your retention policy, then the retention policy will ignore backups that were made prior to that partition change. More info on that here. I avoid that issue by setting my retention policy to match on ALL backups in the destination, but to do that safely you have to have a folder dedicated to backups from that specific job, otherwise you risk unintended deletions. The fact that larger Recovery partitions are needed by newer Windows 10 releases and newer releases are supposed to arrive every 6 months these days is why Microsoft's new recommended practice is to create the Recovery partition after the C partition in the first place. The original practice of putting it at the beginning of the disk was fine when an OS upgrade might happen once or never, but it doesn't scale for today. The DOWNSIDE to placing it after the C partition is that if you clone to a new larger disk, you won't be able to just extend the C partition to fill the unallocated space, because that Recovery partition will be sitting between the C partition and that empty space. That isn't an issue when the Recovery partition is at the beginning of the disk. So now you have to either "stage" the C partition expansion as part of the clone job rather than expanding afterward, or you have to jump through a few extra hoops to perform the expansion afterward.
I wonder why MS doesn't create larger recovery partition (let's say 2 or 4 GB in size) that will be probably large enough for later feature updates so this creation of new partitions doesn't happen. Crating new partition after each major update, that is for a few MB larger than previous just isn't logical. At the end there is more "wasted" space doing it that way instead of creating one larger at the beginning.
If you start with a Recovery partition at the beginning, then yes you have more wasted space overall because that space is never repurposed. But as to why they don't create more upfront, shrinking the C drive as needed going forward in order to expand the Recovery partition after it doesn't waste more space than creating a big one upfront. And if Microsoft did that, then people would complain that Microsoft is "needlessly" claiming hard drive space that they'd rather have for something else. They won't understand that more of that capacity might get used later on. And remember, some Windows 10 systems are running on 32GB eMMC devices. I personally use Microsoft's reference guide to use Command Prompt within Windows Setup to set up my partition layout and perform the entire Windows installation. In that case, you can do whatever you want and you never even have to go through Windows Setup itself.
Osaban, The scenario described by jphughan will almost certainly happen when you do your next Windows Upgrade. Your C: drive will be resized smaller and you will have a second RE partition. You don't have to do anything; everything will still work properly. But if you are obsessional and would like to get rid of the old, non-funtional RE partition... delete the old RE partition slide the ESP to the left to remove free space slide the MSR to the left to remove free space slide the Win10 partition to the left to remove free space resize the Win10 partition if desired slide the new RE partition if necessary
Just wishing to clarify something regarding the Recovery Partition. I just checked my xml backup file and in my GFS chain only the Win10 partition is backed up. Looking at the standard options with either Image selected disks on this computer or Create an image of the partition (s) required to backup and restore windows I always choose the second option. I assumed that this would provide everything I need in case of an emergency. Given that this does not include the Recovery Partition, what would be the consequences?
@jphughan, thank you for the detailed explanation of the recovery partition @Brian K, it’s good to know it can be done, but given my limited knowledge, I would rather let MS make the necessary changes in the future, thanks.
The Recovery partition that's actually in use should be included, and it is on all of my systems when I click that "Create an image of the partitions necessary to back up and restore Windows" option. The active Recovery partition has a special identifier (it's different for MBR vs. GPT disks). Can you post a screenshot of the first step of the Reflect wizard after you click that option to show your disk layout and what's selected by default? The Recovery partition isn't essential to booting unless you're using BitLocker AND the BitLocker unlocking binaries are on that partition -- but sometimes they end up on the System partition. On UEFI systems, the System partition would be the EFI/ESP partition, which is a required partition anyway, so on those systems those binaries are sometimes there. Legacy BIOS systems technically can have a System partition too, and Microsoft's latest guidance is for such systems to have one, but since that wasn't done in the past, many current BIOS systems don't have them. In that case, the BitLocker unlock binaries would be on the Recovery partition and therefore that partition would be boot-critical. But otherwise, if you're a frequent Reflect user, you may never need to use the tools on the Recovery partition anyway, and Windows 10 feature releases will create a Recovery partition if one doesn't exist anyway, whether you want one or not.
On my Windows installation media, I create an additional folder containing two files: a diskpart script file and an installation batch file. I've got examples of both below. In Windows Setup, you can access Command Prompt by pressing Shift+F10. From there, I run Notepad and edit those two files as needed before actually using them. Usually I have to at least change a drive letter in the installation batch file based on the drive letter my Windows installation media was assigned. You can determine that by just running "dir" commands on different drive letters in Command Prompt or checking diskpart. Below is an example diskpart script, which is called by the installation batch file. This example creates an appropriate partition layout for UEFI systems. It assumes the install target is Disk 0 and creates the largest possible Windows partition minus 750 MB for a Recovery partition afterward. If you want to create additional Data partitions, you can customize it as needed to achieve that, although Data partitions should be placed after the Recovery partition. It also assigns temporary drive letters that will be used by the installation batch file. The script deliberately does NOT assign "C" to the Windows partition because that might have already been assigned to some other partition/device in Windows Setup. Spoiler: Diskpart-UEFI.txt Code: rem Based on guidance here: https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions select disk 0 clean convert gpt create partition efi size=100 rem ** NOTE: For Advanced Format 4Kn drives, rem change this value to size = 260 ** format quick fs=fat32 label="System" assign letter="S" create partition msr size=128 create partition primary rem == b. Create space for the recovery tools === shrink minimum=750 format quick fs=ntfs label="Windows" assign letter="W" create partition primary format quick fs=ntfs label="Recovery" assign letter="R" set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac" gpt attributes=0x8000000000000001 list volume exit After that's been customized as needed, the commands below are in a batch file so that you can run "InstallWindows.bat" to run the diskpart script above and install Windows. You have to customize the DISM line to set the correct path to the installation WIM file based on the drive letter assigned to your installation media and whether your install media uses install.wim or install.esd. You also have to specify the correct index based on the contents of that WIM/ESD file and the edition of Windows you want to install. To check that, from Command Prompt run "dism /get-wiminfo /wimfile:E:\sources\install.wim", substituting the drive letter assigned to your install media where I had "E", and using install.esd if appropriate. Find the index number of the Windows version you want to install, then use Notepad to edit the batch file before running it. The first line of this batch file sets Windows Setup to the "High Performance" power profile, which is optional but sometimes makes things go faster. Spoiler: InstallWindows.bat Code: powercfg /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c diskpart /s Diskpart-UEFI.txt dism /Apply-Image /ImageFile:E:\sources\install.wim /Index:1 /ApplyDir:W:\ W:\Windows\System32\bcdboot W:\Windows /s S: md R:\Recovery\WindowsRE copy W:\Windows\System32\Recovery\winre.wim R:\Recovery\WindowsRE\winre.wim W:\Windows\System32\reagentc /setreimage /path R:\Recovery\WindowsRE /target W:\Windows After that you just reboot.
Very strange, although it looks like you've got more going on with your disk than typical. If you partitioned your disk manually, maybe the Recovery partition isn't tagged properly? On an MBR disk, the Windows Recovery partition is supposed to have Type ID 27. Try opening Command Prompt and running the following: Code: diskpart select disk 0 select partition 1 detail partition What's the Type ID? If it's not 27, enter "set id=27". Then enter "detail partition" again to confirm it updated. Then close and relaunch Reflect and see if that changes the behavior of the "Create a backup of Windows partitions" option. If that doesn't work, I'm not sure what's going on there, but I would recommend adding the Recovery partition to your definition file simply because there isn't a meaningful downside given how small it is.
JP, it does show up as Type 27, Hidden: No, Active: No, Offset in bytes: 1048576 Volume 5 Label Recovery FS NTFS Healthy
Ok, last idea. Open an elevated Command Prompt and enter "reagentc /info". Windows RE status should show as Enabled and the Windows RE location in your case should show "\\?\GLOBALROOT\device\harddisk0\partition1\Recovery\WindowsRE". If even that looks ok, then I don't know why Reflect isn't auto-selecting that partition, but I admittedly don't know the exact criteria that Macrium coded for that.
Well that's probably the issue then. Partition 2 appears to be your Windows partition, so I'm not sure why it's identified as the Recovery partition. What's the exact path shown? When Windows is first installed onto a hard drive by unpacking the contents of the WIM file, the WinRE WIM is located at \Windows\System32\Recovery\winre.wim. Windows Setup is supposed to move that WIM file to the Recovery partition, specifically to \Recovery\WindowsRE on that partition. If a Recovery partition doesn't exist, then the WIM stays on the C partition at the former location, but in that case reagentc would show WinRE as Disabled. I'm not sure how you can have WinRE showing as Enabled while the specified path is some location on your Windows partition.
beethoven and JP, The RE partition could actually be partition 2. BIBM can do that with the partition table. beethoven, can you look at the Partition slots in MBR Details. Please let us know the order of the partitions? Open an Admin Command Prompt diskpart select disk 0 list par What are the partition numbers for the RE and first Win10 partitions?
