Let's kill Rollback Rx!....

[tubby]

System Restore Software | Fix Any PC Computer Issue Without IT Knowledge - Horizon DataSys


Above is the address for Horizons ad I was looking at. (It looks like the address is not in link form to to view, one might have to manually enter the address to arrive at the page)

Now really, I have no desire to see Microsoft buy Rollback Rx. I agree, that may be a disaster!
( I did not say I wanted Horizon to actually SELL.....I just wanted the product to develop to such such a degree that Microsoft would "beg" Horizon to sell!.............(perhaps I am being 'sour castic")

Then again, if the perfect "Time Machine" were woven into the OS, it might sell like "hotckakes" and people may have fewer headaches! (there I go, being un-practacal again)
-One friend at work says he thought Microsoft would not focus on such a time machine because what they really want is to develop "cloud" technology whereby our harddrives would not be physically at our hands but on rather on their server (somewhere in the clouds!)

How's that for a a scary thought!

Back on topic. I do not know how Rollback works. I guess in my minds eye I thought it worked similar to a "raw-image" whereby Rollback simply looked at the zeros and ones IGNORING any "format" component (inside/outside Windows, file system(s), MBR(s) libraries etc. - I guess it's more complicated than that!

Perhaps MasterBlaster is right..........this is sort of a stupid post!

[Owl]

Originally Posted by tubby

[url=http://www.horizondatasys.com/169614.ihtml]I do not know how Rollback works. I guess in my minds eye I thought it worked similar to a "raw-image" whereby Rollback simply looked at the zeros and ones IGNORING any "format" component (inside/outside Windows, file system(s), MBR(s) libraries etc. - I guess it's more complicated than that!

I shall try to enlighten you.

The file system is the means by which the raw data storage capacity presented by the hardware of the disc drive is actually put to use by the operating system, and by proxy the applications running under the operating system. In fact, at the heart of things that is what an operating system is all about!

The raw capacity of the drive is divided up into clusters (used to be sectors but now multiple sectors are grouped into clusters), and the OS uses file allocation tables to keep track of which clusters comprise each file, and which clusters are currently unused and available.

Traditional system recovery utilities grab a copy of all the "in use" clusters whenever you declare a snapshot - so that means a long-winded process of doing a file system copy to somewhere else, and an equally long-winded process to copy it back if you want to restore that snapshot. What's more, it takes up a lot of disc space.

RBRx takes a completely different tack. When you declare a snapshot, there is no file copying going on, but the state of the file allocation table is recorded. RBRx intercepts the OS file access requests, and reads continue as normal. However, if a write is made to alter a file or create a new file (or even delete a file), RBRx prevents those writes from altering the disc clusters that comprise the snapshot; instead they are diverted to a new set of clusters and the old clusters are held in reserve. When you want to switch to a previous snapshot, RBRx recreates the file allocation table that was extant to access the old clusters instead of the new ones and there you have your roll-back - almost instantly.

Thus the disc space taken up by a snapshot is only the difference between one snapshot and the next, and the time taken to create a snapshot or restore it is only the time required to rearrange the allocation table.

However, in order to do all this brilliance RBRx has to have visibility of disc accesses via the OS calls, and as I have noted anything which subverts this is likely to corrupt the snapshot tracking.

Does that help?

[nexstar]

Originally Posted by Owl

I don't want to become a parrot, but do you for some reason disagree with my basic premise? RBRx can wind back to a clean snapshot provided 1. there is a clean snapshot, and 2. RBRx itself is still running (boot console minimum). I accept that most malware operates at the file system level, but you cannot discount "zero day" attacks that bypass the file system and access the disc directly. The attack might well INTEND not to damage the machine and therefore go un-noticed, but if it does not understand the non-standard RBRx implementation then it could easily damage it unintentionally.

I stand by what I have said before: RBRx will save you from "oops" moments and meddlesome kids, and it might save you from malware - but you can't be sure of it and you still need off-line backups and/or firewall and AV.

No, I think that was pretty much what I've tried to say in this and other threads. I don't think that protecting against malware is a job for just one piece of software. Even if the software is pretty good then there is always the human factor which can make a mess of things. All I was trying to do in this thread was to challenge the inference that RB had definitely been compromised when it didn't seem as though we had conclusive proof of that.

The use of the word 'protect' is quite interesting in lots of walks of life as it gives the impression that something is guaranteed not to happen and yet, in lots of cases, we know that's strictly not true. AV companies will use it to tell us we are protected but we know they are only as good as their last virus definitions (mostly). Seat belts are there to protect us in the event of a car crash but we know that we can still get injured. So it seems that it is a word which is open to interpretation.

Ultimately, it is a question of being realistic and having a backup strategy in place which will cover you if the worst possible of scenarios actually takes place.

Graham