HoizonData Rollback Rx

Froggy,

That really has me confused. I was using Rx v9.1 for close to a year until it totally hosed my system (so now the subject is purely academic to me). During that time I performed several Hot 'Normal' (Used Sectors) backups and always restored them (successfully) without restoring the MBR. I based that on Wilder's member Pandlouk specifically emphasizing to do it that way in a thread re Rollback Rx and Hot Backups (I'm sure that's not the correct title).

Cruise

 

I think that thread was my original thread when we dug into HOT backups with RBrx and IFW.

I don't think I have your complete picture. I don't think you're saying you had HOT Normal backups that were fully RBrx operational after the restoration. I think you're saying (and correct me if I'm wrong) you had an operational Windows system at the last system state and you probably had to unINSTALL/reINSTALL RBrx to continue from there with no previous snapshots. If true, that may have been the case but think about it. If RBrx's MBR was in tact, it assumes tons of hidden structures that would not exist after a Normal HOT restoration (used sectors)... I don't know what it would do. The restoration would occur all over the snapshot data and I have no idea what state RBrx's database would be in, much less the sub-console.

I just may try that under v10.2 just to refresh my brain...

 

Yes, that is what I'm saying. I did several restores that way during my time with Rx and each time my most current state (current snapshot?) was restored perfectly. Of course I had to uninstall, reinstall and reactivate Rx on each such restore. About the only 'glitch' I recall having was that I had to contact HDS a couple of times to reset my product-key so that Rx would activate. But I never restored the MBR because I had read that Pandlouk advised against it.

Cruise

 

Basically my 1 gripe with RB Rx is it's inability to delete totally the snapshot you choose to delete, as an example If I have Adobe Acrobat on snap 1 and through the week take 5 more daily and installation snaps, Adobe is contained in every one of those snaps. If I now choose to delete snap 1 all this does is to increase the size of every other snap taken there after, and Adobe still isn't totally gone, it may be non existent anymore to the point of installation, but it is everywhere else. This is probably why some snapshots are as big as a bus 3GB or more, And frankly there in my mind should have been a way of preventing all this bollocks in the first place.
punishment for this incompetence from HDS should be they should all be sent to the Arctic and mugged by Polar Bears

 

DVD, that's what a Time Machine is all about. It needs to keep the environment valid that existed at the time of the snapshot. It's not like the HG Wells version of the time machine where you can actually change history and return to a point in a single time line that's now changed after that Adobe removal. RBrx provides for many different time lines (alternate dimensions, as they say). When you go back and make a change, you start a brand new time line, you don't modify the original one.

As far as snaps are concerned, there's really one ONE copy of that Adobe installation as far as space requirements are concerned. Anything that was consumed during the installation remains consumed as long as that installation exists in any referenced snapshot. When all references are eliminated, the original space is finally freed up. The assignment of that space as far as snapshot reference databases are concerned will be constantly moved as you eliminate references to it, but the space remains the same and no additional space is required. When all references are finally gone, so is the space utilization (after appropriate RBrx defrags are performed). Although I don't consider HDS approach incompetent, I still believe they need that trip to the Arctic for a lot of other reasons

In HG Wells world, there's only ONE time line, in RBrx's world there are as many as there are snapshots.

...and NO, I'm still not a fan boi anymore

 

Cruise, I think certain recommendations "at the time" do not hold up anymore as RBrx has moved along in its development. I decided to revisit this (against my better judgement) for a quick looksee.

As I mentioned earlier, COLD imaging of a RBrx-protected volume continues to work very well, so I decided to try some HOT imaging on a W7x64sp1 MBR-based laptop with the current RBrx v10.2 release in place... surprised, I was (in my best Yoda imitation). I've only used Macrium so far (will try IFW later) but HOT imaging only "used sectors" (sometimes referred to as NORMAL imaging) then restoring without restoring the MBR (should leave RBrx modified MBR in place) created a barely BOOTable system with many Windows "Corrupt file warnings" and some RBrx task warnings.

COLD restored the pre-test working RBrx system, then did the same Macrium restore as above but also restored whatever MBR RBrx gave me during the imaging process (used to be the standard Windows MBR prior to RBrx installation). This resulted in an unBOOTable system with the "missing Operating System" error. Clearly these results tell me that much has changed with RBrx since its v9.1 iteration and I would need to dig a bit deeper to be able to decipher those changes.

At this point, without further extensive testing, I would say that even HOT imaging is questionable with RBrx v10.2 (I know, some have claimed success). I would need to try the same with other imagers as well as deconstruct the MBR that RBrx is currently using as well as the one offered when RBrx is being imaged. My schedule prevents me from doing so at the moment, but I probably will do some background testing as time permits.

Looks like we're starting off at GROUND ZERO once again with the current iteration of RBrx and imaging...

 

Froggy, ever since my system disaster with Rx I replaced it with Shadow Defender (which doesn't 'mess with the system' like Rx does), so no urgency here. Afaic this is just an academic exercise (albeit an interesting one).

 

..and in the RBRX world each timeline has elemental connections to every other timeline. This means one timeline can extend into and borrow items from another timeline which themselves are yet still from elsewhere. A complex configuration that is error prone as soon as anything disturbs something.

 

Other snapshot software which uses "True Write" technology (RestoreIT, Toolwiz Time Machine, Sysrestore) is less complex because whenever you go back to a previous snapshot, a new timeline is started, but all snapshots from the previous timeline will be lost. Once you go back in your timeline, there is no way to change your mind and jump forward in this timeline again. I prefer the RBRX way...

Cheers
manolito

 

You could say the same about any incremental imaging system.

 

That makes two of us, but it seems like we are in the minority around here. I completely understand that once bitten (in the a$$) twice shy, but fortunately I haven't had any serious problems with RBRx over several years of use. That said, I still make weekly 'cold-raw' image backups (odd weeks with ATI and even weeks with DS).

 

After my additional testing with HOT "Used Sector" imaging with IFW (previously used Macrium with similar results), I would say that these days (RBrx v10.x), PV's approach above (one really good imager should be enough) is the only guaranteed method to get back to a running system of any kind, with OR without snapshots. Things have definitely changed between v9.1 and v10.x as far as imaged MBRs are concerned as well as the sub-Console structure.

The IFW HOT image restore showed that it might work if the unallocated disk structure is still somewhat in tact (probably Track 0) when you do the restore. I tested the restore with untouched unallocated space and the system returned with what appeared to be a functioning RBrx (after some repair stuff during the RBrs HOME screen)... but when you reverted to any snapshot, it always wound up at the last system state prior to the HOT image... I did not test to see whether RBrx was functioning at that point (how can you possibly believe it was). When I ZEROed out the partition prior to the same restoration above, the RBrx HOME screen did what appeared to be some repair stuff then went to a BLACK screen with "missing operating system."

I'm done HOT testing at this point and will say that HOT restore methods with RBrx v10.X are a total crapshoot as far as the disk surface is concerned... a HOT image cannot be relied upon to produce any sort of BOOTable Windows system, especially if you don't know what made the RBrx system fail in the first place. COLD imaging appears to be the only reliable method at the moment.

 

Frog, can we therefore conclude that hot-imaging a v10.2 system is unreliable regardless of whether or not the MBR is restored?

Btw, the only reason I do cold-raw backups with both ATI and DS is that ATI's boot disk is Linux whereas DS runs in a DOS or Windows environment. That way I feel more secure knowing (more accurately, believing) I will be able to boot and recover from any 'disaster'.

pv

 

According to my testing, that is absolutely true.

I fully understand...

 

Well I guess it's back to sector-by-sector backups with my boot cd. For a while there I thought hot backups might be a viable shortcut.

 

Appster... it used to be viable when using v9.1 but v10.x works very differently when setting up the system for LIVE entry. Since you appear to be an XP user, you may want to test out HOT imaging... it may act differently than the later OSes.

 

I read somewhere on HDS that RBxp is based on RBrx v10.2, so your findings should be applicable to RBxp. Froggie, as you seem to be the expert on these matters, I have a question for you. I'm using AOMEI Backupper-Free and if a full cold sector-by-sector image proves to be reliable, would subsequent cold sector-by-sector incrementals or differentials also work on a Rollback system? If not I'll download Macrium Reflect Free (I chose to go with AOMEI-Free only because unlike Macrium-Free it has differentials and incrementals).

 

Unless you know exactly how things work with RBRX and other "modern" file-system butcherings, it's best by default to stay with cold imaging. I was taught this years ago and it seems to hold true today.

Is cold imaging from a boot disc so difficult? For the typical home and small business user this is a secure and reliable method that's tried and true.

 

Keatah, I'm already resigned to doing that, but now I want to know if differential or incremental (cold sbs) backups will work with a Rollback system.

 

COLD RAW (all sector) INCREMENTALs and/or DIFFERENTIALs should restore COLD without a problem but they work differently than normal (used sector) processes. They have to scan the entire storage volume (and compare each disk block) before they know what the changes were. As a result, your images will be reasonably small (like normal) but the scanning time will be as long as a FULL scan. It might just be better to do FULLs each time.

 

Gotcha Mr. Frog. In that case maybe I should use Macrium Reflect instead of AOMEI Backupper (as you've used it successfully in your RBrx testing).

 

If you're gonna do FULL image backups to backup your RBxp system, Macrium FREE is probably the best (it has a long successful history)... IFW PAID seems to be the fastest (at FULL images).

 

In HG Wells World If He had Killed off the Morlock's and left just the Eloy maybe RB Rx would be more friendlier

 

RBrx *IS* a Morlock!