Introducing AX64 Time Machine - hybrid imaging/snapshot software

I tried it on my XP laptop. New version works just fine. I will add couple of things.

1- Baseline image taking progress bar is a bit misleading. It took almost 12 mins to reach 20% and then only two min to complete the rest of 60%.

2- I also highly recommend an optional boot menu for AX64.

3- Somehow it fails to Mount backup images as hard drives in windows explorer. Gives an error that can,t mount image. Not a big deal though as backup explorer is working still.

I am thinking to start using it as main recovery software for my two latops.

 

BTW it,s working alongwith Comodo Time Machine.

 

To confirm what is your baseline you should either "see" the disk/partition from outside with a PE, or if done from the system you should uninstall RBRX.
Updating the baseline and viewing it inside the RBRX environment is not enough.

edit:
e.g.
a) Create a Baseline with RBRX with PowerIso installed.
b) Uninstall PowerIso and create and then restore and AX64 incremental (of this state)
C) Unistall RBRX to the baseline. (what you see after that?)

RBRX structure is not only linear but can be used with ramifications and you should take them in account too. If a user has many snapshots he will be in big trouble if he follows the pattern that you described, unless he updates his baseline right after the restore of AX64.

Panagiotis

 

First of all, this is a relatively new HP Pavilion dv6t laptop which uses an mSSD as a cache (Intel RST RAID 0 configuration) for the HDD. I can't answer the chipset question, but the laptop has an Intel Core i7 CPU if that helps.

Secondly, I've experienced this issue with every PE boot disk I have tried in this laptop, so it's definitely not your doing ....and what I find really puzzling is that DOS/Linux boot disks have no problem whatsoever seeing and accessing the HDD.

Cruise

 

Hi BG. AX doesnt actually capture the Rollback snapshots but rather works independantly within them. RBRX on the other hand is very much aware of the AX changes. So you have a situation where rolling back using RBRX doesnt affect the AX snapshots (because the drive where the AX snapshots reside on are not protected by RBRX) and a situation where the AX snapshot backs up the current file structure ignoring all of RBRX structure tree bar the current RBRX snapshot its in. Makes sense? Im not sure how else to put it. Let me give an example

1. Install a program called X

2. Take a RBRX snapshot called RBSS1

3. Take a AX snapshot called AXSS1

4. Uninstall program X

5. Take a RBRX snapshot called RBSS2

6. Take a AX snapshot called AXSS2


So your current RBRX snapshot is RBSS2. If you rollback using AX to snaphshot AXSS1, program X now reappears (as expected). When you Look at the RBRX snapshot list, you'll see that Rollback is still in the same snapshot (RBSS2) where program X was uninstalled. Taking a new snapshot with RBRX or AXTM will now reflect this change in the snapshot just taken as you would expect. If i now rollback to RBSS2 using RBRX, program X is in fact now gone as expected. See...they seem to happily work independantly from each other.

Clear as mud.

 

Dear Isso,

I am not sure what we are taking about above. Didn't I create a Boot menu with EASYBCD? With same EASYBCD one can also create a USB Recovery.

Best regards,

Mohamed

 

I did all this and as i expected PowerIso was there again. Is this what you were expecting? This makes sense to me because when i installed RBRX, PowerIso was already installed so uninstalling to the baseline would bring back PowerIso, right? Whats your thoughts on this and what would you like me to try next?

 

Panagiotis, i just ran your same procedure again only this time i uninstalled to the current system state. As expected, PowerIso was now gone.

This experiment has shown 2 things.

1. The RBRX baseline snapshot remains intact after AXTM live restores

2. The RBRX snapshot structure also remains intact evidence being that PowerIso was nowhere to be seen after uninstalling to this state.

Is this what you were looking for?

 

aigle,

Great to hear that it works for you! For progress - you are right, we are working on improving this. Boot menu - noted. Mount - not sure why it's happening, is there any error code that you see? Thank you

 

Cruise, most likely this is a problem with missing RAID drivers. In fact AX is expected to automatically copy all required storage drivers from the system to the recovery media, so looks like something goes wrong. I'll check it out.

 

carfal, Panagiotis, I'm not sure I fully understand what's going on when RBX and AX work together, but this looks very interesting, thank you!

I tend to agree with carfal, because what AX does when restoring is a simple write to the disk, which I expect to be intercepted by RBX just as any other normal disk write operation. In contrast to other imaging software, AX restores when main OS is up (so is RBX driver), thus RBX registers the operation properly. I might be missing something though.

 

Dear Mohamed,

Sorry, how could I forget about your experience creating boot menu with EasyBCD Of course it's a very nice method. I was just thinking to do that automatically from within the program, but for now anyone can use your method, thanks!

Isso

 

Dear Isso,

Almost all imaging programs have this option these days, for users to include it as Boot menu. The choice is the users, to activate it or not. This includes Macrium Reflect, FarStone Total Recovery, EaseUS ToDo and so forth. For Window 7 it baically, adds a simple entry to BCD Store.

Best regards,

Mohamed

 

Thanks Isso. This is what i was thinking as well and why i was convinced that Rollback would be fine with AXTM.

 

Sorry, i forgot about this reply.

So i was going to ask about saving the settings in the backup folder instead so that its not "changed" when a RBRX snapshot rollback is performed. Is this something that would be workable and make AX's first backup or restore work normally after rolling back with RBRX.

I even thought about the idea of having 2 locations for the settings. One located with AXTM and one located on the backup drive\folder. Then when a roll back is performed with RBRX, AXTM will compare the 2 settings files and use the latest version as its template. In theory, the backup drive will always contain the latest version. Is this workable?

 

I will have to think on this for a bit,,,,,,the only part of the above that was really clear to me was the Clear as mud statement.

By the way, I have linked your 2nd test results to the thread I started over on the HDS Rx forum. Again, thanks for doing all this testing and explanation about what you have done. It is most appreciated.

EDIT:

OK, I have been studying the above and I think I am getting it.

Its not a question of AX64 capturing Rx snaps but rather, since its effectively ignoring all of the Rx snaps, and is able to restore a functional Rx console without resetting the baseline, it has allowed the previously existing Rx snaps to continue to exist and be available to Rx. Is this correct? If so, then you would have 2 sets of snaps to choose from, both of which would allow you to recover your PC to a state where the other program and its snaps happily exist. What other imaging solutions (other than IFW) do is destroy Rx and necessitate a reinstall of Rx which means a new baseline as of the time of the reinstall. Have I got it or is this all mush?

2nd EDIT: from the posts I read after writing my first edit I think I do have it correctly understood. If I do its one awesome combination.

3rd EDIT:

carfal, I just posted the following reworked paragraph over on the Rx forum. Is this correct?

 

Wow BG. This is getting confusing.

Lets give it a shot.

Just so we're on the same page. The only AX full backup is the first snapshot that you take after you first install AX. Every other snapshot that you take from now on using AX is an incremental snapshot. When restoring with AX it compares the existing file structure and makes the changes so that they match. The RBRX snapshots subconsole and eveything else thats to do with RBRX are hidden to AX (is my conclusion) . There is no danger of damaging RBRX's structure because of this. All of this is possible because of AX's unique ability to restore on the fly on your live system so Rollback can track this and keep the consistency within it's own structure. All AX's writes are redirected by RBRX (as it should) and when you take a RBRX snapshot these changes are locked into that snapshot. It really is a work of art.

This second part also holds true for AX. I'm guessing that if you had to do a full restore from AX's boot cd then Rollback would be broken. In fact, I'm certain of it without even testing it. (big call)

The above is excellent except for the bit about restoring a functional Rx console. It gives me the impression that AX actually restores this when it's my belief that AX actually cant see it and so it always remains intact. But thats just my opinion.

Thanks for keeping the folks at HDS appraised of the situation here at Wilders.

 

I've done some more testing. Things just keep getting better.

Way back in my first report, I mentioned having AX already installed in my VM with about 3 snapshots. Then I installed RBRX v10 and started testing.

Well, i gave a warning about restoring using AX to a snapshot where Rollback was not installed. Yes, that's exactly what i did. Predictably after a reboot....BSOD.

It's what i saw before the BSOD that kept me smiling. The RBRX subconsole. It survived. (trembling with excitement)

I rebooted, pressed "Home" and there was the heavenly RBRX menu. I paused there and took in the moment. Could it be this easy? I selected a snapshot at random to roll back to and pressed "enter".

In an instant (or so it seemed) the snapshot loaded and windows booted up normally. Eureka!

It's like Isso and HDS are talking to each other secretly. These two progams are in love. All of RBRX's snapshots were there (as they were in the subconsole menu) and all of AX64's were there as well. I performed some rollbacks, backups and restores with both programs and all worked perfectly.

There's no doubt that RBRX is in control when installed with AX64 but thats not a slap in the face to Isso. These two programs really compliment each other. Well done HDS for releasing a really stable first release RBRX v10 and keep up the fantastic work Isso.

 

So i've decided how I'm going to use these 2 programs together.

Rollback Rx will still be my main Instant Recovey Software. I'll use this for my everyday needs.

AX64 will be my offline backup (my security blanket). Snapshots will only be taken when i decide that my system is at a perfect state. This will be my very long term backup. Crucially each snapshot will only be a fraction of the size of a full image at each of these stages. Perfect. Whats more, a year down the track after i've uninstalled and reinstalled RBRX (several times) for the usual maintenance and lost all of the existing snapshots (as we all know) , AX64 would still have all of its snapshots intact.

I'd be able to simply restore any of these snapshots using AX64, do what i have to do, roll back to a previous snapshot using RBRX which will then remove the restore that AX64 just allowed me to work with. Think about this...this is just an irresistable setup that few will be able to pass up once they realize the implications of this.

Another use would be to use AX64 to recreate your snapshots after a system crash or after the usual RBRX maintenance routine. Granted this will probably use a lot of disk space and there are easier ways to do this such as IFW sector by sector backup and restore. But this takes ages. Also using IFW will defeat the purpose of a RBRX maintenance routine since the whole drive will need to be reimaged. Then your right back where you started, Rollback still installed and what not (crazy). You cant beat the incremental nature of AX64 backup and still remain compatible with RBRX.

I cant wait.

EDIT: When i say "recreate your snapshots", what i mean is you would restore the first AX64 snapshot, take a RBRX snapshot and name it the same, restore the next AX64 snapshot and so on, and so on.

 

Hi carfal, very interesting results, thank you for taking the time to test all this!

Personally I would not use RX and AX64 together as I don't really need both functionalities. We must also consider the possibility that whatever works for one system may not work in the exact same way under a totally different hardware/software configuration. I'm glad that it works well for you, but there is always the chance that RX and AX64 wouldn't mix well together within certain setups.

When the AX64 final comes out - and if the incrememental back/restore speed of AX64 improves even further - then I would most probably ditch RX altogether and use AX64 in its place. Too many cooks in the kitchen spoil the broth!

Personally, the only way I would use RX alongside AX64 would be via the AX64 start-up media in order to create/restore off-line full sector-by-sector images which would include all RX snapshots. I wouldn't use AX64 plus RX both from within Windows, I don't see the point in that. RX provides fast day to day restores, and when big problems arise I would just use the AX64 boot stick to restore my last known good raw AX64 image. Basically I would substitute my current Acronis startup media for the AX64 one - provided of course that it would allow the creation/restoration of raw disk images, variable image compression, and the ability to verify previously created images on demand.

Regarding the startup media issue not recognizing disks, it's probably a driver issue. I've had problems in the past with my Acronis and Paragon custom-made WinPE startup sticks: They couldn't see any USB 3.0 disks or any disks attached to ASMedia or Marvell ports. I had to manually inject the ASMedia, Marvell and Renesas drivers into boot.wim in order to be able to save a backup on those disks.

Isso, it would be great if upon creation of the startup media there would be an option where users could supply their own drivers for inclusion in it. This way users would be able to backup on disks attached to USB 3.0 or other ports at full speeds, and without having to manually inject those drivers into the startup media afterwards.

 

Hey carfal, I'm actually developing RBX rival, what love are you talking about?!

Joking aside, that's fantastic results! I would never think that these two programs could co-exist. Ironically this is in part possible because we haven't completed MBR restore at this point. I was planning to add unconditional MBR restore in upcoming days, but maybe now I need to have it as an option.(Otherwise if AX was installed before RX, the restore will destroy RBX console)

Thank you!

Isso

 

CyberMan,

My original plans were to make the first version of AXTM as easy to use as possible, that's why when creating the recovery media it automatically adds USB3 and RAID drivers from the main OS into the PE. I'm not yet sure why this doesn't work with Intel RST, but will check it out.

Later, along with adding advanced features I'll add the capability to specify custom drivers. Thank you for sharing your idea!

Isso

 

I wasn't aware that the startup media automatically adds those drivers, that's great news Isso! In the past I have had problems with the original Linux-based Acronis startup sticks not working on some computers; so I had to create my own WinPE versions which couldn't "see" disks attached to USB3/ASMedia/Marvell ports without having to inject the drivers manually.

Of course I agree with you, the main program should be kept as simple and bloat-free as possible. Any extra options should be well documented in the help file and switched-off by default, ready for people to use only when they need them. Users who want basic bare-bones functionality could buy a cheaper basic version, and any advanced features could be part of a later "Ultimate/Pro" edition

 

No error code. Any way it,s not a big deal IMO.

I have a very important question BTW. As we have seen in case of AX64 and RollbackRx being used together, RollbackRx was able to track all the changes made by AX64 during a restore. My question is that: Can a low level malware/ rootkit intercept/ manipulate a live online restore being done by AX64? I suspect it,s quiet a possibilty unless you do an offline restore.

 

Yes I have used both usb and windows for restore but when windows does not boot it is nice and easy to use a boot menu. Difference between and ISR and imaging in terms of experience

Should be easy to add given the way you have built a revcovery