[Bug] restoring backups is incredibly slow in 8.1.3
Description I recently had to restore app data for some apps which were backed up with neobackup 8.1.3.
I'm running lineageos 19/Android 12 on an oneplus 8T.
For some reason, the restores are extremely slow. For example, restoring a 100MB backup took 59 minutes. Other restores didn't finish at all.
I could see in logcat that thousands oft toybox chmod and modified-date setting operations are taking place, each one for a single file.
Steps To Reproduce
1.restore app data 2. restore takes an extremely long time
Expected behavior Restore should not take one hour for a 100mb backup
Are the backups stored on an external storage (e.g. sd card, ftp server) or the device's one?
Are the backups stored on an external storage (e.g. sd card, ftp server) or the device's one?
On the devices internal storage
sounds like you are 6sing the api implementation of tar (we call it tarApi).
Default is using the tar command (tarCmd). The tar command should do all this in one go. It's the reason, why tarCmd exists.
So, did you disable restoreTarCmd in dev settings?
I know there once were reasons to disable tarCmd, but these should be history. Give it a try.
Another reason might be, that these backups are even older, then a compatibility mode might have stepped in. What is the backup version number in the *.properties file? or just append the corresponding file here.
sounds like you are 6sing the api implementation of tar (we call it tarApi).
Default is using the tar command (tarCmd). The tar command should do all this in one go. It's the reason, why tarCmd exists.
So, did you disable restoreTarCmd in dev settings?
I did not. It happens on a fresh install of NeoBackup.
I know there once were reasons to disable tarCmd, but these should be history. Give it a try.
Another reason might be, that these backups are even older, then a compatibility mode might have stepped in. What is the backup version number in the *.properties file? or just append the corresponding file here.
Not particularly old. Most of the backups are from february this year.
Example properties file:
{"backupDate":"2021-10-29T13:56:29.368","hasApk":true,"hasAppData":true,"hasDevicesProtectedData":true,"hasExternalData":true,"hasObbData":false,"hasMediaData":false,"iv":[-22,44,-45,-117,-84,24,-5,-25,-49,32,-3,-20,-112,-128,-69,-60],"cpuArch":"arm64-v8a","packageName":"com.intsig.camscanner","packageLabel":"CamScanner","versionName":"5.53.0.20210907","versionCode":55302,"profileId":0,"sourceDir":"/data/app/~~xQHyvA75jcJCUsBjU4UEtw\u003d\u003d/com.intsig.camscanner-d5FxjKw9DrCHEcE20SeIxw\u003d\u003d/base.apk","splitSourceDirs":["/data/app/~~xQHyvA75jcJCUsBjU4UEtw\u003d\u003d/com.intsig.camscanner-d5FxjKw9DrCHEcE20SeIxw\u003d\u003d/split_config.arm64_v8a.apk"],"isSystem":false}
at least the backup for this file is from 2021-10-29, as noted in backupDate.
Old is relative :-)
There is no backupVersionCode (added 2022-03-28), which means, it's read in compatibility mode, because the old format wasn't 100% tar compatible.
If the restored app works, I suggest to create a backup with the current NB.
You could use the OAndBackupX from that time, but I think it is as slow as the compatibility mode (or even slower, because other parts were also improved since then)