In accordance with my observation. IMHO Macrium really needs to optimize their imaging/restoring engine to improve 1. the speed and 2. the compression algorithm. In this aspect, Drive Snapshot is a very good example. It used to be slow and produced larger image files ~ 1-2 years ago, however the latest versions (since about ~1 year or so ago) drastically improved its speed and compression ability. It's now probably the most fast and produces smallest size of images.
Macrium V5's speed is not in the base image, but in incrementals. For not using a tracking file, it simply can't be beat.
Thats what version 6 is supposed to do with restore and imaging times (snapshots) 90% faster or better. Time will tell if this is real and if it is it will be very nice. Bottom line,,,,the times with version 5 are of no importance to most of us as we are looking to version 6 and will only be comparing it to AXTM.
Pete, I thought you liked the latest beta from AXTM. Have you changed your mind about it and if so why?
BG, I don't think he changed his mind about the effectiveness of BETA # 548, but, if like the rest of us, it won't run anymore (expired BETA) and we hear nothing from the company (Pete has unanswered questions, I have unanswered questions almost 3-weeks old)... at this point things aren't really looking that well. Pete needs something that works now... and if his BETA is dead, he sure doesn't have it anymore.
I think you might be reading a little too much into things. There has been no claim to imaging times getting 90% faster... restoration times, yes, but not imaging times. I'm not sure they are capable of speeding that aspect of the system up to any great degree (probably some if they put a large effort into it). Sure, their full imaging time can run about 65-70mB/sec to a decent SATA-based HDD, but as Pete and others have said many times... they seem to have the fastest INCREMENTAL capability among many of the imagers. So with a quick "snapshot" capability (INCREMENTALs) and the new RDR (Rapid Delta Restore) capability only restoring image differences rather than entire images, the newly described v6 should be very beneficial to those who do imaging in other ways other than FULL image and FULL restore only.
Froggie, you saved me a lot of typing. Guy's before I put any faith in software there are two major criteria. One is the software has to be reliable. Two the vendor has to be reliable. Unfortunately AX64 seems broken,
Agreed. I don't even have a facebook account. I normally go to the Vendors website or forum for updates to NEWS items. FB, Twitter, and similar social media are fine but companies need to also realize they should not be used as the main thrust of news and/or support.
Is there any news about updates then for their business server products as well ? Will they also be going to this new version 6 or do the business products come out at a much later date than the consumer products? http://www.macrium.com/business.aspx
does anyone know what the differences will be with v6 between standard and pro? im debating on which to purchase and i just wish i knew what v6 was bringing between the 2
Thanks Froggie,,,,I get that now and understand. What a shame, looks like the AXTM team has some real problems on its hands. They certainly have squandered a great deal of good will, time will tell if they can earn it back.
So what exactly does this mean? Sorry about the attachment, I have no idea why its like this but if you click on it the correct image will appear.
BG, here's the on-line Macrium HELP document. Look under "Overview/Cloning." A simple CLONE operation does a block for block copy of the source disk (while managing separate disk IDs and volume letters) so that you have a mission critical HDD ready to use if necessary (no restoration required, just some connections or re-BOOTing). In the old CLONE, the entire COPY was performed each time you cloned a disk. I'm guessing they can now use their RDR feature to DIFFERENCE update a clone volume (actually a combination IMAGE/RESTORATION operation on the fly)... kinda like a INCREMENTAL for a clone. Only a guess, though. I believe this is the same route CASPER takes when managing its clones, also.
Ok thanks, so how long should we expect snapshot generation to take? AXTMs hourly snap takes about 60 seconds to create and does little to disrupt other running processes. Would we expect similar from MR V6?
No one can answer that question until we get our hands on it. And even then it's going to be different for everyone.
I'm only guessing here, BG... While AXTM uses a Tracking file to determine the changes since the last snapshot, Macrium, at least in their current iteration, does not. It compares complete file structures between the last saved and the current to determine what the INCREMENTAL should be... this process does not take too long when watching it happen. AXTM does something similar as far as comparisons are concerned... just uses a difference reference. On my current system, that Macrium "comparison" process takes about 25-sec (mostly limited by HDD bandwidth of the INCREMENTAL storage drive) before the actual INCREMENTAL dump begins (also takes about 25-sec). What's being INCREMENTALly imaged is a partition that is using 38.5gB, hasn't been snapshotted for 4-days, and the resultant compressed incremental is 1.28gB... overall, not a bad result. This is current technology (v5.3). I personally don't believe this part of their technology will have changed very much for v6, but I could be pleasantly surprised. Their current technology allows the user to determine what effect the imaging process has on their system (it can be set in 4-steps from LOW to HIGH priority as far as the CPU is concerned).
My guess is that Rapid Delta Restore and Rapid Delta clone will use the partitions file table to determine which files and subsequently which sectors have being modified. So on the restoration only those sectors and the sectors that occupy the mft will get replaced. But there is one problem "what happens if a file on the disk was corrupted or modified with direct disk access" (bypassing the partition file table with e.g. with a hex editor)? That file will remain damaged and won't get replaced from the old intact one that resided in the image.... ps. Macrium at least when I tested it a few years back had that problem with the incrementals. It does not read all the occupied sectors of the disk when creating the incrementals in order to compare them with hashes from the previous image; only reads the new and the modified ones as they are reported from the file table. Handy and speedy and most of the times will work fine... but one can never be sure if the incremental image taken reflects an exact copy of the partition... Panagiotis
Thanks guys much appreciated. Now we wait for the release of V6 to see what the real world results will be.
