This functionality is built into the GUI. Go to Edit Defaults > Advanced > Advanced Backup Options and check/uncheck "display backup notification delay for xx seconds" Done
Early observations! Incrementals about as fast as AX. I'd probably go to AX first after testing software. I'm glad I've been skimming the thread as I kept having restore failures, even though my incremental was verified. Although I'd built a new boot CD, I hadn't updated the boot menu. Thanks Froggy as I believe it was you that gave us that headsup! After that, no problems. Much like AX v2's "extras," being a person with basic and simple image and restore tools, I'll probably never take advantage of most of the features. I'll keep reading this thread and come to realize I may want to use some though!
Trapperman, that doesn't eliminate the pop-up that occurs when an imaging operation starts... that's for a different issue. Only way to eliminate the Start Imaging pop-up is through Windows 7 "Notification & Icon Control" described in THIS POST.
Ratchet, are you saying that the v6 boot menu wasn't working after upgrading from v5, and that you needed to update it?
I've updated my notes in post 1469 in the hopes that it might be useful to some new MR users possibly doing a search. I think a new thread called something like Good Practices might also be of value to many, but haven't created one due to not being able to check it regularly for anyone expecting a response from me.
Hmmm... after rereading huntnyc's post 3-4 times now, I'm not sure which "popup" huntnyc is referring to, yours or mine. It's a fine semantic line. Either way, I guess he now has instructions on how to turn off whichever one he's referring to.
I was referring to the popup that appears when a scheduled image starts. Did both options to be sure but maybe the Macrium built in option might have done it by itself.
I think that sort of works, but based on how I think it would work I see some negatives. If I am doing dailies, they are an incremental against the baseline. After I reach the threshold for the dailies and I do another daily incremental, what happens to the oldest daily incremental - I think the two oldest dailies would be merged together as that must be the incremental for the oldest daily from the baseline. After a couple of years, I think the oldest daily incremental would become quite large. Similarly the oldest weekly etc, because they are the incremental from the baseline to that point. Much of the oldest incremental for the daily and the weekly will be common - only differing with what has changed in the days between their dates. The idea was to only have the one full backup and one chain for the regular scheduled backups and not have information duplicated in multiple scheduled fulls and multiple scheduled incrementals of different periods. I think this will use more space and so likely cut down on how many additional selected manual backups I could make. This is where AX nailed what I was looking for.
I agree with all that - I don't think macrium will do exactly what you want as it doesn't offer enough control over merging. OT but you could consider file-based software instead, e.g ajc active backup (delta versioning) or max sync up (reparse points) or many others.
They have not announced it yet (per their Forum). I think they're trying to determine what additional features should be available in the free version, if any. The new SCHEDULING system (templates) and the RAPID DATA RESTORE are the two major additions to this version... I don't see why they would give either of them away. If they did, it would really p-ss off the licensees. Maybe they could now offer standard INCREMENTAL and DIFFERENTIAL imaging without RDR or scheduling.
I just noticed something when using YUMI to create the recover media using the .iso, when the .iso is called "Rescue.iso" it works just fine, but when you call it "Macrium Rescue.iso" it just doesn't want to boot, claims file is missing or something like that, realized then that the .iso must be called "Rescue.iso" to work when using YUMI... Just Sanyain, in case someone else using YUMI has/had issues with it.
I bet if you use "macriumrescue.iso", it should also work. Many programs don't like spaces in file names.
Hello SanyaIV, I rename my ISO's that I use with YUMI (including Macrium Reflect) and do not have any issues. I may be wrong but I believe that your issue may be that YUMI does not handle spaces in the ISO's name. If you try to save it as MacriumRescue.iso or Macrium_Rescue.iso then it should work (or at least it does here). HTH...
I create multiboot UFDs for BIOS systems with Easy2Boot. The menus are created dynamicaly at execution time, so the UFDs can be easily updated to include new ISOs and remove others. No problem with the names.
My testing was quite bad, I do believe it has to do with the spaces, however I did try "Macrium_Rescure_6.0.482.iso" and now I realized that I used a lot of dots in that name ^-^'' Note to self: Don't use spaces and don't use dots...
Just so everyone knows... During the use of FOREVER INCREMENTALS, the penalty for using SYNTHETIC FULL (Merging the baseline with the 1st incremental) and INCREMENTAL MERGE (Merging the 1st and 2nd incrementals) is almost identical... it's VERY QUICK. Due to the format of the baseline, even though it's much larger than the 1st incremental, it merges just as fast as two incrementals would. Don't be afraid to use it if you think you could use a moving baseline.
Thanks for this - I was wondering if there was any difference and now don't need to test it. I wish it would only merge once or twice a day like AX64 does - doesn't seem very efficient to do it with each hourly incremental (on my pc, with 6 incrementals, the incremental takes 40-50s, and the merging another minute or more). I imagine it could achieve this by having separate min/max values for the retained number of incrementals.
Actually, trying to use "Macrium_Reflect.iso" with YUMI doesn't work either, I get "Error60: File for drive emulation must be in one contiguous disk area." ... Weird.. I'll just use the default "Rescue.iso" Since it's probably an issue with YUMI this may be off-topic and I apologize for that, will stop now.
This problem existed in an earlier version of MR as reported in another post, and I'm interested to know if it exists in v6: "What happens if a file on the disk was corrupted or modified with direct disk access" (bypassing the partition file table with e.g. with a hex editor)? That file will remain damaged and won't get replaced from the old intact one that resided in the image.... Macrium at least when I tested it a few years back had that problem with the incrementals. It does not read all the occupied sectors of the disk when creating the incrementals in order to compare them with hashes from the previous image; only reads the new and the modified ones as they are reported from the file table."
I notice that Rescue is less than 8 characters - might be worth trying a shorter name. edit: or perhaps ditching the underscore.
