Rollback Rx 9.1 - New Build (July 18, 2011)

Hi again, Scott.

What imaging application app are you using? What indexes are you referring to? And do you mean the RBrx indexes were scrogged after the WinPE-based restore?

 

Hello all,

This post has got me to think a lot on my use of RBRX. Currently I am not using it and am using ATI 2012 by itself. Now my question after reading this thread is this: If I use ATI 2012 to do a sector by sector backup, is this the same as a "cold" or "raw" image and will it work with RBRX to restore all of the RBRX data? I hate to sound ignorant but I have become a bit confused by reading this thread.

Now if I understand all that I have read, Using ATI 2012 doing a sector by sector backup is compatible with RBRX to restore all of its data also (as long as I am also sure to image the MBR and track 0, but do I also need to include the backup of unallocated space within the the ATI 2012 image also? And do I also always use rescue media to take this image too.

As you can see I have became a bit confused but I want to be able to use the two softwares together but retain all of my RBRX data if I do do a restore with ATI 2012. I hope one of you all can help make this a bit clearer to me. I think one problem is all of the terminology I see. It seems each recovery software has its own version of terminology and also when you get to looking around on forums for help you can see some different terminology also. Some of the terms confusing to me are: cold, hot, raw, sector by sector and unallocated space. I just need advice on how to make the two softwares to work together.

 

IFW & DS (trial).

Please read this (and some of the preceeding posts in that thread).

Scott

 

Yes, but you must do the raw sbs backup after booting up with the ATI boot-disk, not from within Windows!

ATI backs-up the MBR everytime you image your volume and by creating a raw image you will backup every sector on the volume including those that Windows hasn't used (which contain the RB snapshots).

The downside to raw cold-images is that it takes more time and more disk storage.

Scott

 

Hi Puff! Let's start with this...

COLD = using the imager outside of the "active" operating system. In the case of ATI 2012, that would be using their recovery disc which runs under a RAM-based version of Linux... not Windows. I believe if you use their "Recovery Zone" (not recommended with RBrx), they also use a RAM-based Linux but it's resident in the recovery zone on the har disk rather than on the CD.

HOT = imaging a primary system partition while running the imager under Windows at that time. This can only be done if Windows is allowed to "lock" its file system while it continues to run. This is done by most imagers (ATI included) by using the Windows VOLUME SHADOW SERVICE. This allows the system to continue while freezing any changes that are attempted to the file system... changes are placed in a temporary place while the image is being taken and they are incorporated back into the system when the VOLUME SHADOW SERVICE request is terminated.

RAW = SECTOR BY SECTOR = ALL UNUSED SECTORS = UNALLOCATED SPACE: basically imaging every sector contained in the partition/disk that is being imaged.

If clear here, we'll move on... otherwise fire away with a question.

ATI has been known to completely restore a RBrx-based system but only when a COLD RAW image is taken. When COLD images are taken, no interference is caused by a running RBrx environment... it's not running 'cause it's in that Windows partition you're imaging, not in the Linux kernel that's running ATI's rescue disk.

With ATI using the Windows VSS to do its HOT imaging, there is NO WAY to obtain a copy of the special RBrx MBR used in its protected system. Why? 'Cause RBrx won't give it to you when you ask for it... remember, it's intercepting every file system/logical disk block request so it can do what it wants with that request. In the case of the MBR, it passes you a bogus MBR, the one present before you installed RBrx. With a non-RBrx MBR in your image, the entire RBRx protected system cannot be restored in its entirety, if you have to do that. The few times I tried variations of ATI to completely HOT image a RBrx-protected system, I had nothing but failure... I had to abandon it as an imaging solution in this environment. The bottom line is that ATI CANNOT do a successful RAW HOT image of an active Windows disk partition protected by RBrx.

To date, the only successful HOT image (to my knowledge) taken of a complete RBrx-enabled system has been done only by the "Image For Windows" imaging application. The reason it can be successful is that it doesn't use the Windows VSS (it can, but it doesn't by DEFAULT) for imaging a HOT system, it uses its own special system driver that operates above (if installed correctly) RBrx's special system driver... it can get its hands on the REAL physical disk before RBrx gets involved.

Gotta run... fire away if you have questions.

 

I am getting more confused by all this rather than less.

Over on the Horizion Datasys forum I posted a question about this topic and one of the gurus did some tests using RollBack Rx and Drive Cloner (which is the imaging program used in this case) his results were positive for restoring a hot image that was made using DC while Rx was installed. The relevant post can be found here http://horizondatasys-forum.com/10700-post21.html

I am confused by the statement above by the rollbackfrog and from the linked to post that if the imaging program made a copy of the original MBR it could restore it. How could it make a copy of this MBR if Rx has been installed and has rewritten the MBR? Presumably the original MBR no longer exists and thus cannot be copied.

I also find there seems to be confusion between simply restoring the state as of the time of the image (hot) as opposed to all the snaps etc (all sector cold). To me this seems to be a point of confusion as Image For Windows keeps being mentioned along with all sector images and this in response (it appears to me) to a question about a simple single snap state (hot image) restoration.

I just want to be sure that if I try to restore from a DC image that was made from within Windows I will get a bootable system. From the linked to post it would appear that the ans is yes,,,at least if you are using DC to create the image. It clearly would be stupid for Horizion to release an imaging program to be used in conjunction with Rx that cannot actually function on a system with Rx installed so I would think I should be able to do exactly that. However the above comments by TRBF seem to suggest this is not the case.

 

Hi bg,

While you and I use different disk-imaging apps, I believe we have the same question, and TheRollbackFrog answered that question quite succinctly in this post.

Here is what I conclude is a fast and reliable way to backup and restore a RB v9.1 system:

Backup:

• Create a normal hot-image backup of your C-volume (without having to first uninstall RB).

Restore:

1. 'Instruct' your disk-imaging app to restore the image's MBR (which should be the original* MBR).
2. Then proceed with the regular restoration of that image.
3. When finished, the system should be bootable into the current snapshot.
4. RB will see that it's integrity has been compromised and will request to be uninstalled - reinstalled.
5. Once that's done all should be good, with the current snapshot serving as the new baseline.

*When we create a normal hot-image RB hides its modified MBR and presents the original MBR to the imaging app.

Scott

PS. I plan to perform the above prodedure this weekend, so if anyone believes it's not correct please let me know!

 

Scott, you have provided a very nice and useful outline. While for the most part I agree with your conclusions, it really shouldn't be necessary to restore the MBR. I believe that RB v9.1 will recognize integrity issues (and ask to be uninstalled and then reinstalled) regardless of whether or not the MBR is restored.

JA

 

Hi, As a new RB user, I was led to believe that RB had to be uninstalled in order to make an image with our favorite image app. The reason being that not uninstalling would use up a lot of free space, and apparently as I read the above posts would screw up the MBR. So rather than do as you suggest here, which asks you to uninstall RB anyway, why not uninstall up front, do your imaging and then re-install as I was told to do? I'm looking for the easiest way to go with the least amount of work. I have yet to do this, and am not schooled in too much manipulation of software, so I don't want to get too deep into restoring or not restoring the MBR etc.

 

Hi, that is the official recommendation and while doing that obviously works I don't find it to be necessary and it's a major inconvenience (if I had to do that, I might as well do cold-imaging)!

Ah, consider this... a sound backup plan calls for regular backups. For example, I now create a hot-image twice a week and it would be a huge nuisance to have to uninstall-reinstall RB every time I backup! On the other hand how often are you likely to restore your backup? I would just do it when RB can't get it done (and that's not very often). So which method is easier and a lot less work, uninstalling-reinstalling RB every time you run a hot-image backup, or just on those rare occasions when you find it necessary to restore an image?

JA

 

Sounds like logical advise. If RB restores my snapshot to a previous one and saves my bacon when necessary, I don't think I'll need to restore an image except in a dire occasion. So I don't think creating a new image would be necessary too often, except when a new image is very different from a previous one. Once a month or so.

 

While I don't know anything about your computer-use, you never know when that 'dire occasion' will raise its ugly head, so you have to ask yourself - "can I afford to lose a month's worth of updates (data, docs, email, or whatever)"?

 

Thank you Scott and Jo Ann, much appreciated (and relieved I might add).

 

I'm glad my procedural outline was of value, but everything I wrote just summarizes what I've learned from others, especially Aaron Here (who hasn't been around for quite a while), Jo Ann, and TheRollbackFrog.

 

So you think I should create images more often like twice a week, and if I understand right I can take hot images without uninstalling RB? I'm not up on the MBR thing though.
Getting back to your post #83 where you say RB will ask to be uninstalled and re-installed, I still don't see the difference if I do it up front.

 

I am going to take the liberty of answering even though your question was directed to Jo Ann, I hope neither of you mind and Jo Ann, if I get anything wrong I look forward to being corrected.

As Jo Ann wrote (and I agree) how often you image depends on your computer use and level of comfort. I have been hot imaging weekly but I upload critical files to an on-line storage facility (iDrive) nightly. I feel this is sufficient since I will at most have to restore my system a max of 1 week back and then I can quickly grab the critical data files from iDrive and be back up to current in short order. With this procedure I can sleep well at night and thats what I suggest you aim for,,,that is sleeping well at night. If once a month suits you thats what you should do. If you feel you need (or want) to image daily then thats what you should do. Its all about what you feel is necessary for you to be comfortable.

I should mention that I have NEVER had to do a restore over the last 3.5 years since Rx has always gotten me out of trouble, so really, the images are simply an extra layer of protection and will have to be used only rarely if at all. What brought this issue to the fore for me was an incident that occurred while I was doing my monthly PC housecleaning with Rx uninstalled. I did not realize there was a problem until I had reinstalled Rx and was considering using my DC image to restore to a state before the housecleaning was carried out when I realized I was not sure this would be the correct thing to do. Thus my questions and concerns. Now I know doing so would have been fine.

The answer to this is yes as long as your image program of choice will include the non RollBack Rx MBR as part of the image (I think it was the RollBackFrog who posted this earlier in this thread).

Neither was I which is why I have been following this thread (and participating) with a lot of interest. I am comfortable now that the MBR will not likely be a problem for me using my imager of choice (Drive Cloner) to do hot images.

The difference is there is a small likely-hood of having to restore using the image so there will be few if any occasions where you have to uninstal and reinstall Rx because of this. That is, you will have to do this only if you do have to restore from an image. On the other hand, if you are imaging weekly (or worse 2x a week) uninstalling and reinstalling Rx each time you make an image can be something of a job.

I hope this has helped

 

Hi Goodman4, Thanks for your response. How do I determine that my image software (Active@Disk Image) includes a MBR?
So you're saying I only have to uninstall RB before I do an image restore? That would be great. I have never had to do a restore since I got my first computer in 1997.

 

No.

What they are saying that before imaging (taking an image), it is better to un-install Rollback Rx and then re-install Rollback Rx after imaging.

After you un-install Rollback Rx and before imaging, you can do disk maintenance like defrag, wipe unused space and so forth.

Best regards,

KOR! (aka aladdin).

 

@ both KOR & twl845, I think you guys should carefully re-read posts 82, 83 and 85 (above)...

 

Hi Scott! The only anomaly with your above plan and expectations is the 3rd item under Restore... Rollback will indeed see that it's integrity has been compromised but it will NOT ask for anything. When the RBrx Application Console tries to start under Windows, it will find the Rollback sub-System NOT RUNNING (following the restore) and will just remain idle (if it stays in the SystemTray, I believe it will not color itself if it isn't active. The icon before the July release used to remain GRAY and not take on color when this happened. It also may disappear from the System Tray). It will not request anything of the user (unless they changed that in the July (really August) release.

All else should be as expected...

 

Believe me... it's easy

If I ever said that, I was wrong...

I will try to summarize as best I can...

Any imaging program that uses the Windows VSS (Volume Shadow Service) during a HOT image (an operation occuring under the operating Windows system partition that's being imaged) will receive, via RBrx, the following data to the imaging program...

The current system state of the active Windows partition...
The MBR that was present PRIOR to RBrx's installation...
No operational RBrx sub-Console subsystem...
No RBrx snapshot data...

As a result of restoring the above image to your system partition, you will have the last system state at the time of imaging and NO active RBrx protection system. The RBrx installation files will still be in their appropriate folder, but the active RBrx system has been neutered by the HOT image.

The system will run fine WITHOUT the operational RBrx. If you want the RBrx system operational, you must unINSTALL the current leftovers (this takes longer than usual due to the unINSTALL procedure waiting to see if the RBrx sub-Console is active), reBOOT your system, and reINSTALL RBrx.

To my knowledge (since I have not tested it directly), DRIVE CLONER is of the imaging type that uses the Windows VSS to do its HOT imaging. If it does not restore the imaged MBR by DEFAULT, the restoration will fail to produce a BOOTable system. Why? 'Cuase the leftover RBrx MBR will not work properly with a neutered RBrx system. If DC images the MBR offered, and the user has the ability to restore it... indeed the resultant restore should function properly (with a neutered RBrx).

The only imager I have found that doesn't use Windows VSS for its HOT imaging (but can be configured to do so) is "Image For Windows"... and the above summary for VSS-based HOT imagers does not apply to IFW (unless specifically configured to do so).

COLD imaging is a whole different ballgame...

Feel free to ask questions if the above still isn't clear.

 

Hi Jo Ann! Your assumption above should not not happen. During the RESTORE operation of a HOT image, the MBR must be restored if the restoration and the subsequent BOOT are to be successful.

Since RBrx is neutered during the HOT image, the leftover (unRESTORed RBrx MBR) will attempt to start the RBrx sub-Console system during the BOOT operation... this cannot happen with the entire sub-Console system missing from the neutered restoration. My experience has shown that an active RBrx MBR, without a sub-system in place, will either HANG with a blinking cursor or stop at a BLACK SCREEN... some have reported BSODs but I've never seen that.

 

Hey Frog, thanks for the clarification on my Restore Item #3.

Frog, as indicated in post 78 (above) I'm using both IFW and a DS trial version. From what I see in DS' Advanced Options (the default setting) it too uses a proprietary Windows-locking-mechanism unless the user specifies VSS.

I'd also appreciate hearing any ideas you may have regarding the indexing errors I get as an 'after-consequence' of booting-up with the Active@ Boot Disk - see my link in post 78.

Scott

 

Thanks for your explanation. According to the above, you ultimately still have to uninstall and re-install RB. It looks pretty involved to me. As I mentioned earlier, wouldn't it be easier to do as RB directs and uninstall RB first, do your imaging etc. and re-install RB? I ask as a novice to imaging/RB procedure.

 

twl845,

No it's not "easier to do as RB directs". It's actually much easier to do what has been described above. But it your decision and it's as simple as this...

1. If you go along with the official recommendation, you need to uninstall-reinstall RB every time you backup (however frequent that may be)!
   
2. If you follow the above advice you only have to uninstall-reinstall RB when you restore (which shouldn't be very often)!

Either way works, but it should be obvious that method 1 is far more labor-intensive than method 2 simply because backups are performed frequently whereas restores are infrequent...

Scott