Rollback RX v10.x (Home & Professional)

Could someone give a simple explanation as to why so many people have problems with HDS and Rollback RX? Lots of sniping, but I have never seen a summation as to why some seem so adamant against RRX.

 

LockBox... a lot of the bad press here at Wilders is directly due to computer decimations caused by Rollback RX. In some cases, years of data were lost in the process. These events hurt bad enough by themselves, but many of those same users have urged HDS, through the years, to discuss those very shortcomings with their current and potential users so that their existing and possible new users are well informed. HDS has always stonewalled these efforts and continues to "spin" their product as a panacea for all types of system failures, of which it clearly is not.

The group here created the "Rollback RX - the 'unOfishul' FAQ," a document that attempts to warn users of the technical shortcomings of the Rollback product. The completed document has been passed on to HDS for their review and hopefully its publication within their user information confines. They stated they would thoroughly review the document and act accordingly. That was done in the beginning of April 2015... no action to date.

You've probably noticed the recent discussion concerning Rollback and its inability to properly manage a user's SSD (no TRIM functionality... it's been an issue since 2011). With positive evidence in hand of such inability, I worked directly with Rollback's SENIOR TECHNICAL SUPPORT and demonstrated the flaw in their product. Their STS people admitted to me that TRIM did not work in my demonstration and that they would work with the developers and determine the cause. Two months later they came back and stated that yes, it did work, but not quite like what people thought it should do. They then spun the failure into some sort of secondary protection that was good for the user and still stated that TRIM works perfectly with the Windows OS.

It's these types of obfuscations and technical spinning that does nothing other than confuse the general user and eventually create some of the disasters that show up in these forums looking for help (see RickFromPhila for a typical example). At this point many of the users here have lost complete trust in the HDS organization and have begun to question their honesty as far as their products are concerned.

 

I have a possible "noob" question...My protected drive is C so if any weird stuff were to happen, is my D drive in jeopardy since it's the same physical hdd?

 

yes unfortunately.

few years ago, RX was screwed by a hard shutdown (in fact a power cut) , when i rebooted RX couldn't load, it was frozen at its "boot page" , i tried dozen of methods and potential fixes , none avails ; result my HDD was destined to be fully formatted with ALL my files in it.

after that, i started to save everything sensitive in several cloud storage sites.

 

Interesting. I have quite a bit of stuff on my D drive I do not want to lose.

 

Overkill, my experience has shown me that if the partition in question was not protected by Rollback, it should be just fine as far as its structure and DATA are concerned. The problem is that when the protected System partition gets scrogged (BOOT path and Rollback's managed access), there's no immediate way to BOOT that system to get access to that unprotected partition.

Any external access (LINUX, WinPE, etc.) should work just fine and your data on the unprotected partition should be available and in tact. Even if you decided to reBUILD (clean install) the wrecked System partition, you can select the wrecked partition for installation and the original unprotected "D" partition will be available following reinstallation.

In many cases all that's required is the repair of your existing MASTER BOOT RECORD on the wrecked partition and that will get you back to your unprotected original System baseline with full access to your current "D" partition. Of course, at this point, I'm not sure I could completely trust that original System baseline...

...or, you could stop dead in the water and always try the Horizon DataSys Support portal. Sometimes this takes some time and the results vary quite a bit as to your success.

If you have important DATA, you should be replicating it elsewhere or backing it up in some manner. Not only do computers just "work" when you need them, they also just "break" when you need them the most. If that HDD goes belly up due to a hardware failure... where's your DATA then?

Back it up, sir if it's that important to you... it really, really hurts when you lose it for good.

 

Well said. Backup is the best way to go as far as data safety goes. No HDD/SSD will last forever. They most likely will die on you when you need the data on them the most.

 

Thanks for the info!
I have to buy another external, my current drives are full

 

Then you better buy two of them. One to expand your system. And a second even bigger drive to back it all up.

It has also been my experience when RBRX crashes, it usually doesn't overstep its authority and go messing up other volumes. Just the one it was "protecting".

 

Well if that is the case then i'll be ok because I don't keep anything important on c-drive and my portable apps are backed up!

 

Hey Froggie, long time no see! I don't know if you remember me, but I was discussing with you the problems of Rollback RX 10, Image for Windows and the possibility to make a cold IFW backup of RBRX snapshots a while ago. So I came back to Wilders Forum and what do I see? WAR!!!

The "problem" with RBRX and TRIM is very simple. It's exactly the same as the relation between RBRX and Defragmentation software : they are incompatible. You can't move data at a physical level on the disk (which both Defrag software and TRIM do) and expect another utility that does the same thing (aka RBRX) not to be affected or viceversa. It's quite logical and doesn't really need "tests" to be proven - it's like expecting two partition managers to work at the same time, for the same hardware and logical devices. The definition of impossible, since they work with the same data at the same time.

Now if anyone looked at http://community.horizondatasys.com...lback-rx-ssd-trim-and-disk-defraggers-support, the HDS answer on both matters is that RBRX "supports" them both. And of course it ... "supports" them . The same way (older) Windows "supported" GPUs by installing only a generic driver: the GPU will "work"...only that it won't do what it's supposed to do (e.g. run at the maximum resolution, have all the fancy stuff available in games, etc.) In other words, RBRX will "support" (read "tolerate") both Defrag and TRIM, just that their basic functionality (the whole point of them existing in the first place) is gone.

More so, if you carefully read HDS statements (aka read between the lines - something I'm VERY good at, LOL) you'll notice that in the above link, Nick10, the moderator, states:
"Fast forward to today... Defraggers are now slowly becoming obsolete due to the new generation of hard drives known as SSD. But just like traditional hard drives, there are a new set of utilities designed to determine its data efficiency. However the concept is the same and RollBack Rx behaves similarly."
On the other hand, at http://support.horizondatasys.com/K...defrag-my-drives-after-installing-rollback-rx, Guru Shiva from HDS states that "If you really need to defrag the drives with a third party tool: Uninstall RollBack Rx, defrag the drives and then reinstall RollBack Rx". Now why would that be required if RBRX fully "supported" Defrag (aka Defrag could be able to proper defragment the drive), huh? Classic marketing lie
Now if you add the conclusion from my last paragraph to the conclusion of the paragraph before it (aka "the concept is the same and RollBack Rx behaves similarly") it's easy to see where this is going to: TRIM won't do what it's supposed to do while RBRX is running. No test required, just properly read between the lines and be logical.

I experienced that before (e.g. losing the partition info) and if I remember correctly, a proper way to deal with it would be either to do a FixMBR thing from a Windows installation media or searching for deleted partitions using a partition manager from another media (e.g. CD, DVD, flash drive or another hard drive). As you said, the data will be OK, it's the "container" (aka the partition info) which is lost in a "weird stuff" RBRX situation. That is, of course, if the data needed to be recovered is on unprotected RBRX partitions.

My way of "protecting", which I've been using for years with no failure whatsoever (except a HDD physical hardware failure which happened to me once - but there's no way to "undo" that, LOL) was to have RBRX protecting my C drive and having Acronis True Image Boot CD make a cold (aka from another media, like DVD) sector-by-sector backup of C with all the snapshots included. The backup would be stored either on a different partition of that drive (but that's vulnerable to physical drive failure) or on an entirely different drive (e.g. a different HDD, flash drive, etc.)

My only question would be if a sector-by-sector restore of a backup would affect a SSD or a TRIM protected drive - since I have no way of testing this (I don't personally own a SSD on my laptop). But since you obviously have a SSD - what do you think of it?

 

Thank you for this post, it sums the situation up nicely. Could you possibly re-post it on the HDS Rx forum? They have created a sticky where they say Rx supports TRIM and have dismissed Froggies test and input as they have above in this thread. Your post would be a good one for that sticky thread. It may be found at http://community.horizondatasys.com/forum/rollback-rx/3265-rollback-rx-and-ssd-trim

 

Oh, and a rethorical question for the users here and (maybe) for HDS : why on earth do we have to wait another 6 months for Windows 10 "compatibility", since the Windows 10 Technical Preview has been available to anyone for almost a year now I mean, what did HDS did all that time? Admiring Windows 10 Technical Preview, LOL? I realize some of the actual features and code of Win 10 TP and Win 10 RTM are different, but the basic low level operations and behavior couldn't be THAT different between TP and RTM for HDS to delay Win 10 compatibility for another 6 months...

I mean, come on, ATI and nVidia have already begun to release compatible Win 10 drivers now. That means they didn't just "admire" Win 10 TP for the last year - they built and tested new driver versions with it.

 

To me the sad truth is that HDS is not a development driven company, it is a marketing driven company. From one of Kurtis' posts it was quite obvious that their "development team" consists of just one lonely guy. And this person already should have DriveCloner 6 ready by now, but guess what...

From the past experience how long it took HDS to make Rollback compatible with Win8 / UEFI /GPT I would not bet anything on a Win10 compatible Rollback by the beginning of next year...

Cheers
manolito

 

Done: http://community.horizondatasys.com/forum/rollback-rx/3265-rollback-rx-and-ssd-trim/page2. I've left only the essentials and modified a few things here and there without altering the basic message.

 

Thank you, much appreciated.

 

HDS is a technology marketing company.

RBRX supports trim and defrag, and technically and by the book this is correct. Very correct. As long as they don't specify the level of support and what that support entails they are good to go in the eyes of the law. They’ve done nothing wrong. Support can mean many things on many levels. In the case of HDS RBRX TRIM and DEFRAG, it's pretty shallow.

It would be like me going on an interview and saying I know "photohop". Yes, I know of photoshop. I know what photoshop does. I know how to load and save images with it. I'm not lying when I say I know photoshop, am I? Nope. Not one iota.

There's this huge ambiguity there. And HDS appears to be skirting around the issue.

Regarding sector-by-sector backup of SSD. Go ahead and do it. It will work like you expect it to. The SSD controller takes care of all the mapping and sleight of hand. With SSD there are TWO sector maps. The one your OS uses for the file system - that's the one you can play with and what SBS backup use. Then there is the hardware translation layer in the SSD itself that the controller uses to map "sector 4324235" to a specific location in the NAND array. That's something you don't get to change. That's something the OS doesn't get to see or play with either. Same goes for your backup software.

Go ahead and test it out. Get a sector editor, view an arbitrary sector belonging to a test/junk file you purpose-made for testing. Back it up. Edit that location. Restore. What happens? Back to normal.

 

In other terms: SSD + TRIM, together, end up making lots of contiguous free space. This is good for writing speeds and longevity.

RBRX works on the principle of cataloging and keeping track of scraps of material that can be part of many snapshots. RBRX does this behind the back of Windows. Windows doesn't know about any of it. Windows doesn't know what one snapshot is compared to another. Only RBRX does. That's how you can have 20 snapshots with the same documents and system configurations taking up only 1 percent of disk space.

TRIM has to be aware of the current $MFT. It is. But it is not, CANNOT, be aware of other snapshot's virtually created $MFTs. TRIM rides on top of the RBRX kernel, just like the rest of Windows. TRIM is not aware of other snapshot data. It wasn't engineered that way. And it will blindly zero-out anything the $MFT says is deprecated.

It would be devastating to the snapshots if Windows and TRIM told the SSD to zero out and concatenate everything that it couldn't reconcile with the current filesystem instance. Well guess ******* what? THAT'S THEIR JOBS!

You see, the way RBRX works is that it depends on the inherent persistence of files and magnetic patterns of the standard SPINNER hard disk. If you don't actively zero-out and overwrite something it stays put. That's how undelete programs and data recovery programs work.

But TRIM tells the SSD it has permission to erase whatever it wants EXCEPT for what's in the current file system. That means all your precious saved data. The SSD is happy, it can now garbage collect and make large blocks of zeros (actually 1's in NAND). And the SSD promised not to touch anything in use by the file system.

"In use by the file system" means anything, any document, picture, executable, music file, - anything - you have stored and saved on the disk. Anything in the $MFT.

Snapshot management works below all this.

And that is why you can't write to an RBRX disk outside of the RBRX kernel like with a Linux boot disc, or 3rd party utility. That's why you can't run CHECKDISK outside of the RBRX kernel. If you do you will make changes to the disk RBRX is not aware of. And your snapshots will go belly-up.

That's why you must un-install RBRX before defragging.

 

TRIM is not aware of RBRX snapshots' directives. Plain and simple. So you have to intercept its commands - the commands that clear and concatenate blocks. Dump them into a black hole.

It would make sense to release a sector to TRIM's actions once that sector is no longer in use by any snapshot. This would need to take place before Windows gets going, but after the system starts. But this does not happen.

What does HDS say on that?

 

Very interesting Keatah and well explained. However I do not agree with your Photoshop example. The correctness of the statement "I know Photoshop" needs to have a context. If there is no context then you can say anything you wish. If you said you know Photoshop when you were applying for a job requiring the use of Photoshop and all you were saying was that you knew of Photoshop then you would clearly be lying, and, in this context, you would be knowingly lying. In the case of Rx supporting TRIM HDS is implying/stating something that is not correct. the context is, or should be, in terms of what the average user would understand "supports TRIM" to mean, not some vague reference to permitting TRIM to exist but blocking what it was designed to do.

As to the reason why deleting a snap does not make its "protected" space free to be TRIMed HDS has said nothing beyond that Rx has to be uninstalled AND the system rebooted before this space can be affected by TRIM. If this were not the case, if TRIM "worked". that is functioned as it was designed to, at any level on an Rx "protected" system, then I would have to agree with your excellent analysis. But it does not work at any level as Froggie has clearly shown and thus, from a common sense point of view, TRIM is not supported. That is, if TRIM is completely blocked from doing its job then saying TRIM is supported is a lie.

 

Hi
RollbackRX is phoning home at every Pc startup and i wonder if it is safe to block that in the Firewall or will it limit the functionality of the program ?

 

It doesn't need to do that for license verification so I'm not sure why.

I would block it with your firewall and check the license status after you BOOT up to make sure you're sctivated. No matter what, it shouldn't affect the operation of Rollback unless the license reverts to a TRIAL. If it does, just unBlock it in your firewall once again and reBOOT.

 

Yeah there is always that possibility and i was thinking of trying it.
I think the "network register" does that but i wonder why the "shield tray" wants out and what it does .?

 

It's probably checking to see if you're the RollbackFrog... and if you are, it'll trash your system

 

I guess that means that you do not have RBRX installed anymore ?