RollBack RX question

[bgoodman4]

When you take a snapshot are you doing incremental or differentials? I suspect/hope they are differentials because if not when you clear snapshots from a set if the snaps were incremental you would lose the integrity of the set.....unless the next snap makes up for the gap somehow.

Also, I know its very individual but how many snaps is it reasonable to maintain? I ask because when the snaps are defraged if there were hundreds of them it could take a fair bit of time to run.

Here is how I have things set up at the moment.

Upon boot a snap is made and is automatically locked. Each hour a snap is made but is unlocked. At the end of the day, if nothing troublesome has occurred, I delete all of the hourly snaps and power down the PC.

I am wondering if you folks think this is a reasonable approach or would it be fine to just leave the snaps accumulate and have Rx simply delete the oldest unlocked snaps as space is required?.

[demoneye]

Rollback RX make a incremental bacup ;D

according to rollback documentation u can make up to 65,000 snaps , so your approach is ok, u can always make a full back up using its build in drive image (in ver below 8.1)

[Peter2150]

Rollback snapshots aren't really either incremental or differential, those are imaging terms.

A rollback snapshot, is literally a picture of what your system looks like at the time you take the snapshot.

So if you take snapshot A, and then add 10 files, take snapshot B then delete 5 of the files and take snapshot C, then go back and delete B, when you go to C it will have the system the way it was with A, but only with the 5 new files you didn't delete, The other 5 are gone. I suppose in a way it's incremental, but it's better to really understand what is going on.

Also when you take a snapshot, no files are created or deleted. Simply a table pointing to the file sectors is updated.

Pete

[Jo Ann]

-{ Quote: "When you take a snapshot are you doing incremental or differentials? I suspect/hope they are differentials because if not when you clear snapshots from a set if the snaps were incremental you would lose the integrity of the set.....unless the next snap makes up for the gap somehow." }-
Although Wikipedia (http://en.wikipedia.org/wiki/Rollback_Rx) refers to RB snapshots as 'incremental sector redirection', in actual use RB snapshots behave similar to differential image backups. I say this because deleting one or more interim snapshots does not 'break the chain'. If they were truly incremental, deleting just one interim snapshot would irreparably destroy your ability to restore any snaphsot taken subsequent to the one you deleted.

-{ Quote: "Also, I know its very individual but how many snaps is it reasonable to maintain? I ask because when the snaps are defraged if there were hundreds of them it could take a fair bit of time to run.

Here is how I have things set up at the moment.

Upon boot a snap is made and is automatically locked. Each hour a snap is made but is unlocked. At the end of the day, if nothing troublesome has occurred, I delete all of the hourly snaps and power down the PC.

I am wondering if you folks think this is a reasonable approach or would it be fine to just leave the snaps accumulate and have Rx simply delete the oldest unlocked snaps as space is required?." }-
As you suggest, it is purely an individual preference. I allow snapshots to accumulate until I create my weekly disk-image (on a weekly basis, I tend to accumulate about a dozen or so snapshots). Once I have created that system-image backup (including all RB snapshots) I update the RB Baseline which optimizes RB's mapping (as well as freeing up disk-space). Then I start a new (fresh) week ...that process works for me. ;)

[Baldrick]

-{ Quote: "...I allow snapshots to accumulate until I create my weekly disk-image (on a weekly basis, I tend to accumulate about a dozen or so snapshots). Once I have created that system-image backup (including all RB snapshots) I update the RB Baseline which optimizes RB's mapping (as well as freeing up disk-space). Then I start a new (fresh) week ...that process works for me. ;)" }-
Ditto here...except that I do hourly snapshots which allow a good deal of granularity vis-a-vis where you can roll back to...but then disk space used by the snapshots over a week is not an issue for me.

Cheers ;D

[appster]

-{ Quote: " I allow snapshots to accumulate until I create my weekly disk-image (on a weekly basis, I tend to accumulate about a dozen or so snapshots). Once I have created that system-image backup (including all RB snapshots) I update the RB Baseline which optimizes RB's mapping (as well as freeing up disk-space). Then I start a new (fresh) week." }-
I pretty much do the same thing. The only procedure that I add to this process is that once per month I defrag my system drive before updating the baseline. Doing this results in a substantial increase in the size of RB's current snapshot, but that is completely remedied with the subsequent baseline update. The only caveat to running a disk defrag with RB installed is to be sure you have ample free disk space before doing it - otherwise you are inviting trouble!

[Aaron Here]

-{ Quote: "....once per month I defrag my system drive before updating the baseline. Doing this results in a substantial increase in the size of RB's current snapshot, but that is completely remedied with the subsequent baseline update. The only caveat to running a disk defrag with RB installed is to be sure you have ample free disk space before doing it - otherwise you are inviting trouble!" }-
Hi appster,

EAZ's & Horizon's FAQs advise against running disk defraggers with EF/RB installed (suggesting that it doesn't do any good). Since you defrag your system drive (monthly) with RB installed - am I to conclude that you are deriving a performance improvement after doing that?

Aaron

[ratchet]

Although just a rookie in this whole snapshot software behavior I still have one observation after using AyRecovery since December. After I uninstall it I run JKDefrag and I don't even think the whole process takes much more than about two minutes, when normally it would take at least 10 to 15, so I would say the snapshot defraging works just fine. I've uninstalled it every two weeks so I can make a Ghost image.

[appster]

-{ Quote: "Hi appster,

EAZ's & Horizon's FAQs advise against running disk defraggers with EF/RB installed (suggesting that it doesn't do any good). Since you defrag your system drive (monthly) with RB installed - am I to conclude that you are deriving a performance improvement after doing that?

Aaron" }-
Yes, I do see a performance improvement after defragging. I use most of the MS Office apps and after a few weeks I notice that it takes longer for my docs, worksheets and databases to open. I find that monthly defrags remedy that.

I suspect that the reason Eaz/Horizon discourages disk defragging is because by its very nature defragging relocates files and RB sees all of that as data changes requiring extensive re-mapping in the current snapshot (RB doesn't know that the files themselves have not changed). This can bring about extremely large snapshots (and slow operation)! By updating RB's baseline immediately after defragging, RB re-optimizes its sectors map and frees-up disk space. ;)

Of course all individual snapshots are rolled-up into the updated baseline, so in order to preserve those snapshots I always create a sector-by-sector image backup of my system drive before updating the baseline.

[bgoodman4]

Thanks for all the comments. They are much as I had expected but thought it makes sense to be sure. I have done a number of restores and have not had any problems so it seamed reasonable that the snaps are more like differentials than incremental. As to defraging Horizon indicates you should only use RBs built in snap defrag utility. There is no statement that defraging should be eliminated completely, just that you should not use any defrag program other than RBs if RB is installed.

Regarding freeing up disk space I did not think this was a real issue since the promotional material indicates something like the ability to store 60,000 snaps on (I think) .7% of the drive. Even if its 7% of the drive its still not much. My concern here was more with the time required to defrag 1,000 of snaps upon boot. Or are previously defraged snaps not re-defraged? If they are not, and only snaps taken since the last defrag are dealt with by a new defrag, then this concern disappears and there is no issue.

[Baldrick]

-{ Quote: "Regarding freeing up disk space I did not think this was a real issue since the promotional material indicates something like the ability to store 60,000 snaps on (I think) .7% of the drive. Even if its 7% of the drive its still not much." }-
Hi Bgoodman

I do not think that the 0.7% of the drive thing is well understood. This relates I believe to the amount of space that RB Rx uses to store the snapshots but infact the critical thing here is the amount of space that is 'locked' by the snapshots, ie, cannot be reused and is therefore effectively consumed as a result of snapshotting...a subtle but important difference. If you look at the main panel of the RB Rx GUI you will see 'Used Space' and that indicates the amount of space that is 'locked' and therefore unusable by the system until all existing snapshots are deleted or the baseline is redone. If you monitor this you can see that eventually you will run out of disk space depending on how much free disk space you have when you set the base line.

So my thoughts are (i) forget the 0.7%, (ii) concentrate on the 'Used Space' and (iii) go for a snapshots every x for y weeks (you fill in the variables...but iin my case it is x = 1 hour & y = 2 weeks) and (iii) after y weeks defrag, take a full image and then reset the base line. (if using v8.1 you need to uninstall RB Rx if using v9 there is now the ability to defrag without uninstallation).

Just my thoughts for what they are worth...but then I may be wrong so if I am then some one plase correct me!

Cheers ;D

[bgoodman4]

-{ Quote: "Hi Bgoodman

I do not think that the 0.7% of the drive thing is well understood. This relates I believe to the amount of space that RB Rx uses to store the snapshots but infact the critical thing here is the amount of space that is 'locked' by the snapshots, ie, cannot be reused and is therefore effectively consumed as a result of snapshotting...a subtle but important difference. If you look at the main panel of the RB Rx GUI you will see 'Used Space' and that indicates the amount of space that is 'locked' and therefore unusable by the system until all existing snapshots are deleted or the baseline is redone. If you monitor this you can see that eventually you will run out of disk space depending on how much free disk space you have when you set the base line.

So my thoughts are (i) forget the 0.7%, (ii) concentrate on the 'Used Space' and (iii) go for a snapshots every x for y weeks (you fill in the variables...but iin my case it is x = 1 hour & y = 2 weeks) and (iii) after y weeks defrag, take a full image and then reset the base line. (if using v8.1 you need to uninstall RB Rx if using v9 there is now the ability to defrag without uninstallation).

Just my thoughts for what they are worth...but then I may be wrong so if I am then some one plase correct me!

Cheers ;D" }-

Thanks for this, it makes perfect sense to me. I never did understand the .7% thing, mind you, I don't understand much of how RB works. The idea that snaps are so small yet can return your PC to a prior state is very puzzling. I know (since it was posted elsewhere) that RB is not imaging the drive but mapping the pointers (whatever they are) but if files are missing because they have been deleted how can changing the pointer restore the file? Very mysterious but hey as long as it works, thats all that really counts.

[Peter2150]

-{ Quote: "Thanks for this, it makes perfect sense to me. I never did understand the .7% thing, mind you, I don't understand much of how RB works. The idea that snaps are so small yet can return your PC to a prior state is very puzzling. I know (since it was posted elsewhere) that RB is not imaging the drive but mapping the pointers (whatever they are) but if files are missing because they have been deleted how can changing the pointer restore the file? Very mysterious but hey as long as it works, thats all that really counts." }-

The reason it works with a deleted file is after you take a snapshot, the file is deleted from that snapshot, but the sectors a previous snapshot is aware aren't removed, so changing the pointers back now points to those sectors that still contain the data.

Pete

[bgoodman4]

-{ Quote: "The reason it works with a deleted file is after you take a snapshot, the file is deleted from that snapshot, but the sectors a previous snapshot is aware aren't removed, so changing the pointers back now points to those sectors that still contain the data.

Pete" }-

Is this not unreliable? What happens if you write over the file? I guess this is less of an issue if you don't let too much time pass between the creation of baselines (or rather between the current snap and the one you want to revert to) and if this is correct then it points out the added importance of regular imaging of the drive. I had thought that imaging was only important in terms of a drive melt down but I now suspect this is incorrect.

Interesting program and one that a user needs to have something of an understanding about how it works in order to make proper use of (I think).

[ratchet]

You seem to be one of the definitive authorities on combining "snapshot" and "image" softwares so I turn to you. Does Ay need to be uninstalled before making the ESET SysRescue CD? Thank You!

[Peter2150]

-{ Quote: "Is this not unreliable? What happens if you write over the file? I guess this is less of an issue if you don't let too much time pass between the creation of baselines (or rather between the current snap and the one you want to revert to) and if this is correct then it points out the added importance of regular imaging of the drive. I had thought that imaging was only important in terms of a drive melt down but I now suspect this is incorrect.

Interesting program and one that a user needs to have something of an understanding about how it works in order to make proper use of (I think)." }-

HI bgoodman4

You address a controversial subject...reliablity. Basically what the rollback family is doing is taking all windows IO and redirecting it thru a kernel level driver to it's own file system where it keeps track of where all the various snapshot sectors are. When working properly it works very well. However some people have had problems with it as if the rollback file system get's messed up, several snapshot can be lost. Early on system crashes were a problem, but the latest versions seem fine.

As to imaging, there are many reasons to image. I use FDISR, but if I am installing something that could really impact the system, I'll image first, and then if there is a problem just restore. Drive failures are just one of many reasons to image.

Pete

[Peter2150]

-{ Quote: "You seem to be one of the definitive authorities on combining "snapshot" and "image" softwares so I turn to you. Does Ay need to be uninstalled before making the ESET SysRescue CD? Thank You!" }-

Hi Ratched

Not sure who you are addressing this to, but if me, I really have no idea what the Eset SYSrescue CD is.

Pete

[ratchet]

-{ Quote: "Hi Ratched

Not sure who you are addressing this to, but if me, I really have no idea what the Eset SYSrescue CD is.

Pete" }-
Jo Ann usually jumps in these threads so that is why I addressed her. Here is the ESET NOD32 quote about their latest v4 product: "System Tools — ESET SysInspector and ESET SysRescue simplify diagnosing and cleaning of infected systems by allowing deep scans of system processes to find hidden threats, and creating bootable rescue CD/DVD or USB drives to help you repair an infected computer."

[Peter2150]

-{ Quote: "Jo Ann usually jumps in these threads so that is why I addressed her. Here is the ESET NOD32 quote about their latest v4 product: "System Tools — ESET SysInspector and ESET SysRescue simplify diagnosing and cleaning of infected systems by allowing deep scans of system processes to find hidden threats, and creating bootable rescue CD/DVD or USB drives to help you repair an infected computer."" }-

Ah. One thing to consider. Say one of your Rollback snapshots gets infected, that bootable CD probably won't ever see the snapshot files. At best all it will see is the baseline.

If you build it from your system, it might work from a snapshot, but to be sure, I'd consider unstalling any Rollback variation.

Maybe some who's done it will step in.

Pete

[Jo Ann]

-{ Quote: "You seem to be one of the definitive authorities on combining "snapshot" and "image" softwares so I turn to you. Does Ay need to be uninstalled before making the ESET SysRescue CD? Thank You!" }-
ratchet,

I'm hardly an authority (but i'm flattered that you consider me to be one). I can't give you a definitive answer to your question as I don't have any experience with those specific applications. However my best guess is that you should not have to uninstall Ay before creating any kind of Boot CD. But as Pete suggests, any AV scan performed from a boot CD will likely scan only Ay's baseline snapshot, so the use of a Boot CD for AV scanning would be of limited value while Ay is installed.

JA

[ratchet]

Thank you both for the input!

[bgoodman4]

-{ Quote: "HI bgoodman4

You address a controversial subject...reliablity. Basically what the rollback family is doing is taking all windows IO and redirecting it thru a kernel level driver to it's own file system where it keeps track of where all the various snapshot sectors are. When working properly it works very well. However some people have had problems with it as if the rollback file system get's messed up, several snapshot can be lost. Early on system crashes were a problem, but the latest versions seem fine.

As to imaging, there are many reasons to image. I use FDISR, but if I am installing something that could really impact the system, I'll image first, and then if there is a problem just restore. Drive failures are just one of many reasons to image.

Pete" }-

Well I am glad to have found this out now rather than after there was a problem. I will take the appropriate steps to protect against this. Would I be correct that not deleting any snaps between imaging and new baseline creation reduce the probability of problems or is the daily writing of data to the drive still likely to overwrite a file that may be needed? Seems to me this issue would make RX much less secure as a way to deal with malware. Seems to me if malware overwrites or corrupts a system file RX will not be able to recover the system. They sure do not address this point in any of the literature on Horizons website.

[Peter2150]

-{ Quote: "Well I am glad to have found this out now rather than after there was a problem. I will take the appropriate steps to protect against this. Would I be correct that not deleting any snaps between imaging and new baseline creation reduce the probability of problems or is the daily writing of data to the drive still likely to overwrite a file that may be needed? Seems to me this issue would make RX much less secure as a way to deal with malware. Seems to me if malware overwrites or corrupts a system file RX will not be able to recover the system. They sure do not address this point in any of the literature on Horizons website." }-

I wouldn't worry to awfully much. Just test under the normal working conditions you use, and if okay you should be fine.

I had problems, but in fairness, I was stressing my system with beta testing stuff, and also I have a raid 0 system and they don't officially support it.

If it's working I wouldn't worry to much, but periodically uninstall and make a good image. Then you should be good to go. Just understand the way it works.

Pete

[nexstar]

-{ Quote: "Well I am glad to have found this out now rather than after there was a problem. I will take the appropriate steps to protect against this. Would I be correct that not deleting any snaps between imaging and new baseline creation reduce the probability of problems or is the daily writing of data to the drive still likely to overwrite a file that may be needed? Seems to me this issue would make RX much less secure as a way to deal with malware. Seems to me if malware overwrites or corrupts a system file RX will not be able to recover the system. They sure do not address this point in any of the literature on Horizons website." }-
It is important to understand that RollBack replaces the Windows drivers with its own so it controls what gets written to, or deleted from, the disk. Once it is installed, the pre-installation files will remain on the disk untouched. Any changes to those files will be recorded on sectors that only Rollback knows about.

This is very efficient in one sense because your data is only stored once on the disk but this is also the achilles heel as any software which is allowed to write to the disk directly (without the RB driver running) has the chance of writing to sectors used by RB and so corrupting what RB has carefully secreted away. This makes imaging a RB system equally as important as any other non-RB system but, as long as you don't do unwise operations then it will provide great benefits in being able to go back and forth in time on your system.

Graham

[appster]

-{ Quote: "....but this is also the achilles heel as any software which is allowed to write to the disk directly (without the RB driver running) has the chance of writing to sectors used by RB and so corrupting what RB has carefully secreted away." }-
As you indicated Graham, any low-level program that bypasses Windows when writing to disk can corrupt RB, so such programs must be avoided when running RB!

-{ Quote: "This makes imaging a RB system equally as important as any other non-RB system but, as long as you don't do unwise operations then it will provide great benefits in being able to go back and forth in time on your system." }-I would go as far to say disk-imaging is the very most important of all - representing the 'last line' of recovery.

[bgoodman4]

-{ Quote: "I wouldn't worry to awfully much. Just test under the normal working conditions you use, and if okay you should be fine.

I had problems, but in fairness, I was stressing my system with beta testing stuff, and also I have a raid 0 system and they don't officially support it.

If it's working I wouldn't worry to much, but periodically uninstall and make a good image. Then you should be good to go. Just understand the way it works.

Pete" }-

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.

[bgoodman4]

-{ Quote: "It is important to understand that RollBack replaces the Windows drivers with its own so it controls what gets written to, or deleted from, the disk. Once it is installed, the pre-installation files will remain on the disk untouched. Any changes to those files will be recorded on sectors that only Rollback knows about.

This is very efficient in one sense because your data is only stored once on the disk but this is also the achilles heel as any software which is allowed to write to the disk directly (without the RB driver running) has the chance of writing to sectors used by RB and so corrupting what RB has carefully secreted away. This makes imaging a RB system equally as important as any other non-RB system but, as long as you don't do unwise operations then it will provide great benefits in being able to go back and forth in time on your system.

Graham" }-

This is very encouraging, thanks.

[bgoodman4]

-{ Quote: "As you indicated Graham, any low-level program that bypasses Windows when writing to disk can corrupt RB, so such programs must be avoided when running RB!

I would go as far to say disk-imaging is the very most important of all - representing the 'last line' of recovery." }-


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.

[farmerlee]

-{ Quote: "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.

[nexstar]

-{ Quote: "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.
" }-
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.

-{ Quote: "
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.
" }-
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 :) .
-{ Quote: "
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.
" }-
The one doesn't exclude the other and the images don't need to be onerous.
-{ Quote: "
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.
" }-
It's all a personal choice but don't do it for the wrong reasons.
-{ Quote: "
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." }-
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

[bgoodman4]

-{ Quote: "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.

[Jo Ann]

-{ Quote: "---- 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

[bgoodman4]

-{ Quote: "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).

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.

[nexstar]

-{ Quote: "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.
" }-
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 :) .
-{ Quote: "
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." }-
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

[nexstar]

-{ Quote: "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." }-
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

[nexstar]

-{ Quote: "

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" }-
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

[bgoodman4]

-{ Quote: "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." }-

Excellent and thanks.

-{ Quote: "

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" }-

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?

[appster]

-{ Quote: "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." }-
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)! ;)

[Jo Ann]

-{ Quote: "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

[nexstar]

-{ Quote: "
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?" }-
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 (http://dimio.altervista.org/eng/) (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

[nexstar]

-{ Quote: "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)! ;)" }-
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

[appster]

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...
-{ Quote: "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?" }-...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!

[bgoodman4]

-{ Quote: "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 (http://dimio.altervista.org/eng/) (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" }-

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

[bgoodman4]

-{ Quote: "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" }-

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

[Jo Ann]

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. :thumb:

[appster]

-{ Quote: "Why would you bo0ther doing this rather than using RBs own internal defrag utility? Seems to me rather pointless unless RBs utility is substandard." }-
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!

[bgoodman4]

-{ Quote: "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.

[Aaron Here]

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! :thumb:

Aaron

[Jo Ann]

-{ Quote: "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,

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

[bgoodman4]

-{ Quote: "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

[Jo Ann]

-{ Quote: ":'( 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" }-
bg, you may be able to get a Windows installation disk from your PC manufacturer. My Dell laptop didn't come with an installation disk, so I called Dell support and requested one. I got it within a week's time.

Also, keep in mind that you can always restore a standard Windows MBR from any backup image that was made before installing RB (as long as you haven't made any partition changes in the interim)!

JA

[bgoodman4]

-{ Quote: "bg, you may be able to get a Windows installation disk from your PC manufacturer. My Dell laptop didn't come with an installation disk, so I called Dell support and requested one. I got it within a week's time.

Also, keep in mind that you can always restore a standard Windows MBR from any backup image that was made before installing RB (as long as you haven't made any partition changes in the interim)!

JA" }-

Thanks for the suggestion. It actually is a tad more complex than that. Before I need to worry about the MBR because of RB being installed I need to uninstall GoBack and then fix the MBR (this according to the Horizon support docs on this subject). GoBack has been on this PC since I bought the PC a few years back (it was one of the first programs loaded) so there is no existing image available that will let me fix the MBR.If I can get GoBack off the PC and fix the MBR, then I could install RB which is something I would like very much to be able to do. I will contact the PCs mfg (Sony) and see if they will provide the install disk. As mentioned elsewhere I have an install disk for my Fujitsu Tablet PC but had been recommended not to try using it on the desktop in question.

[Baldrick]

-{ Quote: "Thanks for the suggestion. It actually is a tad more complex than that. Before I need to worry about the MBR because of RB being installed I need to uninstall GoBack and then fix the MBR (this according to the Horizon support docs on this subject). GoBack has been on this PC since I bought the PC a few years back (it was one of the first programs loaded) so there is no existing image available that will let me fix the MBR.If I can get GoBack off the PC and fix the MBR, then I could install RB which is something I would like very much to be able to do. I will contact the PCs mfg (Sony) and see if they will provide the install disk. As mentioned elsewhere I have an install disk for my Fujitsu Tablet PC but had been recommended not to try using it on the desktop in question." }-
Hi bg

Think I said something similar further back but never hurts to repeat in case it can be of help!

I used GoBack before switching to RB Rx and was concerned because I had heard stories about failed uninstalls & corrupted MBRs as a result but can say that I followed the uninstall instructions (including making sure that I had turned GoBack OFF and then exited it from the sys tray icon) and all was well. I then rebooted and installed RB Rx v8.1 without any issues.

However, as a precaution I downloaded the Ngbboot.iso and had ready a bootable CD withthis utility on it...just in case (but luckily I did not actually need to use it).

It may be of assistance or of reassurance so take a look at the following page and see what you think:

http://service1.symantec.com/support/goback.nsf/docid/2005111514174058?Open&src=w

Hope that it helps!


Balders ;D

[Jo Ann]

-{ Quote: "Thanks for the suggestion. It actually is a tad more complex than that. Before I need to worry about the MBR because of RB being installed I need to uninstall GoBack and then fix the MBR (this according to the Horizon support docs on this subject). GoBack has been on this PC since I bought the PC a few years back (it was one of the first programs loaded) so there is no existing image available that will let me fix the MBR.If I can get GoBack off the PC and fix the MBR, then I could install RB which is something I would like very much to be able to do..." }-
Also, the Norton Removal Tool (http://www.softpedia.com/get/Tweak/Uninstallers/Norton-Removal-Tool.shtml) may be of help in removing GoBack from your MBR.

[Baldrick]

OK. I think that I get it ( ref #38 ) but one little question re. something that is bugging me:

1. create system-image backup (including all RB snapshots)
2. defrag system drive before updating the baseline
3. update the Baseline to optimise RB's mapping & free up disk space

Doing this results in a substantial increase in the size of the current RB snapshot, which is resolved/dealt with by baseline update.

However, there is a need to be careful when running a disk defrag with RB installed that one has enough free disk!

All well and good but whilst carrying out 1., 2. & 3. abovein what state is RB Rx? It is in installed but is it still active or has the special command line option been run to effectively suspend it during these activities.

The reason I ask is that I run hourly snapshots and with a defrag taking more than an hour RB Rx would try to take another image if the defrag crosses the snapshot activation point...which I assume is not desirable or recommended.

I suspect that I will have to temporarily suspend taking hourly snapshots when I want to perform the above...but want to know what the experts think/advise. ???

Cheers in advance.


Baldrick ;D

[appster]

-{ Quote: "I suspect that I will have to temporarily suspend taking hourly snapshots when I want to perform the above...but want to know what the experts think/advise." }-
You would be wise to do that. I really doubt that the developers ever had my defrag procedure in mind when testing various scenarios, so I say "better safe than sorry"!

[bgoodman4]

-{ Quote: "Hi bg

Think I said something similar further back but never hurts to repeat in case it can be of help!

I used GoBack before switching to RB Rx and was concerned because I had heard stories about failed uninstalls & corrupted MBRs as a result but can say that I followed the uninstall instructions (including making sure that I had turned GoBack OFF and then exited it from the sys tray icon) and all was well. I then rebooted and installed RB Rx v8.1 without any issues.

However, as a precaution I downloaded the Ngbboot.iso and had ready a bootable CD withthis utility on it...just in case (but luckily I did not actually need to use it).

It may be of assistance or of reassurance so take a look at the following page and see what you think:

http://service1.symantec.com/support/goback.nsf/docid/2005111514174058?Open&src=w

Hope that it helps!

Balders ;D" }-

Yes thanks, it does help. I was going on what I had read on the Horizons website regarding GoBack. Still, I will study on this a bit more before doing anything and perhaps in the mean time find (or acquire from Sony) an install disk so I can do what Horizon advises. I tend to prefer erring on the side of caution if I have a choice.

[bgoodman4]

-{ Quote: "Also, the Norton Removal Tool (http://www.softpedia.com/get/Tweak/Uninstallers/Norton-Removal-Tool.shtml) may be of help in removing GoBack from your MBR." }-


Thank you Jo Ann, much appreciated.

[Baldrick]

-{ Quote: "You would be wise to do that. I really doubt that the developers ever had my defrag procedure in mind when testing various scenarios, so I say "better safe than sorry"!" }-
Will do...cheers! ;D

[nexstar]

-{ Quote: "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" }-
Hi Jo Ann,
I obviously can't say what went on with your experience there but, I have since tried this with ATI 2009 Home, Active Disk Image and Drive Snapshot and the restoration of the MBR gave me a pre-RB MBR in each case and allowed Windows to boot normally.

To be honest, I am happy to use it here as even if doesn't work, as in your case, I think it is better to have a non-booting system which simply needs the MBR to be fixed than have a RB MBR which will boot the system into a confused and potentially damaging state.

@bgoodman4 - it is well worth having some sort of boot CD in any event so that you carry out any repair operations which might be necessary.

Graham

[Jo Ann]

-{ Quote: "Hi Jo Ann,
I obviously can't say what went on with your experience there but, I have since tried this with ATI 2009 Home, Active Disk Image and Drive Snapshot and the restoration of the MBR gave me a pre-RB MBR in each case and allowed Windows to boot normally." }-Graham, since it was actually my husband who had that experience (twice) I can't shed any more light on the subject, other than possible functional-differences between ATI 10 and ATI 12.

-{ Quote: "...I think it is better to have a non-booting system which simply needs the MBR to be fixed than have a RB MBR which will boot the system into a confused and potentially damaging state." }-No arguement here. Other than suggesting some caution to bgoodman4, did I say anything to imply otherwise? ;)

Cheers,
JA

[nexstar]

-{ Quote: "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.
" }-
Aloha Appster :) ,

Sorry, I'm going to be difficult about this one, I'm afraid ;) .

Firstly, I should say that I don't find uninstalling and re-installing RB much of a problem. The defragging is going to happen either way. However, I don't know if you've read the Horizon white paper on defragging here (https://supportcenteronline.com/FileManagement/Download/6d58d51843ed441ca3f970545e27224c?token=9mD8kJXH15XH1M2hX/9@JQzmCTa3iTHkcXAgqorppEz3rb1kHKs2cTlqlF4EWDhJU92EYTzF6NAFfXwvWIIxFCglRZ9QqJqYiYVHgJoVpIE=) but it seems to me that you could end up with a more defragmented drive than you need to because of the order you are doing this in.

I don't understand why updating the baseline first would result in a very large and non-optimized current snapshot. The updating the baseline is simply clearing out all the previous snapshots and deleting any space used for data which is not in the current snapshot.

Where I think the order you do this makes a difference (and I've tested this) is that the defragger does not 'see' the snapshot data which may be in previous snapshots but not in the current snapshot. So (extreme example, but it was easier to see on the defragger display!), supposing you copy a 4GB image to your desktop and take a snapshot. You then delete that file so that it does not exist in the current snapshot.

When you run the defragger, the area occupied by that deleted file is protected by RB and so won't figure in the defragging process. So you've defragged and then you update the baseline. This will then free up the 4GB used by that snapshot but will leave it where it was on the drive and so the used space on the drive will not be consolidated.

I've tried this test and ended up with a big chunk of space which needed to be defragged again to get rid of it.

If you'd like to discuss this further over a drink, can we meet at your location rather than mine? ;) .

Graham

[nexstar]

-{ Quote: "Graham, since it was actually my husband who had that experience (twice) I can't shed any more light on the subject, other than possible functional-differences between ATI 10 and ATI 12.
" }-
Or maybe differences in the RB versions. I was using 7.2.1 here. I guess that the imaging app is only going to see the MBR that RB wants it to see.
-{ Quote: "
No arguement here. Other than suggesting some caution to bgoodman4, did I say anything to imply otherwise? ;)

Cheers,
JA" }-
No, not all. I was just thinking out loud ;) .

Graham

[appster]

-{ Quote: "If you'd like to discuss this further over a drink, can we meet at your location rather than mine? ;) " }-
Aloha Graham. Anytime you are in Honolulu I'll gladly buy a pitcher (or two) of Mai Tai's to wet our tonsils while we discuss our different points of view. I'm quite confident that will bring about an amicable resolution! *puppy*

Btw, speaking of Mai Tai's I'm brewing up a batch while my wife prepares Sunday dinner.

[nexstar]

-{ Quote: "Aloha Graham. Anytime you are in Honolulu I'll gladly buy a pitcher (or two) of Mai Tai's to wet our tonsils while we discuss our different points of view. I'm quite confident that will bring about an amicable resolution! *puppy*
" }-
Sounds great to me.....I'll get my coat :) :thumb: :thumb: :thumb:

Graham

[Baldrick]

-{ Quote: "Aloha Appster :) ,

...Where I think the order you do this makes a difference (and I've tested this) is that the defragger does not 'see' the snapshot data which may be in previous snapshots but not in the current snapshot. So (extreme example, but it was easier to see on the defragger display!), supposing you copy a 4GB image to your desktop and take a snapshot. You then delete that file so that it does not exist in the current snapshot.

When you run the defragger, the area occupied by that deleted file is protected by RB and so won't figure in the defragging process. So you've defragged and then you update the baseline. This will then free up the 4GB used by that snapshot but will leave it where it was on the drive and so the used space on the drive will not be consolidated.

I've tried this test and ended up with a big chunk of space which needed to be defragged again to get rid of it.

If you'd like to discuss this further over a drink, can we meet at your location rather than mine? ;) .

Graham" }-
So the upshot of this is Update Baseline FIRST & THEN defrag??? or because after a Baseline Update the baseline is never the current snapshot one needs to uninstall/reinstall to make sure that ALL diskspace is considered in the defrag process???

???

[nexstar]

-{ Quote: "So the upshot of this is Update Baseline FIRST & THEN defrag??? or because after a Baseline Update the baseline is never the current snapshot one needs to uninstall/reinstall to make sure that ALL diskspace is considered in the defrag process???

???" }-
Sorry to confuse the issue here :-[ but I'm just going on what I've observed in tests and understood from the Horizon info.

My personal preference would still be to uninstall RB/defrag/re-install RB. This is also the official advice from Horizon. However, if I were going to leave RB installed then I would update the baseline and then defrag.

I'm happy to be proved wrong about this though if anyone else would like to test it out :) .

Graham

[Baldrick]

-{ Quote: "Sorry to confuse the issue here :-[ but I'm just going on what I've observed in tests and understood from the Horizon info.

My personal preference would still be to uninstall RB/defrag/re-install RB. This is also the official advice from Horizon. However, if I were going to leave RB installed then I would update the baseline and then defrag.

I'm happy to be proved wrong about this though if anyone else would like to test it out :) .

Graham" }-
Hi Graham

Thanks for clarifying (BTW - you are not confusing the issue IMHO, it is I who is just being careful I have understood correctly ;D ).

I might try both for the next and one-after-next defrags that I do...now, which one to go with for the next defrag...options, options, options ??? ??? ???

Cheers



Balders ;D