Introducing AX64 Time Machine - hybrid imaging/snapshot software

Its my understanding that the more time that passes between the baseline and the reverted to snap (for cold restores) the longer the restore will take. This is because AX64 has to work its way through all of the snaps to know what is current and what is not. I start a new chain every 4 or 5 weeks to eliminate this problem. How old is your baseline?

Also, what version of AX64 are you using? Is it the same one as the one you were using 6 months ago?

 

Hmm, this is a very good observation & suggestion.
I hope they would state it more explicitly later on (i.e. as one of good practices).

 

Well, not to rain on anybody's parade... but this is a FACT with any INCREMENTAL imaging tool, not just AX64 TM, no matter who made it. They all work the same when it comes to what BG refers to as COLD RESTORE (Macrium, Drive Snapshot, Image for Windows/Linux/DOS, etc.). All the incremental images must be processed to restore the proper FULL image.

DIFFERENTIAL imaging works different in that only the baseline and the most recent differential need to be processed for correct restoration.

 

Well, I am not so sure about this when it comes to Acronis True Image (using the very old version 10 on WinXP).

I often noticed for a backup set of about 15 - 20 incrementals after the first full backup that restoring to the last backup date did not take any longer than restoring to the first full backup. It does not look like it restores the full backup first and then restores one incremental after the other.

Another indication is that when I restore from DVD blanks (yes, I still do use DVDs sometimes for an additional safety layer), Acronis requests the DVDs from the the last one to the first. Do they use some intelligent algorithm to avoid restoring each incremental sequentially?



Cheers
manolito

 

Last to the first makes no sense unless you're dealing with DIFFERENTIALS... and if it's really doing an incremental IMAGE (or FILE) restore it definitely needs to see them all to determine validity of the disk surface (or File).

I know that ACRONIS used to switch between a FILE restore and an IMAGE restore depending on what kind of restore processing it was doing... partition change size, etc.

 

Yeah, I know about incremental & differential.
But, I feel that somehow AX64's cold restore (with small set of incrementals & not too far from baseline) is faster than others' cold restore.
(Was this only my imagination? )
Yet after some more incrementals & further away from baseline, then that speed advantage is gone.
IF this is true, then it makes sense if AX64 warns its users about this.
So, is it or isn't it?

 

No, in my opinion not your imagination. I have been using AX64 only as an other imaging program recently, only keeping Baselines then deleting them and starting over.

Yes, cold restores from recovery cd seem faster than most other programs but I will say this for sure: AX64 imaging restores are definitely the easiest and least confusing!

Acadia

 

Acadia, does your unscientific ("seem") feel for product comparison include only doing just BASELINEs for other products also... just wondering?

Restoring just a baseline will surely be faster than an entire image consisting of many incrementals also. There are differences between products as far as image restoration is concerned. Direct disk I/O is usually faster than the file system mechanisms offered by the OS the cold imager is running under... but I've never run product comparisons. Another thing that can seriously affect restorations is the compression algorithm used for the imaging... the less compression (simpler algorithm), the faster restore, and AX64 TM is clearly not the "leader" in best percentage of compression. I ran tests a few years back, using IFW, comparing uncompressed restores to compressed restores... there was a significant difference in time... and this really plays out in configurations with older, slower CPUs (single core, lower gigahertz).

 

I have NEVER used incrementals for any imaging program ever except AX64 but then only for Hot Restores. Now, since using Ax64 only as another reliable imaging program, I only use the Baseline. I really am trying very hard not to name other excellent and reliable recovery programs here (what few there are) because this is an AX64 thread and that would not be fair to an upcoming company with great potential.

Let's just say this program, at least as I use and have experienced it, has been drop-dead-perfect.
Acadia

 

Oops, sorry, you are right as always...
I was mixing up the behavior of restoring backups with validating backups. During validation Acronis really requests the DVDs from last to first.


Cheers
manolito

 

Hi TRF

I might be missing something regarding your comment about "last to first makes no sense".

Just today using AX64TM version 1.4.124, I installed some software, EasyBCD to add the Ax recovery ISO to my UFD as it has several other boot iso's on it. After finishing with this, I proceeded to test out to make sure the UFD booted into the added AX recovery environment. It booted just fine after choosing it from the UFD boot menu, so I decided to try a cold restore, and I browsed to my external drive that has the backups on it. It has baseline with 3 incrementals. I chose the last incremental purposely to see how it handled a cold restore using the last incremental that I took on Sunday, and the restore went perfectly, machine rebooted and EasyBCD was gone and the disk was exactly as it was on Sunday.

I realize I could have done a hot restore, but I wanted to test the cold restore with choosing my last incremental. It took about 6 - 7 minutes to restore approx. 6.7GB worth of data on volume C. All backups I have done with AXTM have been Manual backups only.

I understand that even though I chose my last incremental, AXTM had to sort through all the parents and then to the baseline for this restore...is that correct?

My question I guess is am I missing the intent of your reply as far as choosing my last incremental to perform a cold restore? Am I correct in my understanding that AXTM had to sort through all parents and the baseline to correctly perform this cold restore?

The restore was flawless, no issues, but I am thinking I am missing something in regards to your statement. I will add that generally I take the position of Acadia in that I never use incremental imaging, but in the case of AXTM, it has been flawless so far.

I really appreciate your thoughts in case I perhaps made an error in how I did the cold restore. My thinking is that had I chose the baseline, I would not have had the volume restored to the current incremental taken Sunday. That is why I chose the last incremental to restore to, which I assumed would also organize and sort back to the baseline as it is necessary to complete the request.

Am I missing something?

Thank you sir!

Jim

 

Sir!?! <jeeeesh...> I'm definitely not your grandfather.

Your understanding is completely correct... for COLD imaging. Even though you're selecting your last incremental, the restoration process must start with the baseline and move forward which it does. It does no incremental imaging application any good to require that it start with the LAST image taken... it must start with the first. That's the only way it can establish the reference for the next incremental. Remember, incrementals are all "children" of the previous "parent" taken... and the only difference between incrementals and differentials is that with differentials, there's only 1-PARENT and 1-CHILD. The choosing of the last is just a reference to its target configuration. The comment earlier had to do with ACRONIS asking for the last image... and that turned out to be for verification purposes only, not for restoration.

Summary... all COLD incremental restorations must start with the earliest PARENT, followed by any CHILDREN, in order, to reach the selected point in time. Selecting the last incremental to restore to is only a point in time reference for the imager to use.

 

Well yes and no...

It's the way you said it that may be confusing.

In an incremental COLD restore, it starts with the BASELINE then sorts through all the incrementals (each one being a PARENT of the one after it) until it's re-established the entire image. Just as the imager creates the incrementals, which are the differences from the last one taken, it must use those "differences" and apply them to the reconstruction to insure the final image is correct.

So... BASELINE first, then sort through each incremental in order to reconstruct the final selected image.

 

Well, I guess that's the way it's supposed to work in theory, but it doesn't work that way for me, both in XP & Win7 Home Premium 64 bit. I've always created a new baseline every 4 weeks. However, because of your comments, I tried a new experiment this morning:

1) Created a new baseline

2) Moved some random folders around, then created a manual restore point

3) Installed a random program, then created another manual restore point

4) Immediately started a cold restore, restoring to my 1st manual restore point in step #2

The total elapsed time was no more than 30 minutes between creating a new baseline & starting the cold restore. As I expected, the cold restore is slogging along right now, slated to be completed in about 6 hours +/-

I'm using the last official version 1.4124 right now because I've stopped experimenting with betas. However, prior to this point in time, I've tried almost every beta with the same disastrous results.

 

I do not remember how AX64 handles the incrementals when restoring, but most programs that restore incermentals usually load in memory the file table of the last incremental (the one to be restored) and then proceed to the restoration.
The incremental restoration is not linear like
restore Baseline->restore increment 1->restore increment 2-> ...->restore last increment

but more like
the last incremental loads in memory like a virtual partition and then a restoration from the virtual partition to the real one is performed. (= only the needed parts from the baseline and the increments are restored).

ps. the additional time needed when having lots of incrementals is caused by an excessive fragmentation of the imaging files and not because of their number.

Panagiotis

 

Hi guys

TRF, or should I say Grandpa? I'm 52 years old soon to be 53, but it would be cool if you were my grandpa! LOL

Thank you so much for your explanation and descriptions! I almost understood the relationships, but your child/parent description was spot on and was very helpful.

To sum up, as I understand it, I chose the point in time to restore to, in this case being the latest incremental or last one I took Sunday, and then AXTM did its thing with assembling the restore to reach the point of my last incremental.

Also, thank you Panagiotis for your descriptions as well. All I know is that I wanted to test a cold restore using my latest incremental, to see the length of time and how it would put all the pieces together, and it worked perfectly. Total time approx. 6 - 7 minutes which is not far from the time it took to restore a complete image baseline without incrementals when I restored over the weekend.

Overall, very impressive being that I never use incremental imaging, and AXTM at least for me handled it with ease. Once the dev team gets this working for the majority, in my opinion it will have a dedicated following and be a strong competitor. Also, in my opinion, I DO think the plans with the upcoming releases to offer the restore after reboot or 'fast rollback' similar to how Real Copy used to handle it will be perhaps a more stable option for those who have had repeated issues with 'hot' restores. So far, I have not had any issues or problems with this build 1.4.124. In my case, using my laptop which is a very clean installation with NO 3rd party security software installed, just what came with Windows 7 Pro, windows defender and windows firewall, my hot restore that I did was flawless and took only 51 seconds, of course not much had changed, but it worked great. I personally think a majority of issues with hot restores are indeed related to low level security apps, etc., that perhaps causes interruptions during the restore. I do not think just 'disabling' will solve these issues in some cases because some of those apps continue to be active in ways that could cause disruptions in the file activity or writes. I usually on some peoples systems, disable their anti virus 'self protection' modes because that alone has caused problems just installing software that must write to the registry, etc. Just my thoughts.

Appreciate all the help and thanks for taking the time to respond! Back to more tinkering...

Jim

 

Any one using it on windows 8.1?

I tried v 24, 36, and 48 on a windows 8.1 tablet, Lenovo Miix 2 8.

Installed fine but ailed to complete a backup with some error code.

Tried v 36 and 48 on XP SP2 and it gives frequent BSOD.

Here is error that i get on windows 8.1 tablet.

Seems after the so called interference from real copy people, AX64 development has been messed up. I am afraid it wil become another RollbackRx!

 

Hi aigle

I checked to see if anyone else has mentioned this error. I found a mention of this here:
https://www.wilderssecurity.com/showpost.php?p=2294301&postcount=5159

Froggie was testing AXTM on a Win 8 OS and encountered the same error as you have. This was back in October 2013 and obviously there are still issues with Win 8 and likely Win 8.1

Hopefully these nagging problems will soon be corrected. Windows 8/8.1 is still a problem with many software vendors having issues reported, some are not yet fully compatible and I am not sure if it is the UEFI/GPT problems or the OS themselves that are making it difficult to trace these problems. It is frustrating, and even more so to developers.

Thanks for the info. I suggest you send the logs to the AX dev team if you have not already done so. I wish I had the answer for you, but we will have to see how this unfolds.

Jim

 

Hi Aigle! I passed this on to the DevTeam many months back... it is definitely a tablet issue, probably with eMMC type storage, what they have most in tablets. My attempt was with a Samsung ATIV tablet.

My guess... it's not high on their list at the moment, but as other higher priority items get dealt with, I'm sure it will surface once again. I would forward the report with the logs just to keep the pipeline full and remind them of the error once again.

 

since i tested the betas on Win8.1 ; none of the restorations were successful; seems we have to be patient

 

I was nearly being swayed by Grandpa Mikey & also Peter, that I have a very wild imagination concerning AX64's speedy cold restore, but then you came...

So, could you explain it more in the context of the cold restore speed of AX64 vs others.
Do you mean:
1. AX64 with a few incrementals relatively needs to take the same time, but with more incrementals then it will take longer
2. AX64 with a few incrementals is faster, but with more incrementals then it will relatively be the same
3. Others that I haven't think of
?

I really hope that you choose # 2, because I love AX64 so much

Another question, is the fragmentation you mentioned is the source's that can be reduced/even eliminated by defragging the source before taking an image?
Yes, I understand that this will make a bigger incremental, and almost like a new baseline

 

I am using version 1.3.0.7 and cold restores take no more than about 2 hours for my entire 110 gigs of data (Win 7 64 bit). Could you please try the same regime as you have described above using 1.3.0.7 on your Win 7 PC? All you need to do is install it over the top of your current AX64 installation and then, after the test, install the version of your choice over that (not sure if you would need to create version 1.3.0.7 recovery disk for testing that version, probably a good idea to do so to be safe). I would guess its been about 6 months since 1.3.0.7 was released so perhaps its a problem with the more recent versions (you did say that 6 months ago your cold restores were faster).

 

I would suggest that it is working for the majority now.

There are relatively few complaints in comparison to those who have stated that AX64 is a very competent program,,,,,,,,and more of those who have issues will post about it than those who have no issues,,,,,,

Now exactly how many make up the majority is a bit of an open question but I would suggest that at a min upwards of 75% of the folks who are working with or testing/trying AX64 are not having issues. If 49% of those trying it were having issues (and that still means a majority of 51% are not having issues) there would be a lot more complaints posted.

Just my supposition here, not trying to start a debate on the issue but seems to me to be a reasonably logical, and conservative, estimate.

 

Just like to say the latest beta 1.4.1.48 has been working on my windows 7 system for the last 2 weeks with no problems, backing up a 62 GB ssd partition.

First backup 8-9 minutes, following backups about 1 minute.
Hot restore a couple of minutes, cold restore about 10 minutes.
Baseline with about 6 manual backups.

Kit1cat