I think you will see the same problem... if you call that a problem. That sounds more like a serious security issue than an imaging problem. Its scanning and restore speeds are too fast to be able to scan the entire content of a disk surface to determine incremental changes. My guess would be it's still the same as it was... but I could be wrong.
Sorry, I haven't been back since I posted that info. Yes that is exactly what happened. I went into recovery mode and when it prompted to use Windows PE it acted normal but then said it couldn't find the file or whatever. Then it would boot but not into the "time" I made the incremental. I tried several times. Then under "Other Tasks" I selected "boot menu." The next restore opened the boot menu with MR selected by default and it restored successfully! I then made new incrementals/snapshots (MR even calls them that now! lol) with both AX and MR so the new menu would be there!
That was my thinking. It seems to me that you could not detect these changes without reading the sectors, and reading the sectors would necessitate longer backup times than we're seeing. I agree that this isn't necessarily a problem though. I can't think of a use case where this wouldn't constitute bad software behavior and I don't know if imaging software should or should not account for bad behavior. However, a safety net could be something like IFW which does read the sectors for second level imaging.
Good point, I guess. The v5 free version was very popular. It will be interesting to see if they are as generous with the v6 free version.
Thanks. I shall look into somewhat is best of these other programs and using both for different purposes, or just decide what requirements I should compromise to make good use of macrium as it is. Would really love if they provided explicit control of merging though.
This is not a problem connected with the length of the filename as some wrote before, though yes, there should be no spaces in it, so if necessary use underscores or hyphens to replace them. Dots are also OK. This error informs you that your ISO file is fragmented on your USB disk and has to be defragmented. To do this, you cannot use any defragmenter, though. There is a specialized freeware tool to defragment specific files called WinContig. Find and downbload at http://wincontig.mdtzone.it/en/index.htm Load ALL your ISOs and defragment them. This will solve your problem and all ISOs that have shown the above error before will from now on load OK. Since this is a self-contained EXE not requiring installation, I even advise you to copy this file to your YUMI boot USB disk to have it always at hand to defragment as needed when adding new bootable ISOs.
But it's only when I use underscore that I get that error 60, it always happens in fact, tried several times, but when using only "Rescue.iso" then it always works.. I may try the tool you mentioned when I get home from work, but first I want to try renaming it to "Reflect.iso" and see if that works.
I successfully use as bootable ISOs on my YUMI USB disk filenames like Macrium_Rescue_v6.0.482_WinPE5.iso and when defragmented with WinContig they load OK... Just give it a try and see the difference...
Quick question,,,,, I am using as my backup/merge schedule the default GFC setup as provided by MR V6. Is this one with a stagnant baseline and creeping snapshots or the evolving baseline scheme? I would prefer the latter I think but am not sure how to determine which is running and how to change it if I need to.
GFS uses differentials which I believe cannot be merged with anything, including the baseline. So your baseline must be fixed. You can have a merging baseline by using Forever Incrementals and making sure the Synthetic Baseline box is ticked.
Good morning, BG! Taotoo is correct in his basic description... but it goes a little further than that. First of all, when the option is available (and it's not all the time), it says "Create a Synthetic Full if possible." The operative words here are IF POSSIBLE. As Taotoo suggests, if you have any DIFFERENTIALS, the baseline (or FULL) cannot move or the differential will be rendered useless (the reference for the differential will have changed). Under these conditions, the IF POSSIBLE will be invoked by the backup scheme created with "Synthetic Full" checked... it WILL NOT be possible and therefore the baseline will not be merged. The incrementals will move forward but the baseline will remain constant (as in Incremental Merge). The other thing you'll notice is that the "Synthetic Full" option is only available if you're using "# of backups" in your Incremental retention rules... any other incremental retention option removes that capability (why, I'm not really sure... they shouldn't have limited that option in that way). So, the best way to summarize is to say... if the "Create a Synthetic Full if possible" option is available and checked, the only way its baseline in the chain can migrate forward is if no Differentials are involved in the backup scheme, otherwise the baseline will remain constant as a point in time and the incrementals will migrate forward. PS- the other thing you must keep in mind with MR is that incrementals are also based on Differentials (as well as Fulls in the absence of Differentials). Some imaging software only generates incrementals based on previous in
OK, so given the retention rules indicated in the attachment, there will be, at some point, a gap of 2 months between my baseline and the first differential available to restore back to. That is, unless the differentials are merged into the baseline when they are deleted. I get that this is not what is happening. Seems like quite a gap if the baseline stays the same and differentials are simply eliminated. The default GFC time frame was, I think, Baseline (G) retain for 6 months, Differentials (F) retain for 4 weeks, and Incrementals (C) retain for 10 days. So at some point, if I understand what you are saying, with the default scheme there will be a gap of 5 months between the baseline and the oldest differential,,,,,,,seems like an awful large gap,,,,,,,or am I misunderstanding. EDIT: actually, I just realized that my concerns are unfounded as every 4 weeks a new baseline and a new chain is automatically started by MR so there will never be gaps of the sort that I have described. Am I correct now?
BG, I can't see your whole scheme but if you're using GFS, indeed there will be a monthly taken on the 1st Monday of every month (that's the DEFAULT unless you've changed it). Retention is just rules for how long existing snap types are kept around. If you're taking Differentials (Incrementals) along the way, they will always be based on (children of) the most recent FULL taken (or Full/Differential taken as far as incrementals go). Those retention rules are just specs for how long things remain available for access. PS- look at the Add/Edit schedules to see what kind of snaps are being taken... those snaps are the ones being "managed" by the retention rules.
Being curious I posed this very question to Macrium as to why the limitation exists only for "# of backups"... they stated there is no technical limitation (as I thought) but they just ran out of time to implement others at the end of the v6 development cycle (they had a deadline that had already been missed by 6-weeks... ahhh, the pressures of a developer ). They have assured me that other options will arrive in future updates...
That is a very encouraging answer. Tells me they are willing to be candid. Makes my trust level go up a notch. Pete
Well... maybe If the "future" update they're saving it for is v7, that would make me very uneasy and not so happy. It's really a very easy thing to add, and if the reason they didn't have it in the release is purely due to time constraint, then I would definitely expect it in v6.x... maybe even in v6.0.x if we're lucky. I guess we'll have to wait and see... (GO Macrium!! )
I had a problem today with the first incremental of a new full image. The drive it backs up to is a USB but is only on when needed. The incremental was due today and I intentionally left it off to see what might happen. The warning came up but was too short to react and so failed. That in itself was not a surprise but I could not find anyway of resurecting the update. Thought there might be some option to re run it. Is there anyway to restart apart from doing a manual update. I did discover later that the timeout could be removed.
I upgraded to v6.482 on a paid home version. I created a new USB rescue media. The USB creation went fine but upon testing it I can't get it to boot. If I leave the USB drive as std FAT32, my PC doesn't even see it. If I format the USB as NTFS, the PC sees it and tries to boot but I get "error loading operation system". I tried two different flash drives with the same results. To create the rescue media, I using PE 3.1 (my operating system is Windows 7 64 bit Pro). I have created a bootable USB from another application which needs a rescue disk and that works perfectly. Any ideas?
Djg05, probably the easiest way is to either do a MANUAL via the DEF Spec (Select DEFINITION, <click> the "Run the backup definition" TOOL from the toolbar, <click> on Incremental) or <click> on the "Scheduled Backups" TAB, <right-click> the schedule item missed and <click> on "Run now."
Thanks - just label me a Dumb Cluck. I looked all over for that and could not find it, but it is so obvious now
Is this NEW info? I was not aware that they would have a Free V6. Feature Comparison Please note: Version 6 of Macrium Reflect Free will be available soon.
They spoken on their Forum about its availability "soon." I think they're just trying to determine what to give away in the way of features.
You know, I have a 512 GB 850 Pro SSD and the FREE V5 backs up all 4 partitions in about 4 minutes. At that speed I see no use for any incremental backups so mine are all full. Also, I used one to do a complete restore to my GPT formatted SSD.