[CRITICAL ISSUE / CRASH] Restore of Files and folders with foreign NTFS permissions causes high CPU load / takes very long time
ATIH 2016 b6023
Again I am facing a ridicilous problem with ATIH 2016.
I have tried this on several computers one with very powerful CPU (i7 2600, 4,6 GHz) and another with a weaker CPU (i3 3220T 2,8 GHz)
How to reproduce:
1. make a full backup of a computer
2. restore the user account c:\users\%username% from the tib file using data / folder based restore
3. restore the files on a computer that is using a different NTFS context (means you are not restoring the data on the same computer you made it from, thus you do not have permissions yet on the restored folder (by design)
4. choose to restore to an alternate location
both (source tib and restore destination folder are on the same local machine + on seperate physical disk, so we can exclude an overload of read /write capacity. Also tried this on SSDs.
ATIH 2016 will restore the data but needs a ludicrous amount of time for that task (estimating 2-4 hours!) as - reproducibly for me - several ATIH tasks / processes (refer screenshot) will cause a constant and very high CPU load (up to 100% on both systems) which will inflict the restore speed.
I admit I need to restore backup data based on folders very rarely so I did not noticed that yet in the BETA or in previous versions but this needs a correction. It is outstanstandingly wrong that an application blocks itself out by soaking up all CPU capacity for a "simple" restore action.
I assume that restoring the NTFS streams with the foreign permissions >might< cause this.
wow... and finally after 2 hours it crashed: nice job...
Name der fehlerhaften Anwendung: mms_mini.exe, Version: 12.0.0.29, Zeitstempel: 0x55ca0442
Name des fehlerhaften Moduls: MSVCR120.dll, Version: 12.0.21005.1, Zeitstempel: 0x524f7ce6
Ausnahmecode: 0xc0000409
Fehleroffset: 0x000a7666
ID des fehlerhaften Prozesses: 0x2034
Startzeit der fehlerhaften Anwendung: 0x01d13fd1beecc5f3
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Common Files\Acronis\Infrastructure\mms_mini.exe
Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\MSVCR120.dll
Berichtskennung: 1b352694-12d7-431c-b87c-2a053ac6315b
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Name der fehlerhaften Anwendung: TrueImage.exe, Version: 19.0.0.6027, Zeitstempel: 0x5656dc06
Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 10.0.10586.0, Zeitstempel: 0x5632da1c
Ausnahmecode: 0xe06d7363
Fehleroffset: 0x000bd8a8
ID des fehlerhaften Prozesses: 0x2360
Startzeit der fehlerhaften Anwendung: 0x01d13fd2f49a1775
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Acronis\TrueImageHome\TrueImage.exe
Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\KERNELBASE.dll
Berichtskennung: ee96640e-b30f-4e76-b6de-b31fb4ce4d0f
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Dienst "Acronis Managed Machine Service Mini" wurde unerwartet beendet. Dies ist bereits 2 Mal passiert.
I have tried to restore other parts of the backup (tib file) with same settings but this time I only tried to recover files from c:\program files (x86) which ATIH 2016 carried out clean and fast. So the problem, as I thought might be really caused when I am trying to restore files from a folder that use a foreign NTFS security description that are not existant on the system / drive that I restore the files on, so likely folders like user profile folders are affected because they have foreign permissions.
Because the same reason it is still not possible to restore / access user profile folders in the tib mounter or the explorer view for tib files as both do not offer write access to change permissions. refer: https://forum.acronis.com/de/node/93186
I ran the restore job of files another time. This time the problem existed with the high CPU load when restoring the user profile folder but at least after a long time of waiting the restore worked without a crash.
Hello, Karl.
Can you give me an idea of how large the directory you're restoring is? How many files and folderd does it contain and what's the average file size?
As far as I understand the OS where the issue is reproduced is Windows 10, is that correct?
Hi Karl,
If you have time to try, how long does the restore take using the offline recovery media to the same recovery location? I would imagine must faster and would be my recommended method to rule out any Windows and third party conflicts. I understand that ideally, it should be just as fast regardless if the restore is taking place within a full Windows OS running ATIH, or the offline ATIH recovery media, but I doubt that is the case. I can't offer a fix for the Windows slowness or issues you are experiencing, but maybe this would be an acceptable recovery option in your case since file/folder recoveries are limited and the time savings for using the offline recovery media would be beneficial?
Hello Dmitry, unfortunately I cannot answer all your question anymore as I don't have this particular backup. But I can try this with another set of data from a different computer and post and update about if this was reproducible again.
Hello Bobbo, I think that the Linux recovery would not be the good deal for this task, but to be honest I haven't double checked that. Of course you are right that Windows or anything else like AV might be blocking here and this might be different when restoring file / folder using the Linux medium.
As said I will try to repro this as soon I can find some spare time.
I've performed some tests on Windows 10, restoring a 1000000-files directory with and without non-existent SIDs.
The difference was not very significant: 12% vs 14% CPU utilization by TrueImageHomeService and 20% vs 24% overall CPU utilization.
Same with recovery time: 22 min. vs 24.5 min.
Thank you Dmitry for investigating this issue. What else could have caused such a behaviour? I have 2 backups from foreign computers and "User" folders, I will test the behaviour, too.
Hello Dmitry I tried the following things:
Restoring files of a backup containing only foreign NTFS permissions.
1. restoring via TIB explorer (not mounting):
Very fast restore times, about 8 minutes to restore / CPU load about 30% for ATIH managed machine service, overall CPU load 40%
2. restoring via ATIH / file based restore on alternative path
quite fast restore time, about 4 minutes to restore / CPU load was about 60% in summary for Acronis processes, hence overall CPU load was 70-100%
However I was not able to repro the massive issues I had back then, possibly there was also a Windows related issue in place. We have seen a few cumulative patches for Win 10 since then.
At the moment the only thing I can "complain" about is the considerably high overall CPU load compared to the TIB browser, for the benefit of a nearly half restore time.
Can you understand / explain the delta in the CPU load between the Acronis processes and overall CPU load the that is not visible in the taskmanager?
What do you think this issue now? Shall we investigate this further or close?
The good news I see is that the restore times are now okay, despite the CPU load.
