Introducing AX64 Time Machine - hybrid imaging/snapshot software

UP, that issue was reported a while back... hopefully they're working on it.

In the meantime you can bring up your RUN dialogue box and execute a MSCONFIG. In the ensuing window, select the "Boot" TAB and the timer is in the lower RIGHT corner... set it to whatever you want. The problem will be whenever you run another WARM restore, it will be set back to 3-sec again.

They're working on it as far as I know... hopefully fixed in the next release.

 

Win7 BOOTmgr (instead of W8.1) and short timeout...

One of the main problems is that they're using the same BOOT option for WARM restore as they're using for LOCAL BOOT... and these need to be separate, even if they're functionally the same. The LOCAL BOOT option needs to remain (if the user has it set) and the WARM RESTORE BOOT option should be very transient... only there when they need it and gone when they're finished.

When they set up the warm restore BOOT option they set the timer real low so the process doesn't linger in the BOOT menu. This is fine as long as you return it to the user selected value when you're finished. They should be able to see all this as they prepare to do the warm restore, make the time change just for the fast BOOT, boot to the warm restore, do their thing, eliminate the warm restore BOOT entry, restore the previous timer entry and move on. It looks like some things were missed in this process.

The issue with providing different GUIs than the native OS offers... I haven't a clue, although they're both fully functional. Of course the W8.1 BOOTmgr GUI is slicker (but that's all)...

 

I had the same problem and it took me foreverrr to figure it out. I didn't have enough free space on my c:\ drive. You need an equal amount of free space on the c:\ drive as the non free space.

svenstar

 

Hi TRF

Excellent points made regarding warm restore. I had assumed they would introduce the warm restore feature that was similar in nature to how the old version of Real Copy performed, which was a reboot and warm restore (called fast rollback) before booting into windows, the timing being similar to say when a scheduled check disk operation was being carried out, right before booting into windows. No preboot environment was used, and when I had tested Real copy at the time, it worked great, although they had some issues with 'fast rollback' to SSD drives, the feature was nice and simple.

Perhaps they could use this type of warm restore that would not use the current recovery mode, so it would remain separate. Not sure if you had ever tested the old version of Real Copy, but the manner it handled 'fast rollback' was nice, apart from any booting into PE as in v. 2 of AXTM.

Just a thought after I had read your description above, this manner would not use the PE recovery and keep the local boot untouched.

As always, thanks for your help with these matters

Jim

 

Yikes! That makes no sense to me at all

Are you saying the selected snapshot has to meet that criteria (more FREE than used) or the current protected volume has to meet that criteria?

 

Hi Jim! I am not privy to the "fast rollback" feature of RealCopy (never tested it... to many things going on at present) but it sounds like it was using a process similar to AXTM's HOT restore, but if so, it shouldn't have had any more issues with SSDs than with the current WARM or COLD restores... all are incapable of TRIMming the SSD during the process. HOT could TRiM if it wanted to but it's a very complicated process (the HOT, not the TRIM) and as others have seen there are some issues with it. I have no idea what those SSD "issues" could have been wth RealCopy... unless they had something to do with system configurations that contained those crazy mSATA SSD (Intel managed) caches that some of these systems have in them.

An easy way to deal with post-restores (HOT, WARM or COLD) is just to schedule a simple task (at reBOOT) that does what the "SSDtool" does... pre-allocates "most" (all but about a coupla hundred megabytes) of the protected volume then deletes that allocation before using it. This causes Windows to issue TRIM commands for all that pre-allocated storage which causes the SSD to clean up after the restore. I do this manually (when I think about it... most of the time) with the SSDtool... very simple.

 

That's pretty tricky stuff. At that point, only a small part of Windows is actually up and anything that runs there can't use the full Windows API for its functionality... it must use what's call the Windows NATIVE API, a very small subset of full Windows capability. Any significant task at this point would be difficult to write without an immense amount of knowledge about Windows and how it does things, not to mention the complete file system (which I think is available at that time).

Any difficult task is better suited for running under the full Windows API... that's why most of this type of work is best done under a pre-Installation environment (WinPE/RE) which does contain the complete Windows API.

 

Thanks TRF I recall reading I think from Wajamus in regards to Real copy, that 'fast rollback' was discontinued for the current beta of Real copy due to problems with some SSD drives, but do not recall the issue. It was a very nice feature though, and restored without any recovery environment other than like a scheduled check disk, then it would boot into windows if I recall.

I had just assumed it would be similar, but AXTM v2 warm restore is nothing like the old version of Real Copy 'fast rollback'. I am sure there is a reason for this, but your points made above make sense, and that is what Real copy old version did...the fast rollback was simply like a scheduled task, and it worked well, apparently not for some SSD drives, not sure what was happening and tells me maybe it was more than just sector change restore, or a drive access problem of some sort.

Thank you again for your help, and once the wrinkles are ironed out of V 2 of AXTM, I hope they can see a much larger market share, and a solution that remains unique. I am concerned about some of the issues you have found, but also realize this is the reason for Beta testing. They have a good foundation with what they are trying to improve and the feature list in my opinion.

For me, v 1 of AXTM has been solid when using it, no problems hot or cold restore and I will be happy for them when they can get v 2 to this level with the fixes needed for users who were unable to utilize v. 1 due to hot restore failures or other issues that did not allow some to even use it. I think most problems are drivers, and certainly Win 8.1 issues that appear to have been a real challenge for many companies. It has to be a hair puller to try and cover all the bases with a new OS such as Win 8 / 8.1 plus trying to test on as many configs as possible. Nothing 'easy' about it for sure.

Have a good day!
Jim

 

Great point here Froggie, this may have been part of the reason they had to discontinue the fast rollback due to SSD issues. I agree, the PE/RE route is the safest in that it contains the necessary environment and access to what is needed.

AXTM v 2 I think is on the right track with warm restore, but they need to address what you have found in regards to warm restore, etc., in previous pages on this HUGE thread LOL

Thanks
Jim

 

...and lest we not forget, W9 will be out next year for sure (Winux, Lindows?).

 

My tests showed that even if an external modification was performed on the protected volume, as long as that mod was done through the file system of that volume (any OS understanding the NTFS file system), TM v2 was able to see that it had been changed and restored the change accordingly, even though it was done outside of its tracking mechanism... that's a really good thing. If that modification was done outside of the file system that controls that volume (HDD sector test or something like that), then the restore would be in trouble.

I quickly read part of Russinovich's book (Windows Internals, VOL #2) this morning looking for an easy way for TM to get its hands on the BOOTmgr entry point (bypassing POST and the BiOS directives) and it looks like its very hard, if not impossible to do so... BUT there may be more to read to really understand that startup flow.

Anyway, the existing WARM RESTORE is fine as long as its process path isn't broken along the way... but they really do need to neuter that capability in the created RECOVERY MEDIA (LOCAL, UFD, CD/DVD or ISO) so only COLD restores may be done from there... there really is a need for FULL COLD restores. Maybe optional WARM restores can be offered in those media "Advanced Options" but the DEFUALT should indeed be COLD.

 

Very interesting!

 

Tatoo... by the way this is exactly what Windows 8/8.1 does when it "optimizes" (defrags) its detected SSDs. It issues what it calls a "TRIM Storm" (cute name) to allow the device to garbage collect itself properly (I think it copied the function from the SSDtool developer).

 

Well I've tried both scenarios (under v2)... snapshot with more USED than FREE and current protected volume with more USED than FREE and had no trouble mounting snapshots in that condition. I believe this may not be a "fix" for everyone.

When I had that problem earlier in BETA test, my system and snapshot were not in that condition. I did pass the info on the the Devs but never heard anything. Alnog the development way (I know not when) it started to work once again.... go figure.

 

Pete try performing the same test (offline restore) with 2 ways:
1st. create or copy a new file on the partition to be rectored from the winpe enviroment. Then perform a restore.
2nd. delete the monitoring file of AX64 and perform the restore.
Both methods should force a full (cold) restoration.

ps. I wish I had time to properly test the 2.x version of AX64.

Panagiotis

 

ok i surely missed it with the huge amount of posts in few days thanks for the info Frog

 

Pete, thanks for doing all of this. How is this different from the iterations of v1? Wasn't v1's cold restore a full image restore?

 

Hi Guys,

We hear your thoughts on the incremental restore occurring in both rescue media and via the warm restore in Windows. It's agreed in the team that cold restores should occur by default using the rescue media, but can also be done warm by choice.

We are compiling all the information and bug reports you guys have been making and organizing them by priority. We are going to resolve these bugs and issues systematically and through subsequent beta builds.

Thanks a lot guys. Please send your reports to: info@ax64.com (save logs by clicking on "backup tools" then clicking on about". Export the logs and attach these to your e-mail with the description of your issue).

Cheers guys,

Waj

 

Stick with a RELIABLE backup solution.

 

Have you seen my post #7821?
Concerning item 2 there, I should like to add that the order in which the partitions appear in the TM Backup Browser 'Backups' pane when launched from within Windows (XP, in my case), corresponds to an alphanumeric sort on the file names of the snapshots as assigned automatically by TM during the initial backup process.

Norman

 

Chamlin, you are correct... all of v1's restore capability via RECOVERY MEDIA was COLD or FULL restores, a complete rewrite of the protected media. The only DIFFERENCE restore was of the HOT or LIVE variety.

What Pete and I have found is that when using any recovery media under v2, the restore appears to be of the DIFFERENCE variety, not the FULL variety (like V1's HOT restore). While that seems to be a "feature" that users may like, it's not something the application should control, especially when using their recovery media. The purpose of RECOVERY MEDIA is to completely rebuild HUMPTY, not just piece him back together again.

If users would like to "trust" in the capability of an off-line recovery tool to piece their system back together (after extensive testing, I presume), maybe it should be available as an option, but NOT the DEFAULT. As a user I cannot offer that trust unless I know exactly how the DIFFERENCE recovery process works, which I do not. Therefore, the process I can offer trust in is the complete restoration of my chosen volume, especially when that process has been extensively tested.

What we want is for the DEFAULT process used by any recovery media to be a complete system restoration (aka FULL) rather than an attempted DIFFERENCE restoration... pretty simple. The special WARM recovery DIFFERENCE process can be what the app developer chooses but all other recovery processes should be FULL by DEFAULT.

 

this thread is very interesting to read, thanks to all of you. I never really force myself to understand the differences between HOT & COLD and now WARM restores, i just used to use (without knowing its "name") COLD restores via a CD or DVD all the time with every backup softs (Acronis, AXTM, Paragon, etc...); i think now i have more options