A rather odd restriction on three posts per topic isn’t exactly useful to conduct a dialog to get to the bottom of things…
So as continuation of Error 60 on WIM File based restore here some add-on questions:
This issue is usually caused by bad metadata on the file that causes the failure. We know what causes the corruption but are looking for ways to detect it and warn.
Exactly what does that mean? Is the backup corrupted? Or is the restore process buggy? How can a valid, bootable Win10 setup which simply contains Windows Store installs and no user modifications, have corrupt metadata?
Do I have to throw away the backup, or wait for a bug fixed release of WinClone that can restore the backup?
If I have to throw away the backup, what incremental backup solutions do I have? It’s really not an option to create a hundred-plus-gigabyte block based backup, after every little change to the bootcamp partition, especially, since then I wouldn’t even have a fall-back backup known to work (with the incremental backups, I can go back in time until I hit one that still restores properly)
Given that this issue seems to have been around for a while now (November 2019!!!), what time frame exactly, if ever, can we expect a solution? What alternatives to WinClone do exist to make WORKING incremental backups of a bootcamp partition?
This situation is rather stress inducing as it stands.
file and disk corruption are difficult to detect and work around. My current thinking is to present a dialog box with a listing of the files that are corrupt, and you can fix them. I alternatively could have Winclone skip them as well. Any feedback would be helpful. At this point, since you know what files have issues, you can delete or back them up then remove and try again.
I understand how this is stress inducing and want to have a good solution to it.
Well, as the necessity for a second thread shows…
…it would have been meaningful to continue this in the original thread, rather than being forced to create a second thread by a three-posts-per-thread limit.
Well, anything is better than what I have now. The odd thing is: I seem to be arbitrarily able to recreate this situation: go back to before the latest feature upgrade, install all upgrades, upgrade WSL1 to WSL2, install Kali Linux, temporarily turn off virus protection (as Kali has penetration testing tools that would trigger them), install the full set of Kali tools from the command line, turn virus protection back on. Shut the system down, back up, try to restore => BOOM.
The worst part, the combination of VMWare Fusion, Big Sure and a Bootcamp partition, is somewhat fragile. Seemingly randomly, after a macOS update, Windows won’t boot anymore. Sometimes this can be fixed with making the boot camp partition with WinClone EFI bootable again. Sometimes that won’t work. And that’s when I try to restore from backup, and it fails. That’s the first indication that something is wrong, even though that WinClone with each incremental backup spends significant time checking the integrity of the backup database.
So anything during restore, that lists corrupt files, allows me to fix or even skip corrupt files is better than what I have now, as the corruption seems to be the result of some WSL2 incompatibility. One nice thing would be: when it’s all said and done, present the user with a list of all affected files, that one can copy/save somewhere, as would be a bit of PITA to manually keep notes of the individual files.
It’s easier to deinstall/reinstall some Linux packages, than retrying to recreate what happened in an ever longer time window since October 2020 (the last restorable backup)
What I don’t quite understand: The files are on a working installation. Windows doesn’t detect any issues. They are being backed up, WinClone doesn’t warn of corruption during backup. WinClone checks the integrity of the backup database with each incremental backup, and it doesn’t find an issue with it. Then I restore, after months of incremental backups, and dozens of backups, it throw errors, and I have to go back all the way to 19th October 2020 to find the last restorable backup. Isn’t there a way to do the same tests during backup as are done during restore? It’s not good to live in a false sense of security of having everything backed up, and then being utterly unable to restore said backup. That’s why at least a restore that lists and skips the corrupt files is urgent: that way at least the majority of the backup becomes accessible, the way it stands now, EVERYTHING is lost.
If you have a version that does any of the skipping of corrupt files for testing, I’d be willing to give it a try.
