Introducing AX64 Time Machine - hybrid imaging/snapshot software

Discussion in 'backup, imaging & disk mgmt' started by Isso, Jan 18, 2013.

  1. TonyW

    TonyW Registered Member

    Joined:
    Oct 12, 2005
    Posts:
    2,741
    Location:
    UK
    It is what is listed on the website. I still have .886 so will update as well.
     
  2. TonyW

    TonyW Registered Member

    Joined:
    Oct 12, 2005
    Posts:
    2,741
    Location:
    UK
    On build .899 now and I switched from USB 3 to USB 2. Just done a backup which took about 2 minutes against an earlier backup from 1 day 18 hours ago. That was much, much faster than the previous day-old backup test. Whether switching USB ports and/or latest build has made that difference I don't know. Just thought I'd share.
     
  3. Cruise

    Cruise Registered Member

    Joined:
    Jun 10, 2010
    Posts:
    1,240
    Location:
    USA
    I'm sure it is (Isso always posts the most recent version on his website).

    Cruise
     
  4. TonyW

    TonyW Registered Member

    Joined:
    Oct 12, 2005
    Posts:
    2,741
    Location:
    UK
    Just done a restore test with build .899, mainly to try to get to bottom of error screen before Windows starts. I've managed to take a photo, and whilst it doesn't capture the whole screen on this attempt, it'll show what I'm seeing. I wish I knew where the crash dumps are stored.

    Photo:

    photo.JPG
     
  5. Isso

    Isso Developer

    Joined:
    Mar 28, 2009
    Posts:
    1,450
    Tony,

    According to the screenshot the BSOD is caused by Intel Graphics Driver (I'm really relieved that is has nothing to do with AXTM!). You can find the memory dumps in either C:\Windows\Memory.dmp, or C:\Windows\Minidump folder. Please send them to info@ax64.com and I'll be able to give you more information, also I'll doublecheck that AXTM is ok. Thank you

    Isso
     
  6. Isso

    Isso Developer

    Joined:
    Mar 28, 2009
    Posts:
    1,450
    Yes, 899 is the latest version.

    For the lengths of the backup - that depends on the amount of changes on your system. Yes, if you make manual backups with long interval, odds are there will be lot of changes between them and the backup will take more time than normal.
     
  7. bgoodman4

    bgoodman4 Registered Member

    Joined:
    Jan 13, 2009
    Posts:
    3,237
    Makes good sense to me given your explanation.

    1 last point,,,,,I would like to be able to control the set structure a bit. That is, determine how consolidations work. 4 hourly snaps and then 4 (I think) 4 hour snaps, to daily, monthly etc is not ideal for me. I would prefer more hourly snaps before consolidation begins and more daily consolidated snaps before weeklys begin. You mentioned above that this would be coming in the future, any ideas how far off in the future? Until I can control this I would have to use AX64 and RollBack Rx together to maintain the coverage I want. I would prefer dropping Rx sooner rather than later so I am anxious to see this implemented.
     
  8. aladdin

    aladdin Registered Member

    Joined:
    Jan 9, 2006
    Posts:
    2,986
    Location:
    Oman
    Dear Isso,

    Here is some information on a live system. The laptop was bought by my friend for his daughter. The laptop was purchased very expensive, not on specs but on designer status.

    1. It is Sony. It is Sony E Series, VPCEH26EA.
    2. It is pink in color with white keyboard.

    However, the specs are not that bad. It is i3-2330M, 2.20GHHz, and the dedicated GPU is Nvidia GeForce 410M. WHY the specs of the laptop?

    1. I installed the AXTM v1.0.0.886 beta on 22-03-2013.
    2. Set it to, "Automatic hourly backup".
    3. On 22-03-2013 it took an image of 19.6GB (initial image). Start time 03:44PM and finish time 04:04PM. A total of 18 minutes.
    4. It immediately took another image of 37.1MB. Start time 04:15PM and finish time 04:16PM.
    5. On a daily basis since then, I have been leaving it on for more than one hour daily.
    6. Today, I checked the image directory. No images were taken at all since the images on installation.
    7. So I manually started AXTM. As soon as I started the AXTM, it immediately took an image of 1.54GB. Start time 07.41AM and finish time 08.01AM. A total of 20 minutes. Too much time.
    8. While the above was taking place, I installed Firefox 2.00.
    9. It then immediately took another image of 40.3MB. Start time 08.01AM and finish time 08.02AM.

    Conclusion:
    1. It is very resources hungry, as I was not able to do anything else for 20 minuets.
    2. The schedule hourly doesn't work.
    3. Don't know why it takes another immediate image, rather than the scheduled ones.
    4. I know I am using the beta, and not using the latest 1.0.0.899 beta.

    Best regards,

    Mohamed

    P.S. Been very busy lately, still have to upload some files for you.
     
  9. carfal

    carfal Registered Member

    Joined:
    Dec 19, 2009
    Posts:
    177
    Hi Isso. I've noticed a slow down since the Beta stage of AX64. I thought at first that i was imagining it but now i'm certain that it definitely feels slower than the alpha versions.

    I think (and dont quote me on this) I noticed it after you released the version that fixed the VSS backup not starting issue. Below are some times to compare

    XL image.jpg

    I think their excessive for the snapshot sizes. Maybe I'm wrong?

    I have an Intel Q6600, Gigabyte GA-P35C-DS3R motherboard, Samsung 256Gb 840 Pro Series SSD and 2 Seagate Barracuda 250Gb drives.

    Lastly, what's happening with the chkdsk issue. Will this be fixed before the production release?

    EDIT: The restore also seems to be slower than the alpha versions
     
    Last edited: Apr 3, 2013
  10. Isso

    Isso Developer

    Joined:
    Mar 28, 2009
    Posts:
    1,450
    bgoodman, I can give some very rough estimate of 2-5 months from now.
     
  11. Isso

    Isso Developer

    Joined:
    Mar 28, 2009
    Posts:
    1,450
    Mohamed, carfal,

    Thank you for sharing your data, that's very very slow. Actually Baldrick too is experiencing quite slow backups, and I'm working on that with him at the moment. I was sure that it's only specific to his machine, but now I see the problem is more broad.
    I'll send an update as soon as we find and fix that problem.

    Isso
     
  12. Isso

    Isso Developer

    Joined:
    Mar 28, 2009
    Posts:
    1,450
    carfal,

    A question regarding restore: how much time it takes to restore any of these backups? I mean the restore operation itself, without considering reboot time. Thank you!

    Isso
     
  13. TerryWood

    TerryWood Registered Member

    Joined:
    Jan 14, 2006
    Posts:
    1,091
    Hi Isso

    " Actually Baldrick too is experiencing quite slow backups, and I'm working on that with him at the moment. I was sure that it's only specific to his machine, but now I see the problem is more broad."

    Including me.

    Terry
     
  14. bgoodman4

    bgoodman4 Registered Member

    Joined:
    Jan 13, 2009
    Posts:
    3,237
    Thank you, I look forward to it.
     
  15. aladdin

    aladdin Registered Member

    Joined:
    Jan 9, 2006
    Posts:
    2,986
    Location:
    Oman
    Dear Isso,

    Thank you for the above response.

    However, do you know the reason, why the hourly schedule doesn't work?

    Best regards,

    Mohamed
     
  16. carfal

    carfal Registered Member

    Joined:
    Dec 19, 2009
    Posts:
    177
    Hi Isso. Just to let you know that the times i showed previously was with RBrx uninstalled. I had been using AX64 with no RB for about 2 weeks but caved in yesterday and reinstalled RBrx. The lure of less than 5 sec snapshots and restores is just too irresistable. If you sort out the slightly slower than desired backup and restore time in AX64, i think i will be able to rid myself of RB....maybe. :D

    Below is the new backup and restore times WITH RBrx installed (sorry).

    XL image2.jpg

    The backup times are similar to before and i now have some restore times for you. Notice the second restore to SS1 took longer still. Is this a normal discrepency? I think you'll also agree that in general the restore times are too slow.

    EDIT: As you requested, the restore times are from when i click the "start restore" and the command prompt appears and reaches 100%
     
    Last edited: Apr 4, 2013
  17. TheRollbackFrog

    TheRollbackFrog Imaging Specialist

    Joined:
    Mar 1, 2011
    Posts:
    5,180
    Location:
    The Pond - USA
    Carfal... I have a quick question. Can you tell us what your disk configuration is for this testing?

    Are the source and destination disks (not partitions) the same/different? What's the disk class of the source/destination (HDD/SSD, RPMs and cache if HDD... make and model # will help)? Is the backup data path SATA, IDE, USB (2 or 3), etc.? What's the CPU class of your test system (# of cores/threads, speed in megahertz). These all will have a major affect on your snapshot times. I didn't see any of these specs but maybe I missed something... :)

    Some of my testing has shown great differences depending on on the system's architecture.
     
  18. TheRollbackFrog

    TheRollbackFrog Imaging Specialist

    Joined:
    Mar 1, 2011
    Posts:
    5,180
    Location:
    The Pond - USA
    <Jeeeesh, Frog... always more questions, huh?>

    Isso, something just struck me... and I'm sure you can supply the answer.

    When running AUTOMATIC HOURLY BACKUPs AND occasionally taking a MANUAL BACKUP, do the automatics take in account the manuals when doing their incremental references, or are they only in reference to each other?

    To expand... when I delete a MANUAL backup, does that trigger a MERGE into the appropriate AUTOMATIC incremental or are the MANUAL and AUTOMATIC incremental streams kept separate from each other?

    Maybe I haven't had enough coffee yet... :D
     
  19. carfal

    carfal Registered Member

    Joined:
    Dec 19, 2009
    Posts:
    177
    Sure, no problems. :)

    Motherboard
    Gigabyte GA-P35C-DS3R

    This motherboard has a SATA II controller. ( I wish it was SATA III :( )

    CPU
    Intel® Core™2 Quad Processor Q6600
    (8M Cache, 2.40 GHz, 1066 MHz FSB)


    Hard Disks
    Samsung 256Gb 840 Pro Series SSD X 1 (Partitioned into 2, Drive C: = 124GB and D: = 114GB ) Connected to SATA II

    Seagate Barracuda® 250GB 7200.10 ST3250410AS X 2 Internal (Drives E: and F: ) Both connected to SATA II

    I have AX64 backing up drive C: (SSD) to Drive F: (7200rpm).

    In the alpha versions i was backing up to a USB 2.0 drive but found it too slow. Backing up to my internal F: was "normal" speed so that's what i have been using since. I believe that the beta versions is when i began noticing the slower backup/restore operations.

    If I've missed something just ask.
     
  20. Isso

    Isso Developer

    Joined:
    Mar 28, 2009
    Posts:
    1,450
    carfal,

    Thank you very much for the information (Froggie, thanks for helping me)! I have two more requests please:
    - could you do a restore of the last snapshot from Recovery media, and note how much time it takes?
    - could you open Task Manager before starting normal (online) restore and note the CPU usage while restore is in progress?

    Please also let me know the number of backups that you have at the moment.
    Thank you for your help!

    Isso
     
  21. Isso

    Isso Developer

    Joined:
    Mar 28, 2009
    Posts:
    1,450
    Froggie,

    Technically there is absolutely no difference between automatic and manual backups, i.e. they belong to the same chain. The only tiny difference is that manual backups have a bit indicating to not merge them in the process of automatic consolidation.

    So, from the point of view of manual deletion there is no difference between automatic and manual backups, that's why the merging will use both of them whenever applicable. But manual backups are excluded from automatic consolidation.

    Isso
     
  22. TheRollbackFrog

    TheRollbackFrog Imaging Specialist

    Joined:
    Mar 1, 2011
    Posts:
    5,180
    Location:
    The Pond - USA
    Thank you, sir... timely and complete, as usual.
     
  23. carfal

    carfal Registered Member

    Joined:
    Dec 19, 2009
    Posts:
    177
    Sorry Isso but i cant accomodate this request. This is my main system and i dont feel comfortable doing a full restore from the recovery media. I feel safer doing my testing with AX64 within the confines of RBrx.

    This i can do and here are the results.

    Restored to SS3 and the CPU fluctuated up to 25%. It only hit 25% once at about the 20%-25% mark of the restore process and only for the blink of an eye. It mostly fluctuated up to 15%-17%.

    Restored to SS2 and for the blink of an eye at the very start of the restore it hit 33% once. Again at the 20%-25% mark of restore process the CPU spiked up to 30% just for the blink of an eye again. CPU was fluctuating all over the place like the previous restore.

    If you look at my previous post you'll see that i have

    Baseline snapshot
    SS1
    SS2
    SS3

    Currently they are all the snapshots i have made, a total of 4.
     
  24. Isso

    Isso Developer

    Joined:
    Mar 28, 2009
    Posts:
    1,450
    Thank you very much carfal, I really appreciate your help! I'll get back as soon as we have a fixed version.

    Isso
     
  25. TheRollbackFrog

    TheRollbackFrog Imaging Specialist

    Joined:
    Mar 1, 2011
    Posts:
    5,180
    Location:
    The Pond - USA
    Isso... if it makes you feel worse (or Carfal, better ;) ), I am seeing almost identical snapshot sizes/times as Carfal on basically the same platform (same CPU, same source <SSD> and destination <7200rpm HDD> disks).

    If there's anything I can do to help (no RBrx in the way on the BETA system), just lemme know...
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.