Hello All, I've just recently installed this software, and haven't had much experience with other backup software either. To test out the functionality, I thought I'd try backing up a [articular directory that contains photo's. The directory and all its subdirectories is about 350GB. I went through the process, selected the external USB drive and chose the compression setting for low. I started the backup and about 2 hrs int it, it said the backup failed. It said it was unable to read a file 0x01340072000001B1 I tried doing the backup again, and the same problem occurred. ANy help on this issue would be appreciated.
Hi @JK200SX Two things that may help. First, have you considered running a checkdisk on the drive you are trying to backup? Syntax would be chkdsk C: (or whatever your drive letter is) /f To do this, I would restart holding the left shift key then click restart, this will take you into recovery mode, then choose Troubleshoot, then Advanced then Command Prompt. It will reboot you to a command prompt window...this is where you would enter typically, chkdsk C: /f then enter to see if any problems are found and if so the /f switch may fix them. Second, are you working on a desktop machine? If so, is your USB device plugged into a front USB port? If so, try using a USB port on the rear of the PC and then run the backup again. Maybe one or both of these steps might help you. I looked up your error code, couldn't find that exact error code, but thought I would mention the above.
Thanks for that. I've done the CHKDSK as you mentioned and it came up with no errors. I've now plugged into one of the rear usb ports and doing the backup as I write this. I'll let you know how it goes in the morning.
I'm not so sure about this, especially when the target disk points to the original locations of the partitions. Both Macrium REFLECT and Hasleo's HBS do this flawlessly (with their System Images) when returning partitions to their original disk. They don't do it blindly, they check partition IDs as well as partition geometry before offering such a feature. Macrium REFLECT does this as well with non-System images (disk images, individual partition images, etc.). If you're careful with identifying partition IDs and disk/partition geometry... it should be a pretty safe operation (I've been doing it for years with REFLECT).
Well at the expense of my knowledge of backup/restore ability to date slipping away. Maybe i been under some wrong assumption regarding Full Disk imaging & restores. The mere mention in this context signified for me anyway that there exists some imminent danger but my results from total disk restores seem to contradict that assumption. I have also done many Image Restores without encountering a single failure. Now that being said i rarely if ever nit pick partition choices to image separately for a restore although i'm sure it wouldn't be an option in the better programs if it wasn't or hadn't been quality tested first. HBS might had been the exception at one point (along with others maybe) but their development with improvements, they have really come a good distance from where it started out. It's efficiency is on par if not exceeding that (for me) of my main backup Aomei Backupper. Neither has failed once on this end. Correct me if wrong but doesn't a System Only restore also serve to duplicate via it's imaged file as much as a Full Disk Image would?
I just use such utilities to backup an entire OS partition so I can restore back my OS to a particular time when everything was working and configured as I want. For backing up personal files, I suggest you try SyncBack Free, check my guide here: https://youtu.be/W7ElYO56rkk
Not exactly... HBS only has a DISK and PARTITIONs restore (no SYSTEM ONLY), but it has a SYSTEM and DISK/PARTITIONS imaging mode. The SYSTEM imaging mode only images the partitions on your System Disk required to successfully BOOT that System. If your System Disk has other partitions (DATA, multiboot OS, etc.), they are not included in the image. So when you restore that SYSTEM image, you have (2) choices with Hasleo... restore the System image as a disk or restore individual partitions as partitions. If you restore it as a disk, when it sees your image as a System Image it checks your target disk and if it's the same disk AND the partitions have the same original IDs and geometry, it restores all those partitions in a non-destruct mode in relation to the other partitions that may reside on that disk... a perfect example of restoring multiple partitions but not all on a disk in a very safe way. If the SYSTEM disk restoration saw that the target disk was different or that the multiple partitions in that System image were not the same on the target disk as exists in the image, it would not allow that restoration unless you selected otherwise. If you said do the restore, then the process would have to be disk-based and destructive of any other partitions existing on that target disk. The problem is that there's no reason to not allow this same process to occur when restoring an entire disk image... say your 10-partition disk image with only 4-partitions selected (your System required partitions for BOOTing). It's really not that dangerous if the above cautions are carefully acknowledged. There's really no difference between a SYSTEM image and a DISK image other than maybe the number of partitions included in the image. Macrium REFLECT has always allowed this type of restore (with all the same precautions)... Hasleo already respects those precautions for System Image restores so it can easily expand the product to do partial disk image restorations for entire disks.
Sorry to hear of the same result, @JK200SX Looking at your graphic, it appears the error comes right at the end of the backup, no estimated time remaining and it is when it is calculating the backup files and size, etc. Good news is it is not a USB port issue. The error code I still have not found that particular code in order to find what it is pointing to. "Failed to read the file"...I have no idea what file it would be, the backup file or a file you are trying to backup? My advice is the same as @pb1 Please email this same graphic to Hasleo support, email here , let them know exactly what you are doing, it is a file backup that fails at the end of the backup as pictured. Remember to let them know the usual about your system, Version of OS, device used, etc.
Thanks, I watched your video, and have a question. If you set up the mirror option, and then automate the step so that the program performs a mirror everynight, what happens if you accidently deleted a file from your primary location - would the program then delete the backup and you have then lost the file? This is a scenario I'm trying to avoid. How do you overcome this?
Just installed Hasleo as I wanted to get a backup plan NOW for my Insiders beta drive. Black Friday to wait for a Macrium sale seemed a little too far off so I'm going to use this in the interim. Watch, betcha I'll never need the image now. But heavens to Betsy, I do NOT want to go thru trying to undo a bad Windows update again anytime soon. Took 2 min 12 sec to restore the drive from my trusty external HDD in a test run.
You may wind up using it for good. It's not as feature rich as REFLECT but it does have plenty to offer.
Right, just as the name implies, mirror is mirror, so whatever is on the source, whether it is a new file you added or deleted, the same will happen to the destination. If you are trying to avoice such a situation, then you can shooe the sync profile rather than mirror. Sync will copy files to both locations but will not delete from the destination. There are 3 different types of backup: Backup, Synchornize, and Mirror. Please check the help file for a better understanding of this with illustrations: SynbackSE Help File Download: https://gofile.io/d/tPu9Tf
I need some help in regards to Hasleo and building a new WinPE emergency USB flash drive. I have had trouble whether it is creating a recovery USB flash drive or creating a winpe from a program like Hasleo. After creating any USB recovery or rescue USB drive, once the boot.wim is loaded, I immediately get a notice of an error. The following is an example of the screenshot I got: https://i.stack.imgur.com/K0Sz2.jpg It is the recovery blue screen, not a typical "blue screen" and it states it cannot load the operating system with this: File: \windows\system32\ntoskrnl.exe Error code:0xc000a004 I think this problem, according to the only place it was mentioned was at Terabyte Unlimited forum. They responded to a guy having the same error as I am that the boot problem was introduced on some systems going back to a June update that updated the Winre.wim in the windows WinRE recovery partition. Only place I found so far about this error has been the Terabyte Unlimited forum where someone had created a WinPE USB flash drive when they upgraded to 3.61 of IFW and then created a new TBWinRE boot drive and it failed to boot, exact same issue I am having using the Hasleo winpe emergency USB boot drive. Error code:0xc000a004 and asking me to perform a repair, but the offending file is in windows\system32\ntoskrnl.exe. Apparently there is some kind of conflict with that file it interrupts the USB drive from booting. Terabyte found the problem, stated it had to do with a June 2023 windows update, and they fixed the problem with their TBWinRE boot media with 3.61a. I want to mention, my WinRE recovery partition works fine, I can restart the PC with shift key held down plus clicking restart, and the system goes right into the WinRE recovery environment, no issues and all options appear to work fine. By the way, I am using Windows 10 Pro 22H2, GPT UEFI (non-CSM) no legacy booting, Secure Boot OFF. Only problem I have with any USB recovery winpe boot drive is with the WinRE based. Apparently others are having similar issues with the system repair disk or recovery USB drives as seen in this link from Microsoft. https://answers.microsoft.com/en-us...ror-code/8042c26c-1bdf-4bb9-a063-8b0fd456147c They say to create a system repair disk that you can use to reinstall windows, in other words include the system files when creating the recovery drive, not just a repair disk, that makes no sense, I do not need that and so I do not choose to include those files. I have an old WinRE recovery flash drive that still uses the WinRE.WIM file created in August of 2020. I haven't created a windows recovery boot flash drive since a few years. That boots fine, no problems, but after creating any new recovery USB drive since after June, or a program like Hasleo that uses the WinRE to build its emergency winPE, it fails to boot with the error above... What can I do...Terabyte says the June 2023 windows update only affected some machines, but they never said what they found was the issue. @Brian K or @TheRollbackFrog or anyone that can help me figure this out what changed in that June update to the Recovery WinRE.wim? Otherwise, I cannot use any recovery boot USB drives created after I am assuming that June Windows update and I can find nothing about it other than on Terabyte forum. I would appreciate any assistance, thank you!
There are discussions all over the boards (other products) about the failure of any Recovery Media that uses WinRE.wim. The problem appears to have started when KB5029331 was applied to the System. Apparently it made some changes to the resident WinRE.wim. When users uninstalled that KB, the System code was removed but the changes to WinRE.wim were not removed (pretty shabby on MicroSloth's part). As this is being worked on at MicroSloth, users that have complete backups are reverting their Windows Recovery Partitions only back prior to the application of the above mentioned KB... when this is done, things are well once again. The problem being, you need to get rid of the Hasleo's resident WIMs in the C:\boot folder and the one resident in the Hasleo C:\Program Files\Hasleo\Hasleo Backup Suite\bin folder as well. Once these are removed AND you've restored a Windows Recovery Partition earlier than the application of the troubled KB mentioned above, you should be able to successfully rebuild your Hasleo Emergency Disk. Otherwise, sit tight. I'm guessing (the operative word here is guessing) also (just to get things working), you should be able to restore the above mentioned WIMs from a backup that was made before the bad KB application. This way any new Emergency Media will use those WIMs to create the Emergency Disks. If those WIMs are missing, HBS will try and recreate and will fail if the bad Recovery Partition is used for the rebuild. ...and if you finally get a working Emergency Disk, keep it. You don't need to update the Emergency Disk (or the BOOT menu) everytime there's a Hasleo App change... old Recovery Media work just fine. Wait until you hear that "the Sloth" has finally fixed this issue (I'll probably hear it in a bunch of Forums, if I do I'll report it here).
--- That appears to be what I am seeing also TRF, and I really appreciate you chiming in to help! I have recently replaced the boot.wim of a newer recovery UFD that i figured one day I would create an updated Windows 10 recovery UFD only to find it failed to boot. So I replaced the boot.wim with an older version of WinRE.wim and renamed it to boot.wim and that recovery UFD worked fine. Apparently, MS is telling people to create a full recovery drive, including all the files needed to reinstall Windows, and I do not see that as a solution to their mistake and for me it is not necessary. Few people I think even use or bother with creating recovery media using recovery.exe, but no reason for MS to make excuses. As far as Hasleo goes, I'll sit tight, I have other imagers I use and their boot media is fine as it was created before that June update. I agree, this is I think shabby from MS to say nothing, that I am aware of, only now finding some people since late August reporting the WinRE UFD's are not booting, giving that same error as I mentioned referencing ntoskrnl.exe file, apparently missing or conflicting, etc. I did already delete the WinPE Hasleo boot wim file from its folder, do you think instead of allowing Hasleo to build its emergency disk from my WinRE partition, I should tick the box to "download winpe components"? Worth a try or likely to cause same boot error? Perhaps I should also mention this on the easy UEFI forum for Hasleo that their is a issue with their program creating emergency disk using the WinRE recovery partition since the June MS update that changed the WinRE.wim file? Again, thanks Froggie for keeping an eye out. I noticed Terabyte found the issue as I mentioned above, they said it was caused by that June update, but didn't state the exact problem they just did a quick update to fix the TBWinRE boot disk.
@Jim1cor13 - definitely worth a try. A WinPE-based (rather than WinRE-based) Emergency Disk should work just fine. WinRE has a lot of additional drivers (based on its resident System) that WinPE doesn't have... but it should BOOT just fine and worth a try in your System environment. The users in the Macrium REFLECT Forum have been doing just that and the results have been excellent. If you have some new and strange disk hardware on your System, the PE-based solution may not work, but it's worth a try to get HBS operational once again at the Recovery level. I have used WinPE-based Recovery Media on my System (full of NvME & SATA-III interfaces) and it's worked just fine... definitely worth a try.
Just for gigs (old people have time on their hands), I rebuilt my Emergency Media using the PE download files from MicroSloth and tested the media... all was fine as far as BOOTing, imaging & restoration were concerned. I do have that bad KB installed but, as I mentioned, I try and never use a WinRE.wim for any of my BOOTable needs, if possible. I tried the Hasleo created media with SATA III devices, M2.2280 NvME devices (mainboard-based) and M2.2280 NvME devices (PCIe-based) and all were handled properly by the WinPE-based Hasleo media, YMMV
Interesting, so the PE downloaded files worked fine, and the Hasleo using the WinRE to build their PE worked also? As far as I know, their emergency disk they use the WinRE based WIM file to build their rescue media. I'll try the downloaded PE files option in Hasleo to see if they work, otherwise, I guess I am one that their machines were affected. My recovery partition as mentioned works fine, shift+click restart I go right into the recovery environment no problems, I just cannot get a UFD recovery to boot when I create it, nor does the Hasleo emergency disk boot. I am using an Adata SU750 SSD on my machine. I never had any issues before with building rescue media on this machine until after June and the failed booting began. Weird, I wish I knew how to fix it. I'm thinking of assigning a drive letter to my recovery partition and copying the old WinRE.wim file into it to replace the weird one. Should work, i think.
I never built a Hasleo WinRE-based Rescue Media (as I mentioned)... I've always used WinPE WIMs when building any Rescue Media. Should work without issue.
Oh ok, I'm sorry. You only use actual WinPE components. So you are not using WinRE at all, only the option in Hasleo Emergency media "Download WinPE components" or something like that rather than allowing it to use WinRE, do I have it right? I think that is what they will use if you do not download the components, they use the WinRE.wim and add their program to it in a boot.wim. I wonder why they still call it WinPE? Going to try the download winpe components within Hasleo to see if that solves my issue. Do you have any idea what happened to the updated WinRE.wim in that June update causing created boot media to state it is missing ntoskrnl.exe error? I am assuming if I can restart with no problems into the RE recovery environment, at least i know my recovery partition is not botched up. As far as me restoring just the Recovery WinRE partition, I only go back to late June, after the WinRE partition WIM file was already updated. Silly me...but that would have been an easy fix for sure. I'll do the drive letter assignment, and get that older WinRE.WIM file back in there for now. I also checked reagentc /info and all is fine there. In any case, that file ( ntoskrnl.exe) is within the BOOT.WIM file, ( \windows\system32\ntoskrnl.exe) not sure how it can be missing but perhaps it is corrupt from the update. If it is not finding it, makes no sense. Such an important function to be able to boot outside of windows, and they botch it apparently. All my older boot media works great, using the older boot.wim file. As I said, MS is telling people to create full recovery reinstallation boot media, not just the recovery - repair media. I have no idea if even that would work. Ok, I'm just rambling now. I am going to try the Hasleo option to download PE components...hope it works. I really appreciate your help froggie!
You do... I had a "discussion" with their Devs on this... the WinRE is really a locally modified (by Windows) version of WinPE so they see the WinRE as WinPE-based and they feel correct in calling it a WinPE. A little different than the rest of the world but somewhat correct . Not a clue and I just don't have time to dig for it... You should be fine... Wish I could do more...
