Introducing AX64 Time Machine - hybrid imaging/snapshot software

Pete probably is right on this. The file
"C:\System Volume Information\AXTrack{5CB70D46-E287-424F-AB68-4C503D56509D}.dat" should be ancored (not excluded) in FD-ISR; otherwise when changing FD-ISR snapshots different versions of that file will be created in each one of them and lead to corrupted AX64 snapshots/incrementals.

Panagiotis

 

I dont mean to start a flamewar with users of FDISR, just giving my five cents to a developer:

That is a wise decision. You risk spend alot of time to try to make your your software compatible to a dead program. You are doing the right thing to concentrate on developing your software to be compatible to "reality" so to speak...

Windows versions later than XP is heavily "tweaked" to be compatible with FDISR, so there are so many more parameters to take into account than if FDISR officially was "built" for W7 or 8. Fact is that FDISR has not been maintained for years and was intended for Windows XP (or was it Vista too? its been long time since I used FDISR).

The original FDISR was my absolute favorite of any software out there. I have not encountered any software that has been so useful for me after that, but the sad fact is that development is dead, and has been for years. Hopefully you are on to something similar though, it sure looks like that

Imo you shoudn´t worry too much to be compatible with Rollback RX either, or other software that do basicly the same thing as your program do. I personally cant see why anyone would want to have two similar software doing the basicly the same thing really... of course every one does as he or she likes, but that should not be your concern as a developer.

 

I'm using Defence Wall on one XP box and was hoping to use AX64 on it in place of Shadow Protect for increased speed and more regular / frequency of use....even though it's an antique with only 2G of RAM.

As DF uses sandboxing etc perhaps that's unwise in view of the preceeding posts?

ISSO - if there's one program that you can manage to get working comfortably / without conflict I do so hope it's Defence Wall. ...pretty please

-cheers,
feandur

Ilya Rabinovich posts here. I will be bold enough to suggest that he may be very happy to work with you. https://www.wilderssecurity.com/member.php?u=38272

 

Heavily tweaked?
The only thing that FD-ISR needs to operate correctly is the windows bootloader and the system to be on the same partition.
If you want, you can even leave the pbr of windows unattached/restored after the installation, but you'll have to use a bootloader to load the "$ISR/ISRBIN" so that you can have the preboot menu of FD-ISR.

Panagiotis

 

indeed - FDISR basically runs out of the box on windows 7 and 8 if a vista boot sector is copied.

 

Pete the major incompatibility with FD-ISR is caused by the preboot enviroment of Firstdefense when booting to another snapshot; related with the following known issue:

Panagiotis

 

I don,t think there should any conflict between AX64 and DW( or any other application based sandbox like Geswall, sandboxie etc). I am pretty sure they will work together happily.

 

Thank you sukarof, I fully agree with your point, and although it would be nice to have AXTM compatible with as many snapshot/imaging programs as possible, I simply don't have resources to do much work in that direction. Maybe later.
In fact, I expect it to be compatible with most of such software, that don't mess with the system too much.

 

Feandur,

Thank you for the information, and I agree with aigle that most likely AXTM will work fine with such programs (and even if there are problems, there should be easy to fix).

 

Panagiotis, you are right, at this moment that's a major limitation. However it'll be fixed in the production release.

Peter, thank you!

Isso

 

I think it will be wasting time and energy to make AX 64 compatible with a dead software like FDISR or a somewhat failed software like RollbackRx.

 

aigle, our team isn't spending time on it now. Maybe later we'll address those issues, thanks!

 

Hi Froggie. You may recall i have the same experience after rolling back a snapshot with RBRX. The first backup always takes a while (the time you described) but produced a small backup. However, speed was normal after this first backup. Is this the case for you with SD? You didnt say anything about that.

Below is the reason Isso offered for the delay in first backup after a restore with RBRX

I think that this explanation would answer the same condition your experiencing with SD.

 

Failed software like RBRX??

Anyway, in principle I agree with you. However it would be in AX64's interest to co-exist peacefully so that people wont have to choose. People wont always choose AX64 so that would mean lost sales unneccessarily. In pursuit of that goal, it wouldnt hurt to have a peek at these other programs and make some minor changes to AX64 now during development rather that trying to make big changes later.

Ultimately, it's up to Isso and the team as to what they do and how they do it. The purpose of this forum is to exchange ones wishes, desires and ideas.

So even though me may sometimes think that its a waste of time entertaining old programs, discussing them may bring or shed light to new ideas.

 

To make any imaging software to work with Rollback Rx, while at the same time capturing all the snapshots of Rollback Rx, doing HOT Imaging is almost impossible a task. Even HDS own imaging software Drive Cloner Rx doesn't accomplish this at the present moment.

Only one imaging software has been able to accomplish this, and this is Image For Windows (IFW), due to PHYlock.sys (instead of VSS.sys). Even for IFW, certain conditions have to be met and the registry has to be tweaked.

Best regards,

Mohamed

 

Mohamed. Slow down there. No-one, especially me, has ever suggested to make AX64 capture RBRX's snapshots.

I think someone asked if AX64 and RBRx worked together so I thought i would be the first to ran some tests so see if RBRX was compatible with AX64 in its current form. As you know i was delighted that in fact they did work together. There was no mention of trying to get AX64 to take images of the hidden sectors of Rollback. In fact, it's this very inability that makes these 2 programs compatible so as far as i'm concerned this is a plus.

 

Dearest Isso,

I fully agree with you. However, one software company you should really worry about is Acronis. Any product (not just imaging) of Acronis either it is still currently installed on any computer or uninstalled from the computer as Acronis leaves remnants on uninstall, AXTM doesn't work on that computer.

So, if someone purchases your product and have any product of Acronis installed on their system in the past (but currently uninstalled), your product will not work.

Acronis is a big, big company and very well known for it products. Almost all computers users have tried Acronis product in the past in one form or another.

If Shadow Protect can co-exist with Acronis, then I am pretty sure that AXTM should too.

Best regards,

 

Dear Carfal,

If AXTM works with Rollback Rx, it is not a big deal. All imaging software work with Rollback Rx, while doing HOT Normal imaging, and capturing the current snapshot of Rollback Rx.

On restoring the image of any imaging program, the console of Rollback Rx has to be uninstalled and Rollback Rx has to be reinstalled.

To me Rollback Rx and AXTM are not complimentary products, but rather they compete with each other on the same system.

It boggles my mind why would someone will have both Rollback Rx and AXTM on their system at the same time, and hog their precious computer resources.

Best regards,

 

Mohamed, all i did was confirm that RBRX and AX64 currently work together. I'm not forcing RBRX onto anyone and as to the reasons why i want to use both, I've already explained....twice.

Mohamed, the content of your reply doesnt syncronise with my previous post to you. Now your talking about restoring images with "any" program and having to uninstall and reinstall RBRX. Where is this coming from? My report on RBRX and AX64 doesnt mention any of these things.

This line of discussion IS a waste of time escpecially if you cant keep on topic. This is how things get out of hand and it becomes a he said she said conversation with no end and no point.

I am not interested in doing this again with you ( thats right, I do remember the last time you did this). So quit it.

Talk to someone else. I'm done with you.

 

Isso, have you managed to check whether RX issues TRIM commands during snapshot defragging like Panayiotis suggested? I'm sure many of us would love to know whether RX actually cripples TRIM altogether or not.

There is a little proggie out there called TRIMcheck. It has no GUI, it runs in a command prompt window. You must copy it on the SSD that you are testing and run it twice, waiting for at least 30 seconds to a minute between runs in order to ensure accurate results.

When executed for the first time it will write on specific sectors on the SSD. It will then delete the written data and try to re-read the exact same sectors. When TRIM works you'll get zeroes on the sectors it wrote, plus a notification that TRIM works. If the data is still there you'll be notified that TRIM is not working. This program is good for cases where certain software use cheap workarounds that cripple TRIM in order to ensure SSD compatibility. In such cases fsutil will still show that TRIM is enabled, regardless if it really works or not. With this proggie you'll know for sure.

Many thanks to Panayioti for pointing it out, and to Fuzzfas for testing it with SD. Get it here:

http://files.thecybershadow.net/trimcheck/

 

Greetings, Carfal!

After some snapping and rolling back from that point, yes, all seems normal once again.

I fully understand Isso's explanation of the "problem" and will act accordingly. In the end, I don't plan to use anymore than one solution for stepping back in time... it'll just be a matter of which works best for me on the particular system.

 

Thanks Froggie. I was just curious if the behaviour was the same which you confirmed.

 

From the FWIW department...

I decided I would try and check to see exactly how Rollback RX handles TRIM and would try it on an AXTM-enabled SSD system (heck, why not). This system has had RBrx on it previously (prior to AXTM alpha testing) but was removed in preparation for AXTM alpha testing.

I left AXTM in place and installed RBrx. The Windows portion of the install went fine but following the actual installation (after next BOOT) that occurs at the RBrx sub-Console level, instead of going into Windows following the actual installation, it hung with a BLACK screen and the infamous blinking UNDERSCORE character, never to BOOT into Windows.

I restarted the system, and during RBrx's sub-Console availability, I jumped in and unINSTALLed RBrx. Following the uninstallation, Windows BOOTed fine to where it was before the attempt.

This time I unINSTALLed AXTM and reBOOTed before I attempted another RBrx installation... same thing happened as above. At the moment I can't install RBrx on this SSD-based system at all.

I ran the exact same sequence as above on a HDD-based lappy and RBrx installed just fine. What this all means, I haven't a clue...

 

Dear Mohamed,

I agree and as soon as we get to the compatibility testing we will be proceeding with the most popular software first, so Acronis will be closer to the top of the list (I plan to start with popular antiviruses first, then move to imaging/snapshot programs)

I think there is absolutely no reason to argue regarding RBX compatibility, as we don't work on it, and I'm grateful to carfal for doing the work that I eventually would need to do.

Isso