Macrium Reflect

Discussion in 'backup, imaging & disk mgmt' started by Stigg, Nov 23, 2013.

  1. jphughan

    jphughan Registered Member

    Joined:
    May 3, 2018
    Posts:
    913
    Location:
    US
    I thought about that, but the partition numbering in Reflect's view always matches diskpart's, even when the partitions are not numbered sequentially from left to right. I once had a disk where the partition numbers were 1, 2, 3, 5, 4 because I had shrunk Partition 3 to make space for Partition 5. Reflect's view showed them numbered that way, not 1-5 left to right. And Beethoven's Reflect screenshot shows that Partition 2 is the Windows partition.
     
  2. Hadron

    Hadron Registered Member

    Joined:
    Apr 1, 2014
    Posts:
    2,137
    Hi Brian.

    As your post is related to this, I'll ask this question.

    In TBOSDT, when I type this:
    Code:
    list hd 0 /f /u /w
    Why would I get the message, "Invalid Drive"?
    I am not concerned about it. Just curious.

    When I type the above Diskpart commands, I can see that it it drive 0.
     
  3. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    12,115
    Location:
    NSW, Australia
    You need to run TBOSDT as Admin.

    Good idea. It will show the partition IDs.
     
  4. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    12,115
    Location:
    NSW, Australia
    JP,

    You are correct. The numbers in Macrium are the MBR slot numbers, not the physical partition order. Just checked.
     
  5. Hadron

    Hadron Registered Member

    Joined:
    Apr 1, 2014
    Posts:
    2,137
    Oh, yeah.
    That was easy. I don't know why I didn't think to do that.
     
  6. beethoven

    beethoven Registered Member

    Joined:
    Dec 27, 2004
    Posts:
    1,388
    Brian, seems that Recovery is shown as 1 and Win10 is Partition 2
     

    Attached Files:

  7. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    12,115
    Location:
    NSW, Australia
    Thanks. As JP said, your recovery files are in the Win10 partition. Mine are too...


    Can you check winre.wim , its date and size?

    From an Admin command prompt...

    Code:
    dir /a C:\Recovery\WindowsRE

    You should see winre.wim along with ReAgent.xml and boot.sdi
     
  8. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    12,115
    Location:
    NSW, Australia
    And then look at winre.wim in the Recovery partition...

    Open BIBM, Partition Work
    Drive 0
    Select the RE partition
    Edit File
    Recovery (press Enter)
    WindowsRE (press Enter)
    you should now see Winre.wim and 2 other files

    Size and date of winre.wim?
     
  9. beethoven

    beethoven Registered Member

    Joined:
    Dec 27, 2004
    Posts:
    1,388
    Brian, as usual you are quite correct. I did the checking above both ways and the results are as you expected. I am just not sure what that means for my imaging with Macrium. Also, what would I need to image in IfW?
     
  10. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    12,115
    Location:
    NSW, Australia
    beethoven,

    Were both winre.wim the same?

    I think it's good news. The RE in your Win10 is enabled so you don't need the Recovery partition. I'd delete it and you only need to image the Win10 partition. You will then have a spare MBR slot for another partition. eg TBWinRE, IFL, Macrium?
     
  11. jphughan

    jphughan Registered Member

    Joined:
    May 3, 2018
    Posts:
    913
    Location:
    US
    The downside to the approach above is that if there's ever an issue that renders the Windows partition unreadable, then you've lost the Recovery partition as well. And that design wouldn't be workable at all for anyone who wanted the ability to use BitLocker. Then again, I doubt many regular Reflect users will ever really need the Recovery partition anyway, so it might be moot.

    I'm not sure I'd recommend deleting the Recovery partition though. Since that's Partition #1, I believe that will affect the numbering of the other partitions, in which case the RE path might break -- if you care about it at all -- but I'm not 100% sure on that.

    I actually didn't even realize Windows allowed you to set up the WinRE path to be on the Windows partition. Did you do that manually, Beethoven?
     
  12. beethoven

    beethoven Registered Member

    Joined:
    Dec 27, 2004
    Posts:
    1,388
    Actually, checking carefully the details are not the same. On my "live" system the size is 443.717.121 and date 10/1/20 while when using BIBM the size is 436.996.799 with a date of 19/2/20
     
  13. beethoven

    beethoven Registered Member

    Joined:
    Dec 27, 2004
    Posts:
    1,388
    JP, I will leave the recovery partition in place as I don't need that space atm. As for changing the path, I must have done that during the installation of BIBM and splitting the original partition in two, though honestly
    I don't remember the details. Maybe Brian has a clearer view on that.
     
  14. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    12,115
    Location:
    NSW, Australia
    beethoven,

    It would be interesting to run
    reagentc /info
    from your second Win10 OS.
    Does it say partition 1 or 4?

    Partition 4 refers to the 4th MBR slot which is actually the third physical partition on your drive. The second Win10.

    Those of us who played with WinXP should remember...

    You saw this error when boot.ini on the active partition was pointing to a non bootable partition.

    In this line...
    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

    partition(1) refers to the partition in the first MBR slot. Not the first physical partition on the drive. So if you saw the hal.dll error on booting you had two choices to enable WinXP to boot...

    Edit boot.ini to the MBR slot number of WinXP or
    Move WinXP into the first MBR slot.
     
  15. beethoven

    beethoven Registered Member

    Joined:
    Dec 27, 2004
    Posts:
    1,388
    Brian, I do remember now some errors preventing the win7 partition to be bootable as planned. However I had forgotten that I had left it there last time, taking a break, so was surprised last night when I could not boot to the alternate partition. Then I realised that I had never installed the Win 10 partition after giving up on Win 7, so for the last reagent test, I need to do that first. Don't think I have time for that today though.
     
  16. jphughan

    jphughan Registered Member

    Joined:
    May 3, 2018
    Posts:
    913
    Location:
    US
    Mostly to tinker, I decided to shrink the WIM file on my own system's Windows Recovery partition. Reflect was showing that partition in red on my system too now, and I also noticed that a fresh install of Win10 2004 results in a significantly smaller WIM file than I currently had. I knew from prior experience that WIM files can bloat beyond what's needed to store their data if they get modified in-place, and I also knew that the WinRE WIM file does get modified in-place. Windows feature releases update it, and apparently it can get modified during driver installations, since one of my systems has a Winre.wim file that contains its Synaptics touchpad driver package, including the few hundred MB worth of video animations to demonstrate multi-touch gestures.

    But it's also possible to export the contents of a WIM file into a new one, in which case the bloat gets left behind because the new one is essentially "compacted".

    So I copied the WinRE.wim file from my Recovery partition to C:\WIM, then ran the following in an elevated Command Prompt:

    dism /Export-Image /SourceImageFile:c:\wim\winre.wim /SourceIndex:1 /DestinationImageFile:c:\wim\winre2.wim

    The new WIM file was over 100 MB smaller, even though it contained exactly the same data. Then I deleted the Winre.wim file on the Recovery partition, copied the new WIM file there, and changed its name back.

    (Steps omitted above included temporarily assigning the Recovery partition a drive letter, using the "attrib" command to remove the system and hidden attributes from the Winre.wim file on the Recovery partition for simplicity, then adding them back to the replacement WIM I copied back onto the Recovery partition, then removing the drive letter.)
     
  17. Krusty

    Krusty Registered Member

    Joined:
    Feb 3, 2012
    Posts:
    10,210
    Location:
    Among the gum trees
    Bug fixes and Improvements v7.2.4884 - 9th May 2020

    • Email Notifications
      Some customers have reported that Reflect notification emails have been rejected by their email service providers. This has been resolved.
     
  18. Osaban

    Osaban Registered Member

    Joined:
    Apr 11, 2005
    Posts:
    5,614
    Location:
    Milan and Seoul
    I think I'll skip this one, I don't even use the email notification.
     
  19. Krusty

    Krusty Registered Member

    Joined:
    Feb 3, 2012
    Posts:
    10,210
    Location:
    Among the gum trees
    I don't either but I didn't think it would do any harm in updating anyway.
     
  20. puff-m-d

    puff-m-d Registered Member

    Joined:
    Feb 13, 2002
    Posts:
    5,703
    Location:
    North Carolina, USA
    Hello,

    A new update has been released, version 7.2.4942.0...
    Homepage - Release Notes
     
  21. Cruise

    Cruise Registered Member

    Joined:
    Jun 10, 2010
    Posts:
    1,236
    Location:
    USA
    I have encountered a strange problem with v7.2. It had been executing its scheduled backups for over a year very efficiently (where a typical incremental backup ran for about a minute or two) ...that is until this week. Now it takes hours to make an incremental backup of my C-drive (even when there has not been any notable changes), spending almost all of that time 'Determining files to copy'.

    Earlier this week (right before experiencing this problem) I decided to 'skin' my desktop by installing Winstep Xtreme, so maybe that's causing the problem? Without suggesting I uninstall Winstep Xtreme, which I really like, I would appreciate any other advice as to how I should go about troubleshooting this MR problem.
     
    Last edited: May 22, 2020
  22. jphughan

    jphughan Registered Member

    Joined:
    May 3, 2018
    Posts:
    913
    Location:
    US
    Did you recently update? If so, what version were you running before? The reason I ask is that the Reflect 7.2.4797 update included a note that the first Incremental created after the update could take much longer than normal because Macrium had changed something. I believe -- but am not certain -- that technically it was the first Incremental created in each set after that update, so for example if you have a disk rotation, then the first post-update Incremental created on each destination would take quite a while. Or you can work around it by just creating a new Full.
     
  23. jphughan

    jphughan Registered Member

    Joined:
    May 3, 2018
    Posts:
    913
    Location:
    US
    Given that one of these changes applies to ReDeploy, it's strange that Macrium didn't add the red text "Rebuild your Rescue Media after updating if you care about this change" note.
     
  24. Cruise

    Cruise Registered Member

    Joined:
    Jun 10, 2010
    Posts:
    1,236
    Location:
    USA
    Thanks for the reply. I'm not one to update every time a new build is released so I'm still on v7.2.4063 as it was working perfectly for me until this past week. So unless you know of a good reason for me to update my version, I'll just try creating a new backup schedule and see how that goes.
     
    Last edited: May 22, 2020
  25. Osaban

    Osaban Registered Member

    Joined:
    Apr 11, 2005
    Posts:
    5,614
    Location:
    Milan and Seoul
    Updated to 7.2.4942 as well as the bootable rescue media. Backup and restore performed normally here, however I've noticed that usually my incremental daily backup would take between 50 - 70 seconds with hardly any changes, but after the last 2 updates it takes almost 2 minutes with the same interval and few changes. Not an issue by all means, but I would expect new versions to to be faster than slower...It is also possible that it might be due to my version of Windows 10 that is v. 2004 build 19041.264
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.