Read this thread. I have successfully used Macrium's fixbcd tool in the past. http://support.macrium.com/topic.asp?TOPIC_ID=5862
Thanks mate, but that did not solve my problem. fixbcd.exe says upon running: The store import operation has failed. The system can not find the path specified. Failed it is looking for something at C:\boot\bcd and that directory does not exist on my computer. I think that UEFI system may be the culprit here? I think I will just head over to their Forum,since I'm a paying customer. Or just create a ticket for support.. Incase someone has a working solution, please post it here for others. I will let you folks know, if Macrium Support can fix my situation..
My guess... you have some strange hybrid UEFI system configuration, but that's only a guess. You mentioned that your Windows partition does not contain /boot/bcd files which means it's configured to have them elsewhere which is what UEFI does... where (EFI or Windows SRP?), I'm not sure When loaded, the PE identifies itself on the top of its UI window. Also, the W10 PE uses a crappy italic text interface which the others do not. You're probably best to handle this question over on the Macrium Forum as you have stated. I know Macrium LOCAL BOOT setting works just fine on both "standard" UEFI configs as well as Legacy-MBR configs which have different locations for the /boot/bcd files... yours seems to be different for some reason (they do exist... HP has produced them in the past. It's amazing what some OEMs can do to screw up "accepted" system configurations).
LOL... Sorry, couldn't resist an OT chuckle. I think you and I are on the same page regarding that font!
The /boot/bcd files, apparently, are always located on the BOOT partition. With typical UEFI configs, this will be the EFI System (Fat32) partition. With Legacy-MBR Systems that were built with a MicroSloth SYSTEM RESERVED PARTITION (SRP) in place, I believe this would be the SRP. With Legacy-MBR Systems built without a SRP, they will be located on the Windows C:\ partition being BOOTed from. For BOOT partitions to be managed correctly by outside apps other than BCDedit (EasyBCD, Macrium, etc.), I think they need to be non-HIDDEN (EasyBCD requires this) and make sure that you have the viewing of both hidden and operating system files enabled on your system. That's about all I can come up with... wish I could help more
I went for a clean install of Windows 10 and my problems with Macrium were solved. (My OS was messed up anyways,so I felt like it was a time to do a clean install, and immediately a new snapshot chain with Macrium..) Anyways, the support answered me: (If you get "Unable to Import Store" when trying to add the recovery environment on pre-os boot,this should be the solution..) The rest of the advice left out,due to it being for ONLY paying customers. (eg. you can't do what they ask you to do in the program,if you're a FREE version user... and prior to that, you have to create a ticket for the support, also available ONLY to paying customers..) ;P
I'm doing incremental backups with a synthetic full, like in this video. I noticed than when the full merged with the oldest incremental, the size of the resulting synthetic full increased by almost the exact size of the incremental ... as if it just concatenated them. Does the size of the synthetic full always keep increasing by the size of the incremental it merges with? If yes then it will eventually run out of space regardless of how big the backup drive is. My concern is size more than time. The video says "Minimizes amount of storage needed for backups." which would directly contradict the ever increasing size of the synthetic full. I was under the impression that a synthetic full actually deletes "internal" copies of files that exist in the incremental it merges with in order to keep the space usage of the backups under control ... that would imply zeroing out space in the full, filling it with files from the incremental, which I know is not trivial to do since files inside have various sizes at various offsets, but I thought Macrium actually pulled it off. Did they?
I don't use BitLocker but there is some info here in the Macriumknowledgebase http://knowledgebase.macrium.com/display/KNOW/Adding BitLocker support to Windows PE
I'm replying to my own post to say that after doing 2 more incremental backups and merging the oldest 2 incrementals with the full into a synthetic full, I've seen the size of the full staying exactly the same for the first incremental merge, and then decreasing a little after the second incremental merge. So it looks it can also shrink the synthetic full. Great stuff. Merging is quite slow though (I didn't want to enable delta indexes).
Hello, A new update has been released, version 6.1.1023: Download Page: http://www.macrium.com/Download.aspx?type=home Release Notes: http://updates.macrium.com/reflect/v6/v6.1.1023/details6.1.1023.htm
Q: when I exit Macrium....the power lite on my ext goes out. Does power lite off indicate safe to remove. The safe-to-remove Icon is still in sys tray. When I click the safe to remove Icon the power lite comes on and I click through safe remove to power lite off. So, power lite is off and I'm turning external pwr lite on for safe-to-remove sequence. Does pwr lite off on Macrium exit indicate safe-to-remove even with safe-to-remove Icon still in sys tray...? Thanks
Does MR have a preference for boot flash drive file type? I rebuild it after MR updates and never get any errors or "reprimands" whether I format ntfs or fat 32? Thank you!
i generally just recreate rescue media from the 'other tasks ' menu, target is my 64gb usb3 flash drive. after that i use the 'add recovery boot menu' with the win10 pe menu option, it seems to overwrite any exiting w/o needing to remove the previous (not sure this is even necessary as the wim itself is modified, but i do it justincase). checking after a reboot by selecting the macrium boot option shows the new version number as it boots into the win10 pe.
An UEFI BOOTing system requires an EFI partition (doing most of what the MBR used to do in a Legacy-MBR system) and I think, according to spec, that the EFI partition must be FAT32 formatted. More knowledgeable users, feel free to correct that statement if I've erred along the way...
Some earlier UEFI secure boot requires the external USB boot device to be formatted in FAT32. If the USB boot device is in NTFS format, it won't boot correctly with UEFI secure boot. Of course I stand corrected. "8. Format FS=fat32 quick (Formats the partition with the FAT32 file system. FAT32 is needed instead of NTFS so that it can load under the secure boot UEFI BIOS.) " http://mythoughtsonit.com/2014/05/installing-windows-8-1-from-usb-to-a-uefi-secure-boot-machine/
Apparently my destination backup drive (which is mainly being used for storing backups, nothing else) has 100% fragmentation... Is this normal? Considering it's an SSD I'm assuming it isn't an issue but what if it was a normal mechanical drive? Or is it perhaps because it's an SSD that there is 100% fragmentation?
The EFI partition must be formatted with FAT32. The same applies to boot UFDs created to be compatible with UEFI. I think this is independent of Secure Boot.
I don't think so. You can NOT use GPT partition scheme on boot UFD, if you plan to use the boot UFD to boot both UEFI/Secure boot and legacy BIOS computers. For the BOOT UFD, you better off use MBR scheme in FAT 32 file system in order to achieve the best compatibility.
It's normal. Any drive used for backups will tend to get increasingly fragmented, and the file system elements used in allocation will, over time, contribute to chopping up space on the drive, as well. There is little downside to this, but the resulting clutter does seem to be a degradation of sorts. My way of dealing with this is to stage large image backups to multiple drives. I have drives where just one or two most recent generations of backups reside. These files get copied to other drives for longer-term retention. Space permitting, copied files are allocated to contiguous sectors, so this longer-term storage does not develop fragmentation and the file system structures remain uncluttered.
I just tried deleting all backups and analyzing the empty drive, 0% fragmentation, of course. I then made a new full backup and instantly 100% fragmentation. I accept that the fragmentation probably isn't (at least significantly) harmful for performance considering it's an SSD but at the same time I kinda just want to know why there's 100% fragmentation.. Just curious is all.
Fragmentation is not a performance issue on SSD's and there is a limit to how many times each block can be written. So the file system allocates blocks on a SSD using a completely different strategy that on a rotating device. It will purposely fragment files in order to level out block usage.