David, if you use the "Incremental Backup Set" (rather than "Incremental Forever"), it will do exactly as you want. Your 1st INC will be a FULL, the next <n> INCs (as set in the retention section) will be created followed by merging INC1 forward as more than <n> INCs are created. The only difference between this setting and INC FOREVER is this FULL baseline remains and the INCs will migrate forward where under INC FOREVER, the baseline FULL will migrate forward along with the <n> INCs. Don't forget to set your INC count to what you want to retain and unCHECK the FULL retention setting. This will give you what you want... assuming you have your schedules set up right.
Hi David! Based on Pete's bump above, you can do as you wish with FOREVER INCREMENTALS... just make sure to take Pete's advice and unCHECK the Synthetic Full option under the INC retention settings. This is really the easiest way... (my head was spinning when I answered before ) When you unCHECK that option, the baseline FULL doesn't move, only the INCs...
The only thing that bothers me with Incrementals Forever is that if one of your incrementals gets damaged or corrupted then the entire chain is useless. Something to keep in mind.
Not the entire chain... just from that time point on. Same risk with a bad FULL (all its dependencies become invalid also) and a bad DIFF (all its dependent incrementals).
Which is why I am using GFC with new fulls every month and new diffs every week and why I take weekly fulls with a 2nd app as well. The problem with Inc For Ever is the forever part,,,,how long is too long? I guess that will depend on each individuals comfort level but forewarned is forearmed.
Hi Barry I've been working with incrementals a long time, now with Macrium and before with Shadowprotect. If you don't mess with them, there shouldn't be a problem. I let SP Continuous Incrementals run for months without a failure, and since I've been testing with Macrium V6, I've let macrium chains go to as many as 30 incrementals. Amazingling the restore time was almost the same. Pete
The tray icon needs to be bigger. Just make it the standard size of other icons. I was looking for it when Reflect was backing up to see its progress, and it took me awhile to find it as it looks insignificant amongst my other tray icons.
Where are the Macrium Reflect tasks stored? I cannot find them in the Windows 8.1 Task Scheduler, which Macrium Reflect is supposed to use.
What's new in version 6.0.516: - Windows PE boot menu in trial - 30 day trial versions of Macrium Reflect can now add the Macrium Reflect recovery option to the Windows boot menu. - Windows PE and BitLocker Encrypted drives - Windows PE can now unlock and image BitLocker Encrypted drives. - Monthly scheduling now includes individual month selections - The monthly scheduling in Templates and Backup plans now allows you to select months. Previously, you could select a day and this would apply to every month
Thanks Pete, thats good to know. If one of the incrementals did get corrupted would it still be merged or would MR know there was a problem?
I'm not really sure what "corrupted" means in this context. If the data stream (the incremental or whatever image) is being corrupted during the write operation by a bad device or data path, that will be almost always picked up in the VERIFICATION process of that image. If the storage device does bad along the way (surface errors, etc.), either the devices error correction codes will correct the data or the device will issue hardware errors for the OS to detect (which it does). If an internal system data path goes bad along the way (SATA, internal PCIe bus, etc.), there may be issues that may be undetectable, I'm not sure. If the application writes corrupted data to begin with, there's not much you can do about it but live with the result. That's why you should try and select an application with a good, solid, reliable track record when using these types of tools (for instance... that's not quite what AX64 is yet). Google, for instance, believes that any "archived" data (images, files, whatever) is only as useful as its ability to be restored error free. That's why it schedules MULTIPLE restorations of its data... just to be sure it's useful. Home users really can't do that in any extensive manner, although I believe Pete does do some of this type of "checking" occasionally.
Thanks for the detailed explanation, sounds like the potential for the problem not being detected is rather low so I guess Incremenetals Forever is not adding much risk..
Thanks Froggie/Pete I will try that out later. The reason for doing this is that I like to revert to a baseline once a month. I can then get rid of the cp I have collected and then update Windows and install any programs I wish to keep. I suppose the incrementals can be deleted at some point and the original image kept for a period.
I sure do check images for restore, and I do it frequently. Something else I've started doing is running chkdsk after restoring. No problems with Macrium, but you'd be surprised on others. Also I see more problems with images from external drives then internal. But I consider testing essential.
The question about incrementals brings up an interesting point. I am relying on Macrium and so far have no reason not to, but just suppose I have a string of images that covers a month and for what ever reason something goes bad, and I can't restore. That's why I do image with other imagers. But they may not be current, then what. This is where I fall back on old reliable, Raxco's Instant Recovery. Aside from imaging, I keep my IR images very current. So if I have to fall back on an old image, I just use it and restore to a old state. I then use IR bring it current. Tried, tested and works like a charm. How much of this one should do is dependent on how critical your data and system is to you. Mine is critical.
I've also had my "reservations" about external storage volumes. Mostly it's in the area of not understanding (or knowing) of the error protocols in play with external HDDs especially. I know how errors are passed up to the OS with Desktops and internal SATA-based storage elements but I know nothing of how similar information is handled by external USB-based devices. This had led me to use only eSATA external storage volumes for use with my main Desktop system... the error protocols are identical to internal SATA-based elements, and they are a bit faster than USB-based items (even USB3). I use a coupla good SATA external docks and standard OEM internal disk devices in these docks... all work pretty well in that environment.
Frog, my v5 MR scheduled backups would wake my sleeping PC. I thought I'd even noticed that choice in v6 but I can't find it. Googleing, or whatever, you can find some scripts to add. Is that the only way to do it? As always, thank you!
Thumbs up for Macrium and ReDeploy. I upgraded my 6 year old AMD motherboard to a new Intel Core i5 today, and along with it went from a HDD to SSD. Took an image of my boot drive last night (data is on another), restored it to the SSD today, used ReDeploy to load up the motherboard chipset driver and the darn thing booted right up into Windows. Thing of beauty. Everything is working like a charm.
...but wouldn't Windows complain about this? I mean, I thought that a new MoBo and CPU would tell MS that they need to deactivate windows. Are you running Win 7 or 8.1?
I always have two 'identical' discs that I use for my system drive C:, one is connected the other is not but serves as a hardware backup on hand rather than rushing out to buy one. I also periodically back up one and restore to the other to prove that Reflect is working properly. I decided to replace my 120GB SSDs with 256GB SSDs. First I backed up and restored to the 'other' 120GB and was able to boot to it which seemed to validate Reflect. However when I attempted to restore the same image to a 256GB SSD upon booting to it I got the desktop for a few seconds and then the screen became 'messed up' and then got the BSOD. The error code was "Stop: 0x0000001E" followed by four sets of "0X0000000000000000"s. I also tried Cloning the 120GB to the 256GB with the same results. The 120GB drives are a Kingston and a Crucial so manufacturer doesn't seem to matter. The 256GB are both Corsair MX100s and the problem exists when trying to restore to either so I don't think it's a drive issue. When using V 6.0 bld 476 I had the same error which is why I upgraded to bld 516. However with these attempts there was a rescuepe.log file created in a seemingly random location with the following text =========================================================== "Macrium Reflect Boot Log ------------------------ Started 2015-03-17 5:28 PM v6.0.476 DrvLoad: Unable to load x:\drivers\Network\VEN_10EC_DEV_8168\rt64win7.inf (Error 0x80070103). DrvLoad: Unable to load x:\drivers\USB\Etron USB 3.0 Extensible Root Hub\EtronHub3.inf (Error 0x80070103). " ======================================================= There wasn't a log file with bld 516, so something changed in Reflect. During the bld 516 restore I saw Reflect loading both the above files, rt64win7 and EtronHub3, but I didn't see that with bld 476. To recap: Reflect backs up and restores an image where the two drives are the same size but doesn't if the drives are different sizes. And there was no opportunity to capture a dump (that I know of anyway). I've posted in The Reflect Support forum but if anyone here has an idea then please post, thanks, J
jwcca, Which OS are you using? MBR or UEFI install? What sort of images were you using? Partition or Entire Disk? I've seen "Stop: 0x0000001E" frequently lately, with other software. But I don't know what it means.
