2

(Android 7.0, Shield Tablet)
I found myself in the situation of having to back up my data without root multiple times, and till now everything went pretty well.
Regarding apps and relative data (on data/data), I use Helium which performs a per-app adb backup with apk, similar to what Adebar does, then I restore them individually using the adb restore command (restore through Helium never worked for me).
This worked flawlessly till now.
I regularly backed up my apps, and respective .adb files of believable size were created, then, after a data wipe, i proceeded to restore my backups, but I found out they weren't restoring right. Here's the adb restore log, received trough adb logcat -s BackupManagerService:

    07-17 19:14:39.562   759  2184 I BackupManagerService: Beginning full restore...
    07-17 19:14:39.604   759  2184 D BackupManagerService: Starting restore confirmation UI, token=761002928
    07-17 19:14:39.620   759  2184 D BackupManagerService: Waiting for full restore completion...
    07-17 19:14:41.125   759  3508 D BackupManagerService: acknowledgeFullBackupOrRestore : token=761002928 allow=true
    07-17 19:14:41.127   759 16894 I BackupManagerService: --- Performing full-dataset restore ---
    07-17 19:14:41.142   759 16894 I BackupManagerService: Package org.fdroid.fdroid not installed; requiring apk in dataset
    07-17 19:14:41.144   759 16894 D BackupManagerService: APK file; installing
    07-17 19:14:41.144   759 16894 D BackupManagerService: Installing from backup: org.fdroid.fdroid
    07-17 19:14:41.968   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.968   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.969   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.969   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.969   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.969   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.969   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.969   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.970   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.970   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.971   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.971   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.971   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.972   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.972   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.973   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:41.976   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:42.548   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:42.548   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:42.548   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:42.549   759 16894 D BackupManagerService: [discarding file content]
    07-17 19:14:42.549   759 16894 W BackupManagerService: Saw type=0 in tar header block, info=FileMetadata{null,0,null:,0}
    07-17 19:14:42.550   759  2184 I BackupManagerService: Full restore processing complete.
    07-17 19:14:42.551   759 16894 D BackupManagerService: Full restore pass complete.

Here I tried to restore the FDroid app, for example, and I see a lot of weird [discarding file content] messages. So, I tried to restore them with Titanium Backup, but it showed me this empty screen: [![Titanium backup adb restore screen][1]][1]

I tried to export an .adb file to a tar file too, using this tool, but all I got was a META-INF folder with a MANIFEST.MF file.

Are my adb backups irreversibly corrupted?

Edit: I perfectly know that I shouldn't rely on non-root backup systems, but I unexpectedly lost root privileges after the infamous SuperSu v2.80 update, and I ended up with a corrupted boot image, so this was all I could do. I completed successfully the same process other times before, before deciding to root my device.

1 Answer 1

1

Can you try running a command as follows:

dd if=<your-file>.ab bs=24 skip=1 | pigz -d | tar -tvf - > file-list.txt

For example, this is the output:

dd if=backup-2018-10-19-2.ab bs=24 skip=1 | pigz -d | tar -tvf - > backup-file.ab.list

The output might look like:

56606374+1 records in
56606374+1 records out
1358552980 bytes (1.4 GB, 1.3 GiB) copied, 74.4385 s, 18.3 MB/s

But if you also see:

pigz: skipping: <stdin>: corrupted -- incomplete deflate data
pigz: abort: internal threads error
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

... then there's a good chance your ab file is corrupted. Maybe the backup didn't complete fully, or the disk was bad, or something else bad happened.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .