I read on their website about 8 hours ago, they have pulled v10.2 due to corruption, something like not currently available. http://www.horizondatasys-forum.com.../240-rollback-rx-10-2-currently-not-available Best regards,
Sorry to hear that Marc. Glad that you have managed to recover...obvioulsy a well layered approach. Regards, Balders
Hi Mohamed The post from HDS seems a little lame given what MarcP has reported. You would have thought that they might try contact all v10.2 license holders (they should know who they are given that v10.2 requires a new license key) to warn them of the issue in case they have recently downloaded from the site. Unsatisfactory, to say the least...and that is probably being far too polite. Thanks for sharing. Regards, Balders
The post seems to be more about the download being corrupted since they speak of the webhost doing checksum verification. But someone else reported blue screens on their forums too.
Hi Mark, good to hear you were able to recover. I gave up on RX quite some time ago and you have confirmed that this was a wise decision. I would suggest that you begin a new thread regarding this problem so folks can see that there is a serious issue with the latest release of RX before they find out the hard way. I suspect only old time RX users are watching this thread. Also, a note in the AX64 thread might be called for as well since the daily snaps saved you.
Honestly, I want to put RBX behind me. I posted snapshots on the HDS forums to show that this happened for real. I should've known better, but I really wanted to give RBX a fair shot after they gave me a free license. The burn still stings to this day. What is really really nasty to a whole new level is that even if you image while RBX is running, your images will be corrupted. You think you have multi-layers of protection, but RBX is crapping all over it. That is a whole new dimension of danger. You are not safe with Rollback RX 10.2!!! And on the HDS forums, I'm not the only one who posted about blue screens. AX64 saved me though because I had a good image minutes before I installed RBX and only then the restore worked. If anything, AX64 is what proved to be THE life saver. Sometimes I like to live on the bleeding edge, but when your safety nets are also being burned down, screw it. Not worth it. AX64 Time Machine is what works.
MarcP, I've just downloaded the version using the link that Iceman posted (internal files dated 17-08-2013) on the HDS forums and have spent the last 3 hrs testing it vigorously. They have fixed the issues that i reported (so far) and it seems really stable. My system is W7 x64 so i cant speak for a W8 system ( I cant remember if yours is W8 ). I know that you want to put RB behind you but i thought that it could be worth one more go. Everyone here should remember that RB v10.2 code had to be rewritten from scratch (HDS's words not mine) so perhaps some slack is in order. I know that they probably dont deserve it so everyone can decide for themselves. My intention is not to inflame anyone. Also during that 3 hrs i threw in AX64 restores and everything seems to work like the previous RB v10. No corruptions anywhere. Again my system is W7x64. I would like to say that whenever i did a rollback with RBrx and would then want to test AX64, I would always do a "test" backup first with AX64 so that the tracking file is synced then i would do numerous restores with AX64 consecutively and it always restored flawlessly. I even took a snapshot with RB after a AX64 restore and then restored back to the RB snapshot to see if there was any corruption. All was in perfect order. I realise that many here are fed up with RBrx but i think that it's still worth shining some light every now and then for those of us who like to be beaten to death. EDIT: You could rightly argue that HDS should not use us as their beta testers for which I totally agree. I guess I'm just not ready to give up yet and so long as i have a rock solid backup (AKA AX64) I'm willing to test. But I do have my limits...
I think that something very important should be added. If you've had AX64 installed for a while and have existing AX64 snapshots where RBrx was not installed then i think that using AX64 to restore to a previous snapshot where RB did not exist would corrupt the RB snapshots. I wasnt game to test this but it's probably a sure bet. I think the safest thing to do is start a new backup set with AX64 so that the baseline has RB installed in it and then there will be no confusion.
That makes no sense. If you restore to a point where RB wasn't installed, then there are no RB snapshots to corrupt. There are no RB snapshots at all! And if you read my post, it wasn't RB snapshots that were corrupted.
Hi MarcP. It does make sense. Remember that RB tracks the sectors for its own snapshots and ensures that any writes are redirected. If you use AX64 to restore prior to RB being installed then there is no RB installation ergo no RB driver to redirect and protect its own RB snapshots. AX64 does not backup or restore RB sectors because it cant see them right? (i could be wrong but i dont think so). So RB sectors are now free for all. If you now use AX64 to restore back to a snapshot where RB exists again, then you would expect sectors that RB thinks it was controlling would undoutably be overwritten (which RB would now perceive as corrupted). Does this make better sense? Sorry for the confusion. I understood your post, I was just letting you know that a new build had been released and for me anyway so far is very stable. I thought that it would be interesting if you tried it to see if it resolved your Imaging corruption problems. You understandably have had enough of RB and i respect that. Just give me a kick in the butt and i'll leave you alone. EDIT: Just to clarify a little more. The AX64 restores i tested were all LIVE restores. I have not tested cold restores using AX64. You also mentioned Macrium in the testing that you did which resulted in corrupted restorations. May i ask how you did those images. Were they LIVE or COLD images and was it RAW or file based? I know that AX64 would have been file based. You may recall Froggies analyses of imaging with RB and IFW and what Froggie discovered worked. With previous versions of RB, taking a file based image with RB installed and then restoring this image resulted in harmlessly disabling RB and all you had to do was uninstall RB and then reinstall it. If your willing, I'd like to know the circumstances of your corruption to better understand RB's limitations. Cheers.
I bit the bullet and decided to do some testing myself regarding restoring a cold image taken while RB v10.2 (internal files dated 17/08/2013....side note: (Winzip reports the file dates as 17/08/2013 whereas WinRAR reports them as 16/08/2013. Go figure)) was installed. I did my testing using VMware Workstation v9 and tested AX64 and IFW v2.83. The guest OS was W7x64. I discovered the key is the MBR. IFW v2.83 I was able to successfully restore an image using IFW taken while RB was installed. But in order for it to work you have to select "Write standard MBR code". If you dont, the current MBR remains intact and the RB boot console appears and corrupts the disk during its "Improper shutdown detected. Checking disk" procedure. Even if i selected the Home key first and then exited the console it would still invoke this process. Not very helpful HDS. The following is the steps i took 1. Select "Restore [Normal]" 2. Select backup location 3. Select the partitions to restore ( in my case drive C: was already selected) 4. Select the partition to restore to 5. Answer yes to the warning about overwriting the existing partition 6. In the options select "Set Active" and "Write standard MBR code" 7. confirm the summary is what you want and click start After the restore, reboot. Windows will boot successfully without the RB boot console. When Windows finishes loading you can uninstall the windows part of RB by going to the start menu and navigating to Rollback's menu and selecting uninstall. All clean. Ok. Not quite. I found that everytime i tried this restore that upon running chkdsk it would find a small number of errors. It would delete 4 indexes and clean up 2. For the life of me after i reboot back into Windows i could not find the affected (possible corrupted) files. So i chalk it up to an anomoly that's probably not worth worrying about. Subsequent chkdsk's report no more errors. I know its still not perfect but it appears to be a massive step forward from what MarcP was reporting. Either HDS did make some improvements or like I've said the key is the MBR being rewritten back to standard code. I did experiment with restoring the image and leaving the RB MBR intact and then rebuilding a standard MBR with another program called MBRWizard by using their boot disk. Rebuilding the MBR must be done before the firt time boot of the OS. This was successful in restoring a working OS but upon running chkdsk the same exact errors were corrected. Once i confirmed the restore to be error free by running chkdsk, AX64 was able to successfully backup and restore its snapshots (always doing a AX64 backup first after and image restore). But you'll have to be wary of the AX64 snapshots that contain the now removed RB. If you decide to restore one of these, make sure that you dont select restoring the MBR in the advanced options for the snapshots that contained RB or the RB boot console will be restored and you'll be right back where you started. Also be aware that upon running chkdsk that i encountered those same corrections. So it seems that they are embedded in the AX64 snapshots that were taken while RB was installed. Unfortunately i only took one AX64 snapshot while RB was installed so i cant really come to any conclusion if this means anything. I know, i should have taken more snaphots.... AX64 I actually tested this first and wasnt able to successfully boot my system after doing a cold restore with AX64 using a snapshot taken while RB was installed. It wasnt until i started testing IFW that i realized the key was the MBR but at this stage i was unaware. So my testing with AX64 was a dismal failure. The RB boot console persistently appeared and screwed things up by performing it's "Improper shutdown detected. Checking disk" message. All this testing is extemely time consuming so at this stage i've no time to test a restore and do an external MBR rebuild to see if i can get an AX64 cold restore image to boot. What this has brought to light is another feature that Isso could add. That is the ability to restore/rebuild a standard MBR. I'll have to requests it as a feature later if it hasnt been suggested already. SUMMARY I think for now that it's probably too much trouble and even dangerous to run AX64 and RB v10.2 together for now. But I'm going to let HDS know that they need to resolve the MBR issue and the aggressive nature of their boot console which is really the culprit in all of this. I hope that some of you find this useful and perhaps will minimize future headaches. Cheers
Hi carfal As ever, a sterling piece of work by you. Thanks. This is extremely helpful/useful. Respect Balders
Thanks for the analysis, carfal. However, I'm too chicken to try RBX again. I know what works for me now and I'm not seeing any negative compromises. I am not willing at this point to be a beta tester for RBX. Not when I've been very negatively burned by their "trial and error" ways of late.
I too want to thank you carfal, very interesting as well as illuminating. Even though I decided that Rx is not something I want on my PC I am interested in it from an academic point of view, it, and how HDS handles itself. What I would hope to see,,,,but do not expect to see,,,,,is HDS immediately putting a warning about the problems that you have explained in a VERY prominent place, like, for instance, at the beginning of the installation process of RX. The problem is a critical one for anyone who does not rely exclusively on Rx for protection and is imaging their systems as well. MarcP would not be considered a newbie to things PC and if he thought he was in major trouble I expect most who encountered what he did would also. If HDS, as I expect they will, allows users of their program to run serious risks while HDS scrambles to correct a serious problem then they will continue to deserve the scorn that has been heaped on them of late.
Thankyou Baldrick, MarcP and Bgoodman4 for your kind words. I know that HDS have handled things very poorly and they will suffer the consequences of their actions. I am also very disappointed but I just cant shake RB off my tree just yet. I want RB to be fixed so I'll keep at it for now. Once they iron out the bugs, I think the new version has a snappier feel to it. I find the defrags are really fast and the snapshot mounting (Explore) is also a big improvement in speed. With my SSD i havent noticed any slow down at boot time. It seems to boot just as fast. I think someone said that it was slower at boot on their machine but i can only tell you what i've experienced and besides the serious issues, it should eventually be a definite improvement. What really gripes me is that i have complained to HDS about lack of new features in every version that they release. This one again has no new features. In fact they took away the TREE view for the snapshots. I've made a complaint on their forums. Hopefully they'll listen and reinstate it.
Hi carfal Well deserved praise...if I may say, and one of the reasons that people frequent Wilders...for the sort of insightful information that you have provided. Appreciate what you are saying, and for me to leave the RB Rx fold was a wrench...but there you go...the grass may always be greener on the other side, etc. One question though; whilst I do not have or use an SSD (yet) I have heard some serious sounding reports re. v10.2 & the TRIM functionality, that is putting a lot of people off as apparently v10.2 is not really compatible with this. have you not found/had any issues? Just curious. Regards, Balders
Hi Baldrick. I have heard all sorts of warnings about the dire consequences of TRIM not executing on SSD's. I think that people are way too hung up on it but that's just my opinion. I bought my SSD in Feb '13 and installed RB v10 on it straight away. RB and SSD's are definitely a match made in heaven. Samsung have a utility that can give you a report on the state of your drive. After six months of RB here is the S.M.A.R.T report. As you can see, i have a Samsung 840 Pro Series 256gb and it comes with 5 yrs warranty. I figure that i would be struggling to keep this drive for 5 yrs and in any case, if something does go wrong, I'll just return it (or get it fixed) under warranty. I dont see the down side. Unfortunately it seems that TRIM on RB v10.2 is still not "really" working according to Trimcheck utility. At this stage, I'm not fussed besides, I dont believe that it will actually ever be possible to implement true TRIM functionality with Live sector redirecting technology (i spoke about this in another post). I dont have any issues to report with my SSD despite having RB running for nearly six months now. It still feels just as fast as the first day i bought it. I would recommend that if you can afford it, to take the plunge. Not for the reason to run RB but for the shear speed improvements you get. I'm not kidding when i tell you that it transforms your computing experience. I have mine connect to SATA II so i can only imaging how awesome it must be for those people that have it connected to SATA III.
Hi carfal Many thanks for taking the trouble & time to elucidate on this. I think that your words may put all this into perspective for a number of the forum users. Re. SSDs...I am seriously thinking about taking the plunge...and my current HDDs run under SATA 3 (and I have the option of using SATA 6, without too much trouble ) so that may clinch it. Regards, Balders
@ Carfal How did you test the trim? The correct procedure for RBRX should be: 1st test 1. Run the trim checker (1st Run). 2. Defrag RBRX snapshots. 3. Run the trim checker (2nd Run). 2nd test 1. Run the trim checker (1st Run). 2. Take a new snapshot in RBRX. 3. Defrag RBRX snapshots. 4. Run the trim checker (2nd Run). For the image corruption. With AX64 did you restore both the partition and the mbr? If yes and the corruption still occurred then RBRX fails to redirect the reads of the mbr from the real one and is a major bug. As for the Trim. Samsunng 840 Pro can achieve write speeds of ~430 mb/s on sata 3. On sata 2 its write speed would be ~260-280mb/s. So your drive speed is already impacted from the bus speed and you would not notice much difference during write cycles. Plus you did not write how the disk is partitioned; e.g. if you have left 20% free space, the GC routine of the drive would be sufficient for common write operations. ps. For understanding how much a non functional trim can impact the drive when no free space is left on the drive, and how to test its performance, take a look here http://www.anandtech.com/show/6328/samsung-ssd-840-pro-256gb-review/6 Panagiotis
Hi pandlouk. I ran both your tests and they both failed. Trim is definitely not working in the true sense of the function. When i was testing with AX64 i did select to restore the MBR in the advanced options. Because RB was still installed in the VM, it wouldnt make any difference whether or not this was ticked. The RB boot code would still remain intact and the "Improper shutdown detected. Checking disk" message would appear and do its damage. This is where IFW differed. I was able to use the "Write standard MBR option" and by pass the RB boot code issue. AX64 does not have this ability. I believe that if a third party tool was use to first rebuild a standard MBR code and then you used AX64 to restore the image without the MBR then you'll achieve what IFW does. I havent tested this so i cant say for certain. I would also imagine that if AX64 had a raw mode option to backup the unused sectors then one would have a working RB system restored. This image would have to be taken cold. What's happening now is that AX64 does not restore the unused sectors where the RB snapshots resided. So the RB boot code gets confused and tries to "fix" it but causes corruption instead. I must confess that until now i have never restored an image where RB existed in it. I've always taken my "this will save my life" images with RB not installed. So I dont even know if this MBR issue has always been there. At this stage I'm only interested in the current version and its short comings. I'm not sure how HDS will distinguish from a disk restored exteranlly to an actual bad shutdown or Hardreset. I think that HDS can best address this by asking a question before the RB boot code tries to "fix" things. It should ask "Have you just restored your system using an external imaging program?" Depending on how you answer will tell RB how to handle the situation safely. This seems lame i know but better to be lame than sorry. As for Trim Here are some more pictures that may answer some of your questions This is how i've had my SSD setup from the beginning. I understand that not having a working Trim will impact my SSD's performance but I'm just not concerned about it. It will always be a ferrari compared to mechaical HD's. I'm just enjoying the whole SSD experience without worrying about a process that could take a few years before i even notice my SSD becoming a real drag. By then I'll just buy a new one. (or have it replaced under warranty )
It was not with RBX 9.1. Back then, I was using RBX 9 as a first layer rescue and Macrium as the last resort. I've done restores that were very successful even with RBX 9 installed (I just had to uninstall and reinstall it to get the snapshots going again).
Hi MarcP, Yes, very true. It could be done by any imaging program. Doing HOT imaging and if need be to restore and then uninstall Rollback Rx to get rid of the leftovers and install again for it to work properly. Best regards, Mohamed
