2

I need to hand in my old phone, but before I do, I want to be sure I am not going to lose any data, including app data.

I've tried the usual adb backup -apk -shared -all, however this produced a file that is a little under 9 GiB. The device capacity is 64 G and is almost full. Also, I made a backup about five months ago that is a much more plausible 45 GiB. Alas, I don't recall what command I used five months ago. (More specifically, I don't remember what arguments; I'm 99% certain it was some invocation of adb backup.)

What am I doing wrong? How can I back up "everything"? (I don't need e.g. OS stuff, but I definitely have more than 9 GiB of pictures, user-installed apps, and such.)

Matthew
  • 181
  • 6
  • First adb backup only includes private app data. What is stored inside /sdcard is not included. Additionally apps can limit or even totally deny backup. In such a case adb backup will miss some data or whole apps. Some apps may provide a app internal functionality to backup data. – Robert Dec 24 '20 at 21:03
  • @Robert, then how did I previously manage to create a 45 GiB backup? I don't have that many apps. Also, I'm aware of apps not allowing backup and am almost certain that's not the issue I'm having. – Matthew Dec 24 '20 at 21:10
  • 1
    @Robert that's not quite correct. The -shared parameter advises it to also include "shared data", i.e. SD card contents. // Matthew: apps can opt-out of backup, so with one monolitic file you never know what you get. Take a look at my tool Adebar, which a.o. creates a script to backup each app separately (so you see which fail) and optionally also shared storage (though that you could backup simpler by simply copying all its files). The script will already show which apps won't backup, just look inside once it is created. – Izzy Dec 24 '20 at 21:31
  • 1
    depending on how old the phone is it may exploitable. the adb backup arguments are easy to figure out. Be aware not all flags are fully implemented, behavior may differ from expectation. But if your previous backup.ab was +36 GB bigger that sounds more like lost connection. for pictures i recommend 'adb pull -a /sdcard' – alecxs Dec 24 '20 at 22:57
  • @alecxs, is there absolutely no error reporting if the connection is dropped? If that's the case, that may well be what happened... – Matthew Dec 25 '20 at 01:13
  • probably no error message. adb backup is very weak implemented (and most likely depreciated). at least for adb pull on latest platform-tools the progress -p flag is enabled by default – alecxs Dec 25 '20 at 02:13
  • @Izzy had to run while [ 1 ]; do adb shell input touchscreen tap 540 1330; done; in second terminal for Adebar, is that intended? – alecxs Dec 26 '20 at 11:42
  • 1
    @alecxs say what? And what for? This is the first time I hear something has to be run in a second terminal for Adebar to work. Where did you get that idea from, and what do those touch-events do? Wild guess: confirming the backups? If it's that, please check your config. Adebar can do that itself (not for all devices, but most). Take a look at things like AUTO_CONFIRM*; if your device requires a specific sequence, even that can be configured. – Izzy Dec 27 '20 at 01:49
  • @Izzy thx will check config – alecxs Dec 27 '20 at 08:55
  • @alecxs, well, after way too much effort spent figuring out how to decrypt a backup, I can confirm that what I'm getting does indeed seem to be truncated. Why it crapped out right in the middle of a file is a mystery; I've adb pulld the same file and it doesn't seem to be corrupt or anything... – Matthew Dec 27 '20 at 18:39
  • always leave the password blank for unencrypted backup.ab (it's just zlib deflate compressed tar in that case which can be extracted with only gzip one-liner) https://android.stackexchange.com/q/28481 – alecxs Dec 27 '20 at 18:45
  • 1
    @alecxs, I can't leave it blank. Because my phone is encrypted (seriously, why on Earth would you not encrypt a mobile device?!), I can't start a backup without providing a password. – Matthew Dec 27 '20 at 18:52
  • you can leave it blank. i am talking about not streaming encrypted backup.ab only (not about screen lock or disk encryption, which is completely unrelated). encrypted backup.ab is unrecoverable when just a single byte is missing, while unencrypted backup.ab still can be partially extracted in case it's broken – alecxs Dec 27 '20 at 19:02
  • of course it's user decision. but it makes data recovery far more easier. same for adoptable-storage MicroSD card, becomes unrecoverable when smartphone is broken (also main reason why i always prefer unencrypted device - broken ext4 partition can be repaired, but if decryption fails the whole partition is lost) – alecxs Dec 27 '20 at 19:45
  • 1
    @alecxs On (at least) Android 11 you can't leave it blank if your device is encrypted; the backup confirm screen says "Since your device is encrypted, you are required to encrypt your backup. Please enter a password below:", and the "Back up my data" button is greyed out until you do so. I don't know if it was like this on previous versions. If you have a workaround that would be great, though. Apparently Samsung phones (maybe all Android phones) are encrypted by default now. – pizzapants184 Mar 10 '22 at 02:40
  • @pizzapants184 "Since your device is encrypted, you are required to encrypt your backup" is indeed absolute unambiguous, got it :) – alecxs Mar 10 '22 at 07:28

0 Answers0