Introducing AX64 Time Machine - hybrid imaging/snapshot software

Hi Alex,

You are right that the above term is very confusing. It means to me restoring from the AX64 website, rather than doing a restore within the OS. Maybe, Isso should consider changing the term.

Best regards,

Mohamed

 

Hi Isso

I can advise that in terms of the following:

KIS - Add AXTM components to 'Exclusions' (and also make them 'Trusted' apps...just to be sure )

WSA - one needs to watch the AXTM driver being blocked on install. What I did is to run each component of AXTM, find the entry in the WSA Process Control option and change the 'Block' to 'Monitor' if it had occurred.

But hopefully, by now, the WSA Cloud will be recognising the AXTM components and whitelistingthem automatically for WSA users who start to use AXTM.

After all of that I have found that both the above exist harmoniously with AXTM.

Hope that helps?

Regards


Balders

 

Hi Alex

It is the component that is run when the online restore is selected, i.e., you request a restore from within Windows, via the Backup Browser, (manifests itself as a command prompt like window that shows the restore's progress).

Would suggest that you look in the AXTM program folder (under Program Files) and add all executables (of which there are only 3 if memory serves) therein to the AV's Whitelist.

Hope that helps?

Regards, Balders

 

A few days back (July 24) there was a question in regards to whether you can restore a previous snapshot once it had been merged with an earlier one. The discussion morphed a bit to include the question of restoring a previous file that had existed in a previous snapshot that got merged (in addition to just the question of restoring a previous snapshot, or system state).

One comment on this was "If you need to recover something, either a particular file or the entire system, you can do so at any time as long as the snapshots containing the file or system state has not been merged into other snapshots."

If I'm not mistaken in my understanding, it might be worth just clarifying that if you had, for instance, mistakenly deleted a file (and emptied the recycle bin), or mistakenly over-written a file, and that file had previously existed in the most recent snapshot that had been merged into another, you could indeed recover that last most recent version of the file (but not still EARLIER versions of the file, if the snapshots that contained those earlier versions had been merged into another snapshot).

The reason I think this is worth clarifying is that, for myself anyway, if I mistakenly delete a file or mistakenly over-write a file, I usually realize my error pretty much immediately after committing the error. If my understanding is correct, Ax64 would indeed allow you to recover from this even if the last snapshot that contained that file had been merged with the earlier snapshot. It wouldn't allow me to go back through multiple earlier versions of the file if the snaps had been merged, but for many (probably most) situations, what would be needed would be just the one most recent version before the deletion or overwrite or file corruption had occurred, so it's good to know that this kind of common error is something that Ax64 does protect you from, whether the snapshot was merged or not.

Is my thinking correct here??

 

THis is exactly what I intended to say. Thanks for clarifying.

 

Thanks, I will keep this in mind.

 

Alexhousek, I can vouch that Avast! AV is compatible with AX64. Just as I did for my other security apps, I listed AX64 in Avast's Global Exclusions as a precaution. Although I don't think it was necessary. You can "click the button" with confidence and start enjoying AX64. No problems.

 

The easiest way to explain this is as follows... if your CURRENT SYSTEM STATE is at the latest snapshot, as long as the newer snapshot involved in the MERGE contains the file of interest, it will be available via the BACKUP BROWSER following the MERGE operation.

The minor misnomer here is that the operation is called a DELETE operation. The above statement is correct at all times if your system's current state is at or after your most recent snapshot. If that state is at any earlier snapshot (you have snapped back for some reason), any DELETE operation on a later snapshot will really be a delete, not a merge... you cannot go back.

Sometimes it's hard to get your head wrapped around what this great app is doing for you... hope the above helps.

 

I guess I'll add my question about merging.

When does it occur? What is the internal time that AXTM use to trigger the merging operation? Is there any way to control that?

 

Marc, check out this ATXM article...

How the automatic merging works

At this point I don't believe it's configurable... they're working on changing that, though. BTW, MANUAL snapshots are never merged automatically, only AUTOMATIC snapshots.

 

The article doesn't answer when in the hour does the merging process trigger, though.

 

1. Am I correct assuming that manual deletion (merging) of automatic snapshots doesn't save any space on my backup destination since all backups are incrementals anyway?

2. The 'Delete' option 'makes' sense only when used for manual backups? (i.e. they are then 'merged back' into the automatic chain)

Thanks!

 

merisi,

Sorry about it. I've sent an email to you.

Isso

 

Hello MarcP,

See this page on the AX64 website: http://www.ax64.com/news.html
under "26 June 2013: AX64 Time Machine 1.2.1090 released"
third item listed: "•Merging done only when the user is idle"

Basically with that version of AX64, once the hourly backup is complete at the top of the hour, AX64 then waits for your system to be idle before starting the merge process. Since AX64 now waits for the system to be idle, the actual time that the merges happen can vary due to system idle state, so the merge can happen at any time during the hour. It is no longer set to a schedule as it was in releases prior to version 1.2.1090. HTH...

 

LOL I agree, any suggestions?

Isso

 

ralws277,

You are absolutely correct. In fact AX64 starts merging the files that are at least 3 hours old. And the latest one is never merged.

To better understand the process consider the merging just as a deletion of excessive backups. For example here's hourly backup without merging:

| | | | | | | | | | | | | | | | | | | | |

Where each "|" is a backup, the interval between them is 1 hour and the last one is the latest one. As you can see there are too many of them, which makes it difficult to manage (consider backup running for weeks or months). And most likely the user won't need the old backups at such a small interval.
So what merging is doing is deleting some of the backups effectively making the interval larger like this:

| | | | | | | | | | | | | | | | | | | | |

Note that the last 3 snapshots are not touched. Hope this helps.

BTW the next version will allow you to specify the number of last backups to keep.

Isso

 

Kent,

Thank you for answering Marc's question. Just one addition - while the user is idle the program makes checks once in 10 min and if there is something to merge - it proceeds.

Isso

 

Jale,

1. Manual and automatic deletion operations have the same effect. And they will save space in certain situations. See this article for details.

2. No, in fact there is no difference between manual and automatic backups, except that manual backups are never automatically merged (deleted). Manual backups can be deleted only manually. From all other points of view there is no difference between automatic and manual backups. Hope this makes sense.

Isso

 

Guys,

To those who haven't tried the program yet - there seems to be some confusion between this merging, deletion automatic/vs manual snapshots etc. Those internal details shouldn't bother inexperienced users. The program is actually very simple to operate, despite quite complex internals.

Isso

 

Why not use the "usual" terms when related to imaging... HOT for using the running OS and COLD for using an external OS other than the one being imaged?

 

So it's possible for the merge to not happen for a whole hour because the system has not been idle?

 

Great suggestion. Let's go with HOT.

Isso

 

Yes, it's possible.

Isso

 

Thanks. That explains how I ended up 5 hourly snapshots yesterday. I had VMWare virtual machines building 3D models..

 

Hi Isso,

You are HOT. I already gave the suggestion, doing restore from within the Operating System (OS). But HOT is as good, though could be still misleading.

Best regards,

Mohamed