RollBack RX question

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?.

 

Rollback RX make a incremental bacup

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)

 

Although Wikipedia 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.

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.

 

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

 

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!

 

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

 

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.

 

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.

 

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.

 

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

 

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.

 

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).

 

Jo Ann, question about AyRecovery and NOD32 SysRescue!

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!

 

Re: Jo Ann, question about AyRecovery and NOD32 SysRescue!

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

 

Re: Jo Ann, question about AyRecovery and NOD32 SysRescue!

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

 

Thank you both for the input!

 

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

 

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.