Introducing AX64 Time Machine - hybrid imaging/snapshot software

Part II - Another quick virtualization test under AXTM

I set Shadow Defender aside (due to its long snapshot time following a virtualization session) and tried a piece of FREEware... ToolWiz TimeFreeze (TF).

An AXTM snapshot, a TF install, sandbox on, lots of activity on the virtualized volume (same as AXTM protected volume), and a reBOOT to exit the sandbox. This all followed up by another AXTM snapshot.

This last snap was fast and brisk, time and size to be expected. Then a revert to snapshot prior to TF installation and testing... also fast and brisk as expected. Then a revert to snapshot following TF testing... also very fast and brisk.

System structures look fine and it appears that TF's virtualization did not affect AXTM's expected functionality at all.

FYI!

 

Thanks a lot for compatibility testing Froggie, this looks very interesting!

Isso

 

Just to let you know guys:

I contacted Tony a few days ago regarding the disabled TRIM while in Shadow Mode issue. A new SD version has now been released two days ago that fixes this issue. Now TRIM is fully functional when in Shadow Mode.

Also new version of TRIMcheck 0.4 has been released:

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

I am in contact with the developer Vladimir Panteleev and we are currently testing further improvements. I published a mini-review about it at Tweak Town:

http://www.tweaktown.com/articles/5...tial-ssd-trim-functionality-tester/index.html

It would be great if someone could test the latest version of SD together with AX64. I hope those two play nice together!

 

Isso... an anomaly.

I just made an XPsp3 system available for AXTM alpha testing. Removed Rollback RX then defragged the entire system prior to installation of AXTM (Build 803). Then fired up the baseline snap.

The AXTM monitored partition has appx. 30gB in use. After 65-min, the process is only 19.2% complete and the snapshot file is appx. 6.9gB in size. I expect the final snap to be appx. 21gB. It looks like it's gonna take an inordinate amount of time to complete. Both the source and destination HDDs are SATA II 7200rpm decent cache-based drives.

When I did this under Windows 7, using a HDD (5400 rpm) as the source and a USB-basd HDD as the destination, AXTM did a 15gB used partition space in about 14-min and produced an 8gB baseline snapshot.

The AXTM process is using CPU time as expected and there's no other significant HDD activity on the system. Is there anything I should be looking at to determine what might be causing the anomaly? My other imaging tools (mostly IFW) do things in an expected amount of time.

Lemme know if I can help in any way...

 

Having continued my testing. it looks like Build 803 may be the culprit. That's the version being used in the XPsp3 test above.

When I upgraded a Build 802 on my HDD-based W7proSP1x86 alpha laptop with v803, and tried to generate a new baseline (in a new folder), I received one of those "-error C10000000" errors. I thought it may be some sort of anomaly in continuing from the point before so I uninstalled AXTM completely then re-installed v803 from scratch. Upon attempting a baseline snap, same error as above.

Went back to v802 and all is well once again.

Just went back and checked on that XPsp3 alpha system and its baseline snapshot is now 15.5gB and it's been running for 2hr, 45min... something surely is amiss there.

 

Hi Froggie,

Hmm, not sure about slow speed, but please don't use version 803, 802 or others that haven't been announced. These are untested and for our internal use only. Please use only the version from www.ax64.com webpage, i.e. 800 at this moment.

If 800 doesn't fix the slow speed, please let me know. Thank you.

Isso

 

Dearest Isso,

Thank you for the above information, and I believe that you have now mentioned the above second time.

However, what I understand from Froggie that the 800 doesn't restore. I am missing something here?

If the above is true that you need to come out with another Alpha which restores the system for testing. I couldn't test on my machines due to incompatibility, when I obtained my friend's machine I only have 800 (not earlier versions) and haven't attempted any restore due to Froggie's statement.

Best regards,

Mohamed

 

Know I shouldn't be doing live tests but I do not regret this now.

We just had a power outage here and I could not boot up afterwards.
My PC kept hanging at automatic repairs and it would not come back.

AX64 on = success -> AX64 just saved my day.
One thing to trial being prepared or use VM's but much different for unprepared scenarios.

Double thumbs up today..

 

<gulp!>

Very sorry about "probing" around... will only use released ALPHA from now on.

Retested the XPsp3 system using Build 800 and the results were the same. The baseline snap is as expected (21gB on a 32gB used system) but it took 4h 8m... not as expected.

I tried an incremental snap on the same system after it sat idle for appx. 7h... snap size = 58mB, snap time = 45-sec including "preparation time, seems normal for that class HDD. Sure don't know why the baseline was so sloooooooow.

Hi Mohamed! What doesn't work is the v800 RECOVERY disk (used for recovering a broken Windows system)... using AXTM'a recovery feature under Windows using v800 works just fine.

I don't believe Isso has dealt with the broken RECOVERY disc feature yet. In the meantime, if you need to perform such an action, feel free to use the RECOVERY ISO from v796... it works just fine. Here 't is... v1.0.796 RECOVERY ISO

 

Thanks for the feedback! All info is good info in testing phase

 

What successfully worked for me is 1.796 PE but I have 1.800 installed, I'm not using PE from this build.

 

CM, they play together... but maybe not as nice as we'd hope.

The ACTIVE TRIM issue wasn't a problem in previous AXTM tests I performed, it was how and when SD punts its virtual storage. I don't know when or how this function is performed during the reBOOT, but it does it in a way that leaves an inconsistency that AXTM will find the next time it tries to snap the system. That inconsistency causes AXTM to scan the entire system to perform the new snap (which will be normal in size) which is time consuming (same time as a FULL baseline backup). The result following the new snap seems to be a normal AXTM status at that point.

BEWARE! This was only tested using SD as a sandbox without any exceptions or special commits... basically running the system in the sandbox then reBOOTing to go back to the previous pre-sandbox system configuration. "We" think that special exclusions like AXTM's tracking data file, or not excluding that file and doing special commits will screw up AXTM's ability to know what the disk's data status really is. If that happens, any snap restores will most likely wreck the system structures.

AXTM was also quickly tested with "ToolWiz TimeFreeze," another sandboxing type application. Using it in the manner described above with SD, it provided no problems for AXTM and its snapshot capability... all snapping and restoring was as expected. Again, this was only using it as a 1-time sandbox... no file freezing or commits of any kind.

 

Dear Mohamed,

The problem with 800 is that on some machines the recovery media that it creates doesn't work. Unfortunately I wasn't yet able to reproduce it, but I'll work on it in coming days.

However the primary, online restore (without recovery media) should work fine on all systems. In fact, even recovery media should work on most of the systems too - just try it.

Regards,
Isso

 

Bionic,

Great to hear it, thank you! Were you using Win 8? It's notable for being stuck at boot after power outage, that's one of the reasons I don't want to shift to it.

Isso

 

Froggie,

Thank you for helping with recovery media problems and sharing your ISO!

For slow operation on XP - could you let me know the CPU usage during full backup. Also - could you test any other imaging software (Macrium for example) and check the speed?

Thank you

 

Yes, your TimeMachine-ship...

You're quite welcome...

Well, this turned out to be a MY BAD. The testing machine is remote from me (no hands on) and when I took your suggestion to use another imaging tool (IFW), it was discovered that my previously very speedy WD BLACK HDD located on an eSATA II port had slowed down to speeds approximating a fast floppy disc.

I moved AXTM's snapshot location to an independent partition on the internal HDD and speeds seemed to return to normal. The baseline is in progress as we speak. The process is taking from 21-36% of a 2.8ghz Athlon X2 Dual Core processor.

One thing that puzzled me... without re-installation of AXTM, I just changed its settings for the snapshot partition to an empty folder on the independent internal partition. I thought when I ran it, it would see no previous snaps and do a baseline FULL... that didn't happen. It did a normal fast snap with just the incremental difference from the last time it ran... who knew.

How do you create different "forks" for different system configurations? To accomplish the above and create a new baseline, I had to unINSTALL/reINSTALL v800.

 

Thank you Froggie,

Regarding the backup to new location - it should always create a full backup when you change settings to use a new location.
Did you by any chance notice if the backup file (.axd) was indeed created in the new location and what was the size of it? Thank you

Isso

 

That's what I thought... what I expected.

The backup file, after moving the snap destination to another partition, was 56mB... about the size I woulda expected from an incremental snap, and the file was in its new location all by itself.

I just tried to duplicate this anomaly and couldn't. After renaming the destination folder and creating a new snap folder (same partition), AXTM indeed started a new baseline snap. I will try and duplicate this later on another platform (not enough different working partitions on the remote system) and keep you informed.

 

Thank you, that would be very helpful!

Isso

 

Allow me to stand corrected on this one.

I tried a very brief test of TF once again this morning with very different results. The FREEZE was on for about a minute while I examined WRITER status during an active VSS state, then unfroze and rebooted the system.

Following the reBOOT, settings files were very messed up (Chrome) and some of my software was now in the German language. I then use AXTM to put me back before the problem... all worked well.

I would advise caution at this point with the use of an sandbox-type app with AXTM until more is known about what's going on. I will be using AXTM as my kinda-like sandbox on this alpha system until I know more.

 

Been quietly following this thread with interest for some time now - already a paid Macrium v4 user (just for the ability to restore from within windows) this solution caught my interest...

I`ve put off testing other snapshot options up to now with having SSDs here, and I think I`m glad I did now after reading some of that stuff, so very interested when Trimming will be sorted out in AX - I`ll definitely be testing then.

 

Fad, feel free to jump in now if you wish. If TRIM is your issue, you may use this standalone tool following any AXTM restore to TRIM your space manually...

SSD Tool

...or if you're a Windows 8 user, their new "Optimizer" (defragger) does the same thing for SSDs.

 

Thanks, I do recall seeing that posted a way back but didn`t realise the significance...(this is quite a lengthy thread and most is now just a blur)

so I would only need to use that tool after a restore ? (obviously until such a time when Trim was handled & managed from within AX)

AX does or does not disable Trim for all the time it`s installed and/or active ?

Haven`t quite figured that part out yet.

(Edit: Win7 here)

Edit 2: OK, very quick install & snapshot/restore test...all seems OK !

I am getting an error from the "Backup Browser" on the main GUI..... " AXTMApp: Cannot start browser error 1060 "

The browser can be started manually from the install folder.

 

Hi Fad,

Thanks for trying the program!

For TRIM - it's fully supported, AXTM never changes TRIM settings, so your SSD should work just fine. As for using "SSD TRIM tool" after a restore (Froggie, thanks for the link) - it's optional, and in most situations not really needed, unless there is a big amount of data affected by restore.

Just be aware that there is no official SSD support at the moment, because there is a very rare and hard to catch TRIM-related bug that sometimes results in corrupted files. Most likely it won't affect you, but we'll release a new version with that bug fixed in several days.

Isso

Oh - for 1060 error - I'll look into it. What OS are you using, and do you have any Antivirus installed? Thank you

 

Hi Isso, that`s great news - I was reluctant at first seeing the SSD info on the main site, but now you`ve said that there`s no problem and I`ll run it for a while and see how things go, hopefully just fine as I like this approach to rapid and simple snapshots...

sometimes just to save me from myself

Regarding the 1060 error, I`m on Win7 x64, and absolutely nothing else running except for browser, AX and basic system processes of course....I disabled everything to try and rule out any chance of something interfering.

AX installed into C:\Program Files\AXTM
backup location is set to D:\AXTM
there`s not really much more to check or change that I can see that could be causing it....the browser works when I manually run it from the install folder, so it actually works, it`s just the GUI can`t seem to "find" it to initiate it