Introducing AX64 Time Machine - hybrid imaging/snapshot software

There does seem to be an increase of potential customers/customers lately so I'll offer this on a x64 W7 SP1 PC. Sometime last summer (after it was suggested that security software could be a hot restore issue) I discovered that by changing Malewarebytes service from Automatic to Automatic Delayed Start hot restores were never failing. I should mention that my issue was somewhat different than most in that the PC booted into what appeared as a normal desktop but the mouse, with visible cursor was frozen.
However, a month or more later I discovered that one of my favorite, long abandoned weather apps was available again. Favorite because it keeps the temperature in the Notification Tray without advertisements or having to use a gadget. Weather Pulse by Brad of Tropic Designs had to be abandoned because the free program used The Weather Channel's data but the WC started to charge for the use of such data. At the end of August a new beta version, utilizing The National Weather Service data became available. I installed it and experienced the same hot restore issues as before. Remembering that the only change with my setup was the installation of WP, I stopped it from starting. To my amazement, I have never had a hot restore issue since September! SO INDEED, SOFTWARE OTHER THAN SECURITY CAN CONFLICT ALSO. I still start WP manually after a boot.
Now if I can figure out why I do not have a functioning mouse or visible cursor during an attempted cold restore, yet with W7 and Paragon boot media I do, I'll proclaim AX as the perfect backup!

 

Yes - cold restoring 20gb data to my old HD took 8 minutes. I replaced the HD with an SSD and estimated it would now take about 4 minutes. However it actually takes about 25-30 minutes - after each 10% or so of the restore process, it pauses for exactly one minute.

I assumed that the SSD didn't like being hit with so much data all at once, and was garbage collecting/wear leveling on the fly, and therefore that it was a limitation of the technology.

But on the off-chance, I then tried restoring a Windows Backup image, and to my surprise it restored in the 4 minutes that I originally estimated. So I imagine it might be a driver issue or similar. I filed a ticket, and they seemed to be interested, so maybe it's being investigated.

 

Taotoo... your HDD AX64 image was most probably aligned to the 63-sector partition alignment. When you used AX64 to COLD IMAGE it back to an SSD, I don't believe AX64 knows enough to change the alignment to 2048k which SSDs need to align their internal NAND blocks. If you missalign an SSD, internal NAND block management becomes very cumbersome and thruput is definitely affected. Windows restore just may know how to do this... that may be why it was successful.

If you have a partition tool that allows you to look at the partition's PROPERTIES, the SSD partition should be aligned at 2048K. If it is, you should try another AX64 image/COLD RESTORE and see if it's any better. If it is it's because the new image was taken at the proper block alignment value and will be restored at the same value.

 

Hmm I just thought of something, if you would exclude some files then restart then the tracker file would not know of these new files as you say so the tracking file is now incomplete/outdated or something like that.. Now I know at least when AX64 detects external modifications then it does something with the tracking, perhaps rebuild it.. What if, after excluding some files from SD and then rebooting, you force it to rebuild the tracking file? Would that potentially fix that issue?

 

A guess... probably, but currently there's no way to do that (that I'm aware of). That's what happens when you access the protected volume from OUTSIDE of the LIVE Windows system. AXTM will see the access and has to assume tampering from without. It rescans the entire system to develop the proper system state before developing the next incremental. It takes a while, timing wise (about the same time as a full BASELINE) but produces the proper incremental size when it's done.

Don't quote me on that either...

 

I didn't try that however I noticed that after having used SD and then rebooted to get rid of the changes, when doing an AX64 backup it claims "The computer was shut down improperly" does it do the same re-scan here? Because I noticed it took like 21 minutes to complete.

I'm not really too fussed about accidentally destroying my OS at the moment, I really need to re-install Windows any way at some point because of another issue I have.. Something on my system locks up/freezes my computer irregularly, if I right-click something during that time I can see the context menu starting to fade in but then it never finishes and programs never fully start etc, I used the safe mode or whatever it's called in Comodo KillSwitch (basically hold in shift while it's starting and it will terminate a lot of stuff) and that always clears the freeze, but I can't find the cause..
(If anyone has any idea about this issue you can PM me, please don't answer in this thread since it's off-topic)

Edit: If I start a backup, what happens to files that are added during the backup? Are they backed up or not or does it depend on how far the backup has gotten?

 

They would be added the next backup since when AX64 begins a backup it puts the system into VSS and backs that up. In other words, no, once a backup has started any files added during the backup will not be part of the snap.

 

I finally dug up an old PS/2 mouse and as I suspected it worked fine during a cold restore. Inconvenient, in that my tower is not sitting out in the open, but still quite manageable!

 

Is this also the case when it says the computer was shutdown improperly or external modification has been detected? I'm thinking since it basically re-scans the drive in those situations? (If I understand it correctly)

So if I want to test an application, I can start a backup and during that backup I can also install that application without any of the files getting included in the backup?

If so, very good to know, thanks. =)

 

But I was restoring an image that was created from the SSD (not an old image made from the previously used HD). And the SSD is aligned correctly, as I checked that. Or are you saying that creating an SSD to HD image results in the image taking on the HD's alignment, and then that alignment being transferred to the SSD when restoring (I presume not...)?

 

This condition is handled exactly the same as EXERNAL MODIFICATION DETECTED is... the volume will be rescaned and all differences between the rescanned drive and the last incremental backup will be in the new incremental

This is the way that MicroSloth's VSS (Volume Shadow Service) is supposed to work... and most of the time it does, BUT... there have been anomalies using VSS that many people have not been able to explain (non-AX64 related). As a result of that, I try to keep my system as quiet as I can during these backups (a li'l web browsing, a li'l email, etc.)

 

All I was saying is that whatever geometry was existing at the time of ANY AX64 image, that's the geometry that will be restored, regardless of the destination's storage type (HDD or SSD).

It sounded like you imaged an HDD then used that image to COLD RESTORE an SSD... unless the HDD partition was on a 2048K partition boundary prior the image, then the operation above will result in misaligned partitions when using AX64.

 

Thanks - understood. So it appears my problem lies elsewhere. Hopefully it won't happen with the new warm restore method, or at least if it does that it can be fixed!

 

What you're experiencing is unique to your hardware configuration. Lots of users, me included, are restoring successfully to SSDs at their normal fast writing speeds without issues.

Maybe your system is cacheing your storage elements somehow... mSATA, maybe a mainboard cache (I just found one of those in a TOSHIBA laptop), who knows... but it's definitely unique to that hardware configuration.

 

Thanks for the explanation.

 

No, the full rescan does not occur if a file is created either during a snap shot or between snapshots. The rescan only occurs if AX64 loses its awareness of what is, or was, happening,,,,such as when the PC is shut down improperly. The simple creation of a file while AX64 and the PC is/are in anyway active will not cause a rescan.

Yes, though normal snaps are so fast that its not likely that you will test fully anything while the normal snap is being taken. During a base snap you are correct, just not going to happen during a non-base snap considering they take, usually, no more than a minute or two to create.

I would suggest that before you do a test you take a manual snap and give it a name such as "pre-test". Then, after the test you roll back to this snap. Confusion can occur if you have auto snap on and AX64 automatically takes a snap while you are testing. Obviously in the case of an auto snap being taken WHILE you are testing will mean that any file, test or not, that was in existence (saved) prior to that snap will be included in the snap,,,,,,,thus my recommendation to do the manual snap and be sure to roll back to it when you are done testing.

 

Can I just add once again that I have never had any problems with AX64, and that's using cold, warm, hot and indifferent restores....I use Win7 32bit and its been perfect for me since v1120...Just wanted to add that for those of us who are still humbled with 32bit systems.

 

Thank you RollbackFrog! With your insight I had a look at the various BIOS settings, did a bit of googling, and found the culprit. Disabling "C3/C6 steady state support" fixes the slow cold restore - now it restores in about the same time as Windows' built in imaging.

I imagine disabling the setting means that the processor now won't go to sleep, so I'll probably just disable it whenever I have to do a cold restore. I see that I could update my BIOS, but not sure if it would make any difference, and would rather not take the risk.

For any future Gigabyte users that encounter the same issue, the setting can be found under "Advanced Frequency settings" then "Advanced CPU Core Features".

 

Is it possible that 32bit & 64bit matter more than I/we previously thought?
Can others with 32bit system attest, whether they ever experienced hot restore failures?

This thread is simply amazing & very enlightening

 

For what its worth and I apologize if I am repeating myself, on my Win7 64-bit system I have never had any failure of any kind with AX64, hot or cold, and that is with several different versions.

Acadia

 

I see them on W7 32-bit systems although at a very LOW rate... only occasionally.

Remember folks, Imps from the 5th dimension are easily impressed... they completely lost the entire history of our 3rd dimension.

 

No thanks to me... YOU found it!

Taotoo, feel free to permanently disable the C3/C6 Steady State Support. Your processor will still clock down automatically to 1600mhz with the C1E function ENABLED... and of course it won't affect the system's ability to "go to sleep." The C3/C6 function allows for an even "deeper" sleep state for the processor when it isn't being used, but I don't think the savings is enough to warrant you having to make BiOS changes every time you wanna restore your SSD.

If your system is running smoothly I WOULD NOT update my BiOS unless you have a real problem.

 

...but without your post I wouldn't have known to look!

That's just saved me an hour of googling - thanks!

That was my instinct - the reward doesn't seem to outweigh the potential downside.

 

Most of the time we don't even know what the reward is

If the manufacturer is willing to document the changes/effects, it's worth looking into the effect on your system... but don't be in a big hurry to change anything unless their documented change(s) really does fix some anomaly you're experiencing.

 

Indeed, the BIOS of all things falls into that category that states, "If it ain't broke don't fix it!"

Acadia