Introducing AX64 Time Machine - hybrid imaging/snapshot software

AXTM Build 800 Feedback

System: W7ProSP1x86, 3gB RAM, Core2Quad, SSD-based protected partition

In continuing to play around with AXTM and SD (Shadow Defender, a andbox-type app), I tried EXCLUDING (not sandboxing) the AXTM special file in "System Volume Information" then entering the sandbox with some follow-on activity. Upon reBOOT (when the sandbox dumps its accumulation), I then attempted an AXTM snapshot. What I wanted to see is if it would have to make a complete disk scan to accomplish the snap or just an incremental reference for the scan. It indeed had to make a complete disk scan to provide for the new snapshot, which was sized as expected (just the incremental difference from the previous snap).

Now... let's see what I can do

I reverted to the snap prior to the SD test and all went as expected (time and data-wise). I then tried to revert to the snap after the SD test (the one requiring the long disk scan) and got the following error...

Error: -99979 starting restore operation

...although the restore operation continued and completed as expected in an incremental (time and data-wise) fashion.

More food for thought...

 

Dear Froggie,

Shadow Defender uses the fake TRIM like Rollback Rx. It puts the drive in fake RAID status to disable TRIM. This fact has been reported to Tony of Shadow Defender.

If people want to use their SSDs with the above programs, then they are better off to disable the TRIM themselves, and have it reported to the above programs as normal HD, rather that putting the SSD drive in fake RAID.

Best regards,

 

Nice to see so much discussion with AXTM you are doing a wonderful job Isso at trying to address all the questions, etc. You are a fine example of a developer that actually listens to feedback and explores the solutions.

I would be careful though at how much effort is made to make AXTM solution compatible with so many other similar programs because it takes time away from arriving at a reliable stable product. Certainly it is good to address potential conflicts, but in my opinion, getting too caught up in chasing this it would be easy to lose focus on AXTM itself.

At this stage in Alpha, I understand trying to address all you are able to, but i just am concerned it will hinder AXTM development focus. I think it is great to see so many involved and so many helpful and encouraging posts. I am not surprised at the growing popularity because I feel AXTM has the potential to offer a very complete and unique solution as it matures and features are added as you are able.

Thanks to everyone contributing to this software development. What a great bunch of folks we have here

Jim

 

Froggie,

Interesting results, thank you. So basically you got it working with SD, that's nice Although I think this needs more testing to prove that data is in consistent state.

For error - that error code means that restore operation was attempted while backup operation was in progress. I don't quite understand how that can happen. Did you have automatic backups on?

Isso

 

Thank you Jim, don't worry, the development continues as usual, and we didn't get to compatibility issues yet. So all of such work is done by the Wilders members.

And I agree that Wilders community is just great, and that's the reason I announced the program here. Thanks guys, I really appreciate everyone's input!

Isso

 

Not really... the result was the same. AXTM had to scan the whole drive to enable a snapshot following the SD test... same a s before. That's the only SD test anomaly noticed previously.

Nope, all I did following the SD test was to create a new apredSD snapshot... this was the one requiring the full disk scan prior to the creation of the snap. Then I snapped back to the snapshot prior to the SD test (size and time as expected), then I tried to snap forward to the apresSD snapshot created at the end of the SD test... the one that took so long to do. At that time I got the error but the snap forward continued as usual (time and data as expected... I just dismissed the ERROR window).

I'll look for some consistency problems but when I snapped forward (with the error), the result contained the changes prior to the apresSD snapshot... exactly as expected.

 

Hi, Isso!

I don't know if you are already aware of this issue:



VirtualBox latest version
Guest OS: 8X64
user: Standard

 

@Froggie
you should not exclude the "AXTrack*.dat" in Shadow defender. SD virtualizes your file table and redirects the writes in the sandbox. When you exclude/commit the changes it simply copies the file to the real system; the committed AXTrack will include the sectors that where modified in the virtual system but they will not correspond to these of you real partition and will lead to corrupted subsequent snapshots.

Panagiotis

 

Isso, I have two questions:

1) AX64 is OS depended for accessing the disks/partitions? e.g. in xp will not support gpt, in Vista and 7/2008/8(x86) will support gpt but for non boot drives, and in 7/2008/8(x64) will fully support gpt?

2) Since it is volume based and does not reside in mbr it should be compatible with apples bootcamp, correct?

Panagiotis

 

Hi test (cool nickname! )

Thank you! Yes, I'm aware of it, it will be fixed in beta release.

Isso

 

Thanks Panagiotis, this is exactly why I was afraid of data consistency problems. It's better leave that file in sandbox along with the rest of the program. There may be other options though, but I'm not sure how ShadowDefender works, so I can't speculate on that.

 

1) Yes

2) Yes

Isso

 

You are welcome.

SD and AX64 should be considered compatible only if the users do not exclude any files and do not commit any changes from the shadow defender's sandbox (for the partition that is monitored by AX64).

Personally, I do not see any point in using AX64 with other imaging apps that use monitoring technics or volume sandboxes apps (like SD); the only thing that they'll succeed is to overcomplicate things and then blame AX64 for corruptions (and offline restores won't be of any help either).

AX64 is great because is simple and provides both imaging and fast system restore abilities.

By the way I have a feature request.
The ability to point/name the folder where the snapshots reside (or if used the default as it is now, to add in the folder name the unique identifier of the monitored volume, or a subfolder named by the unique identifier and put the snapshots there). It will help for multiboot environments when a user wants to store the snapshots of e.g. xp,vista,7,8 in the same partition.

Panagiotis

 

Thank you Panagiotis, I agree that it's better to not mix those kind of apps unless there is an important reason for it.
For feature request:
Yes, I'm considering to do that in the future advanced version. This version is meant to be as simple to use as possible, thus no folder selection exists.

By the way you can capture multiple volumes into the same folder - I don't see any problems with it. In the browser you will see all captured volumes with their letters and machine names, so you can easily view and restore any of them.

Isso

 

This would great - for a update shortly after launch

 

Thanks,

I hadn't tested it in such an environment and was afraid that would empty the folder when creating a snapshot for another volume.

ps. What happens in the recovery PE environment/browser when it finds the snapshot folder in more than one partitions?

Panagiotis

 

Recovery environment at this moment doesn't have automatic backup folder detection (like the online version has). So you should specify the folder manually.
But I'm thinking about putting in some automatic detection. Probably just traversing all drives until a suitable backup is found.

Isso

 

LOL. and I thought that it was a bug or something on my PE's.

Panagiotis

 

Windows 8 x64 RAID, updating 1.0.802 -> 1.0.803
1.0.803 - Imaging error C10000000
Isso, Is there any debug log or similar with AX64?

 

I think I found the problem why I just couldn't get the latest alpha of AXTM working on my test machine. That machine would always lock up tight or throw a blue screen when trying to perform a backup.

The culprit: Intel Rapid Storage utility.

Once uninstalled, no more problems. Just FYI...

 

I use Intel Rapid Storage Technology and I have no BSODS here.

 

Bionic71,

Thanks for the information, I'll look into it. No debug log yet, but will be added in coming days. Also, please don't use the versions that aren't announced (like 803), they are untested and are intended for our internal use.

 

Marc,

Could you please see if there is C:\Windows\MEMORY.DMP file on your machine that had blue screen? If it's there could you upload it somewhere and PM to me the link, or send it to info@ax64.com? Thank you!

Isso

 

I don't have such memory dump file even though I have Win8 set to create it. The vast majority of the times, I get a solid lock up of Windows. The event viewer simply has this to say:

"The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly."

I've had 1 blue screen this week, but can't get it to happen regularly.

Reinstalling IRST brings that nasty behavior back. I have been two days free of any freezes since I removed it and it is only happening when AX64 is doing a backup. I'll try to use other imaging tools on that test machine to see if it's something less specific to an IRST/AX64 interaction.

 

Thank you Marc. I was wondering if you can give me your system information (with RST drivers installed - I'm mostly interested in their versions). Easiest is to run the following on the command prompt:

msinfo32 /nfo C:\system.nfo

And send that system.nfo file to info@ax64.com. Thank you!

Isso