Rollback RX v10.x (Home & Professional)

Stode, I have to respectfully disagree here.

First of all, there is no such thing as a "no space taking" snapshot... all RBrx snapshots take up space on the drive it's protecting. That's one of the main reasons many of their users start to run out of FREE SPACE on their protected drives.

Second, RBrx knows exactly where each and every piece of VALID snapshot DATA and CURRENT SYSTEM STATE DATA is located... it would be very easy for it to TRIM any data that has been really freed up on that drive... it chooses not to because it's a significant design task to perform and I don't believe the expertise of the current RBrx development staff is up to that task. Having had significant technical interactions with both the HDS support and development staff, I have serious doubts about their complete understanding of this product. If my supposition is correct, any design effort to correct the product in the above area would be a large undertaking for them.

 

I know that. I was referring to them (HDS) marketing it at once in a way that would give people that impression.. I think they were saying "takes 1% of disk space" or something..
That's why one has to take full cold sector-by-sector backup if they want to keep the snapshots in the backup.
(..and you have explained this on this thread like a dozen times, yet people keep on asking about this... )

 

Sure, HDS could easily do as you suggest to either a separate partition or a hidden partition... and at that point it would become an IMAGING system (COPY on WRITE rather than REDIRECT on WRITE technology). We already have (2) imaging systems that do exactly that... Macrium Reflect and FlashBack by XEROweight (still in BETA as we all know). If Rollback did that, it would become just another imaging product and its "great speed" would disappear with the technology change... although if it did so and adopted the DIFFERENCE RESTORATION technology that the above applications do, I'm sure people would enjoy the "new kid on the block" using this technology.

Yes, it would be able to avoid most of its known pitfalls by such a technology change... no, it would no longer be the vulnerable speed demon it is today.

 

...and what the heck are we doing on this Forum on a Sunday morning anyway?

 

LOL.
Hmm, it's cold outside .. 10F ...
Good enough reason for me to stay inside the cottage,and sit on internet

 

Not necessarily...
You have forgotten the snapshot software which uses COPY on WRITE (Toolwiz Time Machine, SysRestore, Farstone RestoreIT). These applications are no imaging systems like Macrium or Flashback. Like in Rollback the existing physical file sytem is their 'Baseline' image, but contrary to Rollback any changes to this Baseline are written into the physical file system, the snapshots are written to a protected area on the same drive (can be a different partition though).

The huge drawback of these applicartions compared to Rollback is that you cannot jump freely between snapshots. If you reset your system to a previous snapshot then all later snaps will be gone. No way to change your mind later like in Rollback. And this is the main reason why I am still a big fan of Rollback - and yes I know how to image my system, Rollback is not a backup solution after all.


Cheers
manolito

 

I am getting a bit confused here,,,,,,,Rx protects space that the snaps refer to, that is, it prevents the space from being written to (or over). How could Rx move this protected space to an external drive without taking the time to copy it? If Rx did this it would lose the very thing that gives it its speed advantage.

Also Froggie,,,,,,,I think there is more to it than HDS not being capable of rewriting the code,,,,,,if they had to they could hire people who could do this if they were not capable themselves. I think there are 2 factors that (would) prevent them from doing this.

1: The cost. We have seen that the principle driving force at HDS is sales. They want to sell product and the heck with the customers this attitude/product harms. They get to sell another license,,,,,,all is well in their world. Spending the time and money to rewite the code to make the product safe would cost too much. Its about the money almost exclusively.

AND

2: They would have to admit they were wrong (lying)........ All they would have to do now to enable users to protect themselves from Rx disasters is include your FAQ list in their "how to use Rx" documentation. This would cost them (in $) absolutely nothing,,,,,,, but again it would be an admission that they were not being honest in their marketing in the past. Never will this happen.

 

my guess would be... same hard drive (usually internal,and your windows OS partition)
and different partition (be it hidden,or not) on the same drive.
I can't see why would it be any slower in taking/restoring the snaps.
but then again, i might be blind..

 

Hi Stode! Your understanding of Rollback and how it works needs some updating... you're not blind

Rollback doesn't "take" snapshots as in copying that data anywhere. All it does is update a special internal database that tells it where the data is actually located. When it snapshots data, it just leaves it on its existing disk block and changes its database index as to where the newer version of that DATA will be located when it changes... no copying of DATA anywhere, just changing references to that DATA. When something that's been snapshotted is updated, the updates/changes only are written elsewhere. That why RBrx is a Parent/Child relational database, and that's why your storage disappears over time as you create additional snapshots... all the DATA remains where it was originally written on the disk. The oldest version of any data included in a file is the PARENT, and subsequent changes in that DATA are CHILDREN of that PARENT. As a file is updated along the way, you will always have that PARENT reference (your Baseline/Installation snapshot) and many CHILDREN along the way... the CHILDREN only being the changes that occurred to that PARENT. The DATA never moves, just pointers to that data are created along the way... that's why it's so fast.

To put the so-called "snaps" anywhere else would require the moving of all that PARENT/CHILD data as it was being created... basically just like standard INCREMENTAL imaging software does... it copies all the changes (and the original Baseline image) elsewhere.

 

@Frog:
Thanks for your detailed explanation.
Now I understand it more or less completely,and why it wouldn't work as it is, if the snapshots were "stored" on another partition,
it would completely change it how it works, like you said earlier.
(bookmarks frog's post,and links to it when someone is asking about this again.. lol)

 

Mr.Weary-

Just so you know you are not alone... I agree 100%. I think Rollback is fine.

I have many systems using RollBack, GoBack, Comodo Time Machine, and RestoreIT that are fine after many years.

Cold raw imaging solves the issue of drive failure / snapshot program damage.

I even have machines with some of the early 64GB Samsung SSD's from 2006/7 that still run under WinXP with no trim that run fine with no speed degradation. TRIM is not really as important as people think...for reliability or speed.

Just adding another 2 cents... (I read these forums often, but rarely have time to post.)

Regards,
SteveG

PS - I also have paid versions of AX64 and Reflect. I don't use AX64 due to stability issues (but I am hoping they solve this) but Reflect is a viable option. The only reason I don't consider Reflect significantly better, is that with any imaging solution, I have found that you need to have two methods in place. Sometimes even a verified image does not work. So you still have to backup reflect with Paragon or Aomei...

 

hjlbx-

Totally no offense intended, but I think this is incorrect and a little alarmist.

While TRIM is valuable, it was conceived when the cost of an SSD was extreme, firmware garbage collection was non-existent, and people thought they would need to keep their SSD for >10 years to recoup the initial investment.

Regards,
SteveG

PS- I paid ~$1000 for my 64GB SSD's about 9 years ago!

 

Not alarmist at all.

Windows Optimize Drive functionality is absolutely necessary to preserve data and SSD health.

This has all been officially stated by Microsoft.

 

I haven't paid much attention to this program before, but it appears to be popular.
How reliable is it? Is it worth using?
I already use Macrium Reflect and Image for Windows. I realize they are different beasts.

 

worth using ? yes
reliable? that depends of your use and expectations

 

I just looked at the price.
Quite expensive.

 

If you have SSD drive to protect, I wouldn't use RX on it, cause it disables the TRIM effectively.
Else, as for a normal hard drive, why not, as long as you maintain those full COLD disk images of your system, just incase..
Then again,if you're using Macrium's PAID version, it's incrementals and rapid delta restore are very fast,
effectively nullifying the reason for me to use this software on my computer.
When I want to play around and test software, I install them in a virtual machine.

 

Hi hjlbx-

Would you be able to point me to this (from Microsoft)? I am not trolling, just truly looking for information.

I am an engineer, but by no means a TRIM expert... and the best I can tell technically is that lack of trim might slightly increase write amplification (All SSD's have this anyway) since deleted files are not garbage collected.

In addition to the technical aspect:

• I have production machines running XP (this OS does not have TRIM at all) with SSD's for many years with no issues;
  
• My RAID installations do not support TRIM yet have no issues; and;
  
• Although I am not an Apple guy, I do not think Apple OS's had trim until recently.

All of this makes me think that at worst, you might see some small degree of performance hit but no effect on SSD health or data integrity. While there is slightly more data re-writing without TRIM, it is negligible to the life of the drives being produced in the last few years.

That said, I could always be wrong, so I would be grateful if you could provide me with your source.

Thanks!
SteveG

PS - I always find this discussion about Rollback and TRIM contentious since I am not sure Rollback drives benefit significantly from TRIM... deleted data from the OS is actually not deleted when using RB, just marked by RB so it can be recalled. Seems to me that TRIM is even less important on a RB system since deletions are not happening... much like a very full SSD gets no benefit from TRIM.

I know Froggie has done extensive research work on this which I wish I could take the time to analyze. -SteveG

 

Hadron-

If you decide to buy it, don't buy at the retail price. RB has sales for 50% or more off every few months.

It is usually at holidays like Black Friday, Xmas, Mothers day, Valentines day, etc.

Maybe look at their Facebook page.

Regards,
SteveG

 

Rollback RX is fine until a Windows update comes along that complete trashes your system. The Win 8.1 update and, more recently, Win 10 build 1511 comes to mind. And most can't say no to those updates. RBX will not protect you. In fact, it will destroy your system.

http://community.horizondatasys.com/forum/rollback-rx/3618-windows-10-november-10th-update

 

I wish that really were the case...

DATA does get deleted from RBrx systems... if it didn't, the system would eventually run completely out of storage over time (to some, this has actually happened). The deletion occurs when #1) data is deleted, #2)any snapshot referencing that DATA ("PARENTing" that DATA) is deleted, and #3)a Rollback DEFRAG is performed on your system... but not until those 3-things are done on your system. At that time, that space is returned to the Windows allocation pool for use.

The bigger problem is that makes those DATA blocks available for Windows allocation, but without an active TRIM going on, that space inside of the SSD gets protected from use until it sees the necessary TRIM to really free it up for further use. If it's never freed up, the SSD continues to protect it until all its real free space has been consumed. At this point it can no longer just ERASE and WRITE its NAND cells, it must start shuffling DATA in all those used cells to make room for new blocks/bytes. The only way it knows how to do this is through READ/MODIFY/WRITE NAND cell cycles... and these are very slow in nature as compared to ERASE and WRITE cycles. This is when access time in the SSD starts to really suffer and when WRITE AMPLIFICATION starts to ramp up on the high side. It's only a matter of time before th ose cells become "written out" and are no longer available for writing.

I have no idea when all this happens... depends on how a system is used, but the consumption of NAND cells for DATA that has been fully released by the OS is what starts the process due to no TRIM available. Yes, there are some newer features (assumptions) in modern Garbage Collection that mitigate this a bit, but it does not eliminate this problem.

 

Hi Froggie-

I know you are more versed on this than anyone on this board... I follow your research closely! And, I am not saying I don't agree with the write amplification issue... just that I have not seen it empirically on many SSD systems without TRIM (some with and without Rollback).

My issue is with claiming that "lack of TRIM destroys data" as said in an earlier post. I do not believe that is true and if it is, I would like to see some reference. Destructive SSD testing has shown that wearing out of SSD cells takes a long time... even with the less robust TLC memory. I cannot see Rollback destroying SSD's.

Clearly however, this is an issue to me since I use SSD's and various Rollback type solutions (GoBack, Comodo, RestoreIT, etc.).

Regards,
SteveG

PS - I remember last year an issue with some Linux distros that TRIM actually destroyed real data... but I do not know the details.

 

MarcP-

I am not a Rollback fanboy (although it may sound like it in the last few posts), but wasn't this really a MS issue?

As I recall, they moved partitions on hard drives, etc. Almost like sabotage.

Seems like many programs would be negatively affected in this situation, and also seems like a periodic cold raw image (which anyone using any snap-shotting program should be doing since these are not backup programs) would have made this easily recoverable.

Nothing in life is immune to outside influences.

Regards,
SteveG

 

I, also, do not believe lack of TRIM destroys DATA... but the mention earlier also mentioned using OEM SSD mgmt apps (ie, "Samsung Magician") and I know for a fact that can destroy RBrx system under many conditions (mainly via backdoor TRIM mgmt directly with the SSD)

I think you're referring to the long life testing recently completed on (6) SSDs... this testing used fully TRIM capable OSes, no Rollback.

I'll try and shorten this story. The initial TRIM specification called for the TRIM command from the OS to be a non-Queued command... this means the OS must wait for the result of the TRIM command before issuing any other commands, queued or no-queued (most READ and WRITE commands are queued in nature and, I believe, both the SATA II and SATA III specifications support queued commands).

The newest version of the TRIM spec called for it to be of a queued nature, which really speeds things up (massive TRIMming under OSes, previously, caused some real slowdown... still does under W7-10 when "optimizing" an SSD). Anyway, as soon as the new spec was available, there was a rush by SSD manufacturers to update their firmware to use the queued version of the TRIM command. That race was won by Samsung, which produced a flawed firmware for their 700/800 EVO/Pro series drives which caused havoc on Linux systems (the 1st OS to jump on the use of the new queued command. I don't believe MicroSloth has jumped into that scene as of yet.

 

You may categorize this anyway you wish but I don't believe the FAULT is with MicroSloth. Programs written to co-exist with Windows must work within its purvue as an operating system, not outside that purvue obfuscating the real world from the Operating System. If you want to really operate there, you must become the Operating System that provides the rules under which you should operate.

M$ did what it required to make its OS update work correctly, it cannot be responsible for applications working outside of those rules. Sure, many apps had issues (almost all imaging apps saw differences in their reference backup <baseline> and caused issues with ongoing incrementals) but, clearly, Rollback is an application that works completely outside of the rules provided by the Windows OS. If any app deserves to be at fault for not following the rules, that's probably your finest example.