Introducing AX64 Time Machine - hybrid imaging/snapshot software

if we regard space consuming RX uses c: drive which already in use and have wasted space over there while ax64 need much more space in OTHER drive (eg -> D: , E: )....

at first its doesnt seems maybe much , BUT when time passes by , backups will get bigger and bigger

cheers

 

Good morning, DemonEye! You're missing one very large point here... Rollback RX is *NOT* an imaging tool, and as such, cannot recover your protected partition following HDD failure OR MBR rootkit infection. Unless you're imaging your partition separately, your system would be toast following one of the above scenarions. If you are imaging separately, then you're using up that storage anyway to support the imaging function.

As has been said before, AXTM is primarily an imaging tool, but due to some pretty sophisticated shenanigans in tracking your disk volume status, is capable of performing a Rollback-like return to snapshot at anytime along the way, albeit slightly slower than Rollback RX ... AND it protects your system partition against complete system failure and/or nasty rootkit infections.

As with any imaging product, you can pick a point in time to reproduce your baseline configuration and start your incrementals once again.

I personally find AXTM to be a well rounded product that has been solid as a rock (for me, anyway) since its late ALPHA stages and continues to be so as it's reached its final release. I'm a believer in minimalist system configurations, and as such, do not overburden my systems with multiple AVAS implementations combined with sandboxing apps, snapshot apps AND imaging apps. Those types of app combinations lead to nothing but confusion and possible reactive situations (one app affecting another... tough to figure out sometimes).

The main task here is to protect your system partition against hard HDD failures and insidious rootkit infections... AXTM does this very well (along with a good AVAS product). In my case, my secondary task is to be able to move around to different points of time in my system configurations. Previously, Rollback RX provided me with that function, although a bit risky at times (waded through 3-MBR infections along the way).

AXTM is providing both of those requirements for me now, and in a much more simplified (thanks, Patrick) manner as far as my system configuration is concerned... much less risk than Rollback RX presented. I find it to be an outstanding yet very simple application.

 

Well said my friend Froggie,

Best regards,

Mohamed

 

hey froggy


all this i know for years check out my avatar , been using RX for long long time ...

i just point out a different angel on this subject and its the space left always in drive c: unused

 

For Image for Windows and ShadowProtect - both are very mature imaging products, but they don't offer "fast restore" functionality, as a result their speed is much slower. I made some tests here comparing AX64 speed with ShadowProtect (also I've compared some other aspects too in that post)

For tracking file - it's located in System Volume Information folder, and you can't change its location.

For jumping back and forth - we restore the system just as Acronis eta, i.e. the program itself and its settings are reverted back in time. But the program detects where exactly it is on the chain of backups and allows to go forward in time too if there are such backups available.

Isso

 

Fad,

No, AX64 has no influence on System restore space, although they are using the same folder. No interference whatsoever is happening between them.

Isso

 

Maybe it's time for this product to get a FAQ. A lot of the same questions are asked repeatedly and I'm guessing will still be asked time and time again. It's such a new approach that it may save everyone a lot of time if it was spelled out in a FAQ.

 

MerleOne,

Yes, that would make the backups size somewhat smaller, and as a result would decrease backup/restore times. It's also perfectly fine to keep both of them if you prefer so.

Isso

 

Marc, you are absolutely right, I'm planning to enhance our Knowledge base, but don't really have time. On the other hand it would save a lot of time for me and others too.

Isso

 

Thanks for the advice !

 

As Isso says, the option to run System Restore is in the hands of the user.

BUT... you must remember this. System Restore does not tinker with your personal files, it only restores system registry settings/files and some special batch stuff in the user area. As a result, if you use System Restore, your personal files (on the restored partition) will be as they were before the restore.

If you decided to replace the System Restore function with AXTM's "rollback" capability, you must take a snapshot prior to the restore... otherwise you will lose your personal file status, at the time of the restore, on the protected partition. This is an IMPORTANT DIFFERENCE between the two processes.

That said, I have no problem disabling System Restore (and all its overhead) and taking that important snapshot prior to any restoration... this guarantees the availability (through AXTM's Backup Browser) of all my protected partition files when I reach my new restore point. You must also remember that some isolated system functions will not work correctly if System restore is turned off. If you run into this case, just enable System restore for that function. I have seen this with certain types of system updates.

 

Froggie, thank you for the important clarification.

This leads me to think whether we need to add a "take backup before restore" feature. What do you think?

Isso

 

Hi demoneye,

in reality it's the exact opposite of what you described.
Ax64 needs alot of space for its initial snapshot. The following incremental snapshots will occupy less space than those of RBRX, since the data in AX64s is compressed. Time has absollutly nothing to do with the snapshots size.

Panagiotis

 

A CheckBox for such.. a great idea! I'l add the idea to the Feedback forum.

FWIW... Rollback RX has this feature as its DEFAULT (settable), and it can be turned off, if necessary.

 

i am not sure u understand what i was refer to.
lets says i install w8 and uses 20 gigs .... in time to come i install more and more software , no even counting ALL WINDOWS UPDATES (sp1 is a big daddy ) , so space consuming always get bigger , add to it defrag time 2 time and u done

just to make my point stronger , install a 40 mb software and u will see the image to back it up can be away bigger than this 40mb .

 

I second the idea of a checkbox.
Sevenstar

 

Dear ISSO:
since all my computers are new, with GPT, UEFI + Secure boot, and I do want to keep secure boot enabled. So does AX64 support UEFI Secure boot yet?
thanks

 

Guys, unfortunately the admin refused to open a separate forum for AX64 (somewhat expected), so we'll continue to use this thread for general discussion, and the feedback.ax64.com for more official stuff like ideas and tickets. Thank you

Isso

 

Oliver, not at the moment, but we'll release the GPT compatible version in a couple of weeks.

Isso

 

thanks, man.
Please also include this feature in the recovery environment of the new version.
Please keep up the good work..

 

Oliver,

Certainly, recovery environment also will be compatible with EFI.

Isso

 

I did understand. In the example that you describe above, if we exclude the baselines of both products, AX64 snapshots will occupy less space than RBRX snapshots; if we exclude merging in the AX64 and automatic defrag of RBRX.

Same is also true for RBRX.
What makes the difference in RBRX is the manual or auto defrag that in reality compares the file table of the snapshot with the sectors occupied and then release the space from the empty sectors.
AX64 does not have a similar feature (like snapshot optimization/ reclaim free space) and when you merge the snapshots those become larger and larger.

Panagiotis

 

At least you tried...
Isso go ahead and create more complete miniforum at your site.

By the way I have a feature request. Can you add a snapshot optimization feature (to reclaim free space from the merging of the snapshots)?
similar to the Cleanup virtual hard disk of vmware?
http://pubs.vmware.com/workstation-...UID-421A1073-BF16-4BC7-AA76-46B954CA438D.html
http://pubs.vmware.com/fusion-4/top...UID-6BB29187-F47F-41D1-AD92-1754036DACD9.html

Panagiotis

 

Panagiotis, demoneye,

That's right, the merging feature is currently not fully optimized, however we'll fix that in one of the upcoming releases, so it's able to intelligently exclude the free space. This will make the backup files smaller.

Isso

EDIT: Panagiotis, just noticed your post. I think if merging automatically reclaims the free space then there is no need for a separate feature, right?

 

Yes, for me is the same. Whatever is easier to implement.

Panagiotis