From a LIVE Windows session, you can initiate a System/Partition/File restore to anywhere on your System and it will occur. If that task is to a LOCKED partition (the OS partition is always locked), Hasleo will build a Rescue Media WIM image (if it doesn't already exist), place it in a folder called "boot" on the OS partition, set up a 1-time reBOOT, using the System's BOOTmgr, to use that Rescue Media WIM image to do your restore request. When complete, it has you finish and reBOOT back into the restored System just performed. This is all done automatically for you (not quite unattended, though). When finished, you are now running under your recently restored System image without any effect on your System's previous BOOT configuration. PS- you should always create a Hasleo Emergency Device just so you can do the same operation, if necessary, if that OS disk fails and you have to replace it.... but you don't have to use it unless necessary.
No Actually, without knowing what their imaging format is, we couldn't begin to guess. If it's proprietary, they may have found it easier to extract the FileSystem and present it the way they did, rather than convert it to a mountable dataset that Windows can deal with. It may just be an implementation issue...
I always liked proprietary. It's not far from being equal or just as effective or maybe even better in some respects (depending on the company-and the FORMULI) Oh sometimes they miss the mark. I have used a defragger with a "proprietary" in-house designed driver or other that does what should be done more effectively than default sorting of file segments etc I am of the mind that (and it has been many years now) Paragon use to use (maybe still does) a "proprietary" form of VSS backup that a user could select and go that route or select Windows default one. Not saying that it's good for that particular option of exploring a Hasleo image file but seems to me that it's a bit different. As long as it works as expected i suppose there's no more worse for wear. Nothing else can be done about it except approach them with a Feature Request on that.
Hasleo Backup Suite 3.0.2 Released (December 9, 2022) Website Support Forum Changelogs - Changelog for 3.0.2 not available - Download https://www.easyuefi.com/backup-software/downloads/Hasleo_Backup_Suite_Free.exe
DANGER, Will Robinson!! Until I hear otherwise, pls be careful with this software... especially as far as restorations are concerned. Since you can't pick a time point to restore to, the restoration continues normally, without notice of any kind, EVEN WITH A BROKEN BACKUP CHAIN, and finishes without error. The problem is... you have no idea of the status of the restoration, no indication what so ever. I would assume the status would be up to the broken point in the chain... but you just don't know, especially if you didn't know the chain was broken (missing DIFF/INC, etc.) to begin with. I performed this type of backup and the System seemed error free when I was done, but I just don't know what they did. Be very careful until I hear more from their Devs.
TRF, I had slightly different issues, but worse. Hasleo was installed into Win11. A full and 3 incrementals were created of the Win11 partition. No other partitions were imaged. V1 was the full image. Booted into the UFD recovery disk. Another 3 incrementals were created. V5, 6, 7. Booted into Windows and another incremental was created. V8. V4 was deleted in Windows. Deleted as a test. Booted into the UFD recovery disk. Restore icon on left, Browse image to restore, selected V8. Failed. The data is invalid. That sounds reasonable. Selected V3 (the chain should be OK above V4). It said the restore was successful. But BSOD on booting, 0xc0000034 It's a BCD error and I couldn't fix it. Booted into the UFD recovery disk. Restore icon on left, Browse image to restore, selected V2. It said the restore was successful. But BSOD on booting, 0xc0000034 I'm giving up. Trying to restore V8 with a missing incremental seems terminal.
Brian, thanx for playing... I need all the help I can get I don't know whether HBS is certified for Win11 yet... FYI. I'll try your exact test on Win10 in the morning...
Today i have a different system up without Hasleo. I'm going to want to do restore since i've made a chain of 3 'incrementals' after a full disk. That said i'm testing on Windows 8.1 strictly during this trial of Hasleo. I could do Windows 10 (probably should since i can roll it back) but that might take even more time since i haven't installed to 10 yet. The restore attempt. Was that made with the newest release @mood posted about above? What will pan on this end is intention to do the restore along with the chain of 'inks' and UFD Boot PE and examine what transpires on this end soon as i can.
Similar Brian testing under W10 produced similar results... again, be careful since we're testing with broken backup chains. I also discovered that when I put "Humpty" (broken backup chain) back together and tried an up to date Hasleo restoration, changes I had put in my last INC (INC-5) did not get returned to the System... it only returned changes up to the last-1 INC. This is very troubling and needs to be investigated further. The original chain break was at INC-3 so no relation there... FYI... the failed restore while using the Rescue Media fractures the entire disk (when using a System restore rather than just a partition restore which, I think, Brian was using).
I had given up on Hasleo, but took a gamble on 3.0.2. The Emergency Disk setup still doesn't work for a USB flash drive (at least it detects the correct drive now) - throws up an error message that a System API was not called when it gets to the point of formatting the UFD. I suspect the problem is in the ED creation routine for UFDs - I was able to create a ED by creating an .iso file and burning it to a UFD using both Rufus and then BalenaEtcher. And Bitdefender continues to positively HATE this software - had to disable both the A-V and the Advanced Threat Defense to stop BD from quarantining the entire Hasleo folder. (At least before, it only attacked the main two .exe files.)
Although I was tempted to give it a try following the initial very good feedback I will hold off it for now due to recent observations. It apparently needs more time.
Well, the thing either works right as it should or it's a flop. Guess we'll see which way it takes. On this end the imaging is gone off without a single hitch including the UFD boot but i yet to test it's restore capability to determine if it sets in as expected or not.
OK, repeated most of what Brian did with very similar results... The (2) main problems here using a broken backup chain are, basically... 1. The 1st is generic... the application when doing a restore never checks the integrity (is the chain in tact <all pieces available>, are the pieces basically error free <at the disk level>, etc.) prior to starting the restoration (disk modification), not a good thing. Once the restoration is started, old partitions start to disappear (as expected) in preparation for the partition restoration (in Brian's case) then the broken chain is discovered and you get a DATA error and a request to call SUPPORT at a given number. I'm really not sure what support can do at this point due to Problem #2 to follow... 2. Sometime during the restoration, prior to the error above, the BCD is modified in some way that makes the DEFAULT OS Partition BOOT entry disappear. This is not good because even if any of Brian's attempts to restore that partition at a different backup chain point, without a BOOTmgr reference to the BOOT partition, the "maybe" properly restored OS partition would BOOT properly... it did not, the BCD remained fractured. Since both the image & restore only dealt with the OS partition ("C"), the EFI partition, which contains the BCD info for an UEFI System, should not have been touched... and if it was, since it's not in the image, will be basically unrecoverable. I recovered the EFI partition from my non-Hasleo test protection image and, indeed, the DEFAULT BOOT OS directive returned as expected, BUT... an attempt to BOOT into my Hasleo restored OS partition now requires some sort of Windows REPAIR operation. That tells me there is still something amiss in that Hasleo restored OS partition (that restore was done from a complete backup chain (piece missing was returned). Again, these are tests being done with purposeful errors in place to see how robust this imaging app really is when experiencing non-standard conditions (you know, the ones we all see along the way ). All my tests to date, with everything being done normally, have worked just fine. I will discuss these findings with the Hasleo Devs and see where it all goes... I think the app is definitely a good attempt at a fairly robust imaging System, it's just very young at the moment.
This is a known issue. Hasleo do not guarantee that the Windows operating system backed up using the disk backup function will start normally after being restored. In order to ensure that the restored Windows operating system can start normally, you have to use system backup to back up Windows operating system and restore all Windows-related partitions when restoring. Aomei and EaseUS seem to have the same problem, please refer to this link below: https://www.easyuefi.com/forums/showthread.php?tid=846&pid=3232#pid3232
I was still interested in a single partition image/restore. I made a full and 3 incremental images of the Win11 partition. No incremental images were deleted. I booted to the UFD and did a restore of incremental V4 to the Win11 partition. I was careful to choose the Win11 partition and not the disk. Despite seeing "All data on selected drive will be deleted", I proceeded. Win11 didn't boot and 12 partitions had been deleted from the disk. The only partition present was Win11. This should not happen.
I did a System Backup/Restore of a new V3. Only the first 4 partitions were selected for the restore. Again I saw "All data on selected drive will be deleted". But this time, Win11 booted and none of my other partitions had been deleted. The Disk/Partition Backup choice is dangerous. Very dangerous. That's what I used in the previous post.
Are you sure you chose Partition mode instead of Disk mode when restoring? The program will destroy all partitions on the destination disk when restoring in Disk mode. Please note that when you choose to restore using Partition mode, only the destination partition will have a yellow background, while when you choose to restore using Disk mode, the background of the entire disk will be yellow.
Disk mode restore means that all partitions that have been backed up are treated as a virtual disk, and then the virtual disk is restored to the destination disk, so that all partitions on the destination disk will be destroyed after the restore is complete. If you only need to restore one of the backed up partitions, you should choose Partition mode instead of Disk mode. After selecting the destination disk, you can view the partition layout of the destination disk on the disk layout page, where you can see what partitions are on the destination disk after the restore, as well as the location and size of these partitions, as shown in the following screenshot. https://www.easyuefi.com/backup-software/images/disk-partition-restore-adjust-partitions.png
I'm doing it again. I've made a full and 2 incrementals of the Win11 partition. Booting the UFD. Restore icon on the left. Browse image to restore. Chose v3.DBI Chose Partition mode (NOT Disk mode or File mode) On the next screen, only the Win11 partition is in Yellow. Tick in Restore to original location. On the Review screen, only the Win11 partition is in Yellow. Then a warning, "All data on the selected drive will be deleted". I used the same choices on my previous partition attempt. I did proceed and this time, no problems. Win11 booted and all partitions are present. I'm sure I made the same choices each time but I do have different results. I remember seeing the single yellow partition each time I did the restore today. I did choose Partition mode each time as I was restoring a partition image.
Please check the logs (Tools => View Logs) recorded by the program, maybe you were performing a disk restore operation.
