4

I know this might be duplicate but I couldn't find any relevant solution myself.

Today I tried to be adventurous and install Ubuntu Touch on my Nexus 7 and it was a failure. As a safety measure I backed up my device's data using the following command on a Windows 7 OS:

adb backup all -f ./nexus.ab -shared -apk

It took forever and created a 1.6GB file (sounds reasonable to me). But the thing is, when it was done even though the back up screen on my device was gone but the command didn't return in Windows and I had to press ctrl+c.

So I went through my adventure and in the process I had to unlock my bootloader and as a result all my data was wiped out (I read that it will happen and I was ok with it since I had already backed up my data). Once I was through with my adventure (and failed), I tried to restore my data using the following command (on the same machine as I created the back up):

adb restore ./nexus.ab

It takes for ages and after it is done, it prompts nothing (no success or failure). I can tell that it is done since the restore screen on device will be gone and the command will return in Windows. But when I turn on my device it's the same as it came out of the box. So is there any hope left? How can I make sure if my back up file is corrupted or everything is going fine? Do I need to do anything after my back up file is restored?

  • I'm having the same issue switching from OnePlus 3 to Oneplus 5. Reading logcat gives me Wrong header version: 5 Invalid restore data; aborting. – Saifur Rahman Mohsin Dec 2 '17 at 12:38
3

Try looking at the logcat output. I had a similar issue with multiple devices (all of the same manufacturer, though not yours) -- and it turned out they obviously had a bug in ADB implementation (logcat showed a parse error for the backup file).

If your situation is comparable (some ADB bug on your device's firmware), you can forget restoring that backup using ADB. Still, there are alternatives:

As you can read in the tag-wiki or our tag, there are other apps which can read and restore from ADB backups. Such as e.g. Titanium Backup. I'm not sure if this feature is reserved for the Pro version, but it's at least worth a try with the free one. And even if, this app is worth buying. Note, however, that your device must be rooted for this.

Copy your nexus.ab to the SDCard of your Nexus (I know it has no microSD slot, but the internal SD should do). Then use TiBu to restore from that backup file. You might not be able to restore everything (I never tried, so I'm not sure how far it goes) -- but at least your apps and their data should be able to get restored.

A second way (to be used for the remaining things) is to manually unpack the backup archive. Details can be found here:

You might also wish to consult other questions tagged "adb+backup" for additional information.

  • Thanks but where can I find logcat? There's no such file created by my nexus.ab file! – Mehran Jun 21 '13 at 15:18
  • That's not a file, but rather a command. Once your restore finishes unsuccessfully, run adb logcat and capture the output. See the logcat help page for more details, especially on parameters; adb logcat -v time might provide a better readable format ;) – Izzy Jun 21 '13 at 15:29
  • What if I'm not seeing any parse error while restoring? I believe the process is not broken and I'm missing something. These are the only errors I can see in logcat's output: W/InputDispatcher - Consumer closed input channel or an error occurred, W/DnsProxyListener - Error writing DNS result to client and W/SocketClient - write error (Broken pipe). To find these lines I searched for error keyword, unless the informative line does not mention this keyword I've got nothing. – Mehran Jun 22 '13 at 5:51
  • Seach for "backup"; AFAIR the error was thrown by backupservice. It has not necessarily to mention the word "error", as something like E/BackupService would already make that clear: the "E/" stands for "Error", while your "W/" stands for "Warning". I just remember it where two services involved, and one of them was some backup service. Best is to capture the entire logcat, and then search for all occurences of "backup" and investigate the lines around them. That's what I did, and how I found out in my case. – Izzy Jun 22 '13 at 11:07
  • As I suspected there's no such error in my log. I've even got D/BackupManagerService - Full restore pass complete and I/BackupManagerService - Full restore processing complete. Yet restore makes no change to my device. I managed to unpack the .ab file into a .tar file using android-backup-extractor project but it gave out an error while converting (something like ZipException: incorrect data check). It seems my backup image is not solid. I wonder why it doesn't say so while restoring!! – Mehran Jun 22 '13 at 13:13
1

Use adb logcat command to check system log for exceptions during the restore process. Try looking for BackupManagerService messages like these:

I/BackupManagerService(  716): Reusing existing agent instance
D/BackupManagerService(  716): Invoking agent to restore file fbreader.ui.xml
E/BackupManagerService(  716): Unknown tar entity type: 76
E/BackupManagerService(  716): Parse error in header: Unknown entity type 76
W/BackupManagerService(  716): io exception on restore socket read
W/BackupManagerService(  716): java.io.IOException: Unknown entity type 76
W/BackupManagerService(  716):  at com.android.server.BackupManagerService$PerformFullRestoreTask.readTarHeaders(BackupManagerService.java:4117)
W/BackupManagerService(  716):  at com.android.server.BackupManagerService$PerformFullRestoreTask.restoreOneFile(BackupManagerService.java:3406)
W/BackupManagerService(  716):  at com.android.server.BackupManagerService$PerformFullRestoreTask.run(BackupManagerService.java:3282)
W/BackupManagerService(  716):  at java.lang.Thread.run(Thread.java:841)
D/BackupManagerService(  716): Killing host process
I/BackupManagerService(  716): Full restore processing complete.
D/BackupManagerService(  716): Full restore pass complete.

In above example, you find a message E/BackupManagerService: Unknown entity type 76. It means that the .tar archive inside the .ab file was created with GNU version of the tar tool and used GNUTYPE_LONGNAME ('L') in a file's header.typeflag field, which is not understood by your Android's BackupManagerService. Using tar --format=posix should fix the problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.