I think it's too risky in your case. Take that along with bad support, stringing us along with the promise for a new version for years, and that at least I found it a pain having to constantly uninstall and reinstall, crossing my fingers that it would accept my key on re-installation. I dumped it when I found AX64.
Well, that's the way it works and a necessary part of how it can do what it does. There hasn't been much of a change in that particular methodology over the years. Pete, If you really feel that RB is 'an accident waiting to happen', I don't understand why you posted this: pv
I believe that on a business machine which is used for professional purposes, you need a proven and reliable backup solution (Macrium, IFW...). I do not see why anyone would want to install a snapshot software on such a business machine. RBRX IS NOT A BACKUP SOFTWARE. Neither are other snapshot applications like RestoreIT, Toolwiz Time Machine, SysRestore, whatever... Even using the AX64 hot restore feature would be too risky to use on a business machine IMO. Cheers manolito
Well, there are a heck of a lot of large corporations that use it in some capacity! Checkout their clients - bottom scroll on http://www.horizondatasys.com\ I completely agree; it's 'Snapshot Software' and that's why I make cold sector-by-sector image backups of my system.
I do use snapshot software on my business machines. I use AX64 V2, but i do back it up with Macrium. I've seen their clients. But that doesn't impress me, as sometimes large corporations are the same as individuals.
Pete, I'm not trying to 'sell you' (or anyone else) on RB; my remarks to you were just in response to your recent posts.
Hello pv. Since you are one of the few posters here who claims to have never had any serious RBrx problems (over a good many years), would you mind discussing what you think may be the key to that success?
Hi pvsurfer No problem and I realize why you responded. Mainly I posted so people can think about how they use their PC's and the impact on them.
Yea, it seems like an accident waiting to happen, Pete, but the basic design of that app is very long in the tooth at this stage. The only thing they've been doing along the way is adapting it to advancing OS and HDD/SSD technology (along with UEFI)... the underpinnings are exactly the same as they ever were. I would say it's a well worn technology. BUT, it's not a backup or imaging tool as we all know, and as such, needs that to protect itself (and YOU!). It is a GREAT snapshot tool when it works correctly on your system... without a doubt the best on the market (there really aren't very many). I have loved it in the past, and only backed a way a bit when it entered the W7/UEFI/GPT world... that's when things got tough for the developers. I discovered along the way a method to HOT backup the RAW disk surface... this guaranteed I would have both the OS and RBrx's snapshots and could automate that scheduling. That capability died along the development path of the imager I was using (IFW) and only COLD imaging would work beyond that point. Since then some of us have been waiting many, many years, literally, for RBrx's sister application, Drive Cloner RX, to emerge in its promised way. The promise was that DCrx would, eventually, be able to HOT backup all LIVE Windows OS stuff along with RBrx's snapshots... kinda like the holy grail of using Rollback RX AND being able to manage the backup protection of your system. This promise was made over 3-yrs ago... you can see why a lot of people have moved on. As I've said before, because it's so incestuous with Windows, it becomes very sensitive to system configurations. In many cases it either just works, or just doesn't work at all. If you pick the right corporations to sell/support to (good, known system configs), the benefit is great press with a lot of success. Otherwise you just have to move on from a possible customer/corporation. Along the way there have been many "glitches" with systems that have had Rollback installed. The glitches, in many cases, cause unBOOTable systems... and without a backup, your dead. Many of the RBrx system problems that I've been involved with have been exactly that... the glitch has never really been identified (as to its source), but the result is pretty tragic. A lot of the ones I've worked with were caused by RootKits (TDSS, etc.) and some of those I was able to piece back together (like Humpty)... but only 'cause I'm reasonably familiar with MBR technology, Windows file systems, and the damage path caused by the offending invader. Think about it, MBR-based RootKits will take over your "normal" Windows system and cause whatever kind of havoc they're designed for... but the system usually stays in tact. Put that same RootKit on a RBrx-based system and the damage is astronomical, especially for normal users (once that special RBrx MBR gets tweaked... toast). The other thing... once the RBrx system has been glitched, if the proper path isn't followed to try and move out of that glitch, it can get way worse (see the RickFromPhila thread). I'm not talking about very knowledgeable users here, they can usually protect themselves somewhat by saving various MBRs and trying to protect themselves with COLD images, etc. along with some extensive system knowledge. I'm speaking mostly about plain ol' computer users. Anyway, I occasionally lean backwards to see what's going in in the RBrx world and see if the infamous Drive Cloner RX has finally reached the stage of something other than just another run in the mill imager like many others on the market. In the case of DCrx, something has finally happened on that front... the first BETA became available that purports to image the LIVE Windows OS AND Rollback's snapshots... WOW, after all those years. It doesn't do it in quite the way I had expected, but it does make a journeyman's attempt at it. Anyway, to finish this missive up... my personal experience with RBrx has been good, most likely 'cause I keep my system configurations very simple (all MBR-based, small OS partitions and good fast disks... not too many partitions. The product worked very well for me... until the above mentioned development hump that included W7/W8/UEFI/GPT. At that point things got rough... and I had to move on with some of my systems (can't live with XP forever, ya know... yea, I know, some can). That's where I am at the moment.
Can't say for sure (obviously). Frankly, I think a lot of my success using RB is due to my way of doing things (explained below) and part of it may just be luck! First, I always have a relatively small C-drive/partition, with just my OS and apps. My personal files are all on another drive (which are not protected by RB and backed-up separately from my C-drive). When I ran WinXP my C-drive had a total size of about 25GB and with W7, it's 75GB. Keeping C: small facilitates making sector-by-sector backups within a reasonable time-frame and the resulting image-sizes are manageable. Secondly, I never run any 3rd party file/reg cleaners, defraggers, or any other disk utilities in my RB environment. If I feel the need to run any kind of system (Windows) maintenance I will uninstall RB, run an image backup, then perform any system maintenance and reinstall RB when that's done. I typically do this every couple of months. Thirdly, I avoid running any other low-level programs that could very well conflict with RB and finally, I refrain from upgrading to every new release of RB if the build I'm using is running well ('if it ain't broke, don't fix it'). HDS doesn't do the best job QCing new releases so I always check the change-log to see if any changes affect my system, if not I don't update! Hope that helps - I can't think of anything else at the moment... pv
...and of course RBrx is not backup technology... but it is the superior snapshot technology in the market (when it works). We're taking about two different things here... backup and system protection technology and snapshot technology. They are very different, especially in their needs, but definitely should co-exist on any system. Snapshot software can be the greatest system uninstaller... from those bad pieces of software you've tested, from those bad M$ updates you've installed, from almost any kind of unexpected glitch... and when it does it fast, it's great. Using imaging tools for that same purpose (until the advent of AX64) is clutsy although you could if you had to do the same types of things... but imaging (and data replication) is for BACKUP and PROTECTION, not for addressing system glitches. Even if RBrx was flawless (Go PV!), you still need that imaging/backup tool to complete your system protection package. It would be great if they complimented each other rather than make the user go out of his way (COLD imaging) to protect himself. I'm personally gonna follow the evolution of Drive Cloner v6 and see if HDS can finally get something completely right.
Forgot this - please add to 'the list'. Some antimalware apps will mistakenly identify RB's MBR bootkit as a malicious rootkit and quarantine it, thereby hosing RB. When this first has happened to me I knew immediately it was a false-positive and 'told' the security app to ignore it (I think the latest RB build may prevent this from happening). Just something to be aware of.
There are 2 ways of doing sector by sector(raw) imaging: 1st. The imaging program ignores the partition type and its' contents and preforms a sector by sector as if would do when it would have to image a partition of an unknown format type. During the restore perfroms a raw restore ignoring the file table alltoghether. 2nd. The imaging program does not ignore the partition type and performs a backup, based on the file table of the partition, plus the free space. During the restore, restores the file table, the files and the free space. IFW/IFL uses the 1st type of backup when performing a sector by sector backup of an entire disk, but uses the 2nd type when performing a sector by sector backup of a known type partition. In normal situations 1st and 2nd type should produce identical results after a restore. But when you deal with rootkits (like RBRX) that hide themselves from the file-table when restoring you could end with not identical results because the program could have ignored some data when it performed the backup (2nd type). Example with Rollback and IFW's hot (sector by sector) back up: A. if you backup with IFW and its PHYLock driver (at least with Rollback 7x, 8x, 9x, have not tested 10), after the restore you will end up with a fully functional RBRX system. B. if you backup with IFW and VSS, after the restore you will end up with a broken RBRX system because IFW would have restored the file table of the snapshot from when the backup was made, instead of the baselines file table. RBRX would show the previous snapshots in its interface you will be able to load them as virtual partitions but you will not be able to boot in any of them. In A and B after the restore the data on the disk will be identical, but the real system in A will be your baseline and in B will be your snapshot (as if you commited it as a new baseline and RBRX "forgot" to eliminate the previous tree). Panagiotis
Panagiotis, I appreciate the time you took to explain that so clearly - I never realized there were two methods of raw imaging! I always believed that only the name was different (e.g., All-Sectors, Sector-By-Sector, Maintenance Mode, etc) but I thought they all worked the same 'under the skin'. As I use Acronis True Image (sector-by-sector mode) and Drive Snapshot (maintenance mode) to make my raw images, would you know which raw method they use? If not, how can I determine that? pv
Almost all imagers (that I know) perform sector by sector partition backups, based on the file table of the partition plus the free space. If I remember correctly Acronis and Drive Snapshot are no exception. The only programs (that I know) that for sure perform true raw backups of a partition are dd clonezilla with the command/switch -q1 and partclone when used the partclone.dd with the command/switch -I Panagiotis
Why would most imagers do that? - it 'flies in the face' of the meaning of RAW! DS offers two shadowing methods, their own proprietary (default) method or VSS. I wonder if their own method works like PHYLock?
Well, I'm guessing here, but trying to do a HOT RAW image... most imagers use VSS in Windows, and it doesn't make the "unmapped" space available for imaging (only used and free in its mapping area). IFW, originally, used its own VSS-type system lock, PHYLOCK and made every thing available, including the special Windows caching area it set up to provide for the dynamics outside of the lock. A few other imagers did that in the beginning... now most of them strictly use VSS. My recent quick test of Drive Cloner RX v6 showed it using VSS also for its imaging (HOT), BUT... it came up with the stuff outside of the image area to allow itself to put Humpty Rollback back together again... albeit with a few quirks.
Probably it has to do with mounting the images as virtual volumes or as archives when compressed. If they treat the partition as unknown, the imager won't store any info of the file table inside the archive. So, if afterwards it needs to be mounted, it will have first to be in uncompressed state, on a temp file or in memory, and since it will be raw it will be treated as a single block. For small partitions this is not an issue, but for large partitions it is difficult to do. e.g. if you image as raw a partition of 100GB to a file that occupies 60GB, then for mounting it you'll need a space of 60GB+100GB(temp file)+ a system with a powerfull cpu with lots of ram and a speedy hdd or ssd; or you'll just restore as another partition which will be much faster process. Panagiotis
After closely monitoring Rollback Rx over the last 3 weeks I have found Rollback Rx to be 1: A Space waster 2: Somewhat of a Liar The reason for this is the size of daily scheduled snapshots which on occasions have been over 4GB after cleaning up temporary space and software distribution downloads, the snaps are still this size, not all the time some days a cold start snap was only 60MB then the next snap would be 3½ GB's this all the tie having no size reflect diminish within the HDD/SDD itself, this barely showed a change. Then after uninstalling to a current snap containing everything I'd installed during this 3 weeks there is a significant size increase of My SSD While RB was present My remaining space showed 84.2 GB on removing RB the remaining space is now 91.7 Goodbye RB you're outta here
