Announcement

Collapse
No announcement yet.

Suggestion for a more convenient uninstall&reinstall procedure

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Suggestion for a more convenient uninstall&reinstall procedure

    Hi,

    After gathering as much information about Rollback Rx as I could, I came to realize that i would be one of the users that would occasionally have to uninstall and reinstall Rollback (in order to access the HDDs from external bootable media, send an occasional TRIM), just as suggested by Horizon DataSys.

    What would make the procedure much easier is an option, preferably both in the sub-console menu and the front-end in Windows, that would allow users to fully disable Rollback, but keep the sub-console and program files and registry entries of Rollback as they were.

    That way, there would be no need to keep the Installer file around, and the overall process of doing maintenance work would be more streamlined and quicker. Of course, this implies an option to re-activate Rollback Rx from the sub-console, or the whole procedure would be pointless.

  • #2
    This has been raised in the past and because of the way RB redirects all changes and keeps track of all this it's simply not possible to "deactivate" RB and then activate it. Windows is simply in the dark as to where RB has redirected data and will ultimately end in disaster.

    Comment


    • #3
      I uninstall RollbackRX weekly so that I can defrag my drive and make a backup image using Macrium Reflect. The best I have come up with is to uninstall to Current System, do my maintenance, then reinstall using the unattended install method. If I am doing an incremental backup the entire procedure takes me about 1/2 hour to 45 minutes tops. Not having to specify the options during reinstall removes most of the frustration. Granted I have to keep the installer folder but with HD sizes these days so what?

      Comment


      • #4
        Just so you know, I use Macrium Reflect as well but I don't uninstall RB when I want to take an image. I just do my full/incremental/differential like normal. MR will image the current system state (minus the snapshots of coarse) just fine.

        However, if you do have to restore an MR image, make sure RB is uninstalled so that the MBR is without RB subconsole. Make sure in advanced options in MR that the Replace MBR is set to "Do not replace". That's it..... a perfect restore every time should the need arise.

        Comment


        • #5
          I remove RollbackRX because I defrag the drive as part of the maintenance. Plus I only use one snapshot. In between Macrium images if I install new software, once I see I am going to keep the software, I update the baseline. If I have to restore the baseline I do not make a snapshot(uncheck the option) so that there aren't a bunch of snapshots flying around to get confused.

          But my needs are slightly different since this open box machine will not even properly run a restore point. That is why I bought RollbackRX. A way to quickly undo something without restoring a backup image.

          Edit: Having read your last response again I wonder how you will uninstall RollbackRX if your system is hosed? Seems like disaster recovery would be more successful if you uninstalled Rollback before making the image, then restored with the Replace MBR option enabled in that case.

          I have Windows 8.0 with GPT so I am not quite sure how the MBR replacement bit works in that scenario. I used to do a lot of multi-boot back in the old MBR days. Dos, Windows, OS/2 and Linux all on the same system. But now I only have a Laptop to work with and don't want to get into that stuff again especially with this new fangled GPT stuff to learn. Too risky when you only have one machine.
          Last edited by MilesAhead; 04-05-2017, 10:14 AM.

          Comment


          • #6
            Originally posted by MilesAhead View Post
            I uninstall RollbackRX weekly so that I can defrag my drive and make a backup image using Macrium Reflect. The best I have come up with is to uninstall to Current System, do my maintenance, then reinstall using the unattended install method. If I am doing an incremental backup the entire procedure takes me about 1/2 hour to 45 minutes tops. Not having to specify the options during reinstall removes most of the frustration. Granted I have to keep the installer folder but with HD sizes these days so what?
            The unattended installation method is something I didn't think of, and it seems like a viable workaround to me.

            Even though I wouldn't need to uninstall&reinstall Rollback Rx even closely as often as you do, I still see some benefits if what I suggested could be implemented.

            In your case, the procedure would be as follows:

            1. Deactivate Rollback from the sub-console (All snapshots except the one you choose are lost and the Rollback driver simply idly passes real I/O traffic to Windows, allowing it to access the "real" MFT.

            2. You do your maintenance in Windows, defrag, make a disk image, or in my case, send a TRIM and wait a while until wear leveling and garbage collection have done their thing on the SSD.

            3. In the Rollback GUI in Windows, you select something like "Activate Rollback and set new Baseline on next Reboot", which would do exactly that.

            I'm not sure, but I believe that such an option that would quickly grant occasional access to the real system would be beneficial for many users, including potential ones, especially after they learn more about the inner workings of Rollback Rx.

            Comment


            • #7
              I don't know exactly how RollbackRX is implemented but my guess would be there is some kind of "diff" mechanism to minimize the storage size of the snapshots. If you pass through changes to the "real system" without tracking them then you lose the reference point to calculate the difference between the current state of the partition and the snapshot. I keep my C: partition as close as I can to 30% used. This makes defrags and other operations like image saving quick. It only takes a few minutes to uninstall Rollback. I reboot and run CCleaner just to make sure all the temp files and leftover snapshot stuff is deleted before saving the Macrium image. Then I defrag using the last version of Vopt. If the partition used space is at a higher level then naturally all these operations would take more time at each step.

              What you are describing seems more likely to be available on a "time machine" type of system saver. I used a freeware one that worked fairly well. But they use VSS to redirect system changes to a file. Even if the file is fairly large and defragmented when you change lots of data performance tends to suffer. If changes are few the "time machine" type of utility may work in your scenario.

              Comment


              • #8
                I've used Time Machine tools before, and yes, you're right, what I'm suggesting would come close to such a tool with "autorun on boot" disabled. Rollback Rx is completely different, of course (and its approach is, at least to my understanding, more secure), but there are drawbacks that make me wish to have something like an "Autostart" checkbox in Rollback.

                Now, i do not know if my driver pass-through suggestion can be easily implemented, after all, it seems that it would amount to a "uninstalled but not really uninstalled" scenario where the driver would have to NOT track the changes to the filesystem until you tell it otherwise. The way I understand it, RollbackRx must have an internal table of all sectors on the HDD, including information which snapshot(s) the contents of each sector belong to, or that they're really empty. As you use the OS, that information needs to be constantly updated with every write operation. Now, the fact that RollbackRx can be really uninstalled and successfully reinstalled is proof that it's possible to suspend that process. The only difference with my suggestion would be that users would not have to re-write the MBR and sub-console every single time, but that the internal tracking system would be temporarily stopped and the sector tables (or whatever this system is called by the techs ) would ignored or wiped, until a new baseline is established. Now, the fact the such a feature is not already implemented could either mean that it's really much harder to implement than I think it is, or that it's really 10 lines of code, but the developers didn't think users need such a feature.

                Well, maybe we don't really NEED it, but IMHO it would be a really cool thing to have

                Comment


                • #9
                  The only way I could see that it might work would be when disabled, Rollback would be dormant. Then on enabling a snapshot would have to be taken immediately. Of course we don't know what else has to happen underneath the covers. It may watch for anything trying to alter the snapshot files and prevent it etc..

                  In any case it is fun to speculate.

                  Comment


                  • #10
                    Or maybe we would have to accept that the snapshots are lost with such a function, and re-enabling would mean creating a new baseline. That would be okay with me, and likely for you too, based on the way you said you use RollbackRx.

                    I wonder what's easier to implement, a "deactivate" function or having the driver intercept TRIM commands of Windows and then re-sending it to the SSD with sectors that are truly empty.

                    If it's the former, maybe Sam could show this thread to the techs. Also, this would address the defrag issue for spinning-platter HDDs and both Froggie and Horizon Datasys could update their FAQ.



                    Originally posted by MilesAhead View Post
                    The only way I could see that it might work would be when disabled, Rollback would be dormant. Then on enabling a snapshot would have to be taken immediately. Of course we don't know what else has to happen underneath the covers. It may watch for anything trying to alter the snapshot files and prevent it etc..

                    In any case it is fun to speculate.

                    Comment


                    • #11
                      I'm just trying out the new v10.7 build 2702518295 version, and....


                      ....the features suggested in this thread seem to be implemented, yay!

                      With the protection turned off in the tray, there's no subconsole during boot, and re-activation protection requires reboot (even though disabling protection apparently does not)...in other words, it seems like this is exactly like an equivalent to a full uninstall&reinstall.

                      But before I sing songs of praise about the folks at Horizon Datasys, I need to make sure that it's the real thing

                      So my question to support would be whether with protection turned off, windows now has full access to the disk, like in an truly "uninstalled Rollback" scenario, meaning that it's safe to defrag, TRIM, mount the disk from external bootable media and all the stuff that would be a big no-no with Rollback Installed&Active?

                      Comment


                      • #12
                        Tested: although it appears the deActivated Rollback RX does allow these things to occur, the low-level driver that is disabling TRIM does not get removed from the system and replaced with the standard driver until a reBOOT is performed, even though a reBOOT is not required to do things following the deActivation, only on the reActivation.

                        Another user has stated that the special RBrx MBR does get removed (and replaced with the original) following deActivation so that standard System imaging may occur without needing the special effort following an image restoration taken from an active Rollback System.
                        Last edited by Froggie; 05-29-2017, 05:53 AM.

                        Comment


                        • #13
                          Although I have not tested an image restore based on the 2nd paragraph above, knowing what's going on during the process, it appears that if you image a deActivated RBrx System following a reBOOT, that upon restoration of that image, your System should be in tact with a deActivated RBrx installed. If you reActivate RBrx in that image, all should come back just fine as far as RBrx is concerned... no unintended uninstall/reInstall required.

                          If I get a chance, I'll test this later in the day...

                          Comment


                          • #14
                            Wow, that was quick Froggie, thanks

                            Okay, so no immediate TRIMming (but at least it works without full uninstall, a big plus in my book.). Accessing from external bootable media requires a reboot anyway, but what about users who need to defrag regularly ("MilesAhead" comes to mind )? Do the files really get moved around on the disk without reboot?

                            Comment


                            • #15
                              I don't personally know where all the write/redirecting is going on under Rollback, but once the MBR has been replaced and the low level driver replaced upon reBOOT, the System should be back to almost normal as far as the storage devices are concerned... and at this point a normal defrag should be occurring. It will be a healthy one following the deActivation of a System with a lot of snapshots on it.

                              Comment

                              Working...
                              X