RollBack RX question

Thanks, so far its worked nicely and I appreciate the fact, however, as I said, its good to be aware of RBs nuances so as to not be over confident as to what it can do.

 

This is very encouraging, thanks.

 

As to the first comment ---- thats the trick for sure. I suspecting that malware (including viruses) would be the principle culprit here so avoiding it would/could be a bit of a challenge. The point is that if you believe the program protects you against this sort of thing you are more likely to have a problem than if, as now, you/I am aware that its will not nec protect against this.

As to the 2nd comment ----- I would say so,,,,,,this is why its too bad that its not possible to image all the snaps as opposed to just baselines. In fact, in one sense, having RB installed leaves you at greater risk than not having it installed. Pre RB I was imaging daily, now, considering that its nec to uninstall RB, or at least create a new baseline and then use RBs imaging function (or the new Driver Cloner) I am much less likely to image daily since this has become a manual operation rather than an automatic one. The fact is, since installing RB I have not imaged the drive even once. Its just seemed too much of a hassle and the information provided by the reseller makes it sound like its not a high priority. Clearly this is not the case and discipline is required. Still, daily images are not going to happen so the likelihood of losing relatively big chunks of data is very real.

So the question is are you really better off going for the ease and speed of snapping & restoring with RB or sticking with automatic daily images that take hours to create and restore.

Personally I am beginning to suspect I was better off with daily images and GoBack than I am with RB and say weekly images,,,,,,assuming I even get around to doing the weekly image regularly and consistently.

I am very happy to have had the above discussion, at least now I know whats what and I can act accordingly. This may well mean abandoning RB in favour of a more reliable automatic process such as Paragon or Drive Snapshot. That being said there has been talk about sector by sector imaging with 3rd party programs such as Acronis being effective at preserving all disk data with RB installed,,,,including all snaps,,,,has anyone had first hand experience with this. I guess a test would be wise but I am concerned with really making a mess of things if I do.

 

Using something like acronis trueimage to backup your system with rollback rx and all snapshots is fairly easy. Instead of doing a normal backup you simply do a sector by sector backup. The only downside is it takes longer and the image size will be larger compared with a normal backup.

In regards to security there have been posts in the past about rollback surviving malware attacks. Of course its not bulletproof but it does offer some low level disk access protection. Anyway from what i've read recently most malware these days is focused on stealing your personal details rather than trying to corrupt your system data.

I've been a rollback user for over a year now and its performed great. I've never had any data corruption where rollback itself was at fault.

 

I think that you may have some misconceptions about the way that Rollback functions which I'd like to try and clarify if I can.

RB is actually very good at protecting against malware because of the concept it is built around. When you take a snapshot, RB protects those sectors from being written to and treats them as read-only. This means that nothing, not even RB itself, will modify those sectors from within the Windows environment. If you make any changes to any of those protected files then the sectors which are change are written elsewhere. Those changed sectors now form part of your current snapshot and they themselves can be modified by you....or malware until you take another snapshot at which time they become protected and obtain read-only status.

This is why going back to previous snapshots produces a system exactly as it was when you took the snapshot. If the current snapshot had been infected at the time you took a particular snapshot then that snapshot will still be infected if you revert to it. However, if the previous snapshot was not infected then you can revert to that one and be completely clear of that infection.

This concept which is inherent in RB is also the reason why old versions have to be uninstalled (losing previous snapshots) before RB updates can be applied. They could technically have a system which could go through each snapshot and modify it with the new RB code but, to do that they would have to allow RB to modify snapshots. Once they allow that to happen then malware has a route to the snapshots.

Hmmm....I see no reason not to image daily, or even hourly if required, just because RB is installed. No, you will not image all of the snapshots this way but then, do you need to? If you want some peace of mind that you have a system you can restore to its current state in the event of drive failure etc then surely the loss of the previous snapshots is a small price to pay?

I've got a friend who runs a small media company (the company is small, not the media!) and he has a RB installation setup with Drive Snapshot running daily via the Windows scheduler and some batch files such that DS takes daily differentials which loop so that they overwrite the previous week's differentials. Occasionally, when the differentials start to get large, he will make a fresh full image with DS and so it goes on .

The one doesn't exclude the other and the images don't need to be onerous.

It's all a personal choice but don't do it for the wrong reasons.

There are quite a few threads here on imaging RB and retaining all the snapshots. It became quite a science and a way to while away the long winter evenings .

Graham

 

Thank you for this Graham, this is most reassuring. I think I have been getting confused. I did so much research before installing RB that the do and do nots have become a bit jumbled. Just to make sure I have it right ------- if I image with RB I get the current state of the drive excluding all snaps (assuming not a sector by sector image). It is only nec to uninstall RX if I want to use a 3rd party defrag utility, it is (clearly now) not nec to uninstall it for an image.

If this is now correct then an initial sector by sector image (kept for posterity) and subsequent weekly or by bi-weekly images (not sector by sector) should provide a high degree of security, both from malware (including viruses) and hardware failure.

 

bg,

If a disk-image is created from within Windows of a system drive/partition with RB installed, then RB's current snapshot and only that snapshot is backed up. However, note that restoring that image will likely require performing a FIXMBR or restoring a backup of Windows' standard MBR (this situation is avoided by uninstalling RB before imaging).

Insofar as the need to uninstall RB for the purpose of running a disk-defrag, that is the cleanest method. That said, appster previously indicated (in this thread) that given adequate free disk space, a disk-defrag can also be run with RB installed if followed by an RB baseline update.

JA

 

Ah yes, thats what I was thinking of even though the details were fuzzy. I think this would not be necessary if I were to use RBs own imaging program,,,,,or is this not the case. If its not then I am back to my original imaging problem especially since I do not have install disks so doing a FIXMBR would be a problem.

 

Yes, this is correct, as Jo Ann has summed up. Don't worry about getting confused, there's been a lot written on this topic .

Yes, this should be fine. RB itself should keep you pretty well protected from the consequences of malware though. The one proviso there is that you obviously need to know a)that you've been infected and b)roughly when you were infected so that you can restore either a clean snapshot or image.

Graham

 

There is a simpler way. If you are restoring an image taken from within Windows with RB installed then you can simply restore the MBR from that image. Most imaging software should allow you to restore the MBR along with the image or as a separate operation.

As no imaging software can get the actual MBR from within a RB setup then you will be restoring the pre-RB MBR. When you reboot the PC you will not then get the RB pre-boot screen. All you have to do then is to run the RB installation twice. The first time will uninstall the remnants of RB saved in your image and the second time will re-install it again. You are then good to go with a fresh install .

Graham

 

Not wishing to be contentious here but, I'd be interested to know if anyone has demonstrated that defragging the disk with RB installed has any real effect on the placement of the sectors on the disk itself. I'm sure I'd read that defragging within a RB environment was of no value and, logically, this would seem to make sense as RB should be redirecting those writes to other areas on the disk, not to where the defragger thinks it is putting them.

I don't defrag a lot but, when I do, it is always with RB uninstalled. Just curious.

Graham

 

Excellent and thanks.

I am a bit unclear as to how this can work. If the image was taken with RB installed how can a restore put a pre RB-MBR on the drive? Or are you saying the reinstall from the image must be from an image taken before RB was installed? I am pretty sure that you are saying that the former is the case but just to be absolutely clear & certain..........>>>>>

I am hoping that the situation is one where I can image with RB installed and with all snaps present on the drive. That the image will "get" the current state of the drive but will be missing the snaps, that a reinstall of the image will put everything but the snaps and RB back on the drive and that somehow the MBR thats present at this point will be a pre RB installed MBR (but I don't see how this could be), and finally, that reinstalling RB twice will get me back to a good state with the only thing missing being the snaps that were not present on the image.

Is this what you are saying is the case?

 

Graham, as stated in post #6 I do just that (using the 'Consolidate' option within UltimateDefrag). RB's current snapshot sees the defragged (consolidated) sectors as data changes and consequently becomes quite large - thus my caution that this procedure requires ample free space on the system volume. Upon updating its baseline, RB's optimization rebuilds its 'sector-map' and in the process frees-up the large disk-space previously consumed by the then current snapshot.

Don't take my word for it - try it yourself (note, ymmv depending on several factors, so do backup first)!

 

appster,

I'll try your procedure this evening and will report back. Of course I'll backup (with DS) beforehand.

Besides the obvious advantage of not having to install-reinstall RB, do you find other benefits in this approach?

JA

 

The short answer is 'yes' .

The slightly longer answer is that RB doesn't allow any imaging software to 'see' the RB mbr. This is probably sensible as, if it did allow the RB mbr to be restored with an image without the snapshot data, then the restored image would result in RB in a very confused state when it starts up minus its snapshots.

So. and I'm speculating here, they probably keep the original mbr for restoration purposes and any examination of the mbr gets redirected there.

To test this theory, I saved three copies of the mbr using hdHacker (a handy little utility with a gui). The first was taken without RB installed at all. The second was taken within Windows but with RB installed. The third was with RB installed but was taken outside of Windows using a recovery environment.

I then compared the files with a binary comparison utility and, as expected, the mbr saved within RB was identical to the one saved with RB uninstalled. The 'real' RB mbr was vastly different to either of the others.

So yes, the procedure you have described will work in the way you want.

Graham

 

I tried it . Yes, it clearly does work as expected but (and I may be missing something here) I'm not sure how this is different from either uninstalling/defragging/reinstalling or updating the baseline and then defragging without uninstalling.

From what I've read, the snapshot data will be duplicated on the drive as the defragger works and then, as the snapshots are consolidated, there is the potential for gaps to be left as those snapshots are deleted.

I tried this with a pretty defragmented drive and it all tidied up very nicely when defragged within RB. However, I didn't have any snapshots which could have made a difference to the result.

After you've defragged and updated the baseline, have you taken another look to see how the fragmentation compares with prior to the update of the baseline?

Interesting exercise .

Graham

 

Aloha Graham,

The main difference between my procedure and that of uninstalling, defragging, and reinstalling is that it is much less work. There is also the advantage of having the RB folders and executables defragged & consolidated (which wouldn't be the case if RB were uninstalled). Updating the baseline and then defragging (with RB still installed) would result in a very large (and non-optimized) current snapshot. The only way to remedy that would be to either perform another baseline update or to uninstall RB, so that's a total waste of time.

Regarding your final question...

...the answer is a definite yes. One of the nice features of UltimateDefrag is that it presents a meaningful pictorial display of the disk layout and fragmentations. This facilitates a before-after comparison, which confirms the benefit of my procedure. Even more meaningful (from a practical sense) is that it takes less time to open some of my larger files after the defrag than before the defrag!

 

Thank you very much Graham, much appreciated. I can now image without excess worry (but I will worry just a bit just because).

 

Why would you bother doing this rather than using RBs own internal defrag utility? Seems to me rather pointless unless RBs utility is substandard.

 

Hi appster,

I just tried your procedure. It worked very well and just as you said, before updating my baseline snapshot, my current snapshot became unusually large! After updating my baseline snapshot, RB 'gave back' that disk spce (just as you said). In any case, within the constraints of my limited test I did see improved performance.

Admittedly, I'm not a big enthusiast of disk-defragging and hadn't done a defrag for a few months (although I do defrag my RB snapshots frequently). Before defragging my C-partition with RB installed, it took 7+ seconds to open a large Excel spreadsheet. Afterwards, the same spreadsheet opened in 4+ seconds. While in real terms that doesn't mean all that much to me, it does confirm a measurable benefit of the defrag.

So as you said, it does work.

 

To be totally honest with you, RB is still sort of magical to me, but there's no question in my mind that a snapshot defrag and a disk defrag serve completely different purposes.

Windows and Windows apps write to the disk with total disregard for RB. On the other hand RB monitors Windows disk-writes to prevent any sector changes that could corrupt its snapshots and their sector bit-maps. So if an app attempts to make changes to a file within a sector that's already mapped by an RB snapshot, RB redirects that change to some other sector. That smacks of data fragmentation to me!

RB's snapshot defragger doesn't defrag (or relocate) the actual files in each sector of the disk, it just optimizes each snapshot's relative (to the baseline) bit-map structure. The ultimate RB optimization (a complete rebuid of RB's bit-map) occurs during a baseline update.

So as I see it, an occaisional disk defrag can be of value to an RB user, if done properly!

 

Thank you, I can't begin to tell all you folks how grateful I am to have found this forum. I have learned a tremendous amount here and I am confident I will continue to do so going forward. Previously I just read what a publisher said and I I decided to give the program a try I kept my fingers crossed. Now I can ask a question and get an unbiased answer from someone who has hands on experience. This of course makes things significantly easier. I will add a periodic uninstall and defrag routine to my regime (I know it appears from the above that the uninstall is not required but ....). Thanks again.

 

Hey appster,

Thanks for the good info! I'm running Eaz-Fix, but as EF anf RB are 'sisters under the skin', I'll give your method a go.

I've never seen much in the way of performance improvement after doing a disk defrag and as it's definitely a drag to uninstall EF, defrag, and then reinstall EF, I haven't done so for quite a while. Your method makes doing a disk defrag with EF installed a lot less of a hassle, so I'll probably be doing it more often!

Aaron

 

Graham,

Unfortunately this does not always work. My family uses Acronis True Image to backup their desktop PC (with RB) and always from within Windows. On a few occaisions my husband had to restore an image (including MBR) and upon the ensuing boot he received an error-message to the effect that the MBR was corrupted.

As I'm the 'techie' of our family they usually call me when they have PC/Windows problems. Cutting to the chase, whenever that happened either FDISK /MBR or FIXMBR was the solution. After doing that the restored image would boot and run without issues (other than having to reinstall RB).

JA

 

I thought it sounded too good, I have to try to get an install disk (or at least access to one, perhaps from a friend) if I can. Then I will not have to worry. Thanks for pointing this out JA