If Drive Cloner and RollBack Rx work-----

The problem with the current version of RBrx is the MBR offered for imaging is the special RBrx MBR (it used to be a standard Windows MBR under v9.1). This RBrx MBR knows all about the sub-Console environment and the underlying non-Windows snapshot structure, BUT... none of that is imaged during a HOT imaging session. Only the known Windows file structure is imaged under a HOT operation. When the incomplete HOT image is restored including the special RBrx MBR, the special MBR is left without anything to work with and goes off into strange states associated with Windows.

That's why I say without MBR manipulation, a HOT restoration can not operate properly, or even at the right place. The manipulation works like so... first you restore your HOT RBrx image (which contains only the last CURRENT WINDOWS SYSTEM STATE within it, no snapshot data or database controlling it), then you re-install a STANDARD WINDOWS MBR and BOOT, and the normal MBR will vector to the proper place in the PBR (Partition BOOT Record) and bring up that CURRENT SYSTEM STATE you just restored. Upon BOOTing, your system will be at its last state before imaging but it will have some neutered RBrx Windows-based components which will not operate correctly.

At this point, to continue operating with RBrx, you need to unINSTALL it, reBOOT then reINSTALL it with that system state as its baseline.

 

PV, under v9.1 it used to hide the special RBrx MBR during imaging and deliver the saved pre-installation MBR during that process. Under v10.X it has stopped doing that and only delivers the special MBR for imaging. I think they wanted to hide their special structure from prying eyes. Why they stopped that, I have no idea...

 

Gotcha. As to why, could it be to make hot imaging an RG system more difficult with disk-imagers other than DC6? -Nah.

 

Small correction:
With the current RBRX 10.2 uninstalling and rebooting is no longer required. Just reinstall, the previous installation will be uninstalled automatically.


Cheers
manolito

 

You do have a point,,,,,however the DC solution does not exist yet and the claim is being made now. More or less the same claim as has been made for years so.........

 

I certainly hope that are getting our message because I (for one) believe RB is the best of the snapshot products out there and now with solid evidence of DC soon fulfilling its promise, to my eyes will together be a 'dynamic duo'.

 

Hi manolito,

I take it you are successfully restoring hot backups of your RB 10.2 system by restoring a standard Windows MBR (which you saved for that purpose) before restoring your hot backup, and reinstalling RB after restoring your hot backup. After doing that, the most recent (current) snapshot is up and running as RB's baseline (installation) snapshot. Do I have that right?

pv

 

Not quite Pete. I believe manolito made a backup of his std. Windows MBR before installing RB. So it's a two step restore process. First he restores the std. MBR (made before RB was installed) and then he restores the hot backup but not the MBR that was captured by the hot backup!

I don't think it would matter if the std. Windows MBR is restored before or after restoring the hot image, but as Froggie has pointed out, restoring the MBR from a hot backup (of a RB 10.2 system) will result in a sytem 'mish-mash'!!!

 

Thanks, Mabolito...

 

As long as SP has the capability to write a STANDARD WINDOWS MBR after the restore, it should fly <gulp!>

That "server error" li'l Window you get after BOOTing up (as kryptic as it can be) is an RBrx indication that its normal stuff is not available.

 

No, I first restore the Hot Backup, then I restore the MBR which I have saved before installing RBRX. I believe this order is important, because restoring the Hot Backup will also restore the MBR which in this case is not the standard Windows MBR. At least with Acronis and AOMEI there is no way to deselect the MBR when restoring a whole disk backup.

The procedure is quick and easy if you use a PE based rescue CD which lets you get into a console window. BootICE and the saved MBR reside on the same external HDD as the backup, so I can directly start BootICE after restoring the backup.

This works reliably on my Win7 32-bit installation. What I'd really like to know is if on a GPT based HDD under Win8.1 64-bit it will also be enough to restore just the MBR, or if it is necessary to restore the whole track 0. Can't test this myself...


Cheers
manolito

 

I can't completely answer your question but I know for UEFI (not LEGACY) system, they don't even use the MBR... the UEFI BiOS BOOTs right into the EFI partition directly where the new partition table lives... I think a lot of stuff goes on there. There is a provision of sorts to use the ol' MBR (sector 0) but it's very different than using it the old way.

One of these days I'll class up on UEFI, EFI partiton layouts and the EMBR (Extended MBR) if it even exists in the new EFI flow. You can jump into WikiPedia and take a gander at the UEFI spec... you'll see where lots of stuff goes on in the EFI SYSTEM partition on GPT disks only.

 

That's very strange, I use both ATI 2014 and Drive Snapshot. In both of those disk-imagers restoring the MBR is definitely a user selection option during the restore procedure. In ATI 2014 that option is under 'What to Restore'. Which ATI are you using? Under 'normal' imaging situations restoring the MBR/Track0 is not often needed/wanted, so any disk-imager that doesn't allow you to avoid restoring the MBR is too limited.

Can't help you there; I've avoided W8.x like the plague!

 

Oh I see what you mean...
Before I do a restore I always wipe at least the first couple of sectors of my HDD. And if the backup software doesn't see an MBR on the target drive, it does not offer the option to deselect the MBR. You can deselect it only if there already is a valid MBR on the target HDD.

Cheers
manolito

 

Does selecting sector-by-sector alter the availability of restore MBR options?

 

It doesn't matter (with the disk-imagers that I'm using).

 

manolito, I'm interested in learning the benefit from doing that?

 

I still don't see the benefit of doing that? It's more effort and more time-consuming, so what do you gain insofar as restoring your backup image?

 

@ pvsurfer

Actually there are two reasons why I regularly wipe the first few sectors of the target HDD before attempting a restore:

First one is that Acronis (older versionS at least) seem to do cold restores differently depending on what they see on the target drive. It happened to me several times that after I had a non-bootable Windows (had nothing to do with RBRX) and then making a cold restore of the whole disk including MBR and track 0, Windows still would not boot. Wiping the first couple of sectors always took care of it. Seems like Acronis only restored track 0 completely when it saw a totally unallocated HDD.

Maybe this is just an Acronis peculiarity (Pandlouk will probably know more about it), but it made me change my standard restore procedure.

The second (and more important) reason is that I believe that any backup strategy is worthless if you have not rehearsed restoring more than once. And after a real disaster you cannot assume anything about your target drive. I learned that the hard way...

Maybe some of you remember the transition phase from IDE to SATA. And starting with Vista the AHCI mode became universal. At that time the Linux based rescue media of most backup software did not understand AHCI. So many users made perfect backups under Windows, and verification worked flawlessly under Windows. So they felt safe until one day they had to make a restore. Only then they discovered that the rescue media did not see their target HDD.

Bottom line:
Whenever I test different backup strategies (like using image based backups together with RBRX), I also rehearse restoring under worst case conditions (which means a totally wiped HDD). Assuming that any of the RBRX structures will still be intact at the time when you restore is simply too dangerous.



Cheers
manolito

 

As of right now mainly the personal. However there is always room for improvement. So I want to ask you guys what would you like us to do to better Rollback RX?

 

Hi Shane! One of the big problems I see with your product is that it's too specific. By that I mean it works generally under most circumstances but fails miserably under others. I just watched one of your users work with your Dev team for more than 9-mon. trying to solve a HARD problem (a consistent failure)... NADA. He wound up walking away in disgust. I see this with others, too... they work very hard trying to help HDS solve their problem and a conclusion is never reached.

I, myself, used v9.1 reasonably successfully for a long time but had to back away when v10.2 appeared due to the flakey nature of the release... clearly you folks didn't have a good handle on UEFI/GPT and still don't on Windows 8.1.1... there's just too many areas that can affect a product like RBrx that aren't under your control. I tried to jump back in after v10.2 was released and my first attempt to use the product ended with a BLACK screen... and this was the exact same system that ran v9.1 for a few years. After working with the Devs for a while they said my MBR was not "standard." Turned out my MBR was totally "standard," just not Microsoft-like... but it met all the structures and specs available for manipulation of the MBR. After some back and forth, HDS agreed and came up with some sort of change that worked in my situation... but I couldn't be sure that it wasn't a change unique to my configuration to get it running. It was clear that HDS had been making assumptions along the way about MBRs instead of designing to the available spec at the time. I believe some changes were made to the custom RBrx MBR that were integrated into the general production release... that's a good sign. But I'm really afraid of these "special" fixes for users that may not really make their way into the product overall.

The big thing, of course, is that RBrx DOES NOT protect the user against all these possible failure modes that users see along the way. The two most obvious ones are MBR RootKits and protected disk failures. I've been involved with many MBR messes on RBrx systems and they are painful at best and tragic at worst... there's just no way to recover a user's important data, especially if it's located in one of those snapshots. Your special SCAVENGER software is a crap shoot at best in trying to recover many messes on RBrx systems. You've never had any sort of reliable backup or imaging for RBrx systems which to me seems to be the single most important aspect of trying to recover a RBrx system. Under v9.1, users were at least able to recover the CURRENT SYSTEM STATE by doing HOT or LIVE imaging under the protected Windows system. This was possible only because RBrx would hand the imager a phony (i.e, the pre-install version) MBR (rather than the RBrx special one). This gave the user the current HOT system image with a correct (RBrx pre-install) usable MBR... with this he could at least restore his system if needed (after a RootKit virus or HDD failure). Even that little gift was lost in v10.2 as RBrx now hands a HOT image the RBrx MBR along with the CURRENT SYSTEM STATE. If you restore with this, you wind up with an unusable system most of the time (that sub-Console heads off into oblivion)... the user has nothing to work with.

Sharp systems folks have learned to get around this by personally saving their own pre-installation MBR and restoring that after the image restore has been done... this provides them with an operational CURRENT SYSTEM STATE that contains a neutered RBrx which must be dealt with to continue its use. Other folks have bit the bullet and they are RAW imaging the entire RBrx protected area which allows them, in most cases, a successful restoration of a RBrx protected system. But you cannot expect normal users to know how to jump through all these hoops just to get themselves protected while using RBrx... it will not be done. As a result, when these users experience a failure, it's almost always a tragic one with little or no recourse. Some of these Wilders forums are full of ex-RBrx users... many who have gone through just such a scenario. It's very painful... and most couldn't run away fast enough from that type of system. Don't get me wrong... there are many successful RBrx users, and in my view have been very "lucky."

Some suggestions...

1. STOP telling potential buyers, in your marketing literature, that this application can protect them against any kind of failure. Don't be afraid of your weak points... document them so users know what they're dealing with, and use that list internally to strengthen your product (goals).

2. Come up with an operational tool (it would be great if it was integrated into RBrx) that users can use to fully back up their RBrx system, including their snapshots. Imaging has been around for a long time, and when done successfully, restores not only broken systems, but an immense amount of confidence in the user that his system really is protected against EVERYTHING (RootKits, HDD/SSD failures, and as I've seen recently, standard Windows 8.1.1 updates).

I see that Drive Cloner v6 is some sort of attempt to accomplish #2 above... but from my initial testing, this thing has a long, long way to go.

3. Come up with a way for users to protect themselves against MicroSloth updates... this will probably be your toughest challenge. Having users turn off (or in the case of a RBrx installation, turning it off yourself) AUTOMATIC Windows Updates and pre-clearing them in some way through HDS just will not work... you'll never get control of it. Personally, I think the product will require a major redesign (which it really hasn't seen to date) in the Windows environment to allow it to function without all these "peripheral" concerns.

I'm sure there are other suggestions... I hope others will chime in and CONSTRUCTIVELY try to help Shane with this effort. Not many times does a manufacturer open themselves to suggestions... use it wisely