I'd buy a license, even though I might not use it. Terabyte's IFW is my go-to. But still, hasleo deserves to be paid for their very very good HBS.
yeah, I would certainly pay the same price. I have been using this program free of charge for over a year, so they deserve my support.
Recently (this past Monday), I discovered (during a test) an imaging anomaly when using FAT32 partitions for imaging target storage. Reported it to their support channel... a fix was waiting for me when I woke up the next morning. This Dev team is amazing... this product is almost worth any investment at this point I'm sure a MIG-like protection (I've used my own from Excubits for years <no longer available>) will be forthcoming (it's been discussed with the Dev team).
@TheRollbackFrog - We can assume then according to your fix result they forwarded to you that it's already been added on the release page? Most users i know including myself use a FAT32 formatted External Drive OR partitions to storage images
@EASTER, they often post "test" builds in regards to specific issues in their forums where the problem was mentioned before the fixes make it to their official page. I suggest checking their forums first.
Got it. Thanks @n8chavez These "Amended" fix releases was beginning to add up so it was easier for me to rename THIS NEWEST installer (in this case) just as posted in the Admin's reply. V5.0.2.2 Released (V5.0 Release 2)
Their private fixes are usually in the current release with a different date issue. When there's really a fix, they incorporate it into their next release almost immediately but don't release it until they feel they have enough fixes that users have dealt with. In my case, the FAT32 fix was in release v5.0.2.2 build#250121. Wilders will not allow me to link directly to a download so if you want it, see EDIT below (thanks @stapp ). The problem wasn't in storing on a FAT32 partition, the problem was actually imaging directly into a FAT32 partition. The first FULL always worked, a follow-on DIFF or INC into a chain that had been started on a FAT32 partition would fail. Normally users don't do this on a FAT32 BOOT UFD, but I decided to test it directly on a FAT32 device. They fixed the problem in less than 24-hours. EDIT: Above referenced version has been de-Linked below... https://www.easyuefi.com/backup-software/downloads/Hasleo_Backup_Suite_Free_250121.exe
Just make the link unclickable (de-link) so that it has to be copied and pasted into the browser. For those folk unsure about how to do this see here. https://www.wilderssecurity.com/threads/how-do-we-de-link-on-this-forum.400072/
Correcting myself here (no edit). Just made backups of my Windows and Linux installs with the newer Hasleo 5 (release 2) version and they came out smaller than Macrium 8.1.xxx. Windows image is 6.68 GB (~7.8 in Macrium) Debain 12.9 image is 1.86 GB (2.4 GB in Macrium) Noice! I think Hasleo is shaping up to be a nice, light weight imaging program. I am really liking it so far. Also the little trick where you make a small partition on an internal storage drive and copy the contents of the rescue.iso there works to make a bootable "Hasleo partition" so I don't have to fetch a Ventoy usb drive or anything.
1) Does Compress level: &or Encryption mode: vary reliability. I've been using Compress level: Medium & Encryption mode: None with afaik perfect reliability. Been wondering if I should tweak. I have old ext HDD NTFS 500GB & cheapy ext SSD exFAT 500GB for my simple full/diff (no inc) ~weekly manual backup routine with seldom on occasion restore. Been wondering whether Compress level: High &or adding encryption 128/256 with password will be as reliable. Advanced options disabled. 2) Been wondering why Enable backup filter is enabled with Exclude system files/folders enabled & Exclude hidden files/folders enabled. Wouldn't I need system & hidden for a complete restore? Spoiler: C: NTFS Spoiler: Enable backup filter 5.0 Release 2
Item #1: there's no reason those options would be any less reliable that what you are using currently. DATA is DATA and unless you have unreliable hardware (RAM, bad internal connections, flakey DATA paths), things should be as you currently experience. If you move to HIGH compression and/or encryption... expect your processor to be kicked up a notch or 2 in its utilization (my 8-core/16-thread i7 went to 100% on all threads @4ghz with just the HiComp, no encryption. This will happen with fast NvME/SATA III disks). Feel free to test with a test backup task. Item #2: it's not clear from their documentation what those ENABLES really mean... but they sure don't make any sense in their use when it comes to imaging your System. They make much more sense when doing file'n'folder backups because that's where users would never really need those particular FileTypes-Sets. The current DEFAULTs in use (Page, Hibernation, Swap and VSS snapshots) make perfect sense for imaging a System. If they were active while you were imaging (not file'n'folder) your System, it would never restore successfully due to the sheer amount of System/Hidden files needed for any semblance of a successful System
Okay...things being equal...reliability will be equal. Thanks...I had not considered processor kicked up a notch for my entry level machine. Yeah...that's why I've been wondering why they're afaik default. Are they default? Does a Haselo reinstall clear out any user changed settings? Maybe, I need to reinstall Haselo to confirm what's default? Maybe, they're not default??
What may control your machine's use of those options most likely will be the speed of the target device (holder of images). If an HDD (source or target), I believe the machine won't saturate. Those "other" ENABLEs are indeed CHECKed but the effect on an a System or DISK image is not there. They are CHECKed by DEFAULT. A Hasleo re-install will not remove those settings (by current design)... you need to completely delete the installed HASLEO folder (after its uninstall) for those settings to disappear. No need to reinstall... those settings are on by DEFAULT. It's the meaning of those DEFAULTs that's confusing.
A question for those better versed in cooperation between MR V8 and Hasleo Backup Suite, both installed and set to run system image backups at independent times. HBS suggested to me as the System Backup not only my drive C but also adjacent to it small 200MB system partition of MR. Is this a good thing to do to also backup this MR's small system partition? A possible scenario: at some time, MR could make some changes into this partition and rely on them during its next restores. But if I in the meantime restore HBS's System Backup made much earlier, such MR's partition could be overwritten and returned to its state that does not correspond with MR's latest and expected setting. But is it OK in HBS to bypass this MR's partition and just backup the partition with drive C? Has anybody tested this? My inclination is not to make backup of this partion, hence not to use the offered HBS's System Backup, but rather go for Partition C backup only. But wouldn't HBS overwrite the MR's small system partion on such HBS's backup restore? Opinions?
That IS NOT an MR partition. It is the BOOT partition used by your UEFI BiOS to BOOT your SYSTEM, also known as the EFI partition. MR does not create its own partition for any reason, it only images partitions created by the System build, same as HBS. Don't bypass anything when doing System builds, let HBS select what it needs for a System disk image.
OK, good point. Somehow I thought that this was created by Macrium. OK, will keep including it with the system backup as suggested by HBS. Thanks for sorting this out for me. In my Win 11 Pro, at least, I also have a third small partition on my drive C of 626MB, which should be system repair/restore tools etc. This partition was created during Windows installation. Is it a good idea to also include it with the HBS System Backup, or not? It is not selected by default. MR selects as well as restores all three partitions on my drive C; HBS selects/restores only the first two. Wouldn't it make sense to manually add in HBS also the third Windows tools partition?
@Selukwe - you don't have to worry about interactions between Macrium REFLECT and HBS, they are completely independent of each other. As mentioned earlier, scheduled operations should be independent of each other (different times) not for any Macrium/HBS issues but for Windows VSS possible issues. The VSS System is designed so that multiple apps can use it simultaneously, but there have been isolated incidents over the years. Best to try and avoid simultaneous use if possible... just in case I always make sure there's enough time for my earliest FULL primary backup (HBS) to occur before my secondary (Macrium REFLECT) FULL attempts its image... just to be safe ... so far, no issues at all.
I am running them 30 mins. apart, but I have a quick system (both destination drives are M.2 NVMe SSDs, so both MR and HBS make full backup in < 3 mins. and incremental < 1 min.). No space for any collision. What's your view on the third partition on my drive C, see my previous entry. Shall I include it into the system backup of HBS, or not? Hamlet's dilemma: to backup or not to backup...
That partition is the Windows Recovery Partition. It's not needed to run LIVE Windows but is definitely needed if you try and run any recommended Windows Recovery suggestions (from Windows or elsewhere). Many live without it... it can be a pain, though. It's usually located just after the OS partition. When Windows issues "upgrades" (H1, H2, etc.) it sometimes needs to edit that Recovery partition. When the edit exceeds the available space in that partition, Windows shrinks your OS partition by the amount needed to rebuild a brand new Recovery Partition, unregisters the existing Recovery Partition and registers the new one carved off the end of your OS partition. I don't know whether Windows is smart enough to use unused space at the end of a current Recovery Partition, usually, with many OEM Systems, they stick an out-of-box OEM recovery partition there so users can go back to the state they bought the System at. The results from this mess is as follows... the original Recovery partition is now orphaned, your OS partition is now smaller. The end result of all this is that your imaging applications now fail any existing specification that is being scheduled... why, because the geometry of the OS partition has changed and the original Recovery Partition (which was most likely included in any "System Image") has completely changed (it's now a different partition all together). This gets messy to fix. You usually need to redefine (edit) your existing definitions (Macrium specifically) and restart your image chain from a FULL (since all the chains geometry has changed). Having seen a lot of users having to deal with this issue, I have always recommended the following (if you wish to keep the Windows Recovery capability). Before any image chains have started, I have users use their favorite "partition tool" and shrink the OS partition by a coupla hundred mB (mine is a little over 1gB smaller when I did this at first), then extend the Recovery partition into that additional 1gB of space made available by the OS shrinkage. This will make the Recovery Partition large enough where Windows won't have to modify its size when it wants to make changes during Windows upgrades for quite some time. Generally, its changes are small but typically it runs out of Recovery partition space quite often when using its original Recovery Partition. This has always been my goto solution for these issues. With this modification, your imaging apps should remain stable, even after Windows Upgrades.
