Introducing AX64 Time Machine - hybrid imaging/snapshot software

First, a given... TM v2 WILL NOT have a COLD RESTORE problem when it comes out of BETA as far as restoring the entire TM image is concerned, that shouldn't be part of an if/then/else scenario. And I have to assume that the BOOT time defrag problem that TM has with Perfect Disk will NOT be solved by then.

With the above givens, I'll address BCW's question... in my opinion, Chamlin's "Will it work?" scenario above will not work. Why? 'Cause everything TM does in the way of WARM or HOT restore is based on its TRACKING information. Although the image restored by Macrium, above, will be fully functional even after Perfect Disk diddling of the low level file structure before the Macrium image was taken, the LIVE TM tracking information recorded within it will be flawed (by the PD diddling). From here on, any TM restorations of any kind will be suspect. Unless the saved TM tracking information has been corrected prior to its "saving," the integrity of any TM restoration will be questionable... and it doesn't matter how the information is being saved (Macrium, IFW, whatever). Not until that tracking info has been corrected can you trust a TM restore until you have moved back in time to a point prior to the PD diddling. This is why any PD diddling MUST be corrected, as far as tracking is concerned, at the first image or restore operation following the diddle... otherwise the "anomaly" gets absorbed into the TM tracking baseline which is NO GOOD.

And to remind all the thread readers... this Time Machine/Perfect Disk anomaly that we're talking about only exists if you use Perfect Disk's BOOT time defrag option, any other "on-line" Perfect Disk operations are perfectly safe when using Time Machine.

 

BCW, the Macrium backup will have the LIVE TM tracking info in it when it's restored. It's that info that TM uses to make its decision on what to do during a HOT or WARM restoration process following Macrium's restoration. It looks at the current LIVE tracking (just restored by Macrium) and compares that to the point-in-time tracking saved in the selected restoration snapshot and restores the differences accordingly. TM will always function well if its tracking information is correct... but with PD in the fold running BOOT time defrags, there goes correct tracking information.

 

...and to try and simplify this whole mess we've been talking about.

For those familiar with running AXTM v1 and getting that "External volume modification detected" messages that caused AXTM to re-scan the system in order to reset its tracking information prior to the next snapshot (remember all that time it took?), this Perfect Disk problem we've been discussing is just a case of a low-level external volume modification that Time Machine is not, currently, able to detect.

A lot of you must feel this way, and I'm sorry this discussion has gotten so unwieldy... I guess we're just trying to help readers understand the issues.

 

Where does TM stores its tracking info, in the backup or in the system itself?

Thanks

 

It's a file in a special system folder but that file will be imaged by any imager worth its salt (it's HIDDEN for protection, nothing more).

Edit: I should have added the following... the LIVE tracking file is as above, and each INCREMENTAL snapshot has that tracking file as of the time of the incremental snapshot.

 

I suspect that because AX64 would see/know the contents of the tracking file that existed at the time of the MR image (after all the tracking file is part of the MR image and so would be present after the MR restore) and base its actions on it, it would know what needs to be done. That is go forward in time using that MR restore point in time and the current (latest snapshots) tracking file thus enabling AX64 to change whatever needs to be changed (or added) to the drive from the MR state to the selected snapshot state.

Think of it as if you had used AX64 to go back in time (the state of the PC as of the MR restore) and then decided to return to some point later in time (the selected AX64 snap state). AX64 would simply see the difference between the 2 states and apply the required adjustments.

Does this make sense? Seems logical to me.

And even if this did not work,,,which I see no reason to think it would not, you could still use AX64/TM to access critical files from the last existent snap and copy them back to the MR restored HD. This of course would be a worst case scenario solution.

 

Hi, I have a question. Suppose I have 10 snapshots on an external hard drive. Somehow my system drive fails. I put a new hard drive in my PC. Now instead of doing a cold restore by TM boot media, I just install a fresh copy of windows, install TM and then restore my last snapshot from the external hard disk. My question is: Am I back to the state where I was before my hard disk dialed?

Thanks

 

Yes, you will be... BUT, the COLD RESTORE from TM will be much faster than a CLEAN INSTALL of Windows followed by a TM update. There will be very little in common between the CLEAN INSTALL and the TM update.

 

Morning Pete! I'm not sure what you mean when you say "installing restoring etc." If you're talking about app installs/uninstalls... that shouldn't do anything that would "mess up" the tracking file. If you're talking about restoring to an incremental position via TM, the next incremental following a restore should look perfectly normal.... not to many system changes, not too much incremental time.

But if some of your restores are being done from the Macrium BOOT media, I have noticed that when invoking that WinPE for any reason causes TM to think that an external modification has occurred and does a long scan on the next incremental. I don't know what the Macrium BOOT media is doing... Macrium itself is not changing anything (I saw it the first time I brought up the Macrium BOOT media just to look at its interface). Not every WinPE seems to do this any more with TM v2... any of them before would cause AXTM v1 to rescan on its next incrementall. Without knowing the change criteria being used by TM v2 now, I really can't offer any suggestions as to why things "feel" different with this new release. I just know that when using ONLY TM v2, my incrementals seem pretty normal for the work being done in between snaps.

I'll do some additional Macrium LIVE testing with TM live on the system and see if I notice anything unusual... to quote Ah-nuld, "I'll be bach!"

 

This thread becomes very technical (my Average Joe friend grasped nothing ^^) .

Just a question: does v2 can do a cold restore if the partition was modified (i mean if new partitions were added) ?

 

Me again. Ran some quick Macrium LIVE tests (running under the protected Windows system).

Running a Macrium BASELINE had no appreciable effect on TM v2's incremental time... it was as expected. Running a Macrium INCREMENTAL... same result. ReBOOTing into a WinPE v5.0 Macrium BOOT media, letting Macrium RESTORE show itself (which runs an analysis on all found partitions), using the File Explorer to look inside a folder then exiting the media and BOOTing into the live system. The next (immediate) TM v2 incremental involved a FULL disk scan (long time... same as baseline) and produced a normal incremental file size. This was clearly an incremental following an "External media modification detection" of the protected partition but no message of such was offered during the incremental process.

 

You're not running a periodic defrag are you (Windows automatic, PD?)?

 

Did you notice a major size change in the Day #5 incremental file... was it much bigger than usual?

 

Easy Tiger...

One more question...

Is that 6-min. you mention above a typical FULL SCAN time or something in between a FULL and a daily INCREMENTAL?

 

Hi Froggie-

Yeah, I know its not bulletproof...far from it.

However, I have a separate file backup process so file retention is not my issue...I am primarily interested in:

• Rapid recovery from a BSOD
• Incremental file restores (something happened in last few minutes before my backup)
  
• Quick restore after I visit a "questionable" site or open a "questionable" email
• Quick restore after I install a program that messes up something

I use a weekly cold raw (sector by sector) image with Paragon on the entire drive which I believe covers me from hardware failures and the potential Rollback messing up the entire system. I don't like to do this, but it seems necessary.

Even though it can do hot imaging, I do not use IFW with Rollback because I have never felt comfortable with the whole "where does Phylock sit in the que" problem. Seems too unstable for me, even on machines that only I use.

I generally run Rollback with 15 minute snaps, so I use a lot of disk space, but to me it is worth it.

Between Rollback and Cold imaging, I feel protected, at a cost of a weekly image process. Maybe I am wrong

Note that I have several machines...

• a few running Rollback,
  
• one running Comodo TM,
  
• one running RestoreIT,
  
• and a few that still have GoBack running on them (The older Roxio version, not Norton).

I have to follow this cold backup procedure for all of them. The only difference is the frequency... my business machines get the weekly treatment, my personal machines, not so much.

I will mention that for all of my machines running, neither Rollback, Comodo, RestoreIT, or even GoBack ever needed to have its image restored... and I have been using GoBack since it was owned by Wildfile in ~1999. Now granted, I do not visit questionable sites, have a solid host file, and don't click on scam emails, but I have been using this type of program for 15 years.

I have checked on this forum fairly regularly since the first post... waiting first for AX64 to be finished, then waiting for it to handle separate partitions. To me, the partition issue was important, since I have my data separated from the system partition.

I am truly looking forward to the completion of this V2 beta testing, because I like the concept. However, it needs a "bulletproof" cold restore or I don't see enough value, since I will still have to have a second imaging program (OK, maybe it would be a little easier since I could do hot imaging).

Again, thank you (and your "team") for your work... I have been following you personally through your Rollback forum posts for years. I have also followed Barry, Jim, and a few others (Barry had many of my same issues when GoBack was bought by Norton and then subsequently not updated for Vista).

Perhaps you guys should team up and open a usability testing company. There is definitely a market for it and companies should pay for it

Regards,
Steve

PS - Sorry it took so long to respond... I don't check in daily.

 

Hi Barry-

Yes, I could manage the risks the same way with AX64 V1, but up until this version, it did not support more than one partition. Also, I like 15 minute snaps... which I would gladly give up if AX64 V2 gets rid of my cold imaging requirement.

And yes, I hate to finance HDS... but I also hate how Verizon Wireless treats me, yet they have the best network in the NYC area, so I keep paying them too.

Honestly, if you know the business concept of "degrees of freedom", its really a business model. Basically, you can slack off in some areas if you have one particular area that you excel in so much, that most of your customers will buy anyway.

It is supposed to be an interim business concept to give you time to work on the areas you are not so good at. It only works until someone (like AX64) catches up in the area you excel at, then you will have customer defections in droves.

Regards,
SteveG

 

Froggie-

I do a cold, raw image, so the snapshots remain when the image is restored.

I have tested this on Rollback, but never had to use it in real life. I also tested it on RestoreIT (Farstone).

I do not remember if I ever tested it on GoBack, since I have been using that for 15 years and honestly cannot remember.

Am I wrong?

SteveG

 

Hi Steve! No, I think you are right... BUT, if the RAW Rollback test was done under v9.1 and you are currently using v10, I sure would validate that type of restore once again.

I have stopped extensively testing v10 because I don't believe it's as "bulletproof" as v9.1 was (which also had some issues). I stopped HOT RAW imaging, via IFW (phyloc registry change), when v2.78 hit the street... it failed at that point... something changed in IFW. I never did COLD RAW imaging although many who used to do it, swear by it as far as RBrx restoration is concerned.

If you're willing to do some "maintenance" with RBrx uninstalled, and you're not using an SSD, I would run a good disk defrag followed by one of those surface clearing tasks that ZEROes all the unused sectors in a system. After doing this prior to your COLD RAW backup, the resultant image will be quite small due to the good compression of those cleared unused disk sectors. When I used to do this the image was only slightly larger than a USED SECTOR image (I just used basic ZERO clearing).

 

Froggie-

I actually retested the cold raw restore using Paragon 2014 with Rollback version 10.2 (the most recent 10.2...not the old 10.2 ) this past weekend and it worked and kept the snapshots intact.

I only have two machines using SSD's. One is a Dell XT running GoBack on Win XP. The drive is a Samsung 64GB SSD (one of the very first ones from Jan 200. GoBack and WinXP do not allow easy use of Trim, so it has never had trim run on it in >6 years of heavy use... still works fine. I personally think trim is overrated.

The other SSD is running Rollback 9, which probably does not support trim (who really knows) for a few years and appears OK.

I generally do not defrag my spinning disks often. When I do, I perform the following:

1. cold raw image the drive
   
2. turn off the instant recovery system
   
3. defrag
   
4. restart the recovery system

I have lost my snapshots at that point, but if I find I really need them, I can always re-image the drive to get them back (and lose the defrag).

I have never tried tried the surface clearing task... I never thought it would reduce image size, since I thought a raw copy of a zero or a one tool the same space. However, I will give it a try at my next defrag!

Regards,
SteveG