Imaging Performance Testing: MR8, ETBH, HBSP

[admin]

@garioch7,

Thanks to Phil for testing, glad to see everything's working fine. Have a nice day!

Best regards,

[garioch7]

Another three weeks have passed, so here are the results of my latest three-week testing cycle of MR8 vs ETBH vs HBSP.

I also want to acknowledge, with sincere gratitude, the excellent suggestion by @Bespoken that these regular posts of my testing cycles should have a "Summary Table."  I will be including those tables in all future posts.  If anyone else has suggestions to improve these posts, please PM me.


Imaging/Check Image Times

Computer:

2019 Dell XPS 8930 SE Desktop Computer
i7 CPU, 32 GB RAM
DELL GeForce RTX 2060 GPU (6 GB Memory)
Three Internal Drives:
Drive 0 [HDD]: ST2000DM008-2FR102 (ZFL0WX49) [1863 GB] D:
Drive 1 [HDD]: WDC WD4005FZBX-00K5WB0 (V30884SF) [3726 GB] G: (Target Image Drive)
Drive 2 [SSD]: SSDPEMKF010T8 NVMe INTEL 1024GB (5CD2_E428_9150_7048.) [953 GB] (Source Image Drive)
No BitLocker Encryption on any Drives



Common Defaults to all three programs:

High Priority
Full Disk/Partition Images (all six used partitions, one partition (7) is empty)
Source Drive: Internal Intel 1 TB SSD (Disk 2)
Target Drive: Internal WD Black 4 TB HDD (Disk 1)
Default Compression (Recommended)
OS: Windows 11 Pro 25H2 (26200.8894), unless otherwise stated.
Recommended Program Defaults, unless otherwise noted.


Listed in chronological order of testing (earliest date to the latest date).


2026-07-24 (Times rounded off to the nearest minute)
Macrium Reflect 8 [MR8] (8.1.8853)
Default Filters

Disk 2 (6 partitions) Size: 250.9 GB
MR8 Image Size: 185.7 GB

Image Backup - Disk 2: 14:03 - 14:17 (14 minutes)
Image Verify - Disk 2: 14:17 - 14:31 (14 minutes)
Total Imaging Time: 28 minutes



2026-07-31 (Times rounded off to the nearest minute)
2026 Easeus Todo Backup Home [ETBH] (18.0.0 [Build 20251203])
Default Filters

Disk 2 (6 partitions) Size: 254.3 GB
ETBH Image Size: 200.0 GB

Image Backup - Disk 2: 13:55 - 14:11 (16 minutes)
Check Image - Disk 2: 14:12 - 14:36 (24 minutes)
Total Imaging Time: 40 minutes



2026-08-07 (Times rounded off to the nearest minute)
Hasleo Backup Suite Professional [HBSP] 5.9.2.1
Default Filters, Smart Backup enabled, Highest Priority.

Disk 2 (6 partitions) Size: 255.7 GB
HBSP Image Size: 174.7 GB GB

Image Backup - Disk 2: 13:48 - 14:01 (13 minutes)
Check Complete Image - Disk 2: 14:02 - 14:15 (13 minutes)
Total Imaging Time: 26 minutes

Have a great weekend.

Regards,
Phil

[admin]

Thanks again, @garioch7. It would be even better if more users could provide additional test data.

Have a nice weekwnd!

[garioch7]

@admin,

It would be even better if more users could provide additional test data.

I totally agree with you.  I would love to see more testing results being posted here regularly.  They would not have to be comparisons with other products.  Even reports of HBS performance on multiple platforms would add much more clarity as to how HBS performs on many different systems, thereby providing valuable feedback to the Hasleo Team.

Have a great day.

Regards,
Phil

[Bespoken]

Well you asked, so here are my informal test results.

Test System backups (HBS V5.9.2.1 & MR8 v8.0.7175) were performed from a laptop running Win 11 25H2 26200.8894. The target was an external SSD plugged into a UBS3 port. The backups were run with the highest priority, maximum compression, and 4 partitions selected. Two backup were performed with HBS, one with filters enabled to exclude "Windows page, hibernations and swap files", and "Windows VSS snapshot files", and the second with filters disabled. I have no idea if MR8 automatically excludes these Windows files. Setting up a filter in MR8 is not as easy/simple compared to HBS, so I did not bother.

The initial Source Size was identical for all the test. The used space on the C: drive was 88.7 GB

These were the individual steps performed:

- full backup to ext USB with MR8
- check integrity with MR8
- full backup to ext USB with HBS filters enabled
- check integrity with HBS
- full backup to ext USB with HBS filters disabled
- check integrity with HBS
- disk cleanup
- restore HBS
- verify boot and OS working normally
- disk cleanup
- restore MR8
- verify boot and OS working normally

The disk cleanup made only minor changes to the system, so the restore was fast as expected.



ps. A Full backup over wifi (not part of the test) to a network storage drive using HBS took 26 minutes.

[admin]

@Bespoken,

Thank you very much for taking the time to conduct these informal tests and share your detailed results. We truly appreciate the community's efforts to provide real-world performance data, and your feedback is very valuable to us.

I noticed that your tests were performed using Macrium Reflect v8.0.7175, whereas the latest version of Macrium Reflect v8 should be v8.1.8853. If you or other users could run similar tests using the most current version of Reflect, it might make the comparison more fair and meaningful.

Thank you again for your contribution to this thread.

Best regards,

[Bespoken]

I noticed that your tests were performed using Macrium Reflect v8.0.7175, whereas the latest version of Macrium Reflect v8 should be v8.1.8853. If you or other users could run similar tests using the most current version of Reflect, it might make the comparison more fair and meaningful.

Similar tests redone with MR v8.1.8853 and HBS V5.9.2.1. Both using default setting but with high compression. The source was now 88.0 GB. Here are the revised stats:

[Froggie]

I have noticed a recent anomaly with MR8.1 that, at this point, won't allow me to run an unquestioned comparison... I have no idea what's going on.

While imaging a multi-BOOT System (EFI, MSR, Win10 OS, Win11 OS & Recovery) I experience a very weird anomaly.  While imaging between NvMEs (different internal SOURCE and TARGET), The LIVE OS partition images at the expected speed while the non-LIVE OS partition images at a speed 10x lower.  This occurs regardless of whether the LIVE OS partition is either Win10 or Win11... makes no sense at all.  Both are standard NTFS partitions, one LIVE and one hidden.  It almost acts like it's viewing the hidden partition as though it's an unsupported FileSystem.  I see the same kind of imaging speed differences between LIVE NTFS partitions and hidden EXT<n> partitions.  Macrium (like HBS) must image the "unknown" format (EXT<n>) in a forensic mode, having to read every sector of DATA defined in the partition... this creates a much longer imaging operation for those partition types.

I only bring this up when I noticed Bespoken's latest MR8.1 imaging... his MR8.1 time is double his HBS time, this should not be the case when using identical SOURCE and TARGET devices.  Although my anomaly (multi-BOOT) is not the same as Bespoken's, the massive difference between MR8.1 and HBS is the same.  Remember, both use the exact same DATA compression algorithms during their imaging processes.

I believe something has changed with MR8.x's Windows interface recently, probably due to a possible Windows update.  I have never before seen this type of anomaly and I've used HBS and MR8.1 side by side for years.

Just some food for thought...

[Froggie]

Just noticed an interesting phenomena regarding the above observation associated with the SOURCE NvME.  I will report back as soon as I can confirm.

[Bespoken]

I only bring this up when I noticed Bespoken's latest MR8.1 imaging... his MR8.1 time is double his HBS time, this should not be the case when using identical SOURCE and TARGET devices.  Although my anomaly (multi-BOOT) is not the same as Bespoken's, the massive difference between MR8.1 and HBS is the same.  Remember, both use the exact same DATA compression algorithms during their imaging processes.

I believe something has changed with MR8.x's Windows interface recently, probably due to a possible Windows update.  I have never before seen this type of anomaly and I've used HBS and MR8.1 side by side for years.

It would not be a surprise if the performance impact was due to a Windows update. The v8.0.7175 version was instelled from an old saved download, and it would not update to the latest. The v8.1.8853 was downloaded from softpedia.com and a registration key applied. This suggests that the anomaly is not with the program, and I have not seen any other reports of performance issues.

It will be interesting see what you find.