RollBack...geez...they got me too...

These problems have been covered extensively in the (now deleted) old Rollback forum by Froggie.

Using an older version of IFW it was possible (with a little registry tweaking) to do a hot sector by sector backup while also backing up all of Rollbacks snapshots. This method does not work any more with current versions of IFW. And at least for me it is not required that the image backup contains the snapshots. Plus sector by sector backups are sloooow.

This leaves us with two methods which both do not backup the snapshots - hot backup and cold backup. I tested both methods extensively under WinXP with Acronis True Image.

Hot backup:
Since it runs under control of the pre-OS Rollback driver, the current state of the HDD will be backed up. What will not be backed up is the Rollback modified MBR. After restoring such a backup the whole pre-OS part of Rollback won't be there, so the Windows part of Rollback is also not functional. It will terminate itself right after starting. The user has to uninstall Rollback at this point and then reinstall it. MarcP indicated that this method destroyed his Windows installation, but for me this has always worked under XP.

Cold backup:
Due to Rollbacks virtual write technology a cold image backup will only backup the baseline. If you want your current state to be backed up it is essential that you reset the baseline to the current state before doing a cold backup. Which of course means that you will lose all your snapshots. Since the cold backup does not run under the control of Rollbacks pre-OS driver, it will backup the modified MBR. After restoring such a cold backup you will have a working Rollback installation.

I always use the cold backup method, simply because I reset my baseline regularly. I do not need hundreds of snapshots, and there is always the potential that Rollback becomes unstable when it has to manage too many snapshots.


Cheers
manolito

 

Uhh no. The MBR is part of Windows. By that I mean that Microsoft uses well established rules to set up the boot code in the MBR. If fact, they're responsible for setting up the MBR properly otherwise Windows wouldn't boot. If HDS wants to twist the system for their own purpose, it's on them when things don't work with the OS they mean to support. This whole Win8.1 upgrade didn't just appear out of nowhere.

 

With the unnecessarily rapid pace of software updates I think we need to fall back on old school techniques from time to time. And as computers take on the behavior of an appliance-like black box I think standards and guidelines are more important than ever. Especially when the inner workings are hidden and complex.

HDS should be slapped for architecting RBRX the way they did.

 

Then do you have a proposal what they should have done differently (except going out of business)? Their "Virtual write" technology requires that they intercept all HDD I/O, and this can only be done by a driver which loads before Windows. The only alternative would be using "True Write" technology like RestoreIT, SysRestore or Toolwiz Time Machine. And this technology has its own drawbacks (like after restoring to an earlier snapshot all the newer snapshots will be gone).

I believe that a company like M$ should not own the MBR (maybe the ISO should be responsible for something like this). There are many multi-boot installations which use Grub or some other boot loader instead of the M$ BCD store, and M$ should respect these boot loaders and not destroy them during an OS upgrade to a newer Windows version.


Cheers
manolito

 

Not so much architectural changes but instead added features. The MBR and sector maps should be better protected, and an alarm sounded if there are changes.

This type of thing should really be integrated with windows, if not, then done at the bios level or hdd/ssd firmware level.

 

Not wait until the Win 8.1 update comes out before figuring it out. The update had been available to developers for months prior. They would've known well in advance to come up with a strategy. Instead, not a peep was said until people's computers started crashing. That's professional?

Excuses said here are no consolation to the user whose computer has collapsed.

 

Could we get an update from the OP to see where we're at and what has been done?

 

Thx buddy...PLEASE let me know what to do in newbie detail...so I don't screw it up and make things worse, thanks a lot...especially if I use that SuperScan feature to access and recover as much as I can from a snapshot if that is possible...that you mentioned. Thx

 

thanks buddy. I'll get back to you and let you know what happens. I'll be happy or crying. .. one or the other!

 

..we happy?

 

Nothing yet...anybody heard from froggy?

 

I see him online. Why not use PM.

 

Although I'm sure it must have been greatly improved since the mid 2000s, when RollbackRx totally filled my hard drive on my Velocity Micro machine with data that could neither be seen nor deleted by Rollback or Windows, making my PC unuseable. I got messages that would say "can not do-hard drive is full" and yet Windows would show hundreds of gigs of free space.

I had to use a special diskette (yes DISKETTE) that contained a program that totally zeroed out my entire drive to make my PC useable again with a full restore.. I believe the program was downloadable from one of the hardrive manufacturers. The tech support at VM first question when Idescribed my problem was :"Do you use Rollback?"

Rollback is an extremely convenient program when it works and does not otherwise mess-up your PC. I often found that it would not work when I needed it the most.

I would never again install Rollback, no matter how much it has been improved. PCs give us enough problems by themselves, no sense in adding the possibility of more.

 

RBRX could possibly be alright if you're backed up with full and complete offline sector-by-sector disk imaging. File-by-file filesync backups of vital user data are also acceptable, if you don't mind the occasional format and re-install of the OS and Applications drive.

The most common (and deadly) mistake people make when getting into Rollback RX is that they treat it as backup software. Or as a witch's broom that can whisk away any PC problem.

Contemporary PC file systems such as NTFS are remarkably reliable. It's not good practice to add in a layer of complexity which is constantly in beta.

 

+1

 

I responded to Rick via PM as far as what little I know about the Active@ File Recovery tool which he has available to him. I also sent him a manual on the use of the tool. Using that tool, if it can't find any additional file content that what has already been found (and scrogged) by chkdsk, he's probably reached the end of his digital rope as far as Rollback RX crash recovery options.

I wish him luck...

 

Therein, in the opening post of the thread, lies the crux of the problem. Everyone I know of that ran into unsolvable loss with Rollback Rx, did so due to attempts to treat it as a backup application. It is not a backup application. It's a rollback application. It's quick, convenient, and for the most part performs as it should. However, whether you're using Rollback Rx or any other time saving utility, a backup is the prudent method of insuring a restored system. A system can crash, due to Rollback Rx. nearly any other application, or even a hardware issue. A backup is the only thing that will get you back up and running without loss.

Feel free to enjoy the convenience of Rollback Rx, or any other complicated helpful utility, but I wouldn't recommend doing so without a full backup. Who know? Maybe, with a frequent backup you may come to realize you don't really need a convenience utility; not even System Restore.

While this doesn't solve your problem, I couldn't solve it if your system crashes without a backup for many other reasons. Backups Rule!

 

Ya... Try to restore from a backup with RBX still in the MBR. See how it will trash your system after the recovery.

 

Why would I try to do that without repairing the MBR?

 

Because imaging a drive also images the MBR. If you're expecting everyone to know this fine surgery then I say don't use RBX. It's a minefield.

 

Fine surgery? There are good computing practices, and bad. Encouraging people to practice bad computing doesn't do anyone favors. If spending a few minutes learning how to recover from a corrupt MBR permits such "fine surgery", it would be time well spent. Toodle-oo ........... I'm headed offline.

 

When backing up RBRX volumes (using Acronis), you have to select Sector-by-Sector and Unallocated Space. This could result in a huge backup file almost the size of the original disk itself. In today's era of big disposable disks, this isn't a problem. But if you want to be elegant and efficient about it.. read on!

A way to minimize the size is to SecureErase it and then format. Then install your OS and applications, then use Ultimate Defrag to push everything to the front and finally zero out the un-used space. With ASCII ZEROS! Not some stupid pattern like from CCleaner or a multipass wipe algorithm. A single pass of ZEROS! Hex #00 or $FF. Then install os and apps and RBRX. And finally perform your image backup. In that order.

This way you're only capturing data, and all the unused sectors are Zeros and compress nicely into, well, zero! RBRX will have knowledge of the disk capacity, but not yet have started stirring things up. Not yet have started "throwing sectors around", convoluting the map, or using unallocated space.

A test install I did consumed about 6GB, and when backed up via sector-by-sector with compression and unallocated space it came to be 75GB. The unallocated space is vital, because RBRX knows about it and may use it at any time. It was 75GB in size because of random and seemingly unused data left over from previous installs. Normal backups ignore that, but an RBRX backup needs all that space put back exactly as it was when RBRX was installed.

When I formatted and zeroed the disk, the sector-by-sector image came to be 7GB. A huge savings as you can see.

Hope that all made sense.

To recap, to make an RBRX disk suitable for reliable backup imaging you need to do some planning and work:

1- Zero out the disk with hex $00 or $FF. Built-in Secure Erase works fine.
2- Format it (quick or long)
3- Install your OS
4- Install your Applications (and userdata if so desired)
5- Use something like Ultimate Defrag to push all the un-used space to the front or back
6- Run something that can non-destructively write hex $00 or $FF again. A free space wiper.
7- Install RBRX
8- And now, finally, you may image your disk for backup purposes. And the image size will reflect the amount of data you actually have stored. And if your imager program supports compression (most do) you'll get perhaps a smaller size than your actual amount of stored data.

It is possible to forgo steps 1-4, I just do that as part of good practices if it is a well-used disk I am working with. Step 5 gives you a large single unbroken section of blank space. And step 6 makes sure that space is all the same. These two steps, 5 and 6, are critical to chopping the backup filesize down to something reasonable! All that space will compress to just a couple of megs, even if it's 100GB. The compression routines in your imaging program just love that massive unbroken block of freespace wiped to all Zeros or Ones.

If you already have RBRX installed, you will need to un-install it and begin at step 5.

If you do none of these things, and just go ahead and run the imager program, you'll get a backup size about the same as the source disk. 120GB disk comes out to about 100GB depending upon the random nature of the data in the free space and unallocated space.

When I talk about unallocated space in the context of this post, I am referring to what is defined in the MBR/Partition Table. What the MBR/Partition Table says is free.

Also be aware that restoring the disk image will take time, as it IS restoring GB upon GB of zeroed-out sectors. All in the name of keeping RBRX happy and image at a reasonable size.

A 1TB boot disk, with 10GB of os and apps, will come to be about 11GB sector-by-sector image if done via this method. Give or take. Without the zero-wipe operation, it would be 1TB.

This all for an offline Spinner disk. A Solid disk has an entirely different procedure - in order to minimize wear and excessive writes.

 

Yep...you're right about that froggy. if any of you guys out there can figure out a way to possibly access the rollback damaged database that froggy said or repair it in some kind of way, please let me know. Its been 7 months and my laptop is basically been collecting dust. I've been using my neighbors tablet to get online and take care of emailing, etc.

Hey Froggy...do u think @Active or another type of utility available can look at the virtual disk to recover or copy the entire virtual disk onto a new hard drive? Or does anyone know of a way I do it? I'm scared to try different ones because it may destroy my hard drive data permanently.

Scavenger was supposed to serve this purpose, but the rollback people will not develop it decently to perform this or any type of repair function, unless they have came out or something lately I don't know.

Thanks

 

The only way we've had success with imaging RBRX disks is by using something that can do these 3 things:
1- Sector-by-Sector
2- Include Unallocated Sectors
3- Offline Imaging via boot disc

And when we used to do that, we had 100% success with backup-restore operations.

 

The wife says:

There is no commercial/consumer tool available to do either of those functions. There hasn't been enough of these kinds of failures to warrant a software firm developing such kit. I agree. The best you can hope for from commercially available software is what was there before RBRX was installed, or what was in the unaptly named "baseline snapshot". Ughh..

Furthermore, Scavenger may not (obviously) know how to handle the "damage" done by checkdisk or other "invader to the RBRX environment. I also agree here, too.

She wants to know why a sector-by-sector clone hasn't been made yet? It's ridiculous to be working on a simple logical failure without a clone. Her words not mine. I agree.

Have the files "produced" by checkdisk been examined? What are the file lengths like? Are they similar in size to the lost data? What are their contents like when examined with a hex editor?

Scripts and custom software specific to this case are likely required in order to make any progress. Analytics and statistics and file carving are all part of the arsenal of tools.

She thinks a successful outcome is definitely possible. There are lots of clues on the disk as to what it was like before this little hiccup.

But it is my opinion you have 4 choices.
1- Continue efforts and hope a solution presents itself.
2- Wait it out till someone writes a utility that can unravel this situation.
3- Format the disk and call it a day. Begin rebuilding what was lost.
4- Contact a data recovery professional skilled in forensic work. I assure you they have tools and techniques far more sophisticated than what can be offered here. Print this thread out and send it in with the disk so they have a clear picture of what has transpired.