Introducing AX64 Time Machine - hybrid imaging/snapshot software

Some early morning thoughts (maybe not enough coffee yet ) on TM's ability to detect the Perfect Disk BOOT Time defrag anomaly...

During any HOT or WARM restore process, if TM performs a "mini-track" on the current system volume in place just for METAfiles ($MFT, $LOGFILE, etc... there aren't many of them)... then compares that to their tracking mechanism for the same files currently in place on the same volume, if they are different then something's happened to those files outside of their tracking mechanism and a COLD restore is invoked.

BOOT time defrags do all their work with these files in trying to make the system more efficient. Most do it using standard Windows mechanisms available at pre-BOOT time but Perfect Disk does not. From Isso's comment on PD's anomaly, they do have their tracking mechanism loaded and available at the Windows pre-BOOT time, that's why other BOOT Time defraggers have no problem with TM.

Just a thought... (more coffee needed)

 

I warned you... not enough coffee.

What I failed to mention is the above mentioned detection MUST OCCUR at both IMAGE time and RESTORE time. At image time, if change detected (PD BOOT defrag since last incremental), it needs to do the usual re-scan operation (like external media modification detection) to reinitialize its tracking file and produce a proper incremental change file. At restore time, if change detected (PD BOOT defrag between last incremental and next restore), it needs to know that it's image is golden (from the incremental detection and fix prior) so that it can be sure of a good necessary COLD restore. If the PD change occurs between incrementals, the incremental detection and fix will correct the image. If the PD change occurs between the last incremental and the next restore, the restore detection will find it and use the last good incremental to COLD restore the system.

I hope that makes better sense. Once a chain is allowed to absorb the mistracking of the PD BOOT time defrag (undetected prior to ANY incremental), it is suspect and as such, cannot be relied on for any type of restore. Detecting that change at either INCREMENTAL image or ANY restore operation should insure the integrity of the required restore regardless of what type.

 

My head hurts.....

 

If Steven runs into this issue from RickFromPhila or this issue from JohnV, "managing" the issues go right out the window.

 

Alex, it's that lack of coffee I was talking about

 

I would suggest that the way you are going to manage the risks of Rx (with a 2nd app to create images) is exactly the way to manage the risks of AX/TM. Especially considering that AX64 rarely needs to go the cold restore route for most of us. HDS, the publishers of Rx should not be financially supported in anyway given the atrocious support they offer to paying support license holders and the very misleading hype put out by their marketing team.

 

Wouldn't both of those issues be 'managed' by simply making regular images with a second program? Indeed that is what I was advocating elsewhere in my post - perhaps that's how he in fact 'manages' it.

 

Hi all, I followed this thread for quite a long time but dropped off around the time 1.4.1.48 came out. I am still using it. (registered owner of multiple copies)

1) Where is this new 2 beta?
2) Has it tested out enough to be recommended to try at this point? I.e. is it at least as stable as the 48?
3) Does either version work well if I run windows 7 defragger or is it not a good idea?

Thanks!

 

Secondary imaging of his protected volume would protect his CURRENT SYSTEM STATE (the most important I would presume), snapshots are always history.

That's why I asked him above what app he uses to protect against hardware failure. or in the case of the above 2-examples, massive Rollback RX failure creating unbootable systems.

 

Here...

There are some real differences at this time but it's working well, especially in the same vein as AXTM v1 did. A TRUE COLD RESTORE is missing at the moment but it seems to be restoring well in the meantime... COLD RESTORE will be returned shortly. If you are a "Perfect Disk" user, I would not use it.

Any defragger will cause any snapshot program (or INCREMENTAL imager) to create LARGE snaps (incrementals) following the defrag operation but the program will function just fine. If you're running W8 or W8.1 and the protected volume(s) are on SSD(s), the defrag should not seriously impact the snapshots.

 

Thanks!

Nope not using PD and been pretty happy with Ax64 now as my main backup for some time. I do offload important files via another solution as well usually daily. So if push comes to shove nothing vital will be lost.

On upgrade will it continue the same backups from 1.x? My wife's computer is on WIFI and I would want to put it on the wire to the NAS if it is going to redo the baseline.

 

Nope. It's reccommended that you squirrel away the v1 baseline and start anew with v2. V2's DEFAULT folder is called "My Backup" which is used by tons of other apps. I would recommend changing that to something that makes better sense to you. Create the new folder on your backup device of choice, and when you select your partition(s) of choice to protect, use the BROWSE button at the bottom of that window to select your folder on that device. It may still make a "My Backup" folder (a l'il bug) but it'll use the one you selected... feel free to DELETE the "My Backups" folder once you have a successful BASELINE. It also DEFAULTs to AUTOMATIC mode so if you don't want that (it's very different in v2... Time Machine now keeps hourly backups for the past 24 hours, daily backups for the past month, and weekly backups until your backup drive is full) you'll have to turn it off.

 

Correction,,,,,, oldest snaps will be deleted automatically when drive is approaching full.

 

With all this talk of them, can someone quickly sum up the difference between cold, warm and hot restores?

 

Sure - but that goes with the territory - I suspect anybody who's used Rollback etc. for any period of time has found that realistically you're unlikely to end up with a reliable sequence of snapshots going back forever. But secondary imaging would still protect against the various gotchas that Rollback (or possibly even TM) could potentially throw up, and of course you can have multiple secondary images so you're not necessarily just stuck with the most-recent backup.

Then I'm unclear on the suggestion that no "managing" of Rollback would prevent those 2 examples from resulting in non-recoverable scenarios, when "managing" by making a secondary backup would appear to do so.

 

Hello MaximumFish,

A good explanation of the different restore methods can be found in post # 7848:
https://www.wilderssecurity.com/thr...napshot-software.339999/page-314#post-2373807

 

I sent this brief v2 comment list to AXTM Support 10 days ago - no response from them, so I'll just post it.
---
Here are a few things I noted, but not mentioned in your recent UI summary Forum post:

1. Please re-look the browse and selection functions for networked drives. I am experiencing W7 "credential" denials, "server not accessible" messages, and inability to even "browse for folder" when I select "Network". I am using a WD Home Cloud NAS and cannot access it for backups (V2), and (under V1) very difficult to access for restores. I would expect the Create Restore Media, and Backup processes to remember my default NAS, similar to the way it remembers my USB Drive.

2. The current tray icon selections do not include opening the "Backup Dashboard / Backup Tools" application window.

3. I trust you plan to implement a "Schedule Backup" function, along with Automatic and Manual.

4. As I noted on the Forum, if the previous backup destination is not found, the user should be given the opportunity to select a different destination - not simply "fail".

5. I notice you create and use a folder named "My Backups". A number of other backup (and non-backup) applications and NAS devices have that as well. Would not "TM Backups" be more precise?

Thank you.

 

Thanks for that, just what I was after.

That's caused by the TM program running with administrator permissions. When UAC is enabled, programs running as administrator are run with a different user access token - essentially it's running as a completely different user - making mapped network drives and saved credentials unavailable. There's a registry tweak that will share these items between the normal and administrative tokens here: http://technet.microsoft.com/en-us/library/ee844140(v=ws.10).aspx

I've no idea how they managed to make it work in V1, or how the program can see the drive up until that point, but the above tweak does work around the bug.

 

That's caused by the TM program running with administrator permissions. When UAC is enabled, programs running as administrator are run with a different user access token - essentially it's running as a completely different user - making mapped network drives and saved credentials unavailable. There's a registry tweak that will share these items between the normal and administrative tokens here: http://technet.microsoft.com/en-us/library/ee844140(v=ws.10).aspx

I've no idea how they managed to make it work in V1, or how the program can see the drive up until that point, but the above tweak does work around the bug.
---
Thanks for the info ... I am running this particular PC with W7 UAC disabled.

 

Is it disabled or have you set the UAC slider to "never notify"? Because there's a difference. Setting the slider to never notify still leaves UAC enabled, but it will automatically elevate any program that asks for it. It's ever so slightly more secure than disabling UAC entirely in that it stops buggy but otherwise benign programs from having too much access to the underlying system (and having those bugs potentially exploited). Of course this doesn't protect you against malware that actually asks for elevation.

 

Actually for Windows 7 and below, it's completely disabled when set to "never notify". All programs run as admin whether they ask for it or not. To do what you explained, Admin Approval Mode is the answer.

 

I'm interested to understand how this would work. I had expected that the snapshot allows you to go back to some point by knowing all the changes that have occurred since the point you want to restore, and basically reversing out these.

But just say two weeks into the the month you need to do the restore, so you start with restoring the MR reflect monthly backup, and just say that backup was made at say 3:30am on that day. If I then say you want to use TM to get back to the latest snapshot. But how does TM know what changes need to be made tot he system because the MR backup occurred somewhere in the middle of two snapshots, so how different is the starting position from either of the two snapshots. And how does TM even know that an MR restore was performed to get back to that state from 3:30am two weeks ago, so how does it know what it needs to load? I can understand if you did a full restore using TM, but then you are effectively doing a full restore in MR then a full restore in TM, rather than a smaller snapshot difference.

So how does this proposal work?