Hasleo Backup Suite Image Compression Levels

Ol' @EASTER here is trying to distinguish between the most optimal compressions levels which work best in External OR Other Storage for you users. Each Imager from TeraByte For Windows, Macrium, Aomei and others that are a main part of your protective/proactive backups.

To the topic title i am focusing with this discussion on Hasleo for now. Since they are the newest to make a useful splash on the scene of Imagers sporting features. They ALL employ Compression levels. I have normally left it to a brand's preferred DEFAULT or RECOMMENDED but also in order to really see if the other other levels actually live up to their claim have used High Compression.

Does anyone have a better experience going a step up or down in compression away from default either way, and find it basic to other imagers? Or does one imager seem to perform a better Image for you space-wise using the Compression Level such as higher or lower more satisfactory?

And does let's say a high compression still meet same ETA time durations expectation you find interesting compared to previous or other Brands?

 

I'm not sure that compression/space saving is the best way to look at this. You need to be aware... in the case of Hasleo, it is a multi-threaded process that does the imaging. As a result, when you kick the speed upstairs (HIGH compression) it will eat up a seriously threaded machine.

On this machine I use a 10th Gen Intel i7 machine.., an 8-core/16-thread processor that runs at turbo speeds of 4.8ghz. If I image at MEDIUM compression, the app uses 12 of the 16-threads at about 60% of each thread to do its compression work. If I kick that up to HIGH compression, it will bury the processor... 100% of all 16-threads. It does this because the DATA source and target are NvME SSDs (3.2gBs each). The high disk bandwidth allows the app to bury that processor.

If either your SOURCE or TARGET is an HDD, it really won't matter... it won't need near that much CPU to do its work due to the slow disk speed.

If the metric you're trying to determine is the actual amount of compression, it's a fair ask... just don't bring speed into the discussion, it will be tough to derive a base reference on that metric.

I'll be back with a quick comparison...

 

The SOURCE partition is 48.3gB

Hasleo HIGH compression: 23.78gB
Hasleo MEDIUM compression: 25.3gB

Macrium HIGH compression: 24.7gB
Macrium MEDIUM compression: 25.3gB

I use Hasleo MEDIUM compression for my imaging, not due to any size issues... due to the fact that it eats my 16-thread Intel proc during the imaging process, if I use the HIGH compressions setting, and I need to do other things while it's imaging . Target space is not an issue for me...

 

Hello Frog - THAT was EXACTLY where i was going with this Hasleo compression inquest. Since the DEVS finally first took up the challenge presented to them early on, it added the ZIP that this Imager needed in order to not just compete, but to fall in line with the best power metrics any Imager needs to fully realize best results and leave laggings behind.

With today's latest higher output CPU's courtesy those electronic hardware experts raising the potential for software to tap into more available central energy, (SSDs), when we look at Imagers, in this talk, HASLEO for one makes multi-threaded process to perform stronger results a reality.

You must read minds

 

Unless it was drastically different (haven't seen this with either Hasleo, Terabyte or Macrium), I would not really use this metric to determine what imaging application I would use.

 

For the record my ongoing Imaging i keep 'Compression" level at the MEDIUM.

However i have used HASLEO BACKUP SUITE High Compression on another job in order to measure the outcome. The successful result i got might have tapped more of the energy but i didn't notice any real strain from using that "upstairs" setting.

Plus i have to admit, i seriously multi-task during every HASLEO backup processing during an image session, if you can call it that, by also Chrome Web Browsing while at the same time running MPC-HC either songs playlist or even while running a video.

Now THAT IS impressive given it's a mediocre Gateway System with minimal capacity. It's not even SSD equipped.
Gateway Laptop NE56R31u Intel Celeron
Dual Core
B830 (1.8 GHz)(4GB Memory)

 

As I mentioned previously, if either your SOURCE or TARGET disk is an HDD, HIGH (or any other) compression will not really tax your CPU... multi-tasking should be just fine. Speed up those disks... Katy bar the door

 

Was the backup time noticeably different when using the higher compression setting?

 

For me, not really. A system image, 4 partitions w/50gb of data takes 2:30 on medium and 2:45 on high compression.

 

As far as time my result SO FAR was the same result as @n8chavez when switching to High Compression.

However i still need to do more image testing using High Compression on more units to see if it anything is really different and becomes noticeable

 

In my case, and in both instances, I was imaging from to SSD to an HDD.

 

As long as you're using one HDD in your Source/Target scenario, and your CPU isn't much smaller than a dual-core at 3ghz, there won't be a big time difference. As soon as you up your I/O speeds (all SSDs) things will change, and if you do that and up your cores/threads, the change becomes noticeable.

Using my 8-core/16-thread iCore, speed went from 56-sec (MEDIUM compression) to 1-m 40-sec (HIGH Compression) for a 50gB used space OS partition. That was a NvME to NvME (PCiE v3 at about 3.2gB/s) HIGH compression task and it buried all 16-threads of the CPU at 100%. If the PCiE subsystem was v4-based (about 2x the speed of v3), it wouldn't be any different since the CPU was already buried at v3 speeds. v4 would make a big difference in time if your CPU was heavily cored/threaded (an AMD 64-core/128-thread could easily bury a PCiE v4 subsystem, maybe even a 16-core/32-thread CPU).

 

Addendum to the above... the HIGH compression task used about 50% of the SOURCE disk's bandwidth (about 1.6gB/sec) and 8-30% of the TARGET disk's bandwidth (same speed as the SOURCE disk capability). So it looks like you would need appx. 32-threads of a CPU to saturate a PCiE v3 SOURCE SSD storage device (3.2gB/sec) using Hasleo's HIGH compression storage algorithm. This assumes the Hasleo algorithm will thread multiple without limits with your CPU (without seeing the code, impossible to know).

Haven't looked at Macrium REFLECT... too busy at the moment.

 

Good info to know @TheRollbackFrog - Some digging using the good program HWINFO that @JRViejo keeps us updated on. My current newest system sports quad/4 cores from it's (DELL) Intel Pentium Silver with a Gemini Lake CPU Interface NVMe M.2 x48.0 GT/s

Not familar as i should be on how to measure THREADS

 

CPU-Z... it will tell you everything about your processor.

THREADS are basically processors that are incapable of doing any I/O operations... they must pass that on to COREs to accomplish.

 

Thanks Froggie Will conduct an exam as soon as HASLEO is finished doing an Incremental MERGE for a pair of them on my new install of Windows 11 yesterday. Another good one.

EDIT: CPUZ Results, 4 Core 4 Threads

 

Anyone else has 4.91 installed yet? I'm having an issue that was not in 4.9. When you go to mount a volume, after you select your task, when I click on "change version" there is no other image listed there except the most recent. There are other images in the same directory on my disk though, they're just not listed. This was not the case with 4.9. Can anyone confirm?

 

@n8chavez - when I use the "Mount Image" feature of v4.9.1 and select "Change version," all the images in the chain for that task are available and it allows me to select any one of them.

 

Right. With 4.9 I was able to mount images that were not in the current chain. Chain does not mean task. There are plenty of times I have an images from, let's say, two weeks ago that I want to extract from. But in 4.91 I cannot do that because I can't see it, or anything outside the current chain, to mount it, but in 4.9 I could. I can manually browser for the image to mount it, but it's part of a task and I should be able to see it. Make sense?

 

Let me check once again... I don't think I looked back that far.

 

@n8chavez - don't think I can check your issue. Although I have two unique chains associated with a given task (FULLs, DIFFs & INCs), they are in the same numbered sequence, created through automatic retention mechanisms. I am able to see all segments from both chains using the Mount Image "Change Version" option.

 

Interesting. It's odd that I can see the only the one chain. Oh well.

 

I think i got tangled up just a bit here. Really, the setting to MERGE is an okay cool and perhaps feature option, (it works fine), but i like @TheRollbackFrog's personal set of sequence. Yet to establish a solid Retention Schedule (that can be later). The tangle was, i had (1) Full Backup (Windows 11) followed by a pair of incrementals. Then, contrary to my own imaging habits/practices, did a Differential follwed by another Incremental (3 total).

Enter the MERGE screen, i could only select 2 oldest incrementals so far. Not sure if that is the LIMIT per MERGE or not. Well that eat up time in itself so i cancelled the operation and deleted ALL the chain.

What i am trying to get at with HASLEO 4.9.1, is since DIFFERNTIAL is recognized in the order of the images taken/made how best to form an organized schedule using BOTH incs + differentials. I think MERGE of INCS is satisfactory for small changes and most recent's (howbeit limit the merge function), and do a pair of Differentials in between.

You can see by my explanation where the TANGLE comes in.

That said, to @n8chavez's potential issue i can also see ALL my images when selecting the Mount Image "Change Version" option myself.

Again MERGE for me is absolutely efficient per Incrementals as long as not too many pile up to combine, It would seem to me to be faster just to delete the Incrementals and restart that chain instead. I dunno. Maybe i am missing something?

 

When scheduling a GFS-type (Grandfather/Father/Son) backup), only INCs will get merged, nothing will be merged beyond the next Diff/Full... that's why I set the number of DAYs in my schedule to not have to be longer than 7-days, the MERGE stays reasonable at 7-days with a decent retention method. It could get unbearable longer than that, especially as far as time is concerned when using an HDD. With a GFS retention schedule with a reasonable daily set, things are not too bad.

It all depends on what your needs are in the schedule... how many days do you need, etc.

 

I absolutely enjoy being a noob on Retention Policy. But everything is running swimmingly with how HASLEO handles it.
For the record, mine is set to keep 5 daily incs, a pair of weekly Differentials. Keeping the tether plugged into the Windows 11 laptop, she came on at the scheduled time silently without a hitch. You could tell by your external storage drive activity light beginning to blink as the inc was written to it.

Good Tips @TheRollbackFrog