Troubles restoring ADB backups

Question

(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.

Answer 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.