Rollback RX - PROPOSED KnowledgeBase article

Discussion in 'backup, imaging & disk mgmt' started by TheRollbackFrog, Apr 1, 2015.

Thread Status:
Not open for further replies.
  1. TheRollbackFrog

    TheRollbackFrog Imaging Specialist

    Joined:
    Mar 1, 2011
    Posts:
    4,945
    Location:
    The Pond - USA
    Thanks for the suggestion. I will incorporate it at the next update.

    I'm still looking for input, folks... is there anything else I need to know about Rollback RX (as if what's there isn't enough :)) other than what you've read in the lead POST?
     
  2. manolito

    manolito Registered Member

    Joined:
    Apr 23, 2013
    Posts:
    407
    Hi Froggie,

    your proposed KB article is perfect IMO, as a longtime RBrx user I do not see any additional warnings that should be added. Great work...

    I have been following the recent exchanges between Kurtis and some users who have been bitten by RBrx in the past, and my conclusion might be interesting:

    I tend to divide users into 3 different categories:

    1. Users who only have very basic computer skills, and who are aware of it.

    2. Users who are skilled and curious, and who feel the need to understand the inner workings and underlying concepts of the stuff they use.

    3. Users who have this "Dangerous Half Knowledge", and a good part of Wildes members fall into this category.


    I believe that only the users in the third category are the ones for whom software like RBrx is dangerous. Users from the first category would never ever consider to use any software you mention in your KB article. (With the exception of automatic Windows updates).

    Users from the second category (you and hopefully me) will know about the inner workings and limitations of RBrx, and in most cases they will have the right methods to recover from a software failure.

    All the Rollback horror stories here at Wilders are from users who are quite naive IMO. They blindly believe all the advertising hype, they have no idea how the software works, but they are not shy enough to refrain from potentially dangerous actions. Your proposed KB article should educate these users, and I really hope that the HDS marketing department will not try to block your effort.


    Thanks a lot for your work on this...


    Cheers
    manolito
     
  3. TheRollbackFrog

    TheRollbackFrog Imaging Specialist

    Joined:
    Mar 1, 2011
    Posts:
    4,945
    Location:
    The Pond - USA
    Thanks, Mab... appreciate the support.

    I guess what got me into this was all the people that wind up here at Wilders with unbelievable horror stories about their loss of important data... that and the 10s of non-Wilders users I've dealt with directly that have had corruptions or accidental explosions. Maybe I'm just getting tired :doubt:

    If anything in the article being created can help anyone from falling into the documented traps... it's really gotta help us all, especially the RBrx current and potential users.
     
  4. bgoodman4

    bgoodman4 Registered Member

    Joined:
    Jan 13, 2009
    Posts:
    3,237
    The only thing I can think of that you might want to add is that since the snaps (and Rx) reside on the protected drive if there is a drive failure you are out of luck. Emphasis that the only way to get beyond this would be to reformat reinstall or (hopefully) have an image of the drive (and mbr) that you can use to restore.
     
  5. TheRollbackFrog

    TheRollbackFrog Imaging Specialist

    Joined:
    Mar 1, 2011
    Posts:
    4,945
    Location:
    The Pond - USA
    This piece will not attempt to document "solutions" to experienced problems, but I will add your concern (I forgot all about it) about device failure on a Rollback-enabled system... thanks for the reminder, BG!
     
  6. NCP

    NCP Registered Member

    Joined:
    Mar 18, 2015
    Posts:
    22
    Nice job, Froggie. Hopefully it will spare others from much unnecesary grief.
     
  7. TheRollbackFrog

    TheRollbackFrog Imaging Specialist

    Joined:
    Mar 1, 2011
    Posts:
    4,945
    Location:
    The Pond - USA
    Lead ARTICLE updated to include clarifications, better description and new section on Catastrophic Storage Device Failure.
     
  8. bgoodman4

    bgoodman4 Registered Member

    Joined:
    Jan 13, 2009
    Posts:
    3,237
    Nice update Mr Frog,,,,you are doing a heck of a job for the folks at HDS who will be designing the marketing for DC. Given what has been said elsewhere they were not even able to conceive of a situation where Rx could not get the user out of trouble,,,,now you have provided a concise list of these situations and HDS staff will be able to use it to promote DC. They should compensate you for the valuable service you have provided.
     
  9. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    You are assuming they get DC to work right
     
  10. bgoodman4

    bgoodman4 Registered Member

    Joined:
    Jan 13, 2009
    Posts:
    3,237
    You have a point there
     
    Last edited: Apr 5, 2015
  11. Keatah

    Keatah Registered Member

    Joined:
    Jan 13, 2011
    Posts:
    1,029

    Well what happens if snapshot 1 has this version of Office on it.
    And snapshot 2 has that version of Office on it.
    And yet a 3rd snapshot with a failed and buggy beta version of Office.

    Do you un-install RBRX and somehow combine all three versions into one? Can't do that. You have to pick which one you want!

    Think of "un-installing to" an activity that gives you back your system the way it started out. Or the removal of a tool that presents different configurations to you. In parting ways, when you remove RBRX, you have a choice how the place looks. What do YOU want it to look like when you leave?
     
  12. jwcca

    jwcca Registered Member

    Joined:
    Dec 6, 2003
    Posts:
    772
    Location:
    Toronto
    Well I don't have RBRX so I have no hands on experience but it depends on where my base starts (date) and the number of snaps.
    I'll use your example but with slightly different numbers where they're snap 141, 145 and 157 rather than 1, 2 and 3, and where my highest snap is 163 which is the one where I first discovered that the Office introduced in 157 was buggy.

    From what I've read, I'd tick the one with the version of Office that I wanted to keep. In this, my example, it's snap 156 because, if I hadn't liked the version of office introduced in 145, I would have reverted to 144 "way back then".
    Any snap after 156 (e.g. 157-163) would be 'lost', and therefore the first Office introduced in snap 141 and the buggy Office introduced in snap 157 would be, as you say, 'uninstalled'.

    That's assuming that I'd kept a record of the snap in which things were first installed and knew that 157 was the 'bad' one. Otherwise I'd have to revert, snap by snap without uninstalling the program, starting with 162 working backwards until I found that the buggy Office was 'uninstalled' by reverting to 156.

    I could then uninstall the RBRX program, selecting snap 156 (the last one at this point) and I'd end up with the consolidation of the base plus the 156 snaps as my new non-RBRX drive C:.
    I could then re-install RBRX or leave it uninstalled.
    (And I would have copied all my data in snap 163 to somewhere else before doing any 'reverting/uninstalling' so that I wouldn't lose my data added or changed after snap 156 (if I'd been foolish enough to keep data with the OS and didn't have a backup copy somewhere else. )

    But, I personally would never let the number of snaps get so high (my example).
    I'd install RBRX (after buying it), which starts a new base, I'd do a bit of 'stuff', maybe have a few snaps, possibly revert to one once in a while, and then, on a 'regular schedule' I'd uninstall to consolidate and either never use RBRX again -or- I'd re-install to create a new base so a base would never be really really old. And if, in this example, that meant that the base included the 'wonky' Office, I'd have to re-install the 'good' Office over top.

    But that's just me, obviously others have done things differently as we've read here on Wilders.

    I don't install more than a couple of things per day.
    I first make a back up, then install, then I wait to see if problems develop.
    If they do develop, I revert and test them one at a time, etc. etc. etc.
    If not then I still make a back up of the 'good' system on my regular weekly schedule.

    And my Data is kept on a second physical drive and it's also backed up on a third physical drive.
     
  13. Keatah

    Keatah Registered Member

    Joined:
    Jan 13, 2011
    Posts:
    1,029
    You don't have to un-install and re-install to create a new base. You can just update the baseline to the snapshot you're running now.
     
  14. jwcca

    jwcca Registered Member

    Joined:
    Dec 6, 2003
    Posts:
    772
    Location:
    Toronto
    OK, got it, I'd install something, wait to see if it's OK (as in test thoroughly) and after a few days create a new base or roll back.
     
  15. Keatah

    Keatah Registered Member

    Joined:
    Jan 13, 2011
    Posts:
    1,029
    Be aware doing that erases all snaps.
     
  16. jwcca

    jwcca Registered Member

    Joined:
    Dec 6, 2003
    Posts:
    772
    Location:
    Toronto
    OK, got it, I'd install something, wait to see if it's OK (as in test thoroughly) and after a few days update the baseline or roll back.
    Semantics... but thanks.
     
  17. taotoo

    taotoo Registered Member

    Joined:
    Mar 13, 2013
    Posts:
    459
    Can Rx be set to have a rolling baseline - e.g. take hourly snaps and have the baseline always be 3 days old?
     
  18. Kurtis Smejkal

    Kurtis Smejkal Registered Member

    Joined:
    Mar 17, 2015
    Posts:
    253
    Location:
    Vancouver, BC
    Under 'Tools and Settings' you can click 'Baseline Manager' and update your baseline.
     
  19. Kurtis Smejkal

    Kurtis Smejkal Registered Member

    Joined:
    Mar 17, 2015
    Posts:
    253
    Location:
    Vancouver, BC
    No. The reason being that if Microsoft ever were to release an update, or say you install software that conflicts with ours, that could cause problems. We have to give users the ability to consciously decide whether they want to update that baseline or not. As someone who works on the other end, I hear horror stories of people updating their baseline not knowing of the consequences and it doesn't end well :p

    That being said, there's always a possibility down the road that we could find a safe way to do this. Not too sure how as I'm more of a Community Manager then Developer, but I'll pass your feedback forward!

    Cheers,
     
  20. taotoo

    taotoo Registered Member

    Joined:
    Mar 13, 2013
    Posts:
    459
    Thanks for the reply Kurtis - so can the baseline be reset to a snapshot of the user's choice, or can it only be reset to the most recent snapshot or current system state?
     
  21. Keatah

    Keatah Registered Member

    Joined:
    Jan 13, 2011
    Posts:
    1,029
    I know in the .PDF manual and the .CHM helpfile of RBRX it says that "Updating baseline will consolidate all the existing snapshots into the new baseline." That sentence directly tells me that data scattered amongst different snapshots will all be combined into one snapshot.

    Snap1 has V1 of ProgramX
    Snap2 has V2 of ProgramX
    Snap3 has V3 of ProgramX
    Snap4 has V4 of ProgramX
    Snap5 doesn't have ProgramX installed, instead it has some photos from my recent safari.
    Snap6 has 5 hours worth of development material. V3 of ProgramX, and no safari photos.

    So when you consolidate, somehow, you will expect that data from all 6 snapshots is brought together in harmony. Magically! Some of us know RBRX doesn't work that way. But not everyone - in fact it is totally mis-leading and a neophyte will assume the consolidated baseline will have:

    V1-4 of ProgramX
    The safari photos
    The 5 hours of development material

    In reality, the new consolidated baseline is whatever snapshot you choose. If you pick Snap3, then your system now only has V3 of ProgramX. All other versions, the dev work, the photos.. All gone.

    Consolidate = combine (a number of things) into a single more effective or coherent whole.

    Maybe we're arguing semantics, but when I first used RBRX (around the version 9 timeframe) I had to do a double-take and a verification experiment to reconcile the differences between what actually happens vs. what the documentation says. This behavior is not a good thing or bad thing. It is what it is. The discrepancy between what is said and what actually happens is a bad thing!

    Overall I think the help file and the pdf should be updated to explain this better. I'm not trying to rag on RBRX, but to make it one step better. The devil is in the details as they say.

    http://horizondatasys.com/files/downloads/RollBack_Rx_Pro_User_Guide.pdf
     
    Last edited: Apr 6, 2015
  22. manolito

    manolito Registered Member

    Joined:
    Apr 23, 2013
    Posts:
    407
    It is even worse...
    In the baseline manager you cannot pick a specific snapshot to "consolidate" to. You either reset the baseline to the time of Rollback Installation, or you update the baseline to the current state. If you want to update the baseline to a different snapshot, you first have to restore your computer to the desired snapshot and then update the baseline.

    For me this is a prime example how the HDS development team and the support team have no idea what the other department does. Sometimes you even get the impression that the support team has no clue how the software actually works.

    In the case of baseline management the term "consolidate" has no room whatsoever. There is no consolidation of different snapshots. Period. You either get the baseline at the time Rollback was installed, or you get your current system state. Nothing in between.

    Maybe Kurtis should lobby for updating the user guide...


    Cheers
    manolito
     
  23. TheRollbackFrog

    TheRollbackFrog Imaging Specialist

    Joined:
    Mar 1, 2011
    Posts:
    4,945
    Location:
    The Pond - USA
    Taotoo, it would be a 2-step process. First you would "rollback" to the snapshot you wish to re-baseline to, then you would perform the re-baselining of the system. When you do this, all snapshots after the point selected for re-baselining would be gone and all snapshots prior to the point selected would be merged into the new baseline.
     
  24. Keatah

    Keatah Registered Member

    Joined:
    Jan 13, 2011
    Posts:
    1,029
    Careful there.

    By that logic, and my example..
    Snap1 with V1 of ProgramX
    Snap2 with V2 of ProgramX
    Snap3 with V3 of ProgramX
    ..would then be incorporated magically into the new baseline. Clearly RBRX cannot do such a thing. V1 and V2 would be lost if you restore or un-install to Snap3.

    Also by that logic, deleting Snap3 would kill V1 and V2 of Program. Clearly this does not happen.

    When you set your new baseline to Snap3 - RBRX may take bits and pieces from previous snapshots internally, if they are a part of Snap3. But the user will only see what is in Snap3.

    Keep in mind that from the user's point of view each Snap is independent of each other.
     
    Last edited: Apr 6, 2015
  25. manolito

    manolito Registered Member

    Joined:
    Apr 23, 2013
    Posts:
    407
    IMO this is wrong. (Maybe semantics...) The new baseline would consist of the current state. Internally this would of course consist of files which are stored in previous snapshots, but this is totally transparent to the user. If you delete a file in your current state which has been there in your previous snapshot, then after updating the baseline this file will not be there, it will not have been merged into your new baseline.


    Cheers
    manolito
     
Thread Status:
Not open for further replies.
  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.