Discussion in 'backup, imaging & disk mgmt' started by Isso, Jan 18, 2013.
It is what is listed on the website. I still have .886 so will update as well.
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.
I'm sure it is (Isso always posts the most recent version on his website).
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.
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 email@example.com and I'll be able to give you more information, also I'll doublecheck that AXTM is ok. Thank you
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.
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.
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 v184.108.40.2066 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.
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 220.127.116.119 beta.
P.S. Been very busy lately, still have to upload some files for you.
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
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
bgoodman, I can give some very rough estimate of 2-5 months from now.
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.
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!
" 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."
Thank you, I look forward to it.
Thank you for the above response.
However, do you know the reason, why the hourly schedule doesn't work?
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.
Below is the new backup and restore times WITH RBrx installed (sorry).
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%
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.
<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...
Sure, no problems.
This motherboard has a SATA II controller. ( I wish it was SATA III )
Intel® Core™2 Quad Processor Q6600
(8M Cache, 2.40 GHz, 1066 MHz FSB)
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.
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!
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.
Thank you, sir... timely and complete, as usual.
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
Currently they are all the snapshots i have made, a total of 4.
Thank you very much carfal, I really appreciate your help! I'll get back as soon as we have a fixed version.
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...
Separate names with a comma.