I agree with post #96. Offline cold sector-by-sector across the entire disk is the only reliable way to image an RBRX volume. It is the job of the imaging program to restore all sectors, used and unused, allocated, non-allocated, whatever, to their original positions and contents. How it does that, differential, incremental, full, is entirely up to you and your software. As long as each sector is put back upon restore you're good to go! ADDED: If you're using hot imaging & realtime imaging while working live within an RBRX snapshot, who's to say what the imaging program is seeing, how is it interacting with VSS? How is RBRX interacting with VSS? What happens if you delete or create "snapshots" while in the middle of imaging? What happens if you delete a snapshot that spans "already imaged" sectors and "not yet imaged" sectors? And then create a new one.. Until you can concisely answer those questions with 100% certainty I wouldn't even waste time trying. You'll get a nice mess upon restore.
If your only comparison metric is FULL image speed for those (2) products, from my experience, I would say yes. Of course each gives you options for amount of compression vs speed. I was comparing Macrium's DEFAULT (Medium) with IFW's "Enhanced Speed - A." For a 50gB system partition containing 25.8gB of used sectors and all unused sectors set to a value of ZEROs (smallest compressed FULL image capability), the FULL (RAW, all sector) image for each application was... Macrium: 11.8gB in 24m IFW: 12.5gB in 15m This was done on a 2.4ghz Core2 Duo platform with 2gB of RAM. BUT... for other capability, Macrium (PAID) is a vastly superior INCREMENTAL/DIFFERENTIAL product as far as speed is concerned. Both products have a long reliability history and as such a very LOYAL following (Bryan, Pete... are you there? )
Here's the LATEST EXAMPLE of the above, posted this morning in the RBrx forum. And this was a user that has worked with HDS for a looooong time trying to understand his particular problem. He probably has a very strange system configuration.. but after almost a year of closely working with the user, you'd think the Devs could have a handle on that. It's the nature of the product, folks... be careful.
Thank you Froggie Indeed it appears they are running into more problems as systems become more complicated. Think of the number of folks that do not mention their frustration. It has been a growing frustration it appears for two years now since the advent of V. 10 I find it strange so many problems are still not ironed out, but for some, it works, likely on a more basic system config. Perhaps HDS are too full with trying to satisfy the corporate realm and not paying enough attention to home users?
Frog, how did you go about filling the unused sectors with zero's? Isn't doing this rather risky insofar as potentially wiping Rx's snapshot indices which are stored somewhere in there? ...even so, is the resulting backup 'savings' really worth the time and effort that the 'zeroing' process takes?
Jim, I would think that corporate customers are much easier to deal with. Usually, across corporations, system configurations are almost identical. They do this for ease of there own internal IT support... without this, that support would be almost impossible to perform. If this is indeed the case, then HDS only needs to get the basic common corporation system running well with their product... the other 200/500/1000+ systems, support-wise, are just gravy. With this support model, all you need to do is find some large corps who like the product, nail down their systems, and VOILA... lots of corporate income. But if you view that on an individual user basis, the model blows up in your face... you just don't have enough Customer Service technical support to deal with all the myriad of issues, and that appears to be what has happened to many ex-RBrx users over the tears. The idea of the product is basically an excellent one, the implementation of it is fraught with problems, mainly due to its incestuous nature with the Windows operating system. When HDS broke away on its own in order to migrate the product onwards and upwards, they did a decent job moving into v9 and zeroing in on Windows XP. By the time v9.1 showed up, it ran very well on XP. BUT... as MicroSloth has moved onwards and upwards (VISTA > Windows 10, UEFI, SecureBoot) and storage elements have done the same (GPT, >2tB, large block, & SSDs), HDS seems to have been a victim of a lot of those changes. Even at the current W8.1 stage, RBrx is occasionally getting blown up by M$ updates... this never happened before. Us v9.1 users would actually use RBrx to protect ourselves against faulty M$ updates... I'd say that's quite a change. I don't know where their future lies as far as commercial, individual users... but clearly it's become very hard for them to provide the needed support in order to retain that community.
Even as a satisfied Rx user I would agree that HDS' tech support should be better. In that specific case I did notice that the user's PC has a very high performance RAID 0/1 SSD (with its own dedicated drivers), so I'm wondering if Rx has been tested with that configuration?
I only did it prior to the RBrx installation and my 4-snapshot test configuration... it's not done while RBrx is installed. Although doing it LIVE (which is how I do it with BCwipe) under RBrx would not hurt anything, it definitely would create a very large next snapshot. With a protected SSD under W7 and beyond, this shouldn't be an issue due to the TRIMming of SSD data but HDS has never convinced me that their "TRIM support" was actually doing anything useful... all my tests have showed their TRIM, especially in the current system state, to be non-functional, which, by the way, would be the easiest place to allow full TRIM support... it hasn't been snapshotted yet! If the protected volume is "prepped" properly (ZERO wiping of unused sectors), it definitely makes for COLD RAW snaps that aren't much bigger than used sector snaps. If you're protecing a large volume (40gB used out of 500-1000tB), and it previously had a lot of scattered data on it, it makes a huge difference with the timing of the COLD process. Of course, once RBrx is installed, this prep process cannot be used in any sort of COLD mode... it will, indeed, destroy the RBrx snapshots.
PV... that user has been working with HDS for almost a year. That means they know exactly what his system configuration is. If they had any deep interest in his problem they would have easily duplicated that configuration. I have to assume that in his case, the effort was not worth what would be learned in the overall support arena or monetarily gained in the licensing arena.
That's what I thought. So as an Rx user I would have to uninstall Rx, run BCwipe and then reinstall Rx; correct? Would this be a one-time process? i.e., once its done, do the unused sectors (other than those used by Rx) remain zeroed?
Hi Froggie I am here, but following out odd interest. Not even a consideration for me with the necessity of a full sector image. My C: drive is a 1tb drive. Nuff said. Pete
On any RBrx system that I work on (not mine, primarily), whenever I do any sort of system maintenance/enhancement activity, most of them (defrag, partiiton size change, system disk change, etc.) I have to do with RBrx uninstalled. It's at that time that I "prep" the system after all my work is done and the last step is to reINSTALL RBrx. Otherwise, just keep an eye on your COLD images... if they start getting pretty big, schedule yourself a maintenance session. All unused sectors will remain ZERO as long as RBrx hasn't been there with either snapshot data (that'll be where it was originally) or redirected written data... that will remain until ZEROed during maintenance. If your system is very dynamic, you will see your COLD images start to grow over time... if the COLD protection process starts to become a challenge in terms of time, schedule a maintenance session. Usually there are points in time when you really don't need old RBrx snaps any more... in fact if you're using COLD backup protection, I would guess most of them are useless after a short bit of time, to lose them during your maintenance periods is no big deal.
That's the kind of drive, especially if it's reasonably dynamic (storage come and gone), that doesn't work well with the stuff being discussed here.
Well I do believe Sam's response to be an honest if not satisfactory one. Most likely their developers and tech-support are spread too thin. I have been on their case for years re the 'DCRx promise' as an end-all for a backup safety net and the most important feature they could possibly implement. Now supposedly, it's finally materializing with v6; we'll see.
Good morning (at least here in paradise). I want to thank all of you who have made constructive posts (especially Mr. Frog). I'm learning a lot about the pros and cons of RB. I guess it all boils down to individuality (type of user and type of hardware). For the time being I find RBxp a very nice addition to a Windows XP system no longer being supported by Microsoft (my 10 year old laptop won't support any newer Windows version and I'm too old to start messing with Linux).
This was the point I was making above with trying to apply the corporate support model to individual users... I just don't know how it can possibly succeed. Carfal has been testing the BETA extensively and has had some... well, decent results. There's a lot more to go, though.
PV, I've had a quick opportunity to play with the Drive Cloner v6 BETA... results are HERE in a new thread.
I believe that you came to your conclusions a little bit too fast... I decided to do some tests of my own, and the results are not too bad: Test environment: Win7 32-bit, MBR HDD, no UEFI RBRX Build: 2699751435 from Nov 06 2014 AOMEI Backupper 2.2 Test results: I made a backup of the MBR using BootICE BEFORE installing RBRX. To be on the safe side I also made another backup of the whole Track 0 (63 sectors for my HDD). Made a hot backup of the whole drive with AOMEI Zeroed out the first couple of tracks Booted from the AOMEI recovery disk and made a full disk restore (including MBR) As expected this left me with a non-bootable drive. There is no doubt about it, RBRX 10.2 passes a non working MBR to an image based backup software. Booted from a WinPE Live CD and restored the pre-Rollback MBR. Booted into Windows, no errors at all. In Windows of course RBRX was not functional. Reinstalled RBRX (no need to uninstall previous version any more, the installer does this automatically. Too bad that the previous settings are not retained). A ChkDSK did not reveal any errors. No need to restore the whole track 0 (no idea if this is also true for GPT based HDDs). Conclusion: If you do not feel the need to back up your drive including all your RBRX snapshots, the usual hot backups do still work (only tested with AOMEI so far, but other imagers should work the same). The only catch is that you have to restore an MBR which you have saved before installing RBRX. BootICE can do this, but there are other tools also. Cheers manolito
Hi manolito, Although I don't really mind making weekly cold all-sectors backups of my RBxp system your test is certainly of interest, but I wish you would have also attempted a restore without restoring the image's MBR. That's the Hot Backup restoring method that Cruise said works (based on his successful restores with RBrx v9.1). Furthermore, Cruise even warned against restoring the image's MBR! That made absolutely no sense to Froggie. I'm a total noob at all of this so I'm just learning. Would you please conduct a similar test, this time restoring the hot image without restoring the image's MBR or your externally saved MBR (that is what worked for Cruise). Then see if the system boots-up into Windows. Another AOMEI Backupper user, appster
Sorry, restoring without restoring the MBR makes no sense to me. First of all, I always do full drive image backups (as opposed to single partition backups). And when restoring full drive backups neither AOMEI nor Acronis even offer the option to not restore the MBR. Furthermore restoring without also restoring the MBR would only work if the original MBR is still intact. But in case of a real disaster you cannot rely on that. I always assume the worst case, and that would be a totally hosed drive, and I want to be able recover to a drive with nothing but zeros or FF on it. Cheers manolito
