Neo-Backup icon indicating copy to clipboard operation
Neo-Backup copied to clipboard

[Bug] restoring backups is incredibly slow in 8.1.3

Open Yannik opened this issue 3 years ago • 5 comments

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

Yannik avatar Oct 22 '22 23:10 Yannik

Are the backups stored on an external storage (e.g. sd card, ftp server) or the device's one?

machiav3lli avatar Nov 25 '22 12:11 machiav3lli

Are the backups stored on an external storage (e.g. sd card, ftp server) or the device's one?

On the devices internal storage

Yannik avatar Nov 25 '22 13:11 Yannik

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.

hg42 avatar Nov 26 '22 11:11 hg42

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}

Yannik avatar Nov 26 '22 14:11 Yannik

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)

hg42 avatar Nov 26 '22 23:11 hg42