Could someone explain what the highlighted section of the users guide means? ALSO, Is it recommended to "verify an image before restoring" and if so how much time (apx) would doing so add? I understand that the time added will be a function of the size of the image being restored, and would the entire chain be verified or just the incremental (or Diff) being restored to?
BG, if you <right-click> on one of your HDDs and select "Properties," you'll see, at the bottom of the window, an option that says "Compress this drive to save disk space." If you're using that option, RDR will not be operative. For an incremental restore point, all images (incl. the FULL) required to restore to that point will be verified... that will be all earlier images (incrementals/differentials/fulls) needed to provide for the restoration (all PARENTs and CHILDren of the selected restore point).
PCfan, you need to look at the release notes. Since the WinPE will include the latest released version of MR, you need to determine if the changes will affect any functionality you feel you might need in that WinPE. If they don't, there's no need to reproduce it. In my case, anything that affects a bug in Rapid Data Restore or the general speed of things, I'll probably reCreate the WinPE... but I don't think it's needed for every release, but that's just me
Enjoying htis program a lot. Is there any way to disable the popup message from appearing when scheduled backups are run? Not a big deal but just wondering and thanks.
You might get a lot of answers on this one Some will claim what's called "bit rot" over time... a degradation of the storage media the images are held on... in my opinion this is probably misplaced pessimism with today's HDDs. And then there's always the need to protect yourself against a flakey disk, whose verification at the time of imaging was GOOD but reVerification at the time of restore may be bad... this is a valid concern with any device that can fail over time. That's why production users of GFS backup schemes move data from one storage media to another along the GFS backup time line. My view of reVerification is as follows... if you find your most important data BAD at this time, what do you think you can do about it unless your backup scheme is broad enough to include other media at different times along the way. If you don't have that, you've got no recourse when you detect a failure anyway. My answer is to "refresh" the data elsewhere if it's that important to you. That's the main reason people separate "data" management from OS protection and imaging... they are really different beasts. Really important data will be replicated (in my case, in real time) elsewhere and most likely duplicated somewhere (other media/cloud/<where ever>). SYSTEM partitions can always be rebuilt, if required, to make them functional once again... imaging just makes that task much easier. I'm not sure "imaging" is really the right way to protect important data.
Probably the easiest method on your W7 system is to <click> on your "Show hidden icons" function in your SystemTray, then <click> on "Customize..." When the window comes up, find your "Macrium Reflect" icon and, using the associated DropDown, select "Hide Icon and Notifications," then OK out. Should be dead at that point.
So I pulled the trigger but it won't let me finish the v6 install, claiming I'm entering the wrong v5 key in that field. I had uninstalled v5 first. Could that be the problem? I have posed that question to support. Thank you!
Hi PCFAN I don't. I look at what has changed in the new build to see if it affects me, and if not, I don't rebuild. Pete
If you upgraded you still need the old key number. If you uninstalled with out releaseing the key that maybe the problem. You could try reinstalling v5 and if it shows a good key, then release the key(I think it's somewhere under the help menu). Then the v6 upgrade should be okay. Pete
I left v5 installed and installed v6 over top and had no issues. I suggest reinstalling v5 and then update to v6.
Good Idea, I have a list of all my keys in case some file get accidentally gets deleted or gets corrupted somehow and I have to re-install.
Its off topic but I have an app called Recover Keys that searches the PC and creates a list of keys and registration info that can be saved to a number of different formats (or printed if you prefer). Real handy (I found) when I upgraded my PC and had to reinstall all my apps.
When I try to restore the image of my Windows7 partition, i Get an error message saying "Too many primary partitions". I have 3 primary partitions and one extended. Other backup software restores without problem. See disk structure: http://i38.servimg.com/u/f38/18/62/46/70/parts10.jpg I have V5.3.7277 Free.
Hi Froggie Sounds like the log was still open in some way and deleting it took out all the logs. Any way you can just start the logs over? Pete
Turns out, when Macrium deletes individual logs they wind up in the RECYCLE BIN as expected. This is what happens for every log but the one I identified. When I delete that one, the entire LOG folder(s) wind up in the trash... that's why Macrium thinks it has no logs. If I restore everything from the RECYCLE BIN, all is back in place as expected, but I still have the same problem. If I delete just that LOG entry, they all go bye-bye... it doesn't matter what order the entries are deleted.
Sorry, had to repost this due to TMI in the original post (Thanks, Stapp!) ----------- Greetings! An anomaly this morning... sometime after 9pm last evening, my image storage volume dropped off-line during a scheduled imaging process. This morning, the LOG showed this happening... fully expected. Placed the device on-line and everything continued along its merry way. In the process of cleaning up my LOGs (deleting failures, cancellations, etc.), when I deleted the following LOG entry, my whole LOG system completely disappeared. It was only the deletion of this particular entry that caused the problem. I'm posting the entry here at the forum in case you folks might have any ideas. This was the last error that occurred prior to my placing the target drive on-line (it was about to run that incremental definition). Any help, greatly appreciated.
I've just had a quick play around, and it looks like you *possibly* may be able to achieve something along those lines (i.e. only one baseline and non-linearly spaced merging) by doing something like the following: Create and schedule 4 separate backup definitions (Q, M, W, D), each as incremental and without synthetic baseline. Use 4 separate destination folders. Set Q to keep 8, M keep 3, W keep 3, D keep 3. Make the backup filename the SAME for each of the four backup definitions (e.g. Backup). Run the Quarterly backup to establish a baseline. Using fsutil, create hardlinks to the baseline in the Quarterly folder from each of the other three folders by elevating a cmd prompt and typing something like: fsutil hardlink create e:\monthly\Backup-00-00.mrimg e:\quarterly\Backup-00-00.mrimg - repeat two more times for the weekly and daily backups by changing 'monthly' in the first half of the command. Once done you should then see that baseline in all four folders. I think Macrium will then keep 3 dailies, 3 weeklies, 3 monthlies, and 8 quarterlies. I only tried it quickly and didn't try a restore (though imagine it would work since the baseline isn't synthetic). See attached image for an example of separate monthly and weekly destination folders. You'd have to experiment to see how it works in reality. Failing that you're going to need multiple baselines as far as I can tell (which is what I'm doing). http://i.pictr.com/vsavi4nnko.jpg
So AX64 saved MR. Well not exactly! With AX I did hot restore v5, then installed v6 over it this time. The odd thing was that the third from the last character in the v5 key was missing. I'm a hunt and peck guy so I never, never ever do anything but copy/paste keys, yet this key that I had on file was wrong. MR support did bring it to my attention thankfully.
Just to add to this... Normally, LOG files, when deleted using the CONTEXT menu item "Delete Log," wind up in the RECYCLE BIN with a name associated with the backup job... when created they have this name. They live in C:\ProgramData\Macrium\Reflect. The LOG file in question had no PRIMARY FileName... just a file Extension (I didn't know you could do this... except maybe at the API level). When that was deleted using the same mechanism above, the entire "Macrium" folder under C:\ProgramData got deleted and wound up in the RECYCLE BIN. You just can't make this stuff up...
