This weekend I helped my wife retrieve the data of her failing Android 10 mobile (in this case a Motorola Moto G8). The phone worked well for a long time (more than five years), but it has been very slow, and now (rather suddenly) the battery failed, which is making it crash a lot - usually not even booting up fully.

The phone has internal storage and one MicroSD card. Apart from not booting or running reliably, it seems the root file system has issues.

As with any device that has turned unreliable, we go for data recovery first - we don’t run any apps that could modify the file system and do further damage.

Maybe this procedure can be improved by using the recovery ROM or mounting more of the phone storage read-only, or doing something else entirely. If you know of a better way, please write me, I’d be happy to learn and improve this article.

We sought to copy over the internal storage as well as the SD card, mostly for the pictures and videos on the phone. Secondary/nice to have, we’ll also get applications and their data (“Full device backup”).

If we wouldn’t have been able to boot up the phone at all, we’d still be able to get the data from the MicroSD card by putting it in a card reader. And, but probably only with some serious fiddling, we’d also be able to get at the internal storage, but I am feeling lucky that wasn’t necessary here.

The procedure

1. We connected the phone to a charger and let it charge fully.
2. Next, with the charger connected, we boot it up, turning down the screen brightness and putting it into Airplane Mode as soon as we can. If you have multiple chargers around, use a strong one - it might need to support the phone by itself during the phone’s more power demanding phases of the boot process etc.
3. We connected the phone to a laptop via USB, set up the connection (“File Transfer” mode / MTP) and turn off the phone screen to keep the energy use down. The phone then pops up in Windows Explorer (or whatever you use) and you can copy the data. If this works for you and you get all the data that you’re looking for, you’re done now. Congratulations :)

However, step 3 didn’t work well for us. Most files where missing from the listing - we could only copy ~ 67 MB (of around 2 * 60 GB, so about 0,05 %). I attribute this to the phone file system errors, but that’s just a guess.

Next try: Some command line kung fu

1. We get and set up ADB, the Android Debug Bridge. Download and set up the Android Platform Tools and get it far enough that the phone shows up when you issue adb devices. This might require the “Tap the build number seven times” dance to enable USB debugging on the phone.
2. I explored the phone’s file system using commands like adb shell ls. With this method, I could see many more (I’d say: all) files. I tried getting the internal data via the adb pull command - like adb pull storage/7296-1A1B internal. This is also what I’d recommend trying first. That almost worked, but failed when the process encountered an unreadable file.
3. Use the (quite limited) tar on the phone to create an archive, pipe that to the laptop, and keep excluding files until the process runs to completion.

It took me a while to find a method that let us get the files with at least one file unreadable causing the adb pull process to abort. I like failing hard and early much better than letting errors go by unnoticed, but in this case, we were happy with having as much of the data as we could get, save a few broken files. It seems adb pull has no option to ignore errors/skip broken files. It might have that option! It seems there’s lots of deprecated/undocumented functionality in ADB, and I didn’t bother/think of reading into the source code. Next time!

ADB has multiple ways of executing programs on the phone: adb shell is documented, adb exec is referred to much on the web, adb exec-out seems to be what we want here. They might all be aliases, I didn’t check. What I did check was that the command actually created a valid TAR archive, and that was harder than I thought: adb exec-out combines STDOUT and STDERR into one stream, so we have to suppress the error stream output. Some people report it also adds carriage returns after newline characters on some systems?? For that, adding in a | gzip step might help (maybe with --fastest or -1 option to not waste time), but my setup didn’t require that.

I ended up with the following command. It gave me a valid archive the size of the data I wanted to retrieve, successfully ran to completion (with only one excluded file, lucky me) and even comes with a bit of a progress view through the tar -tf - command at the end, which looks like a nice-to-have, but was really useful for me as a tighter feedback loop to set up a pipeline that writes a valid TAR format data stream.

adb exec-out "tar -cf - --exclude=IMG_20230627_161716_527.jpg storage/7296-1A1B 2>/dev/null" | tee motog8-storage-internal.tar | tar -tf -

After that, we also did a full backup with the deprecated adb backup command for good measure:

adb backup -apk -shared -all -f full-backup.ab

Maybe this actually is able to restore most of Mariana’s data onto a new Android phone? We’ll see.