Flaw/Achilles Heel in Rollback Rx??

Hello all...

I just recently purchased Rollback Rx. From what I've read, it seems like it will be a great component to add to a security system. There was one thing that occurred to me the other day that has given me pause tho.

Thinking of a scenario where some kind of system change occurs that is going to be detrimental to the overall stability of the system but isn't immediately obvious (whether that be due to some malware that got access to the system, or some other change that wasn't the result of deliberate mayhem, but which might be subtle enough that it wouldn't be obviously apparent immediately).

If I were to do a baseline update shortly after this system change occurred, it seems to me, from what I understand at this point, that I would be screwed as far as being able to undo that change via Rollback, since all earlier snapshots are deleted after a baseline update. Is that correct??

If that's true, I see two ways that situation could possibly be avoided. One way is if Rollback allowed you to update the baseline from an earlier snapshot, and the other is if there was a way to "archive" or export multiple baselines, so that you could update more often and have access to a "backup baseline" if needed.

Am I correct in my reasoning here, or am I missing something??

One other thing I haven't been able to figure out from reading the documentation is if there is any way to store Rollback's file map on a partition different from the one which it is protecting (I'd like to keep my protected C:\ partition as small as possible, for imaging purposes).

Thanks for any input on this. Hoping there may be some ways around both of these issues....

 

Greetings! You are correct in assuming that all previous snapshots are gone once you've re-baselined the system.

The way I manage what might be referred to as multiple baselines is through programmed snapshots and due dillligence in deleting unneeded snaps.

Since RBx is based on a parent-child snapshot relationship, every snapshot is based purely on previous snapshots and or the baseline if nothing's changed since then. It's nothing more than a good database of "used" sectors (not the data, just the allocation maps) that are a unique part of any snapshot since the baseline. That database is updated each time a snapshot is added... or deleted.

I program 3-unlocked snaps a day M-F, 1-unlocked snap on Saturday and 1-locked snap (no accidental deletion) on Sunday. As time moves on, the weekly M-F snaps and Saturday snap are deleted, allowing RBx's database to be updated for the Sunday locked snap. These locked snaps act as a weekly baseline, if needed, to chase back problems that are greater than the snapshot resolution I use during the week. Eventually, as time really moves on, I start to unlock and delete those Sunday snaps also leaving 1-Sunday snap as my new "monthly" baseline. After a while I have some daily snaps (unlocks), weekly snaps (locked) and some monthly snaps (locked). Since everything between snapshots is incorporated into the next snapshot (parent-child), any disk space used by a previous snapshot that is no longer in the current parent is released for re-use. Remember, RBx protects existing sectors (will remain in use) that are still referred to in any existing snapshot. Once that protection is released (no snapshots need it), the disk space becomes available once again for re-use.

Although those weekly/monthly locked snaps aren't really a baseline per say, any none of them may be used to re-baseline the system at that point, if necessary.

At the moment the RBx database (file map) must be on the protected partition... BUT, that database (filemap) takes up very little space itself. What takes up the space are the sectors in use by any given snapshot. If that snap is deleted, and that snap's data isn't used in the next child, the space become available on that drive.

Managing your snapshots correctly (deleting when really not needed anymore, locking those that are important) goes a long way towards keeping your protected areas as small as they can be.

 

Hi ralws,

As good and as convenient a tool as RB truly is, it is not invincible! So I strongly suggest that you do not rely completely on RB, but in addition, make image-backups a regular (frequent) routine in your computing practice. That and only that is the best assurance for disaster-recovery.

Furthermore, image-backups can provide a way to save your entire RB environment along with RB's snapshot history on your backup storage drive. The method for doing this (with just about any image-backup program) is to use that program's recovery disk to boot your system and then make a raw (sector-by-sector) backup of your C-partition from that boot environment. Much has been written on this method in this forum as well as on RB's forum.

Scott

 

Thanks for your replies, Frog and Scott.

Frog, the routine you suggested (or similar) sounds excellent, and seems like it would indeed substantially reduce the risk of the scenario I was asking about. I was always a bit unclear about what the locking or unlocking snapshots was all about. Am I correct in thinking that a locked snapshot will be deleted in the process of updating the baseline, but will NOT be deleted if I want to reclaim some disk space or increase system speed by using Rollback's snapshot defrag option??

Scott, thanks for the reminder to do image backups regularly. I've been very lax about that in the past, but am set up to do that more conveniently at this point, and will. Am I correct that if I was NOT particularly concerned about preserving the "hidden" Rollback information when I did my disk image, I could just do a file-based image rather than a sector-based image, and that would restore okay (aside from not having the Rollback sector map intact)? In other words, the requirement to do a sector-by-sector image is only necessary to preserve the Rollback snapshot structure, but if I only wanted the windows-readable files available for restore I wouldn't need to do a sector-by-sector backup?

One last thing I'd like to pick your brains on: Currently I'm only protecting my C:\ partition. As long as I don't modify the size of C:\, can I feel free to re-size and change the labels of my partitions D:\ and E:\ via a non-Windows live CD, or should I be sure to do any modification of even those non-protected partitions via Windows? (I'm thinking the answer to this probably depends on whether partition labels and sizes for even the non-Rollback-protected partitions are stored in the MBR and would therefore need to be written by a process that is subject to Rollback's control, but I dunno about that...)

Thanks much for your assistance...

Robert (In cold gloomy Boston, lol...)

 

You're quite welcome!

Yes, all snaps are gobbled up when re-Baselining is done regardless of LOCK status, and if you re-Baseline at some snapshot prior to the CURRENT SYSTEM IMAGE, all snaps after that time will be lost.

The LOCK mechanism is nothing special... just a method to protect snapshots against either MANUAL or AUTOMATIC deletion (by program settings)... it does not protect them against re-Baselining.

RBrx defragging will always do what it does regardless of the LOCK status but freeing up space by DELETION will only work on unLOCKed snaps.

You're in a "black magic" area right now

Since this whole process has never been explained by the RBrx developers, and re-partitioning (size or otherwise) of the protected areas will blow up RBrx, I have NEVER (mainly due to pure FEAR) done any partition work on a RBrx-protected hard disk (whether the partition was protected or not) without first uninstalling RBrx prior to the work and re-installing when finished. It doesn't matter whether the work is done under Windows or a LIVE CD, without a proper explanation from HDS, I would never do it on a protected system.

Others may have tried the above with other results, I chose not to take the chance. I haven't had time to protect the system, via image, for the testing... maybe some time in the future.

 

Robert, I'm sorry for not getting back to you sooner on this, but somehow it flew beneath my radar.

If you are don't care about preserving your RB installation and its snapshots then you can simply run a normal 'hot' image backup (NOT a normal 'cold' image backup!). Upon restoring your 'hot' image the entire Windows volume should be intact with the exception that RB will not be functional and of course, all RB snaphots will be gone. You will need to first uninstall and then reinstall RB. Otherwise, all should be ok.

Scott

 

Once again, thanks, to both of you, Scott and Frog for that additional information. I seem to be getting the hang of this, bit by bit, so to speak. I really appreciate you guys taking the time to educate me a bit on this. I do read thru the forum, but find that I still have some questions.

Since my original post I've had a couple of odd occurrences. The first might be "normal" but just not expected by me: I told Rollback to take a snapshot one day, and it went into what looked like "lockup" for quite a while. I saw that the hard disk was working away, so I decided to just let it go. I waited for half an hour and it was still busy (tho no "progress" was indicated on the snapshot progress bar), so I left the house, came back an hour later and it had finished the snapshot sometime in the interim. I hadn't done any major program installation or disk defragging (unrecommended!) or windows updates or anything since the previous snapshot. Does rollback occasionally take 30+ minutes to take a snapshot??

The second "odd occurrence" was a bit more troubling. I don't know if Rollback has a tendency not to play so nicely with Windows hibernation, but I tend to hibernate the computer much more than shut it down, and twice out of perhaps 20 hibernation revivals, when I've gone to revive the computer I've gotten an "Error 8002: Invalid MBR" message from Windows, after the Rollback boot screen had come and gone. THAT is not the kind of thing to give a person a warm fuzzy feeling. In both cases I re-booted, let the Rollback boot message come and go again, and got the same message again. Re-boot again, and this time invoke the Rollback console, and I rolled back to the most recent snapshot and things were more or less fine, aside from a couple of my program data files being a bit outdated (I had declined Rollback's message asking if I wanted to save any data files before rolling back).

Are those behaviors something common with Rollback?? Hopefully not. Since the MBR issue, I find myself saving and backing up data files (via Windows) more than I ever used to, and taking snapshots several times a day, just so as to not get stuck with being too far behind if I have to roll back and get that error again. It's a bit inconvenient.

I'm investigating the possibility of using Rollback with the Altiris / Symantec SVS Application Virtualization program, wondering if people here might have any experience with that combination, but I'll start another thread if I need to, for that.

Again, thanks for the time you've taken to help ease me into feeling more comfortable with Rollback...


Best warm regards,
Robert.....

 

Hi Robert! The two scenarios you mention... loooooooong snapshot times and that MBR error... I've never seen either using either XPpro or W7. My snaps run from 3-7 seconds MAX and that MBR error seems ominous... and I HIBERNBATE most of the time.

What OS are you using? I've never heard of Windows checking the MBR following a HIBERNATION event. Although Rollback's MBR is non-STANDARD, it is NOT in error. Since I've never seen the error before, I would suggest other nefarious things might be going on here, maybe a rootkit of some sort.

If rolling back to other snaps doesn't rid yourself of the error, I would uninstall Rollback and carefully diagnose that system for possible malware/rootkit. When it stabilizes, then maybe Rollback again.

 

Frog...

Hmmmm..... I'm not sure whether I should be pleased or upset that the long snapshot and MBR error aren't typical. I'm running Win 7 Home Premium 64-bit.

It's on a Samsung RV511 laptop, which is a nice machine, but for a few months now I've had occasional hangs either going into or coming out of hibernation, so whatever is doing that might likely be what's messing up the restore from hibernation and catching it somewhere that it doesn't recognize the Rollback-modified MBR correctly.

Malwarebytes gives me a clean bill of health. I suspect I may have some setting(s) on the laptop not set quite right or something. I often leave several programs runnnig and browser with a fair number (20 - 30) tabs open, perhaps that causes hibernation problems (tho I really don't know why it should). I'll fiddle around a little and see if I can find any pattern to what's going on. I guess it wouldn't kill me to do a rootkit search either. Offhand I don't remember whether Malwarebytes checks for that.

Thanks for the good news /bad news, lol...

Take care...

Robert...

 

Are you saying the hibernation problem predates your installation of Rx or since the Rx installation?

I would suggest that you consider doing the following:

Image the drive with Rx installed (just in case)

Uninstall Rx

Allow the PC to go into and out of hibernation a number of times to see if the problem persists or disappears

If it persists do what you have to to try to resolve the problem

Image the drive again

Reinstall Rx.

It is possible that simply uninstalling and reinstalling Rx will clear the hibernation problem, hopefully that is all it would take, so if the hibernation problem has occurred only with Rx installed then a reinstall may do the trick.

As to the long snap,,,I had that occur once. I did not wait for it to go to completion but powered the PC off and rolled back to the previous snap (I have Rx set to auto snap hourly). I have no idea what the problem was but it never occurred again and I saw no ill effects from the actions I took.

Please note,,,,,it is VERY important that you regularly image your drive. Rx is awesome and very reliable but crap happens.

Better safe than sorry IMO.