Introducing AX64 Time Machine - hybrid imaging/snapshot software

When testing on a x64 Win7SP1 machine observed the following behaviour multiple times with automatic hourly backup set:

If a AX64 snap does not complete (leaving a *.axtemp file) for whatever reason (crash, power break, user-forced stop), the next .axd snap takes very long and is larger than normal (although not making a full new baseline snap). In such case, it does not automatically remove the incompleted old .axtemp snap during a later successful snap or during the auto-merging process of snaps.

Anybody else seen this and is it considered a bug Isso?
Best regards,

defconnect

 

defconnect,

Thanks for testing the program! If power break or crash happens, then long backup time is normal. The size of the backup may be slightly bigger, because the system (and some programs) make changes to the file system at reboot.

For "user-forced stop" - what do you mean? If simply closing the program - then it should take the next backup fast and never leave .axtemp. If kill the program from task manager - it's normal.

For .axtemp files remaining in such situations - at the moment we don't remove them, will implement it in the upcoming versions.

Isso

 

Thanks for the quick feedback Isso.

With "user-forced stop" I indeed meant the killing of the program's process, so not a normal closing of it. All seems to work as currently expected then.
The incomplete hourly snaps also result from an automatic power-down of the computer during its process. Perhaps AX64 could sense such system exits and postpone its ongoing snapshot untill the system powers up again, preventing a long and large next snapshot after the one that was left incompleted otherwise.

Looking forward to testing the new beta with error logging.
Good luck, defconnect

 

Hi Isso

Just in process of trying AX64 Time Machine. Installed OK, although the % complete backup bar is misleading and understates progress of backup.

Creating recovery cd direct to cd (as opposed to creating ISO) proved problematic on my machine HP Pavilion Slimline Win 7. I got round this by creating the iso and then burning separately.

When creating direct to cd it prepared the files then ejected the cd at 62.5%. Then after reclosing cd tray and pressing start the cd kept being rejected, I tried several cds, all rejected. All cds subsequently unusable.

Will keep u posted as I test

Terry

 

Hi Isso or Anyone else

Really need some help. As I said in my previous post I am trying out this software.

After doing the first backup which ended up as 30,803,497 kb file on my external hard drive and took 29 minutes, I then decided to delete a whole load of files in one folder, some 4 Gigabytes in total after which I pressed the make backup button again.

This took 19 minutes to produce a file of 116,505 KB on my external hard drive.

Now my problem should be obvious to all, WHERE IS THE SPEED, that is referred to in Isso's write up. Am I doing something wrong?

My PC is an Intel (R) i3 CPU 530 @2.9GHz with 4GB of RAM

Isso referred to subsequent backups at taking slightly longer than snapshot software, 19 minutes seems to me a long time even for an incremental.

Anybody suggest what I might be doing wrong?

Thanks

Terry

 

Hi Terry,

19 min for 116MB incremental is a huge amount of time, I've never seen anything like this. Could you make another backup and see if it still takes the same time, and specifically which operation takes it - "Preparing" phase or "backing up %" phase?
I'll also look into CD-burning issue, sorry about it.

Regards,
Isso

 

Hi Isso

Thanks for your reply.

I have just done as you suggested, although you might question the validity of what I have done.

I did nothing ie no deletions, no additions no installations etc. I just did another backup which carried on from the last one.

Preparation time circa 45 - 60 secs

Backing up (Nothing) 1.5 minutes

Hope this helps

I am going to do another backup with something major, either deletions or installation and will let u know

Terry

 

Hi Isso

I forgot to add that that the saved file in my external hard drive is 74,857 KB

(for absolutely no change in my hard drive size) over the previous backup

Terry

 

Hi Isso

As promised I did a third backup (One full two incremental)

As in the second backup I deleted files (same folder) of 2.6GB.

Then I backed up. The results were a backup file of 33,833 KB in my external hard drive, preparation time circa 45 sec, backup time circa 30 sec.

Whilst this is definitely a more acceptable response it leaves me uncomfortable, since I have done nothing different.

I suppose the answer will be, only over time and with experience, will I become confident.

One thing I would say is this, there are two very large threads dedicated to AX64 Time Machine with a lot of people showing very great interest in your software. With the benefit of hindsight there is very little or no specific information on what you and forum participants believe to be the "measurable" performance in comparison to other forms of backup.

Yes, their are superlatives like fast or the fastest or "works for me" but nothing that instantly says "this is what we achieved in terms of speed of backup/restore under these conditions"

Put simply if there is not a significant and consistent speed benefit then people will not buy your product.

I hope others will come forward with information that measures speed of backup/restore to see what the ranges are.

For my part I will continue to test your software on backup then possibly restore. So far I I remain uncommitted, and yes I know it is Alpha software.

Terry

 

Also noticed long backup times as reported by Terry, but only sometimes and seemingly not directly coupled with the size of the resulting snapshot.
By the way, these long snapshot times are also not related to the earlier mentioned prolonged time needed after an incompleted snap.

 

From the FWIW Dept. once again...

Fired up Build 800 on a N270-based NetBook (2gB RAM, Single core, dual threaded 1.6ghz, W7ProX86SP1 <old Asus EeePC 1000HA LINUX machine>). AXTM works as expected but requires from 75-100% of both threads while compressing/writing the snapshot.

Will test Rock (snap back) and Roll (snap fwd) mode this evening... expect it to be fine as on other ALPHA test beds.

 

Hi Terry,

Thank you for testing. Even 30 sec is not normal. According to the time of your initial backup the speed of your backup drive is about 17 MB/sec (USB drive I guess?). Considering that speed I would estimate the "Backing up" phase to take 3-4 sec, not 30 sec. So looks like something doesn't work as expected on your system, sorry. By the way, since the time of the last backup was still many times better than the previous one, I suspect there is some activity happening on your HDD while AXTM performs its operation. HDDs (in contrast to SSDs) are notable to become many times slower when there are two or more tasks using them concurrently.
For "Preparing" phase - in this version it takes too much time, we fixed it already and in beta it should take no more than several of seconds.

As for speed measurement - I fully agree. But because of the nature of incremental backup there is no fixed figure like "each backup takes 30 sec" that I can provide, because the backup time depends on the size of changed data since last backup, also on the speed of your drives and CPU.

But in normal conditions the speed should be approximately the size of changed data divided by the speed of your drive. I.e. if you've installed a new program that has 100MB size, and your drive speed is 17 MB/sec, then the backup phase should take about 6 sec. We need to account for Preparing phase too (about 30 sec in current version), but this as I mentioned will be significantly better in beta version.

Reagards,
Isso

 

defconnect,

As I mentioned to Terry, you might also check if there are other programs using HDD at the moment when AXTM is backing up (for example antivirus scanning the drive). I guess that might be the reason for slow backup.

Isso

 

Hi Froggie,

Thanks for such a comprehensive testing! The CPU usage is normal considering that processor is quite slow.

Isso

 

Hi Isso

Thanks for your views.

Which boil down to Alpha software versus possibly faulty or inconsistent Iomega USB drive and other software using the HDD.

I have no reason to believe the USB drive is working other than normal, and if other software happens to be running at the time of a backup such as you suggest ie Antivirus scanning (I use Avast Free) then I am not prepared to switch it off.

As I said in my previous post time will tell

Terry

 

Terry,

Surely I don't recommend to turn off antivirus. My point was that perhaps at that point of time AV activity just overlapped with AXTM backup (I assume AV performs scans intermittently).

I'd suggest you to later try the production version of AXTM (that we are planning to release in about a month). If it's still slow for you I'll be happy to work together and figure out the reason.

Isso

 

Isso... quick question.

Is the snapshot file "opened" before or after the "preparing" phase? If after, snapshot speed may easily be determined by the file entry time indicators... CREATED and MODIFIED.

Lemme know.. thanks!

 

Froggie,

No, sorry it's opened before preparing phase is started. However we improved the "preparing" speed significantly, and beta release will be much faster.

Isso

 

I'm really ithcing for the beta (if not the final version ).

Just to update for anyone who's interested. I've installed v1.0.800 on my real system with RBRX v10 and so far it's performing exactly like it did in my VM....three cheers hip hip, hooray!

The only issue I'm having is with my Intel RST drivers (I assume that's what the problem is) . I cant create a recovery ISO with this version (or any previous version).

 

Same here carfal. Since isso and his team are unable to find/pickup the Intel RST drivers while building the Recovery ISO, the next best solution would be for isso to tell us how we can add the Intel RST drivers to the Recovery ISO so that the recovery media can detect our drives!

Cruise

PS. I don't get that same error message when building the ISO - in my situation it seems to complete the build, but the resulting CD simply doesn't see my HDD!

 

Actually, I've just spent the last 2 hours looking at this and have come to the conclusion that it's probably not related to the RST drivers.

When i initially probed my system i discovered that the Intel drivers were not being used at all. My system was using the standard MS AHCI drivers. After much mucking around i was able to install the older Intel RST drivers (v10.6.0.1002 WHQL) and my system was now using the "iaStor.sys" file. I also noticed my system booting alittle faster. Excellent. I now tried the recovery media creator and same error.

I uninstalled (rolled back to) my standard MS AHCI driver, again uninstalled the Intel RST drivers and this time installed the latest Chipset drivers (v9.4.0.1016 WHQL) from intel. This updated the standard MS AHCI driver to an Intel one (but was using an updated "msahci.sys" file presumably from what i could see). Anyway, tried to create the media and still the same error.

To me, my error doesnt seem related to the RST drivers since their nowhere to be seen after i uninstalled them.

What do you think guys?

EDIT: I should probably mention that before i purchased my SSD i was running Raid0 with 2 normal HD's. I then cloned my Raid0 to the single SSD and disabled RAID in the bios. I'm glad i had this issue with AX64 because it's allowed me to clean up my system and have AHCI mode running properly (faster).

 

carfal, Cruise,

Thank you guys for continuing using the program. Carfal, it's great to hear that it works fine on real machine along with RBX!

I agree the issues with boot media that you experience have different roots. For Cruise it's apparently AXTM not picking Intel RST drivers (we'll fix it, no need to add it manually). And for carfal it's something that I don't have any idea about, but when we release the version with logs I'll hopefully will be able to figure it out.


And sorry for getting late with beta, the SSD support took much more time than we were thinking. At this moment we are done with it, and in 2-3 days we'll start testing phase. If testing is ok, the beta will be released in about a week from now. At that point I'll be able to address the issues faster than now.

Isso

 

Good to hear! I will probably start testing myself as soon as that gets released.

 

Isso, I'm very glad to hear this - it would be most appreciated.

Cruise

 

Carfal, there's been a problem creating a RECOVERY disc ever since Build 800 (as Isso notes). If you'd like to have one around just in case, Build 796 was the last version able to create the RECOVERY disc, and the one I made is here...

AXTM v1.0.796 ISO (Froggie)

I'm not sure it'll work with the intel drivers but you can give it a try (no need to restore, just boot up with it and see if you can find your backup folder). If you want, you can reinstall Build 796...

AXTM v1.0.796 Installer

...and try and create a RECOVERY disc from there, then re-install Build 800 to carry on (the install/reinstall will probably cause a 1-time full disk scan on your next snapshot, creating only a snapshot sized file).