Macrium Reflect

MRs was 110 GB and AX64s was 102 GB.

Very odd. I should mention that for the MR one there is partition that AX64 does not backup but it is empty as I did not want to put anything there as it was not being protected (I plan to start using it now that I have MR GFC running). I doubt that this would cause MR to take so much longer than AX64 unless MR has to read the empty partition (not likely but I don't have any idea how these programs work so,,,,,,).

I am attaching a screen grab of my MR interface. It shows whats what in terms of my drive.

 

Weird.

 

Yes, maybe someone else can run comparisons, it would be interesting.

 

Thanks.

 

Thanks - that sounds almost exactly like what I want to do (numbers are different but basic aim sounds just right). Seems I need to look into GFS and what I can do with it.

 

No, not odd, it depends on the compression algorithm used....

 

BG, your system, especially that USB sub-system, must have some issues. The only differences between the two process described above will be compression algorithms (which I see very little difference in their DEFAULT state) and possibly program buffering sizes (which are up to the developers). Any CPU requirement (data compression) differences would only show up when using very fast disk subsystems at both ends (SSDs). Since you're using a USB2 connected device, if those even existed they would completely disappear and your overall task would become pretty much I/O bound in speed.... and as a result, should run about the same.

When I run your test above using an internal SATA-connected 7200rpm HDD device for my images, AX64 runs about 50% slower for the exact same image than MRv6 does (6-min vs 4-min for about 35gB of used sectors). I'm using a fast CPU (i7) and a fast SOURCE volume (SSD). With these components in place, what I would expect to see is a process pretty much driven by compression differences and Input/Output buffering used by the different apps. Also the file structure searching that has to go on prior to imaging may have some affect (MRv6 actually does an optional file system check <kinda like a quick CheckDsk> prior to examining file system changes to determine the extent of the incremental/differential it's about to do... I doubt AX64 does).

You can see from above that system configurations will have a major affect on overall performance... but NOT a 300% difference as you are experiencing above. I don't know what to say other than what you are experiencing should not be happening across USB2 (or USB3 ports).

...and, you need to consider reconfiguring your system to shrink that 262+gB SYSTEM partition and place (and manage) your DATA in a different way. That's quite a load on your overall imaging requirements. But it has little to do with the above problem other than overall time for processing.

 

Using GFS instead of (or along with) Incremental Imaging is a good way to provide for longer term DATA retention... that's what it was originally designed for (not by Macrium... but by data center managers back in the late 60s/early 70s). I wouldn't use it for protection by design (although all that data is accessible at any time), I would only use it for data retention by design. That's why I'm running (2) different DEFINITION systems (with associated images going to DIFFERENT folders)... an INCREMENTAL FOREVER for protection purposes and GFS for data retention. If you don't think you need data retention, use incremental merging or incremental forever (with synthetic baseline) and keep safe under that umbrella.

 

To be sure, just open the "Scheduled Backups" TAB under BACKUP... there shouldn't be anything there if you didn't get some sort of DEFAULT schedule.

...and, even if you set up a schedule, if you didn't CHECK the "If missed then run at next Start Up" option, the scheduled item will just be deferred to its next time period if the device isn't there. All that will happen is the # of incrementals that your trimming in that DEFINITION will move ahead by the time of that schedule task. If you never saved that DEFINITION at the end, nothing was set up anywhere.

 

Yep, that's what I see using a SSD > HDD (7200rpm) imaging path.

 

I was refering to the time frame being odd, not the amt of compression.

BTW, my morning incremental snap took just 2 min 45 sec and was 844 mb. Much better time,,,,I don't get it but it seems more in keeping with what you would expect,,,,,

 

Thats more or less what I expected, I will have to re test.

You are not the first to tell me this and I will do so,,,,,, eventually. Thanks

 

Thank you! That sounds like a very reasonable and doable plan! And, while I'm at it, thanks for your earlier post as well. Quite helpful.

 

I generated a rescue image (ISO). If I boot this (using grub4dos) I'm required to press a key to (continue to) boot "from CD". If I'm not fast enough, my PC will boot the regular Windows OS on the SSD in my PC instead. How can I prevent that key press question? (I always want to boot Reflect if I boot the ISO from grub4dos).

Additionally, is it still not possible to change the resolution of the (Windows 7 based) WinPE image? It currently uses less than a quarter of my 27" screen... (and text is hard to read)

 

On my pc it's full screen - albeit at low res - perhaps it's a monitor stretching option.

 

I'm currently running both Macrium and AX64 too, though don't really want to be.

Right now I'm thinking I'll just use three Macrium schedules, each with its own synthetic baseline: hourly, daily, and weekly. I think I might steer clear of GFS for now as it doesn't seem to offer any advantages for my use.

(With Macrium's GFS video example, does anybody know whether the incrementals are children of the baseline or of the differential?)

 

That 3-hr FULL he mentioned was on a USB2 port... the USB3 port was 1-hr. The real issue is the MR FULL at 3-hrs and the AX64 FULL at 1-hr on the same USB2 device... that makes no sense at all from my experience. I ran his test this morning (albeit on different hardware) and found MR to be 50% faster than AX64 with compression rates about the same.

There's something really strange going on with that USB subsystem of his. Come to think of it...

Note to Barry: with your USB2 drive plugged in, go to DEVICE MANGLER/Disk Drives/<right-click> your USB2 drive/Properties/Policies TAB

Make sure the "Better Performance" option is selected then OK out. You should do this with all your external USB connected drives. With this option in place, though, you will need to give the drive some time to settle before you PULL it when you've finished with the operation. If you use "Safely Remove" feature, it'll let you know when it's OK to PULL.

 

With MR (and almost every other differential producing imaging program), a DIFFERENTIAL is never a child of anything other than the most recent BASELINE (using the same backup DEFINITION file).

 

Sorry - what I'm not clear on is who the incrementals' parents are.

edit: I suppose it must be the Full..

 

Taotoo, for a given definition, it's the MOST RECENT FULL (or 1st incremental if it wasn't preceeded by a FULL)

 

Actually... I've had difficulty with that decision myself.

 

Thanks, thought it likely was (though imagine an incremental could theoretically have a differential parent).