Rollback RX v11.x (Home & Professional)

Discussion in 'backup, imaging & disk mgmt' started by TheRollbackFrog, Jul 5, 2018.

  1. pb1

    pb1 Registered Member

    Joined:
    Apr 4, 2014
    Posts:
    571
    Location:
    sweden
    Whats hybrid - 0 and hybrid - 1 and how do you change if necessary?

    Eazy fix is working ok for me to, with Macrium as the safe outpost.
     
  2. carfal

    carfal Registered Member

    Joined:
    Dec 19, 2009
    Posts:
    173
    When you download Rollback RX and unzip the contents, you'll find a file called "setup.ini" under the "Rollback Rx Pro" Folder.

    Right click and edit this file and you'll see an option "Hybrid=1" as the default setup. This is a new feature introduced since v11.2 called "Space saving mode" (SSM). There is a new "kernel Mode" page under the "Tools" options that monitors this. Whether or not this actually saves space is something I'm not convinced of but it allows a new ability to delete the first snapshot called "Installation". This is essentially the new way to do a Baseline update and consequently the Baseline Manager page no longer exists if you setup as "Hybrid=1" . When I tested this it had a huge bug in that the newly merged "Installation" snapshot grew at least twice (if not 3 times) in size. I dont know if this has been resolved in this latest build (ending in 224) as i personally dont use this feature of RB. I always uninstall and do my maintenance.

    If you want RB installed the original way with the protected first snapshot and the "Baseline Manager" page back then change to "Hybrid=0" in the "setup.ini" file mentioned above.
     
  3. pb1

    pb1 Registered Member

    Joined:
    Apr 4, 2014
    Posts:
    571
    Location:
    sweden
    Thank you.
     
  4. pb1

    pb1 Registered Member

    Joined:
    Apr 4, 2014
    Posts:
    571
    Location:
    sweden
    By the way, are there any other interesting changes one can do in - set up.ini?
     
  5. khanyash

    khanyash Registered Member

    Joined:
    Apr 4, 2011
    Posts:
    2,149
    @carfal I have noticed one difference with the recent versions. Sometimes when I shut down the system, it restarts, Eazy Fix performs updates and shut down the system. Any info?
     
  6. carfal

    carfal Registered Member

    Joined:
    Dec 19, 2009
    Posts:
    173
    Hi Khanyash. Sorry but i cant help you there. I've never known RB to cause a restart after a shutdown. I've never used Easy Fix so i dont know anything about their updates on shutdown.

    Might be time to create a support ticket with Easy Fix. :cautious:
     
  7. khanyash

    khanyash Registered Member

    Joined:
    Apr 4, 2011
    Posts:
    2,149
    @carfal

    It could be Eazy Fix checks for snapshots corruption, etc.
    I have requested info from the Eazy Fix Support.
     
    Last edited: Apr 1, 2020
  8. carfal

    carfal Registered Member

    Joined:
    Dec 19, 2009
    Posts:
    173
    Upon reflection I think a candidate for the symptoms your describing may be the second task listed in the "Task Scheduler" as "System Maintenance". This is a new addition since build 596 (I think)

    upload_2020-4-1_14-13-1.png

    Whats probably happening is RB (or Eazyfix) will periodically perform this task by rebooting the PC on shutdown. I tried to reproduce this in a VM machine but failed to get this task to execute no matter how many snapshots i created and deleted. I think it doesnt work in a virtual enviroment.

    I personally have always deleted any tasks listed here. I like to do my own snapshots/defrags.

    FYI, below is the way i setup my system

    upload_2020-4-1_14-19-31.png
     

    Attached Files:

  9. khanyash

    khanyash Registered Member

    Joined:
    Apr 4, 2011
    Posts:
    2,149
    @carfal

    My system is old and has a few issues. It could be the reason Eazy Fix performing updates, etc.

    A few days back, I did a clean install of Win 10 version 1909. No issue yet.

    I use Eazy Fix on manual mode, no scheduled tasks, automatic tasks disabled. I manually create/delete/defrag snapshots.
     
  10. manolito

    manolito Registered Member

    Joined:
    Apr 23, 2013
    Posts:
    401
    Playing with the latest RB Rx version 11.2 I found a different behavior compared to previous versions 10.xx...

    When Rollback is active you cannot access any protected partition under WinPE or WinRE without destroying the snapshots. With earlier versions RB Rx always renamed the file "Winre.wim" in the Recovery folder to "Winre.shd" to prevent that this WIM image was used under the control of RB Rx.

    Now with version 11.2 I found that this "Winre.wim" file is no longer renamed. Is this on purpose or is it a bug? Or is it now possible to access an RB protected partition under WinRE?
     
  11. TheRollbackFrog

    TheRollbackFrog Registered Member

    Joined:
    Mar 1, 2011
    Posts:
    4,228
    Location:
    The Pond - USA
    @manolito (Mab for short), I personally believe that the recent WinRE.wim anomaly is a case of lost development info... meaning the reason they used to do it has been lost along the way. If that's the case, nobody will remember that it was ever done. I also believe, based on anecdotal reports, that HDS really has nothing to do with the development efforts anymore... maybe some testing. I believe the EAZ FIX folks have taken the lead in this effort.

    The underlying design of Rollback RX has never changed... it's still based on multiple FileSystem MetaDATA used with each of the snapshots. This MetaDATA is only accessible through the underlying Roilback RX snapshot System DataBase which is available only within the protected OS. Any external PE/RE does not have access to this underlying System... unless it's been installed during the making of the PE/RE itself. As you know, any PE/RE only has access to the baseline FileSystem when looking into a RBrx FileSystem, it cannot see the underlying multi-snapshot DataBase of other FileSystems associated with the Snapshots. As a result, any actions taken by any application based on a FileSystem will only use the baseline's FileSystem as a reference. If the PE action requires a change in the FileSystem (defrag, copy/delete/move/rename), the change will be done only to the baseline FileSystem, effectively possibly destroying any file references being made by any of the snapshot FileSystems.

    A good way to test this is to have a multiple snapshot RBrx-based partition then BOOT up any external PE/RE-based environment and write a few very large files (or lots of much smaller files) and by then the protected partition should be shreaded as far as any underlying snapshot DataBases are concerned. That operation will have most likely rewritten many disk reference blocks referred to by various snapshot FileSystems, and most likely the snapshot FileSystem itself.

    The way the newer Windows FileSystems add/extend to their existing System is a little more forgiving that it used to be, but not forgiving enough to keep the above from happening. I s'pect the same danger exists today that has always been there. Since no one has ever discussed the basic design of Rollback RX, we'll just never know without testing as described above.
     
    Last edited: Apr 2, 2020
  12. TheRollbackFrog

    TheRollbackFrog Registered Member

    Joined:
    Mar 1, 2011
    Posts:
    4,228
    Location:
    The Pond - USA
    To be fair to HDS and EAX Solutions, I should actually retest the above scenario since I haven't done that in many years. If I do, I'll letcha know what I come up with.
     
  13. TheRollbackFrog

    TheRollbackFrog Registered Member

    Joined:
    Mar 1, 2011
    Posts:
    4,228
    Location:
    The Pond - USA
    I now stand corrected. Indeed a change has been made to Rollback RX (when, I don't know). The FileSystem of a RBrx prepared partition set now looks unrecognizable to any PE/RE-based external System... therefore it cannot make any changes to those partitions. If you wish to modify those protected partitions, they must be completely formatted first before use.

    I guess this is one way of keeping damage from occurring by using external Windows/Linux Systems which are looking for known FileSystems.

    Based on my testing, I would say it is on purpose (for external protection reasons). This allows a user to now use the "standard" WIM for other purposes other than doing anything to the RBrx partitions. Maybe they even modified that WIM to allow it access to the protected partitions (I doubt it). Not worth it to me to test that last hypothesis.
     
  14. TheRollbackFrog

    TheRollbackFrog Registered Member

    Joined:
    Mar 1, 2011
    Posts:
    4,228
    Location:
    The Pond - USA
    OK, that's it for this year :argh:

    I just tried accessing the RBrx protected FileSystem thru the included WinRE.wim recovery media. That turned out to be a standard recovery media and even using the COMMAND PROMPT environment of that media, the RE environment finds an unrecognizable FileSystem on the protected partition... same as an external PE environment found.

    I'll wait for v12 to play some more :rolleyes: ...and I will update, shortly, the "Rollback RX - unOfishul FAQ" to reflect those findings so as not to scare too many people from possibly using the application (not me, though :eek: ).
     
    Last edited: Apr 2, 2020
  15. carfal

    carfal Registered Member

    Joined:
    Dec 19, 2009
    Posts:
    173
    Thanks for all your testing TRF. You are always keen to go that extra mile.:thumb:

    Mab...TRF pretty much confirmed your observation (one that even i didnt know had changed. I dont really have any reason to go there unless Im restoring a full image using MR).

    However, in regards to renaming the "Winre.wim" file, it was my understanding that this was done to break the F8 boot time recovery of Windows at startup. It probably was reasoned that this would reduce the number of PC's that would suffer unrecoverable data because the "Fix MBR" option could be run from here and as we all know this is a sure fire way of completely losing all snapshots with no chance of file recovery (as low as it was anyway). It was a way of forcing people to ask for help before they damaged their system irreversibly. Who knows if this helped save anyone as there are many other ways around this, the very least being that renaming "Winre.wim" restored the F8 function.

    In light of you and TRF testing, the protected drives are now "encrypted" and not visible to any RE enviroment or most likely external access (by plugging the drive into a non RB PC) hence the renaming of "Winre.wim" is no longer necessary.

    EDIT: Still no corruption in sight:D:D
     
  16. manolito

    manolito Registered Member

    Joined:
    Apr 23, 2013
    Posts:
    401
    Thank you so much Froggy for testing...

    I found another possible change in how the MBR is treated when restoring an external image. I normally make images with Acronis or Macrium under the control of RB Rx. This means that the actual state will be imaged, all snapshots are lost. After restoring such an image from the recovery CD the MBR needs to be fixed before booting the system. One way to do this is to boot from the Windows installation disk, go to the console and execute 3 Bootrec commands. This method still works.

    But when I made my image with Macrium, I used to be able to fix the MBR using the tool from the Macrium rescue disk. This method now fails with the latest v. 11.2 of RB Rx. IIRC the latest v. 10.7 build had no problem doing it this way. Please note that I always wipe the HDD sectors which contain the MBR before restoring the image backup.

    Not a big deal, but this Macrium feature to fix boot problems using the recovery CD was one of the reasons to use Macrium at all. If I cannot get this working I will probably revert to the old and reliable Acronis TIH 11.
     
  17. carfal

    carfal Registered Member

    Joined:
    Dec 19, 2009
    Posts:
    173
    You can avoid all of this MBR issue by uninstalling RB first (which will restore the original MBR. Dont forget to reboot). Then restore any image you like but importantly, you must not restore the MBR from the image (if it was taken with RB active). You'll have to go into the MR settings (RESTORE>MASTER BOOT RECORD) and select "Do not restore".

    This has always restored a bootable working drive, everytime, for me. No MBR fixes necessary. But I'll admit that i havent tried it since since these last 2 builds as they haven't corrupted my drive....yet. :isay:

    EDIT: If RB has corrupted snapshots, it doesnt really matter if you uninstall to these as the restored MR image will fix all of this. The point of this excercise is to get RB to restore the original working MBR.

    EDIT2: Let me also add that if you only have corrupted snapshots to choose from then pick one that will at least boot back into windows so that you can be certain that the original MBR is restored. If every snapshot hangs at boot then the only option is a total HD and/or MBR wipe, as you've already have stated.
     
    Last edited: Apr 3, 2020
  18. TheRollbackFrog

    TheRollbackFrog Registered Member

    Joined:
    Mar 1, 2011
    Posts:
    4,228
    Location:
    The Pond - USA
    @manolito

    With RBrx v9, the pre-installation MBR was always supplied with a LIVE image being taken under RBrx... alas, restoring & BOOTing from those images always worked, albeit supplying a dead RBrx System as a result.

    With v10 things changed and now LIVE imaging of a RBrx System produced the RBrx malformed MBR along with the image. Upon restoration, these images had to have their MBR "tweaked" to make them BOOTable once again (as you described above).

    With v11, they took a step backward to v9 as far as the MBR was concerned and now supply a pre-install copy of the MBR which allows any LIVE image taken from an active RBrx System to be BOOTable... without tweaking. I've never had to tweak an MBR following the restoration of a LIVE imaged RBrx v11 System. Of course the results of those image restorations haven't changed... an actively protected RBrx image BOOTs fine but has a broken RBrx available for (non-)use. If the new v11 de-Activation feature is used prior to imaging, the resultant LIVE image BOOTs just fine back into a deActivated RBrx, requiring reActivation once again before snapshoting may begin.

    I can't explain the "FIX failure" you describe above... but if you were using RBrx v11 when the image was taken, it shouldn't even need a FIX at all. What you describe is unusual.
     
  19. TheRollbackFrog

    TheRollbackFrog Registered Member

    Joined:
    Mar 1, 2011
    Posts:
    4,228
    Location:
    The Pond - USA
    PS- do you get some sort of error from the FIX BOOT when using Macrium?
     
  20. TheRollbackFrog

    TheRollbackFrog Registered Member

    Joined:
    Mar 1, 2011
    Posts:
    4,228
    Location:
    The Pond - USA
    ...and one more l'il tidbit. Since my disk was built with a 1mB partition boundaries, and I forgot to ZERO out any MBR/EMBR areas when I did my test above... this time I ZEROed out the 1st 2048 (0-2047) sectors of the disk before restoring an RBrx-active LIVE Macrium backup image. As expected, without doing any MBR repair, the restored image BOOTed just fine with a broken RBrx just waiting to be used. Restoring a RBrx deActivated but still installed image produced the same results with RBrx intact but needing to be reActivated.

    As I've always experienced, RBrx v11 Macrium images have always been BOOTable without MBR diddling.
     
  21. manolito

    manolito Registered Member

    Joined:
    Apr 23, 2013
    Posts:
    401
    This would have been nice, but unfortunately I cannot confirm your findings on my system.

    My system:
    Win7-64, MBR formatted HDD, no UEFI, no GPT. 3 partitions (C: and D: NTFS, E: FAT32)
    Latest RB Rx 11.2
    Image Backups taken with Acronis TIH 11 (yes 11, not 2011) or latest Macrium 6.3 build
    Restoring images with Acronis Linux based rescue disk 2019 or with Macrium 6.3
    Always wiped out the first sector (512 bytes, this sector holds the MBR information) before making a restore.

    Under RB Rx 9.1 no problems, the HDD was always bootable after a restore.
    Under RB Rx 10.xx the HDD was never bootable, an MBR fix was always required.
    Under RB Rx 11.2 the situation is not at all identical to v. 9.1. After restoring an Acronis image, I get the Rollback console window telling me that Windows was shut down unexpectedly and a check needed to be done. This check would hang at 66%.
    Restoring a Macrium image I also got the unexpected shutdown warning, but this time the check would finish. But when booting into Windows ChkDsk was triggered and it repaired tons of errors. Windows did boot finally, but I would never trust it.

    This method did make a difference. But I fail to see why this should be required. The whole idea of an image backup is to restore exactly this image no matter what is on this HDD at the time of restoration. Wiping only the first sector or the first 2048 sectors before restoring the image should not make any difference.

    Sorry, it is different for me. For restoring hot images taken under the control of RB Rx 11.2 for me the only reliable way to avoid boot issues is still fixing the MBR after restoring the image, either using the Windows installation disk, or restoring a previously saved MBR (BootICE or similar).
     
    Last edited: Apr 5, 2020
  22. TheRollbackFrog

    TheRollbackFrog Registered Member

    Joined:
    Mar 1, 2011
    Posts:
    4,228
    Location:
    The Pond - USA
    :oops: Mab, on my knees I humble myself at your feet... a boob I am.

    While running through all the machinations needed to make my statement above, all my results were derived from a W10 installation. Tonight I reran everything under W07 and my results were almost the same as yours. Your ChkDisk hang at 66% did not occur on my System (you may have a disk issue on that System) and following the successful ChkDisk run the System BOOTed into W07, albeit broken as we all know.

    Looking at the bits and bytes, Macrium is restoring all that it was given when it imaged, every disk block in use as well as the MBR and Track 0 (in either a 63-block config or a 2048-block config). RBrx appears to be doing exactly as it did in v10 by allowing Macrium to image it's bastardized MBR. The reason FIX BOOT no longer works is because the RBrx protected Windows partition is indeed encrypted in v11 (it wasn't really encrypted under v10) and FIX BOOT cannot see any sort of Windows System on that partition to repair. As you stated, BOOTice or some other MBR writing function is the only way to return to a BOOTable volume if that ChkDisk process hangs.

    Sorry for my misleading statements above... I'll try harder next time. (what's the Wilders emoticon for "boob?")
     
  23. khanyash

    khanyash Registered Member

    Joined:
    Apr 4, 2011
    Posts:
    2,149
    There was an option under settings & manual snapshot creation, refresh cache or something, have they removed it?
     
  24. khanyash

    khanyash Registered Member

    Joined:
    Apr 4, 2011
    Posts:
    2,149
    @TheRollbackFrog

    I'm using a system maintenance utility on Win 10. It has 2 options to optimize the system. Does these optimizations affect Eazy Fix/Rollback Rx?

    1. Windows Boot Optimization Function - Loading of the operating system can be accelerated by using defragmentation at startup.

    2. Disabling outdated table of MS-DOS files format - Table of MS-DOS files format reduces system performance and can be disabled.
     
  25. TheRollbackFrog

    TheRollbackFrog Registered Member

    Joined:
    Mar 1, 2011
    Posts:
    4,228
    Location:
    The Pond - USA
    At one point along the RBrx timeline, defragmentation operations were disabled by the app... I don't think it does that anymore. BUT... any change in the location of disk surface blocks (and defrag operations definitely cause that) will create large follow-on snapshots. Why? Because that's what RBrx does for a living... it constantly monitors disk surface block utilization in order to establish changes needed to be reflected in its snapshots. It doesn't work at the FileSystem level.

    The other thing you should know is that RBrx uses whats called a REDIRECT-ON-WRITE philosophy in establishing locations for new versions of DATA (disk blocks) while leaving the old versions in their original place (no copying or "saving" involved). This operation, in itself, will heavily fragment a RBrx protected volume over time... and there's no way to change that. That's why savvy users of this type of protection will be willing to give up their current snapshots occasionally, deActivate (or uninstall) RBrx, reBOOT their System to its current state, then perform all needed System maintenance functions while RBrx is absent. Most users who do this will completely defrag their entire System as well as take an image of that System for disaster recovery purposes (blown disk, etc.). Also any needed partition changes are done at this time. They then reInstall or reActivate/reBOOT RBrx and go on their merry way.

    To summarize, although #1 above would not hurt your System, it really provides very little, is any, real optimization for the System and creates unneeded snapshot storage on your volume. #2 above is innocuous and won't bother much of anything.
     
  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.