BE VERY CAREFUL with this new release (v3.4, 22Feb2023). Although I received no error codes, when I restored a mixed version image chain (v3.2 Full and v3.4 Diff) with v3.4, there were some anomalies in the restored image... and they were reproducible. I'm now gonna create a v3.4 ONLY chain and see if those same anomalies exist. Once I can make some sense out of the anomalies, I'll report the issue to Hasleo.
FYI... the HBS v3.4 ChangeLog (below). The 1st bullet (improved restore) was already included in the v3.2 (13Jan2023) out of band release. Version 3.4 (2/22/2023) Improved restore performance Fixed bug: Backup service program crashes in some cases Fixed bug: The program does not start properly in the emergency disk Dutch, Swedish and British English language support Fixed some bugs to improve product quality
I did a fresh install of the new HBS 3.4 and created new backups. HBS successfully restored the system to the selected incremental backup.
I know Hasleo uses this forum for feedback, but if they're going to be serious contenders, they need to open their own support forum. Contacting them by email is not good enough for imaging backup support. Especially when an application is in its infancy.
Thanks, stapp. I couldn't see any forum links under the Support menu on their website. But I now see a link down the very bottom of the page.
That looks promising. Sure hope so. It will take me a few days to try the new release myself and see if the restore goes normal. Is there any chance we can restore the previous chain of backups with this new version efficiently?
Until I completely understand the anomalies discovered in the mixed chain, I wouldn't trust it. I imaged 5-partitions (Disk Image) from a single disk (EFI, MSR, C, V & Recovery) in a 2-image mixed chain (Full <v3.2> & Diff <v3.4>). When restored, there existed EFI, MSR, C, F & Recovery (V was restored as F). At the same time, all my Macrium Reflect definitions for the same backup image set lost their selected partition references... probably because Hasleo put them back in the wrong order or used different GUIDs when restoring. This has never happened before. As I mentioned above... BE VERY CAREFUL!
According to what they themself have said, i think it was in this thread, "they are a small company with few developers and small resources", consequently they do not have time and so on, to test every potential new release extensively. That in effect means, of course, that as long as the situation is like that, this will not be a reliable product. A gamble to use just like Aomei and EaseUS is.
I did some regression testing on the configuration mentioned above, and the problem I see is also in the 13Jan2023 edition as well. I have reported the issue in the Hasleo Forum. This issue did not exist when using the "System Backup" mode for just imaging the BOOTable System... it only shows up having used the "Disk/Partition" mode imaging during restoration.
Well that being the case im sticking with the previous version which so far has been error free for me.
OK, the forensics have been completed on Post #327 above and the results are <drumbeat>... 1. It matters not whether the images are v3.4 or v3.2 generated... the problem has been around since the beginning when using "Disk/Partition Mode" images. 2. "System Backup" restorations not affected since December (when a similar problem was discovered). 3. During restoration of "Disk Mode" images, all partitions in the image are returned to the disk with new Serial #s and new Partition IDs, correctly mapped to their original LBA locations. This is not a good thing as discussed below... ---Windows considers all new partitions (not seen before) to be letter assigned to the next available disk letter. This will include any partition not part of the Windows BOOT set (EFI, MSR, OS & Recovery). ---Since almost all imaging software identifies the partitions they are working with using that same information above, most of that software will fail when trying to use it after a Hasleo "Disk Mode" restore operation (Macrium REFLECT can't find any of the partitions it needs for its Definition files). That's about the extent of the damage (not too bad)... you reassign your disk LETTER accordingly for non-Windows restored partitions and EDIT your REFLECT definition files to include the "new" existing partitions and all should be good once again, BUT you should never have to do this! An existing partition requires all pertinent information returned upon restoration... otherwise any existing app that is partition-based (most imaging apps and even Windows itself) will think it's a brand new partition and react accordingly. Hasleo has acknowledged this anomaly (didn't say what they will do) and hopefully they will fix it accordingly... it's kind of a major fail at this point.
FYI... the CRITICAL piece of information being twiddled by Hasleo is the Partition ID. Although it also changes the partition's Serial #, this does not seem to affect anything currently running on my System. PS- I rechecked the Hasleo System Backup mode (for my own piece of mind) and indeed it returns the proper Partition ID upon restoration... still good to go.
It appears Hasleo has successfully fixed the crash issue in the new version. HBS 3.4 has not crashed on my system since the install. The restore (System Mode) operation is also working well here.
@TheRollbackFrog You may test this version. "We've made some changes recently, can you try this revision below? https://www.easyuefi.com/backup-software/downloads/Hasleo_Backup_Suite_Free_230228.exe"
Hasleo released this version on February 22. The version I posted is a revision Hasleo Support sent me on February 28.
While this version may have addressed the crashing issue of @khanyash - it DID NOT ADDRESS the faulty restoration of Partition IDs during a "Disk Mode" restore of a Disk/Partition image (just checked <as described in Post #342>). We'll keep waiting for that one (one problem at a time )...
