Version 3.6 (05July2023) has been released. It looks like an amalgamation of all the li'l issues that have occurred over the last 2-mo. Change Logs Version 3.6 (7/5/2023) Command line interface support Fixed compatibility issues with VPNs like Windscribe Fixed bug: Fixed some issues that caused file backups to fail Fixed bug: UI crashes when deleting operation logs Bulgarian language support Fixed some bugs to improve product quality
When this program does a System backup, it omitts the Windows recovery partition, should not that one be included for safety? I have learnt that, here actually, that the best practice is to include that partition when backing up for safety reasons.
When doing the initial System Backup, the single RECOVERY PARTITION is always selected. The only time I've ever seen what you describe is when a System has applied a MicroSloth (M$) update which required the making of a new RECOVERY PARTITION. When this happens, M$ shrinks your OS partition and creates a new RECOVERY PARTITION with the freed space and registers that as such within your System. At that point the old RECOVERY PARTITION becomes abandoned by the OS but remains on your System, useless at this point. Since Hasleo can't figure out which one is the real RECOVERY PARTITION, it selects neither when doing a System Backup. You can fix this by deleting the inactive RECOVERY PARTITION... but be careful and make sure you select the right one. In almost all cases, the currently active RECOVERY PARTITION (if the above process occurred) will be the one that is located right after your OS partition. There is a way, using your LIVE OS, to determine which one is the real one... but it's not at the top of my head at the moment.
If you open a Command Prompt window as an administrator, you can use the reagentc /info command to see where Windows thinks your Recovery partition really is. It will list a harddisk# and a partition# in its location information. Since many non-M$ programs list the hard disk #s differently, it's safe to assume that the partition# indicated is on the same disk as your OS partition is... and those partitions may be safely counted, starting at 1, from left to right in their positioning. Pls DO NOT ASSUME that your OS resident disk is Disk0. It can be anywhere depending on where it's connected to your System (SATA vs NvME vs PCIe, etc.). Hope this helps...
I thought i remembered correctly that this has happened before, but probably not. I tried it on a Os without RBRX installed, and then it backed the mentioned partition up. Back to the main question, is it not safer to also back up that partition with regard to, well, malware?
Coupla things... I don't know RBrx's current implementation with UEFI Systems so I wouldn't count on any Backup Suite returning it to normal when an image is restored... unless it's been deactivated and/or uninstalled AND reBOOTed before the image is taken. The RECOVERY environment doesn't keep Windows from running, it just provides various options when trying to troubleshoot a Windows System. Many users who use imaging don't even capture the RE environment. That said, when Windows does its semi-annual update (ie, 21H1 to 21H2 for example), it will most likely create a new RECOVERY partition in the process, especially if it doesn't find one large enough to contain the new changes. Is it important... up to your perspective. I don't know how MalWare would make this partition any more important that a BOOTable OS set... and DATA partitions are even more important. I always image the RE partition (haven't used it in over 10-yrs), but I also dump the neutered RE partition after the Windows update if a new one was created in the process... just a waste of space.
And another thing ... the Windows process mentioned above (new RE partition) always changes your disk geometry, which imaging Systems find very important. Most go slightly ballistic when known partitions change as far as any automatic schedules are concerned... new FULL images are usually required when those changes occur.
Ok. I always back up the recovery partition so it is the actual one and correct one in relation to the rest of the partitions. I have an extended one, 1.5gb. The thing is, the backing up and restore takes more time with that partition existing, and with using IFW, i suppose i need it for use with the automatic Reboot option. So the 2 concerns with it are, necessity for the backup program and potential malware infection from downloaded and installed program. If i could do without it and still use the mentioned IFW option, i would be glad. Regarding RBrx, it was just a test with HBS and went well with a deactivated RBrx. HBS is really fast and straightforward. Thanks for straightening some things out and, your time.
Thanks @TheRollbackFrog for alerting us to the new Hasleo Backup Suite v3.6 and posting up some of the Change Log! I'll have to remake a USB Emergency UFD again and expect everything will be smooth as to do with that. The other 'fixes' is another quality control that i'm very happy to see them continue with on this product.
Since December, I have used both the produced ISO (USB) and the BOOT.wim contained in the ISO as a BCD BOOT menu item... both have successfully EXITed (using the CLOSE button) from their running state after a few seconds. v3.6, in both forms mentioned above, doesn't ever EXIT... it remains at a BLACK screen with the mouse pointer visible. A HARD machine ShutDown seems to be the only way past this state.
Why is it that this program when adding the boot menu, adds about 1.4gb when MR and IFW only adds about 700mb?
It's not clear what you're looking at to determine that size. I think Hasleo needs to download the WADK from M$ to build the basic WIM it uses, then adds the HBS application software to that WIM. The WIM on my System is about 527mB and the ISO, when created is about 60mB more. When that entry is added to your BCD, it's only a pointer entry to a copy of the WIM included with Hasleo's created ISO ( C:\Program Files\Hasleo\Hasleo Backup Suite\bin\winpe.iso). Between the ISO creation and the extracted WIM from that ISO, you're going to see at least about 1.2gB if not more (and it may be dragging some stuff out of your OS and/or WinRE to add to the whole mix). I'm just not sure what you're looking at...
Anytime a vendor builds a BOOTable media, they make a call whether to use the System's existing WinRE (used in the troubleshooting and maintenance of the System), which is usually a bit larger, or build their own WinPE utilizing MicroSloth's pre-Installation package (WADK). There are advantages and disadvantages for both depending on what you want your outcome to be. WinREs are a bit bloated as they tend to contain almost all the drivers that exist on that Windows System when it was built... WinPEs are paired down and pretty lean. I'm not sure what Hasleo uses in their ISO/WIM creations.
Interesting. Well, i am using the default option "all the way" in HBS to create a boot meny, meaning that i just click my way through to get it done. I do not add anything or download anything by myself.. The program gets to do its thing just as with MR and IFW, hence my facts about size. So i wonder, why so much more and what does it contain? Or even better, is it actually nedeed when others does it much less.
Others don't really do it for much less. MR, by DEFAULT, uses the System's WinRE.wim to build its BOOT/Recovery media. That WIM resource is built when the System was built or possibly when a major OS upgrade occurs (ie, 21H1 to 21H2, etc.). MR has options to create a WinPE instead, but to do this it needs to download the MicroSloth pre-installation kit, then build the appropriate WIM. I believe IFW also uses the WinRE by DEFAULT but don't quote me on that. So MR and IFW (an assumption on my part, @Brian_K can jump in and add more, if necessary) , by DEFAULT (what you seem to use), will not add a new WIM BOOT media, they will just add their appropriate app and controls to the current WinRE BOOT media and use that. Other apps may build their own WinPE BOOT media to keep it smaller than most. I'm sure if you deleted the HBS' ISO (almost 600mB) and any WADK components laying around in the HBS area, the created BOOT media (in C:\BOOT) will still be available for BOOT Menu use, but if you ever want to rebuild that media, HBS will have to get the components to do it once again, adding some additional size to your disk. There's really nothing more that HBS needs to create its BOOT media except the "building system" and it's own application... basically the same as all other apps that may need a BOOT media. There's nothing special about the HBS BOOT media (BOOT menu linked to WIM or an ISO <UFD or CD/DVD>).
I've been watching this thread for a while. Would you rate Hasleo Backup Suite as a reliable system image backup application, @TheRollbackFrog ?
Nevertheless, on the same Os without any backup program, the difference is as i mentioned before between the 3 when installing and uninstalling as a test. So there is a big difference between HBS and the other 2. I do not delete any ISO or anything else that these programs create for the boot menu, i just create it and leave everything as is. But still, there is this difference. I see how much the Os increase and it increases that much with HBS. But that is an idè to satisfy my wanting, i can delete the ISO. But that is all can do to shrink the boot menu installation HBS do, or?
@Hadron - I've reached a reliability level with this product that has allowed me to continue extensive testing of this app as my main secondary app, replacing IFW temporarily in this role. All the main bugs discovered along the way, in the imaging area, have been safely addressed. My testing has mainly been in the imaging and restoration areas... I have not gone into cloning yet (I've never considered that capability as important). An occasional anomaly may show up when a version release is made, but it has never affected the imaging/restoration areas in a long time. When the anomalies have been discovered, the HBS Devs have been very responsive in their actions to remediate these issues. With Macrium REFLECT being my primary imaging app, I have used REFLECT images to restore Hasleo testings as well as using Hasleo images to restore REFLECT testings as well... all has worked seamlessly, for me, to date. To get some general GFS (Grandfather, Father, Son) type of scheduling, I have been using Powershell and the CLI (Command Line Interface) capability of HBS to do this somewhat successfully. The Devs have plans to improve their scheduling capability in their product roadmap. For a FREE imaging application which includes Full, Diff & Inc images, rudimentary scheduling, rudimentary CLI capability, BOOT menu & Recovery Media capability... I think it's an excellent choice for a piece of FREE software.
Well, I just ran a test on my Test Laptop and the following was observed... I cut off the network and allowed a freshly installed HBS to add a BOOT menu. It does not download a WinPE building environment, it uses the current System's WinRE to build it's BOOT media. It creates only a WinPE.iso in the folder described above, then extracts the BOOT.wim from that ISO, renames it and places it in the C:\BOOT folder for use with the Windows BOOT menu... that's it. No other files, just some BCD directives to enable the BOOT menu addition. The laptop test produces an increase of about 1.1gB in space for the two files mentioned above. My guess at this point is that your WinRE, created by your most recent System upgrade, is pretty large (possibly due to complex System configuration). If that's the case, then you will see a sizable increase (maybe that 1.7gB) in storage usage by Hasleo due to the dual image creation (ISO and WIM). If you delete the ISO mentioned above, you should get a little over half that storage back... you can't touch the WIM in the C:\Boot folder... it's required for the BOOT menu configuration to be successful. But remember, you'll recreate the ISO once again if you update your BOOT menu use of the WIM or create a new Recovery Media.
The recovery partition is c:a 1.6gb. Complex system, hmm, i think it is simple, the most complex about it is that it is stripped down with the help of NTLite and some other more "normal" cleaning programs. Besides this, nearly nothing installed. The setting is also normal, blocking or inactivation of a lot of phoning home and unecessary services in the Settings panel. The restore point function is removed with NTLite. But the rest of the backup/restore function is intact. So the ISO i can remove is in C:\ Program Files... . But fact remains, MR and IFW creates a smaller boot menu then HBS with the same recovery partition in use on the same Os. So, why, hmm?
I just learned by experience that it was the C:\boot that could be removed - he. With this removal fact i am good, but i still wonder why HBS file is larger. The simplicity and speed of this program is just... beautiful.
As I mentioned above, the BOOT Mgr calls the EFI partition for BOOTing the System (UEFI), and that process points to a WIM in C:\boot for the Hasleo BOOT menu item. If that's the WIM you removed, are you sure your Hasleo BOOT menu item still works?
Sure! First i removed it within C:\Program files... , then HBS had to create a new one when initiating a restore. Second try i let that one alone and removed the C:\boot, then the program rebooted directly instead of stopping for a creation and the restore went fine. In both cases i fresh installed HBS after making sure that nothing of HBS existed on the Pc.
Thanks for that, Frog. I also have Reflect as my main image backup app and IFW as secondary. I also use Drive Snapshot. I guess that's why I haven't bothered testing this one. But judging by others, it seems like it's going to be a good, reliable option.
@Hadron- Like you i been an avid backup/restore as an alternative with Drive Snapshot as well. However since now 1 year running Aomei Backupper is my MAIN Go-To and it has not errored or failed once so i'm all the way onboard with that one as my Primary. That said you really (when you have time) experiment with Hasleo Backup Suite yourself. Heck, The Frog has done most the heavy lifting for EVERONE in testing, reporting to the vendor issues and the development team is been advancing great fixes etc. HBS is my new Number 2 behind Aomei Backupper and actually HBS is far and away faster in my comparison tests, so i always begin with my Primary then switch up to HBS as a now notable secondary which it has even pulled my bacon out the fire once on my Windows 10. On Windows 8.1 Hasleo is super efficient and error free- Give it a spin when ready. You won't be disappointed.
