G'day Brian. Does that mean I'll get a spare 450MB Recovery partition, just like if I "upgrade" Win10 over installed Win10?
Krusty13, Maybe. We've experienced spare Recovery partitions with Win8 so determine which is the "inactive" one and delete it. That's my plan.
Brain, bear with me here please what if I do not want any updates/ upgrades, what then? Let's deal with some scenarios here. Say the backup I have stored on FAT32 7-year-old WD XHD works. What if it doesn't? I have used the MediaCreationTool and stored the suggested by the programme version of W10 on my primary 32GB flashdrive, which I am gonna need sooner or later, so I reckon I'd need another stick to store it on, say, 8GB - does it have to be USB 3.0 and fast?
Unfortunately Macrium can't image/restore a USB flash drive. I assume you have an ISO made from the MediaCreationTool. Use that to create a Win10 UFD whenever it is needed. You only need an 8 GB UFD, USB 2 or 3.
from what i see so far if you "upgrade" to the next version it does create the added partition. it can always easily be removed later with diskpart though, its very simple to do.
You know what, funny thing, haha, there was a DVD with W10 in the box, apparently. My bad. Yet,... so what. I still should have a partition with Recovery. Do you think I should use Aomei Backupper Standard 3.2 to I don't really know...see if it works? I'm leaning towards your scenario though. If the cable plug doesn't ideally fit the USB port it may malfunction. Otherwise, the imaging on WD wouldn't have been successful, right?
korben, If your Macrium image Validates then you are almost certainly OK for a restore, if it is ever needed.
It did validate + I couldn't resist and installed also Aomei Backupper Standard 3.2. And you know what? The image is done without any issues, validated too. I know. Now I'd have to go to the extra lenghts and do the full restore to see if it really works. On Aomei I chose VSS, not their own technology. So? DOes it mean Macrium is faulty on my config?
Can I stop all the Reflect Windows 10 Notifications when my scheduled backup starts? I get about 4 notifications (starting, initializing, backup started etc) when it starts.
Disable the notifications mate http://winsupersite.com/windows-10/how-manage-notifications-windows-10
I just mentioned this in the AX64/FlashBack thread but clearly that's not the place to discus any known details. A new technology, similar to AX64's "tracking file" technology, is being BETA tested within the Macrium community. It's called CBT (Changed Block Tracking) and will be optional in it's use at the application level. It produces a smaller imaging footprint, is as fast (or faster) than the AX64 imaging method, and overcomes the AX64 anomaly of having to rescan the entire surface (basically a full surface scan) following the discovery of a possible external volume modification. It also overcomes BOOT time system changes (BOOT time defrag, etc.) with a very basic approach to the problem. It's primarily aimed at periodic incremental imaging that includes small changes in large files. The testing is going very well as it looks like the technology release may come sooner than later. I have some questions in to the Devs to determine how CBT will operate in a LV (Lite Virtualization) environment... will pass that info on as soon as I hear something.
RBF - great news - the program just keeps getting better. Can you just elaborate on what you mean by " CBT (Changed Block Tracking) and will be optional in it's use at the application level"? Optional in what way? Use it or not? When would you not want to have this enabled?
BT... some people just don't trust the reliability of LIVE disk block change tracking. If done properly (and I believe Macrium has), there should be no fear. But users of AX64's Time Machine/FlashBack discovered many anomalies along the way and may have lost some trust in the technology. Macrium's implementation includes an option where the technology may be used or the user may continue to use Reflect as they do today. My testing... and I'm not a large file, frequent imcremental user (I use daily INCs), has shown much smaller snapshot images and much faster imaging for those small images. It seems like a win-win for a user like me. Those who would like to snapshot more frequently (hourly?) should get a great benefit from this BETA effort. CBT uses a special Windows Kernel-mode driver (as AX64 does) which keeps track of the exact disk blocks that have changed since the System has been reBOOTed. It's this "map" that is used to determine what has changed since the last image was made. The "changed block map" is used to generate the next incremental. Since the map only includes the disk blocks that have changed, it's much more efficient that the "looking for changes" mode used for the current incremental. The FileSystem compare used during that mode contains some inefficiencies and also records what we call "noise level" changes which are not really relevant to the actual incremental change. As a result, the CBT image is much smaller but accurate enough to return the system to that point in time. One of my quick tests did both a CBT and non-CBT image over a 12-hr unbusy period. The non-CBT image was 450mB and took 1m38s to complete (VSS lock, FileSystem integrity check, "looking for changes," the image and verification). The same CBT image was only 190mB and only took 35s. There's no way to equate those numbers to any particular system environment, but in mine it represents quite a significant change. You can see where someone who takes lots of incrementals over a long period of time would really see a significant difference.
In thinking about this issue... since CBT resets itself at the First incremental following any System reBOOT (current incremental style used <"looking for changes">), and most, if not all, of the Lite Virtualization tools that I'm aware of must reBOOT a system to return itself to the previous state (modified or not), the "reset" should handle any changes incurred by the LV system state. Just a guess... I haven't heard from the Macrium Devs as of yet.
Froggy, thanks for the explanation - just as a follow-up. Is the choice you take for all images or could you run your standard GFS system under the new arrangement but do individual sets of full + incrementals under the old style by manually choosing at the time? I suppose it's a decision for all your images, right?
Thanks for that, korben, but I think that will probably turn them all off. Or am I wrong? I would like to keep the Successful notification.
Actually, it's a pretty easy and straight forward solution. AX64 tries to validate its "tracking data" across System restarts... if it can't, it does a complete scan of the protected volume's surface to determine the incremental data required for its next image while re-synching its tracking data at the same time. This scan is as long as a full scan for purposes of taking a full image. CBT says... "Nah, I'm not gonna even try and validate my tracking data across System restarts, I'll always re-sync my tracking data following a System restart by doing my previous "Looking for changes" type of operation on my 1st FULL/DIFF/INC following that restart. From then on any additional image will use re-synched CBT tracking data. The difference, of course, is a Reflect old style incremental is waaaaaay faster than an AX64 complete surface re-scan, so other than the 1st operation after a restart (which would be the same as it is now), all that follow until you restart your System once again will be CBT-based." I consider that a pretty elegant solution to possible corrupted tracking data. I believe the Devs discovered that determining the validity of tracking data across System restarts was more difficult than it was worth, especially since their method of re-synching data is already pretty elegant.
Sorry I'm late with this, BT... It looks as though the option may be turned on and off at will. If its on, and CBT has been re-synced, you get a CBT image. If it's off, you get an old style image. So far I see no reason for running it any other way than on... BUT, it's still in BETA test and you know what that means
I have spent some time reading tutorials. I have also tried AOMEI Backupper Standard 3.2 to make sure I'm not barking under the wrong tree, but even though it seemed to work the first time, the created image couldn't complete verification later, so fail. I scanned the external both with the SSD with cmd scannow - no errors found. After plugging the external into Dell and then on Vaio there pops up a message: check for errors, which is pretty common with memory sticks. Let's begin: W 10 Home x64 on Dell vostro 5459 i7 8GB with external HD HGST 1TB Macrium says the C: is GPT but external disk is MBR, so I followed the advice and converted external to GPT seeing that the previous attempts were fiasco. I used diskpart to achieve it. Now I know there is Unallocated 931.39 GB GPT + Other 128MB GPT (Reserved Partition) Should I use MiniTool 9.1/ EaseUS 11 to make the partition now or...? However, I tried my old WD with Fat 32 which is MBR and it worked under W10 with Macrium 6. That's why I'm puzzled.
Korben... it's not clear what you're trying to do here. It sounds like the Vostro internal disk is a GPT formatted SSD, yes? And the external disk at 1tB was MBR formatted. There's no reason those 2-disks shouldn't work just fine together... no need to re-format that I can see. What exactly are you trying to do?
TheRollbackFrog, For the last several days - same thing. Ensure the external is working fine or not. So what format the external should be knowing the laptop's SSD is GPT? NOw it's converted to GPT with Unallocated 931.39 GB GPT + Other 128MB GPT (Reserved Partition)
That external 1tB HDD should work just fine with that System as an MBR-based drive, there should have been no reason to reformat it as a GPT device. You will have to FORMAT the MBR drive before Windows allows its use as a mounted volume... this may be done under the LIVE WIndows System. Did something not work when you connected it to your Vostro?
