Windows' 10 Core Isolation and Rollback Rx compatibility

Hi, is Windows' 10 Core Isolation and Memory Integrity feature, when enabled, compatible with Rollback Rx?

 

There's been no report of such an incompatibility... but a lot of users do not use either of those OS options. It's probably worth a test... following a complete IMAGE of the OS partition itself for safety, and you should image BEFORE you install Rollback.

 

Thanks for your reply. I haven't installed Rollback Rx, as I've been reading the following thread you started a few years ago:

https://www.wilderssecurity.com/threads/rollback-rx-the-unofishul-faq.374977/

And as I am using a Windows 10 PC with SSD, I think Rollback Rx could cause some problems, as your FAQ on that thread suggests.

I used Rollback Rx on my last PC, which was an old one, still running Vista, and which had a HDD. I had two Rollback Rx disasters on that PC. One when I cancelled a snapshot that was taking ages to complete, this caused my PC not to bootup when I turned it on the next day, The second was when I activated the internal Rollback Rx snapshot defragger. Again, for some reason, this caused the same bootup problem as with the first incident. Apart from those two situations, Rollback Rx worked ok for me.

But given the history of the poor HDS customer support, which is now quite well know in this forum, I think I'll give Rollback Rx a miss this time round.

By the way, I still use Drive Cloner Rx 6, which seems to work ok. But I was wondering if it would be safe to also have Macrium installed on the same PC. I was thinking of using Drive Cloner Rx for making backup images and Macrium for file backups. Would there be a compatibly issue having these two on my PC at the same time, although used for different purposes?

 

They should work just fine, even if you decided to IMAGE rather than Files'n'Folders with Macrium REFLECT. You appear to be using (or want to use) DCv6 as a pure imaging app rather than using it to image both your System and RBrx's snapshots... this should not be a problem at all. Even if you continue to be a RBrx user and want to use DCv6 to image both the System and RBrx's snapshots (which it claims to do), there shouldn't be an issue between the two imaging apps. There may be an issue if using Reflect v7 and its CBT option if you want to use RBrx once again... installed without CBT it should work fine even in that scenario (as long as you don't want REFLECT to try and image RBrx snapshots).

When I was BETA testing DCv6 (it never worked correctly with snapshot imaging before the BETA was cancelled and the product released), I used REFLECT as the instrument to always have a backup image of my System to backup to... I had to backup many times and it always worked just fine as it was installed along side of DCv6.

DCv<n> always worked basically well if just used as a System imaging tool... it wasn't until v6 came along that it developed issues associated with snapshot imaging. But as a basic imaging System, it worked well. I use Macrium primarily for its speedy restoration algorithms (RDR) due to the fact that I do many System restores with some of my Systems. DCv6 is just a standard ol' imager that restores the old slow method that almost all imaging Systems still use... but it's reliable.

You should be good to go...

 

Thanks.

One other question. Is there a program that has the same capability as Rollback Rx but operates within the Windows OS, rather at the MBR level?

I ask because it is the potential for Rollback Rx to mess up the MBR that I think is the biggest problem with the program. True, it needs to operate independently of Windows to do its job, but I no longer trust it doing its job safely.

I'd rather have a program that took fast snapshots that operated within Windows alone.

 

Well, I can only offer you my experience. Sure, RBrx is quite fast at taking snapshots, mainly because it never has to move the DATA, it only changes the reference to DATA that already exists on the disk... therein lies the danger.

In 2015, Macrium released REFLECT v6 with a new feature known as RDR (Rapid Delta Restore). It used an entirely new restoration algorithm which only restored DATA that had changed on the disk rather than completely restoring the disk in its entirety to some time point in the past.... such a KEWL idea! It worked very well and was very fast. Since REFLECT takes its images (snapshots) on LIVE Systems, it didn't affect my workflow at all while it was protecting my System. Since my OS disk had just recently become an SSD, I then noticed that when I did a restoration to a previous recent time point, the process was very quick... almost as quick as RBrx. I did some benchmarking and decided that REFLECT, while being just a tad slower than RBrx in returning to a previous snapshot, was very reliable and worked entirely under the purview of the Windows OS... a much safer place to be. At that time I dumped RBrx (for safety reasons) and REFLECT became my snapshot managing image System.

In 2017, REFLECT added a feature called CBT (Changed Block Tracker). This feature dynamically tracks block changes on the disk in real time rather than detect those changes later during the imaging process. This of course allowed for a much smaller and quicker imaging time and also improved the already quick (RDR) restoration time by restoring even less DATA than in the previous RDR scenarios. At this point, my "snapshot" restorations are even faster than previously. As a result, I have been very pleased with using REFLECT, a disk imaging tool, as a snapshot System at the same time. I even have REFLECT taking automatic "snapshots" every 15-min during my normal business (System) and they are merged forward in time as I don't need them anymore. I also use REFLECT to do manual snapshots when I am doing software testing or playing with OS updates. This System is extremely reliable and I've easily become accustomed to the only slightly slower restoration times than RBrx would offer... a real win-win for me and my System's reliability. I really haven't looked back since I made the switch in Feb 2015.

 

That is very interesting. I never knew that.

I assume that REFLECT 6's RDR lets you restore the system without having to use an external drive. I that so?

 

Reflect's image may be held on any partition that is not part of the image being taken... that partition may be on any disk, anywhere. The faster the device (SSD vs old, slow HDD) and the "closer" to the System (Internal connection vs external connection <USB>), the faster the restore will be.

That being said, if you're imaging the entire disk (all partitions) AND you only have one (internal) disk on the System (laptop for instance) to be imaged, then, of course, an external disk for imaging will be required.

 

I phrased my question wrong. It should have been: can you restore an image taken by RDR to the same partition it is being stored on? From your answer, it seems no you can't. I may have misunderstood though.

 

No. The image must be stored on a partition that is not involved with either the restoration or the imaging operation itself... otherwise the restoration will destroy the image being used for restoration.

...and RDR doesn't "take" images, it's only involved with the restoration process.

 

I see. That is unfortunate, as it is not like Rollback Rx's snapshot restoring method regarding convenience.

I just came across a program that is more like to Rollback in its snapshot restoring method. It's called AOMEI Backupper. It's GUI is simple to navigate, and it takes system snapshots just like Rollback does and restores them on the same partition (I think) as the saved snapshot is on after reboot. And unlike Rollback operates within Windows. This is my understanding of it from the following link describing the process:

https://www.ubackup.com/help/system-restore.html

 

No, you got this wrong...
Aomei Backupper is an image based backup software just like Macrium reflect. It does not have Rapid Delta Restore, so restoring from an image will take much longer. Aomei does not take system snapshots like Rollback RX. The images it creates must be either on a separate HDD or at least on a separate partition (not much recommended).

I did use Aomei quite a lot, it is reliable and has a nice GUI. The reason I got rid of it was that taking incremental images was very slow, it took almost as long as taking a full image. I have no idea if Aomei has fixed it since then.

 

AOMEI Backupper is just another imaging program and will have the same restrictions as REFLECT or any other imaging System... at least to the best of my knowledge.

All imaging software works the same as far as taking and restoring images... some like REFLECT (and IMAGE FOR WINDOWS) have some neat features to improve their performance but they all work basically the same.

The only other snapshot program that works like RBrx is an RBrx clone called EAZ-FIX (they share Developers... which could be a problem ). Everything else is an imaging System.

 

I'm not sure what you mean by "convenience." If you're referring to speed, yes, RBrx is faster... but not by much in the grand scheme of things. If you're referring to a "click'n'restore" operation allowing you to select a time point for restoration and then a single <click> GO operation, many of the imaging Systems support that as well, including REFLECT. If you're referring to keeping the snapshot DATA on the same volume that's being protected... only true snapshot Systems (RBrx and EAX-FIX) can do that... BUT, lose that partition (software bomb, disk failure, Windows update massacre) and your whole System is basically history (without other types of protection in place).

Snapshot Systems (RBrx and EAZ-FIX) use what's called Redirect-on-Write technology... a method that leaves the snapshotted DATA in place and writes its new version elsewhere on the protected partition. This operation is fast but leaves the protected partition vulnerable to other System anomalies... all your eggs are in one basket. Imaging Systems use what's called Copy-on-Write technology... basically insuring that the snapshot (and all its backup DATA) are somewhere else other than on the protected partition. Yes this requires DATA storage but pretty much insures that your System may be restored upon almost any disaster... which is way more important to me than losing the entire System and its change history.

Many of the more knowledgeable RBrx/EAZ-FIX users on this Forum use a combination of the technologies mentioned above... a snapshot System to speedily return to System time points that are important to them and an imaging System to insure they can rebuild any disaster scenario that may come along, that's basically the best of both worlds. In my case, the slight extra speed provided by the Snapshot environment does not really float my boat... I'm happy to wait the few extra seconds (minutes) for the image restoration to be performed. Even at my advanced age... I have that sort of time

 

I see. I was a bit confused because the instructions for AOMEI's System Restore feature (in the link in my last post) never mentioned that you couldn't restore to the same partition. Maybe they expected people to already know this. I'm new to making backups etc.

 

There's nothing wrong with being "new" to backups... it's always best to learn from either your or others experiences. There's a lot of help on this Forum... feel free to partake.

 

Thanks.

By the way, do you know if Drive Cloner Rx Version 6 interferes with the MBR seeing as it was designed to be used with Rollback Rx installed?

 

As a RBrx snapshot imaging tool, it has some quirks which have never been fixed as far as I know. HDS has since abandoned Drive Cloner (last year or so) so maybe this is all moot.

As a plain imaging system (no RBrx snapshots) it always worked reasonably well, albeit somewhat slow in some of its operations. It does not mess with the MBR but does image that area of the System (as all imaging apps do) in order to restore complete and accurate configurations.

As a snapshot imager the whole thing was a kluge. It used proprietary RBrx database info to determine where the real end of the used disk was, and just, basically did a forensic image (all sectors, used by the Windows FileSystem and in the RBrx snapshot areas) of the RBrx System. Many users do that now with standard imaging tools but they don't know where the RBrx underlying FileSystem ends so they forensically image the entire RBrx protected disk/partition whether used by Windows/RBrx or not. These images are large since they include all disk/partition sectors, used or not, but may be used for RBrx restorations since they include everything either Windows or RBrx knows about as far as disk usage is concerned.

BUT, as mentioned above, if you want to use Drive Cloner for standard imaging, it should be adequate. As an aside, if you own Macrium REFLECT (v6 or better), I would not even consider using Drive Cloner as a piece of abandonware.

 

PS- the other item that may be of some use to you, especially as Macrium REFLECT is concerned... the entire CBT (Changed Block Tracking) BETA effort was actually performed under v6 but wasn't product released until v7. The effort went exceptionally well and the BETA code runs trouble free under the latest release of v6 (v6.3.1865). The BETA CBT installation under v6 is a separate MANUAL install but is pretty simple. If interested, lemme know and we'll hook up backchannel (PM) to discuss the specifics of the implementation.

 

Thanks.

I find that Drive Cloner 6 makes an image of my systemin in about 20 minutes, including with validation. I'm not a program tester so speed is not that important to me regarding imaging.

What with all the negative publicity with Rollback Rx, do you think it has a future? Or is HDS flogging a dead horse?

 

As far as RBrx is concerned, it's current user base must be reasonably happy with the product or they wouldn't still be there. In the past, so many users were burned so badly that I can't see any of them staying the course. Now, to be honest, most of those users felt RBrx could protect them from anything (and HDS actually said they could at the time), but when a disaster of sorts occurred, they were burned... not a single backup file. One user on this Forum tried ad infinitum to recover his 3-yr old RBrx configuration, even using so called "HDS Recovery Tools" and got next to nothing... the user was devastated. That's only one example, there were many more.

Now we do hear from users in this Forum of successful RBrx installations. I'm guessing many of them are using very "friendly" configurations so they probably would be trouble free. Others are well protected (using backup software as well) so that when they do experience a glitch, they can recover reasonably from that hiccup. When the semi-annual Win10 upgrades started to rear their ugly heads, lots of RBrx users were burned when Windows decided to resize their OS partition during the upgrade process... not a good thing to do while not under RBrx's purview. HDS has since stated that this should not be done without deactivating/uninstalling RBrx first before the Windows upgrade is performed. Of course this process will wipe out any current RBrx snapshots so if they're very important (as far as DATA is concerned), the Windows upgrade will have to wait.

Prior to Windows upgrades, HDS even started a special Forum thread to warn users about monthly updates (not upgrades) by trying to do them before their users did and "clear" them for installation before users attempted to do them. This didn't last long because Windows 10 HOME users didn't really have control over when those updates were done... ahhh, the best laid plans.

All I can say is if a user is very familiar with the quirks of RBrx and very carefully protects their Systems against possible unexpected disasters, their general RBrx experience may be somewhat acceptable as far as results are concerned. Some of our users are just plain addicted to RBrx's speed (@carfal - are you listening )... they can't get away from it, but they are shown to be very knowledgeable in the ways of RBrx and as such, have few, if any, problems they can't get out from under.

As far as the future of RBrx, I can't even offer a guess... I do know that I'll never use it again

 

Thanks for explaining.

It's a pity about Rollback Rx. The technology it used was innovative but too risky for the way PCs work.

 

This may be a silly question, but as I said before I'm new to all this: how is it possible to still use your pc while it is cloning? What are the "mechanics" behind it? I would have thought that if, for example, you opened a file on your PC, or did some action on it while cloning, that would disrupt the cloning procedure. What stops that from happening?

 

Well it depends on what app is doing the cloning. Most "responsible" cloning apps, with Windows anyway, will use the Windows VSS (Volume Snapshot Service or "Shadow Copy") capability. This causes Windows to take a few seconds to organize a frozen snapshot of the FileSystem. When completed, it offers that snapshot to the application calling for the service. While that app is now imaging/cloning the frozen, non-changing FileSystem snapshot, Windows continues to operate normally, keeping track of all changes since the frozen snapshot in a separate area of the System. As soon as the application using the snapshot tells Windows its done, Windows will release the snapshot and re-integrate all the changes that occurred while the snapshot was in place. This guarantees a non-changing FileSystem while the app is imaging/cloning your System

Without VSS (and without a private proprietary implementation of VSS by the app itself <that's what they did before VSS>), the FileSystem being imaged/cloned will be inconsistent and flawed for anything that was dynamically changing during the image/clone operation.

 

Thanks. Does Drive Cloner 6 use Windows VSS?