I'm trying to back up my Nexus 7 before installing a new factory image. (There is an issue preventing OTA update from succeeding.) But when I run

adb backup -f android-nosystem-backup.ab -apk -shared -all -nosystem

the backup gets stuck after writing 2147483647 bytes. This number is 2^31 minus 1, and I recognize the problem as a lack of Large File Support somewhere. I'm running the adb that ships with my current Debian Linux distro "Jessie." The problem occurs whether I try to back up to a local file or to a remote NFS-mounted file server, so I suspect that something in the adb toolchain has been compiled without Large File Support.

The Nexus 7 reports total storage in use of 4.2GB, so I'm expecting a backup file on that order of size. Is there some workaround I should be using? Is there a way to split the backup into pieces?

  • I didn't try this, but as you speak of NFS I assume you're running Linux on your computer. Raw idea is making use of named pipes (aka "fifos", see e.g. mkfifo questions on SU). Basically, you create a fifo, and specify that as "file" to adb backup. In parallel, you run a second process reading from that fifo, e.g. Create a tar archive split into blocks of a maximum size. If you try this, please let us know how it worked out.
    – Izzy
    Feb 6, 2014 at 10:57
  • I am running Linux as it says in the question. I tried a non-NFS file system with the same problem. Dunno if the named pipe will help; I realized that other programs can do more than 2GB on the NFS file system, and that I've had problems with my own code and large files, which were solved by recompiling. Feb 6, 2014 at 13:30
  • In which case it wouldn't a restriction of the file system (as suggested by your original question). Thanks for the edit: I second your assumption of missing LFS support in the binary. To my knowledge, there is no option to split. But as using a pipe is different from writing a file, I'd say it's worth a try. Might as well turn out it doesn't work at all, as usually you redirect output/input when using pipes (which then act as a "buffer"), e.g. writerproc > mypipe and readerproc < mypipe.
    – Izzy
    Feb 6, 2014 at 14:48
  • I compiled GNU tar, which unlike android's normal tar, supports files over 2GB. My website's down at the moment, but I've got a armv7-a statically linked binary for 4.4 and higher (5.0, 5.1, 6.0, etc) here. You can put this somewhere where you can use chmod, like /data/local/tmp, and make a tarball that way and adb push it over.
    – Wyatt Ward
    Jun 14, 2016 at 14:15

1 Answer 1


It turns out this is a known issue and there is a patch.

You must log in to answer this question.

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