Introducing AX64 Time Machine - hybrid imaging/snapshot software

Agreed. Cold restore is the bottom line of all types of restore processes. What else would be expected to be called that? And then it should obviously also deliver on cold, i.e. full restoring. For cold restore there should be no margin for anything else invoked by the program's algorithm that in other situations may apply a different restore pattern.

 

My C:\ drive is 50GB. I had 15-20GB free. I was unable to mount the snapshot, although I got the message that the mount had completed. I repartitioned the C:\ drive to have a total of 85GB, leaving 55GB free. I was then able to mount the snapshot without issue, and have done so since. I don't recall changing anything else, so I have no other clues to what happened!

 

More TM v2 anything-but-HOT restore observations...

1. From outside of the "tracked" OS (from a WinRE installation) I deleted an inconsequential TEXT file from the "Downloads" folder then ran a restore... all was returned perfectly.
2. From outside of the "tracked" OS (from a WinRE installation) I deleted most of the Windows BOOT elements needed to bring up a LIVE system, including Winload.exe which does most of the work. A restore returned all to normal.

Both of the above restores were done from the TM v2 LOCAL BOOT environment and the restore time was very fast... like a HOT restore.

3. Repeated #2 but instead of running a restore, I tried to BOOT the system 1st. It fell flat on its face, as expected, and invoked the WINDOWS REPAIR facility. While the REPAIR facility scan was in progress (it tries to find out what's wrong then asks if you want it to repair) I cancelled the scan before it ever asked me for repair permission. I then BOOTed into the LOCAL BOOT environment and did a restore. Whatever the WINDOWS REPAIR scanner did to the volume (it's not supposed to change anything before its scan is complete 'cept maybe some access times), the restore operation performed a FULL COLD restore, returning everything to normal.

Speculate away...

 

Pete, you might wanna request, via <info@ax64.com>, that the rest of Track 0 beyond the MBR become part of the DEFAULT save of the MBR... I don't believe it is at present.

 

I don't quite see how your merging schedule is relevant. What I was trying to say in my 4th point above was that with 100 snapshots say for partition C:, the corresponding 100 for partition D:, another 100 for partition E:, and 100 more for F:, when I come to do a complete disk restore (all 4 partitions), I require a consistent set: one snapshot from C:, another from D: with the same timestamp, a third from E: with the same timestamp, and yet a fourth from F: again with the same timestamp. Selecting the appropriate snapshots from D: and E: and F: is a precarious and error-prone procedure, and I was suggesting that you automate it.
Thank you for your reply. I am looking forward to hearing from you by PM concerning my Startup Boot problem.
EDIT: I have already heard from your support staff; I hope we will be able to solve the problem. Thank you again.
Norman

 

Pete, I know I'm asking for a guess here... but do you believe that the PD failure is due to PD tweaking the protected volume (BOOT time defrag?) outside of an active tracking mechanism? If true, then TM can never be anything other than a pure imaging program even after they fix the PD conflict (if they can). If that be the case then the product sits right in the middle of tons of other products that pretty much do the same thing... it would lose its snapshot capability.

It's a vulnerability any program would have that requires no external volume modification whatsoever to operate. AXTM v1 at least sees the external mods but, I guess, doesn't do PD any better than v2... or is that a bad assumption on my part?

 

No, i change PC processor platform from socket 775, to socket 1150. This is not ax64 build version, that I use.


On my old PC i backup windows partition with ax64 build 1_4_1_36, and later 1_4_1_48. When i move to new PC, and install 1_4_1_48. I Can't mount this image, i don't want restore, only mount to copy some important files from it.

Please help, this is important.


Regards, and thanks.

 

It's not necessary to mount a snapshot in order to access files from it, you can access the files directly in the Backup Browser, just left-click the desired snapshot and under the list of snapshots you should see a list of for example "Desktop", "Documents" and "Music" etc, under all of those you should have the drive letter & username, for example for me it's "C: (on SANYAIV)", click on that and now you should be able to search your way to the files you want from the snapshot, once you find them you can just drag them to for example the Desktop or a folder.

Sorry if the instructions are bad. =S

 

You can also open the file from within the AX64 browser by double clicking it. Its not necessary to drag and drop in order to see the contents.

 

Don't work for me, i click on backup and right panel still empty:

 

That's really wierd.

Camis, use this AX64 SUPPORT link (right hand side of page) and send the same msg to the support folks... maybe they have a suggestion. The only time I've seen that is between the OLD and NEW backup formats way, way back in early BETA, not since. Might I guess that you went from a Windows x86 (32-bit) platform to a x64 Windows system with that processor change or are you just trying to load an old backup to grab some files... it may be an architecture change issue.

 

Camis, if you think it may be an architecture issue, the TM v2 installed folder of the 32-bit edition is HERE (my DropBox). Just download it and extract the included "Time Machine" folder into your c:\Program Files (x86) folder. Make sure your current 64-bit version isn't running (check SystemTray and <right-click> EXIT if it's running). Now try and run the "TMapp.exe" file in the "Time Machine" folder you just copied into your "Program Files (x86)" folder. It should work fine as far as running is concerned... don't know about seeing any backup files.

If it still doesn't work, CLOSE TM then EXIT it from the SystemTray, now delete the TM folder you just added to the Program Files (x86) folder... you don't wanna get too confused with this stuff.

If you're still using AXTM v1, ignore the above...

 

Don't forget to replace files AXMount.sys and AXTrack.sys in the C:\Windows\System32\drivers folder overwriting the ones from AXTM1, if they have not been duly uninstalled... By installing from installer these files are copied automatically and the subsequent system restart should enforce their replacement.

 

Please guys stop using those acronyms that nobody understands.

I know that PD stands for Perfect Disk. But what is TM? Froggie seems to use it as an abbreviation for AX64 Time Machine, but what the hell is Peter2150 referring to when he says 'TM'?

Plus all of the image backuppers I have used do not backup the page file and the hibernation file by default. They all rely on Windows recreating those files upon the next restart.


Cheers
manolito

 

I am having trouble creating the boot menu in version 2 and seem to remember someone reporting an issue with Rollback Rx: when uninstalled, it leaves stuff behind.
I think that may be the problem in my case as well, and would appreciate a reference to any old posts on the subject. Thank you. (Windows XP 32bits)

Norman

 

Pete, I know this won't make you feel ant better...

Many of the imaging apps available offer an option to either save or not save the SWAP/PAGEFILE... reason, neither are very important as to the integrity of the system upon RESTART. The PageFile is always reinitialized when the system is booted (not from SLEEP or HIBERNATE, just on restart) and the SWAP environment has no real context from RESTART to restart. Some never save it and say they do by just providing placeholders in the backup image ($MFT entries with really no substance in the image, reconstituted space upon restoration). And if they're basically useless upon restart, it really doesn't matter where they are unless you're some kind of disk organizing geek that wants his PageFile in some absolutely optimum place on the disk. I personally don't care (as most casual users shouldn't) as today's systems have so much RAM that the system hardly ever pages or swaps... but there ARE working environments that have different needs in this area.

I know, the above is a bad blanket statement, I realize that. Users should have complete control over their system and its organization, incl. PageFile placement... that's why many run these crazy BOOT time optimizations thinking their system is much faster after the optimization. Th effect may seem that way but the reality is usually very different.

...and TRACK 0 is very important, especially to users of MBR-based systems... it's not as important for EFI-based (UEFI BOOT) rigs. Track 0 should be considered like the MBR, always saved (hell, it's just 63 more sectors).

Anyway, I don't mean (and don't wish) to start a big bru-haha about defragging and BOOT optimization (there are already threads on Wilders concerning those issues)... bottom line is that the USER should have his way, and for that, the app must offer the option to save/restore all major elements of the system exactly where they were when the image was taken, that's a given... personally, I don't care about most of those special files.

One of the big problems here (as mentioned in earlier posts) are pre-BOOT apps that run the Windows NATIVE API before the full Windows system is loaded. My educated guess is that is what Perfect Disk (PD) and maybe even Ultimate Defrag (UD) are doing with their Pre-BOOT disk optimization processes. If this is the case, then it's most likely being done outside of or around (AX) Time Machine's (TM) tracking drivers, whether they are in place at that time or not (I believe they are not). Most of the Native API calls are very low level, especially as far as the file system is concerned. We even have a documented case where after you run the PD's BOOT optimization, UD doesn't even finish its process... it hangs, clearly "stuff" is being messed with as far as these types of apps are concerned (and lets not talk about Rollback RX which even tweaks at a much lower level). If the tracking mechanism of TM is being bypassed by some of these file system manipulators, then there's no way the INCREMENTAL recording system can keep proper track of what's happened without re-scanning the file system each time it runs (which AOMEI Backupper does) which TM does not (at least not in its AXTM v1 previous form). This is most likely why TM images become "corrupted" following a PD's optimization run. AXTM v1 seemed to be much more "sensitive" to volume changes and re-scanned accordingly when doing its INCREMENTAL runs, and, of course, always COLD restored, although maybe not handling the PageFile/SwapFile as some users would like. TM v2 doesn't seem to be as sensitive, that's why we're getting WARM restores when we don't expect them.

Anyway, most of the above is just a Sunday morning ramble... sorry for chewing up the space. SECOND bottom line ... TM, like Image For Windows (IFW) and a lot of others, should offer the PageFile/Swapfile options (recommended NOT as the DEFAULT) and allow users to make their choice. If the defaults are created properly, the app can still be simple (at the UI) for the general user and "tweaky" for the geeks among us.

 

Good morning, sir!

It's not clear to me that AX64 (not TM) has this problem... yet. Since both PD and UD are most likely changing the file structure at a very low level (Windows NATIVE API?), then any tool wanting to track those changes would need to be able to detect those changes at their next snapshot (incremental) and re-scan accordingly. If this is done, the tracking file will be updated accordingly and things will move on happily. As we know from AXTM v1, this happened quite often when external BOOT environments even accessed the file structure (just bring up the WinRE environment with a task that looks at the file structure <ATXM Browser, for example> then reBOOT back into the system... AXTM would always rescan). I do not see this with WARM restores in v2 at all. If that was really working properly, any change made to that file structure by an external file access/modify would be detected and handled accordingly... clearly that is not happening. The WARM restore does see that type pf change (my file delete test showed that) but may be missing the low level changes to things that weren't tracked properly. I can only guess at this 'cause I don't know the inner workings of this beast... but v2 is definitely different than v1, and v1 may have had some of these issues also, BUT... it did detect external modifications and rescaned accordingly.

I'm not sure where we're headed with all this. I plan to do an AXTM v1 test with BOOT time defrags just to see what the eventual reaction will be.

Any additional enlightenment... greatly received

 

Hi guys

Pete, I am also curious as to what your SP contact was trying to say about your disk structure and potential damage. Even if you had problems after you killed that application you mentioned, even if check disk was unable to fix the problem or delete the corrupted file/folder, an image restore *should* put the disk back to the shape at the time of the image unless he is talking about some other terminology, perhaps geometry but even so, a restore of an image would cover that as long as it is just one partition disk. I must be missing something.

In regards to PD and UD defraggers, I am not familiar with them, but I personally do not like boot time defrag utilities. In fact, I think we all probably defrag too often in many cases, but it is always personal choice. I am also curious as to what AXTM V 1 is having problems with Perfect Disk, etc. other than its tracking file is not catching the modifications and causes potential problems or failures in back ups. I know this was a problem with V 1 of AX, but I also recall Waj stating about this also and V 2 does it also choke on boot time defrags?

Froggie, also looking forward to seeing how your tests go with the boot time stuff. It does bother me that AX tracking file may be missing certain events, but I would think a cold restore would fix those items, apparently that is the big question if I am following along correctly. In my experience with V 1, AXTM always noticed volume modification even after booting into winPE, and it would appear on next backup after it stated external modification, that it was doing a full backup as it would take the same amount of time, but generate only a small backup file. It definitely is missing something with boot time operations of the utilities, it would appear.

Thanks Pete and Froggie. Look forward to reading your results, and also regarding the 'disk structure' comment.

Jim