Cool! Thanks, that makes me feel better. I've only just started using Macrium, so I was hoping I wasn't in for a bumpy ride.
v6.1.1309 was pulled shortly after release as a problem was found with long Volume names. This caused a program crash at startup for a very few customers. If this didn't affect you then you don't need to worry. As mentioned above, it has been corrected.
Krusty... , this is about the biggest bump you're ever gonna feel with Reflect. The app is very solid, and the Support Team behind it is very qualified and very responsive. The closest thing you're gonne ever get to a bump will be a slightly unnoticed undulation just like this one
Ok, will try that again - the one time I tested this, the flash drive did not work. Might have been an issue with the stick.
You need to prepare them to be bootable. Read this KB http://kb.macrium.com/KnowledgebaseArticle50210.aspx
Just read the techie tuesday blog from Macrium here https://blog.macrium.com/2016/05/24/techie-tuesday-backup-folder-synchronization/ re Incrementals and realise I am still a bit confused about the types of merges. Looking at the examples and reading the text I am confused. According to the explanations under Example 1 the full image is merged with the first incremental. For Example 2 the first incremental is merged with the second incremental. What puzzles me is that the picture seems to indicate the opposite with the full image being steady in Example 1 and moving forward in Example 2 - based on the text I would have expected the pics to be reversed. My assumption would be that the option with the full image being steady gives you one "safe" original image and a moving chain of 5 incrementals, so you could go back the last 5 days or to the old original missing the interim. Alternatively your full gets merged and moves forward in time. When would you prefer one over the other?
Beethoven, indeed the graphics are backward and the descriptions are correct... swap them in your mind As far as which is better... it's up to the user, really. If you really don't need a FULL to be as old as it can get under "Incremental Merge," just CHECK the "Synthetic Full" option and off it goes. A lot of users don't need that Full very old at all... they just want some granularity of a specific period of time and don't care about the system status prior to that time period. People have noticed that doing a Synthetic Full does create some long merge operations after your retention period has expired... due to the fact that your Full needs to be merged after each Incremental taken once you reach your retention limit. Incremental merging creates much shorter merge periods unless you have a large retention number, then things get slow eventually. Being a user of GFS, I only get to experience "Incremental Merge" due to my INCREMENTAL Retention period only being 7-days.
One of the niceties of Reflect, especially if you're running a pure "Incremental Merge" operation... if your baseline starts getting a little long in the tooth, all you do is EDIT your definition and CHECK the "Synthetic Full" feature and save the change. On the next Incremental run, Reflect will merge that baseline (Full) all the way up to the oldest Incremental in the chain. After that, just re-edit the def and uncheck the SYN FULL option and your back to where you were when you started, without having to generate a new baseline or start a new chain...
Thank you - it's amazing what you can do once you fully figure out the depth of this program. One follow-up question - in the blog was the reference to delta restore. I see this is still optional. Do you use it? I checked my settings and it's still off. The way I use my images is for insurance. I am not frequently moving back and forth between images, so I am not sure if I need this additional feature. I noticed that apparently if you change from the full images to delta you best start a new chain.
I think you're confusing "Delta Indexes" with "Delta Restore"... they are very different. "Delta Restore" is the feature used during restoration only that allows you to restore only differences between where the system is and where you want it to be... basically a high speed restore. "Delta Indexing" has to do with the way Incrementals track each other and allows for simpler merging and record keeping. Delta Restore may be used with all image chains whether Delta Indexing is used or not.
Boy, it is confusing for me - maybe I should go back to my music - the setting I refer to is indeed Delta Indexes. On the page where you can choose to either use this feature or leave it off it gives some explanation which I try to understand. The way I understand it now ( and I am known to misinterpret these things) is that the incrementals will be smaller and merging faster. Mounting via explorer may however take a bit longer and there is some additional reference to previous files that have to be appended. I have never been particularly bothered by macrium merging some files in the background, so I probably would not even notice if it was a few seconds faster. I only use the explore image function very occasionally, so a slightly longer time would be no big deal either. So I am not sure if changing the default and tick enabling Delta Indexes will be beneficial - just looking for feedback from experienced users as maybe the advantages or disadvantages are more pronounced in the real world than I can see from the explanation.
I think you are making it more confusing than it needs to be. Just get back to the basics and set a regular backup regime and relax knowing that it will most probably save you if you need it.
Beethoven, as Hadron basically says, don't sweat the small stuff. You are correct in saying that the speedup in incrementals and merging is minuscule, BUT... there is one big difference that makes me use Delta Indexing. Without Delta Indexing, a complete INDEX is saved in each of the Incrementals following a merge operation. While this makes the reference Index (used for restoration) available directly in the Incremental being used as the restoration reference, it causes all Incrementals to be updated (only the Index, not the data itself) following any merge operation. For Reflect imaging and restoration purposes this is no big deal... but for replication of backup data this is a PITA. Since every Incremental changes after each merge operation, the replication of your backup data becomes a real chore... every Incremental must be re-replicated (unless using some sort of DELTA file replicator) during the backup of the backup process. This can be a lengthy operation. When using Delta Indexing, the restoration Reference Index gets re-built from all the Incrementals rather than from ony the one being referenced. The reason... active Delta Indexing only updates the index of the file changing during the merging operation... usually the oldest incremental in the chain. With that happening, any replicator/syncher <sp> will only replicate the one changed file that occurred during the merge operation, not all of them. Other than the above, all operations are the same and Reflect does what it does best under either scenario. To quote Hadron... "Just get back to the basics..."
I am now trying to create a bootable stick as rescue media. Unfortunately similar to a previous test I am having issues with the rescue media creating within Macrium running "successfully" but a boot attempt failes with missing operating system. I thought maybe last time my stick was faulty but I now got a new stick and it's exactly the same error message. My disk management shows the UFD as active partition, so what am I missing? I looked at the link Peter provided before but I am afraid I don't understand the references to MBR. My stick was completely empty and I let Macrium install the full rescue media and did not get any error messages. There is reference that some sticks have track 0 not writable - how would I check that?
Hi Beethoven Go back to that link and read down to the point where it tells you how to make the UFD bootable. You have to go thru that proceedure You have to do these steps and then the add the RE with Macrium and then it should work
beethoven, Nothing has been written to your USB. Try this as it just worked on my test computer... In Windows open an Admin Command Prompt diskpart list disk select disk * (* will probably be 1 but be careful you have chosen the UFD and not the HD) list disk (make sure the correct disk has been chosen) clean exit exit Now use this blank UFD with Macrium to make a boot disk.
Brian, I will do that but if I look at the stick in explorer I can see all the files from Macrium already. Peter, I had actually looked at it but thought this procedure was only necessary if there was an error by macrium. So, basically you always have to do that?
