I factory reset my rooted Android M phone but now I realize that there was a file in the /data directory which I need.

Is it possible to create an image (.img or something similar) of the /data partition so that I could run some recovery software for ext4 on that image? I have a little knowledge about ADB.


3 Answers 3


First to clarify root and data:

  • Root directory / of Android devices is a read-only pseudo (temporary) filesystem (rootfs) that lives in RAM and is vanished when device is powered off. When device is powered on, it's again extracted from initramfs that lives in boot partition along with kernel.

On newer devices with system-as-root, system partition is mounted at root /.

  • /data directory is a mountpoint, where largest partition, usually named userdata is mounted. This partition contains all user apps, their data (settings, databases, caches, temporary files etc.), system apps' data and all other configurations we make through Settings. /data/media/0 is the directory that we see as /sdcard or /storage/emulated/0 through emulation.

... there was a file in the /data directory which I need. Is it possible to create an image (.img or something similar) of the root directory ...

If a file is deleted from /data, you need to create a dump of data partition, not that of root directory.

You can do that in multiple ways described below. All require root access.

But first of all, see this answer to make sure your data is recoverable.

In short, recovery is more or less possible only if (1):

  • Your deleted data hasn't been TRIMmed or discarded.
  • And you haven't done a factory reset on encrypted /data partition.

What you should do immediately:

  • Switch off phone to make sure the deleted data isn't overwritten.
  • Don't install data recovery apps on device, it can do more harm than good.
  • Mount the filesystem (if required) in recovery mode (or on PC) only with ro,nodiscard options.


In order to access the userdata partition, you need to find its block device. If you have root access, you can do so from mounted partitions:

~# mount | grep 'on /data'
/dev/block/mmcblk0p... on /data type f2fs (rw,nosuid,nodev,...)

On Qualcomm devices, it's located at /dev/block/bootdevice/by-name/userdata (symlink). For MediaTek (MTK) and other SoCs, the path is slightly different. You can find all block devices or by-name directory using find command:

~# find /dev -type b
~# find /dev -type d -name 'by-name'

Or by hit and trial:

~# ls -d /dev/*/by-name
~# ls -d /dev/*/*/by-name
~# ls -d /dev/*/*/*/by-name



Once the block device is known, you can use the dd command from:

  • ADB shell (OS or custom recovery)
  • A terminal emulator app like Termux

Since the userdata partition is the largest partition (all other partitions are hardly using 5GB out of total storage), you can't dump it to your internal memory. An external SD card with larger capacity is needed.

To create the dump:

~# dd if=/dev/block/bootdevice/by-name/userdata of=/path/to/ext_sdcard/data.img

If you don't want to use an external SD card, you can also dump the partition directly to PC. First you need a working adb setup, running as root. Then it can be used in multiple ways:

~$ adb exec-out dd if=/dev/block/bootdevice/by-name/userdata > data.img

* Make sure your adb binary (on Windows or Linux) supports exec-out.

But you may end up with corrupted data when writing a whole large-sized partition to STDOUT of terminal because there are issues with line break types (CR and LF). Also STDOUT or STDERR from the programs involved could possibly be added to the file if not directed to /dev/null. Even a single wrong byte may render filesystems un-mountable. See this question for reference.

To avoid unwanted characters, use stty raw and/or dos2unix:

~$ adb shell 'stty raw && dd if=/dev/block/bootdevice/by-name/userdata' > data.img

But the most straightforward way is:

~$ adb pull /dev/block/bootdevice/by-name/userdata data.img

See this answer for more details.

To avoid the terminal-related complications described above or if for some reason adbd cannot be run as root, it's also possible to create a minimal TCP server for data transfer. Forward the port from phone to PC and run a netcat TCP server in listening mode:

~$ adb reverse tcp:1024 tcp:1024
~$ nc -v -l -p 1024 </dev/null | pv -ab >data.img

On phone:

~# cat /dev/block/bootdevice/by-name/userdata | busybox nc 1024

To avoid using ADB at all, USB tethering can be used to provide network connectivity:

~# cd /sys/class/android_usb/android0
~# echo -n 0 >enable
~# echo -n rndis,adb >functions
~# echo -n 1 >enable

* You may also change other files like {iSerial,iProduct,iManufacturer} and f_rndis/{ethaddr,manufacturer,wceis,rndis_transports,max_pkt_per_xfer} in the above directory if required. * On new devices you might need to use /config interfaces instead of /sys. Some relevant hints here.

Add IP address:

~# busybox ip rule add lookup main
~# busybox ip address add dev rndis0
~# busybox ip link set rndis0 up

On PC add IP manually (there's no DHCP server):

~$ sudo ip address add dev usb0
~$ nc -v -l -p 1024 </dev/null | pv -ab >data.img

On phone:

~# busybox nc 1024 </dev/block/bootdevice/by-name/userdata

In the same way it's also possible to use rclone rcat to transfer the dump over WebDAV or FTP or SFTP. See How to stream an encrypted backup of the entire device to remote host?

This method is useful if you don't want to create a dump of the partition, but instead access partition directly on PC. See my answer to Why can't I see Android storage as a partition on PC? for methods on how to enable UMS thorough /sys or /config interfaces.

Once done, userdata will appear as a partition on Linux PC just as we connect a USB drive. If /dev/sda is the hard disk drive, usually /dev/sdb will be the userdata partition. You can find that by using blkid command:

~# blkid | grep userdata
/dev/sdb: PARTLABEL="userdata" PARTUUID="..."

You can run recovery programs directly on the block device or mount the filesystem (if needed) or may also create a dump.


There are basically two ways to recover deleted data as mentioned in this answer: carving method and through the filesystem.

Recovery tools mostly don't need mounting filesystems but if it's required, it needs to be done on Linux PC because Windows doesn't support ext4 or f2fs natively, hence the tools aren't easily available AFAIK.

If anyone has been able to successfully make block/journal level access to Linux/Android filesystem for data recovery on Windows through Ext3Fsd or any other driver, let me know so that I can update the answer.

On Linux you can use tools like extundelete to recover data using filesystem journal:

~# extundelete --restore-all data.img

Or to recover data directly with UMS:

~# extundelete --restore-all /dev/sdb

Since you have done a factory reset which erases the filesystem, consider carving method using tools like TestDisk or scalpel:

~# testdisk data.img

In the same way you can use any other data recovery tools. See the ArchWiki on File Recovery for more details.


  • 1
    you just forgot to tell mount the fstype. use mount with -t ext4 -o loop,ro,noexec,noload and instead of adb exec-out you could just use adb pull /dev/block/bootdevice/by-name/userdata or adb pull /dev/block/dm-0 digital-forensics.sans.org/blog/2011/06/14/…
    – alecxs
    Commented Aug 12, 2019 at 17:55
  • @alecxs mentioning fstype isn't necessary; mount binary can guess a number of commonly used filesystems. No -t is actually -t auto. adb pull is worth-mentioning. Thanks for pointing out. Commented Aug 13, 2019 at 8:27
  • mount can not detect fstype for loop mounts, especially for dirty mounts (see link)
    – alecxs
    Commented Aug 13, 2019 at 9:47
  • @alecxs you must be right, though the link you mentioned is a bit outdated. But I never came across such situation that mount couldn't guess filesystem type including ext4, f2fs, ntfs and exfat, either from loop file or block device. busybox mount as well as toybox mount can detect filesystem type. Commented Aug 13, 2019 at 11:15
  • 1
    @alecxs no. EXT-undelete reads deleted or corrupted data information from the journal of Linux's EXT[N] filesystems. F2FS is not a journaling but log-structured filesystem i.e. roughly saying the whole filesystem is a journal. So the tools developed for one filesystem won't recognize the other at all except the common ioctl's etc. Commented Feb 16, 2020 at 2:20

Based on this question I did use the method described above:

~$ adb exec-out dd if=/dev/block/bootdevice/by-name/userdata > data.img

But there is an issue, the image will be encrypted if the data is not decrypted first. File and folder names will be gibberish.

The only way I got decrypted data was via TWRP, because it asks for decryption password on start.

And then I was able to copy the data via mtp.

I know this may not seem on topic on how to recover files, but this question is getting a lot of traffic and the proposed solution has a drawback and I'm not allowed to comment right now.

Edit: The original answer does how a way to access the decrypted information that I had not seen.

  • 1
    From my answer: “If your /data partition has Full Disk Encryption (FDE) you need to decrypt it...”. The same is applicable to File Based Encryption (FBE). // Also MTP is of no use when it comes to data recovery. Raw access is required to the filesystem or the underlying media. Commented Jul 13, 2022 at 7:05
  • You're right, I've updated my answer to reflect that part of your answer.
    – martinszy
    Commented Jul 13, 2022 at 20:52
  • 1
    copying files in TWRP is unrelated to data recovery - "dm-crypt decrypts the block device to /dev/block/dm-0. Use this instead of userdata" ... for recovery attempts with extundelete (from @IrfanLatif answer)
    – alecxs
    Commented Jul 13, 2022 at 23:15
  • 1
    Actually data recovery with FBE is far more complex than with FDE. With FDE, after decryption, you've the whole filesystem structure intact until it's not TRIMed or BLKDISCARDed. But with FBE the encryption key is also deleted with the deleted file. So along with the actual data, you also have to recover the key or recalculate it, which may or may not work. But to make it work, you surely need a dump of the whole userdata partition. After decrypting FBE in TWRP, you have access to only the intact files, not the deleted files and their deleted keys. So I'd say this answer is invalid. Commented Jul 14, 2022 at 8:11

Where exactly in DATA ? Is it in the emulated SD Card ?
If it's in the emulated SD Card, you could remove your external SD Card and mount the device under USB Mass Storage mode... You can the use free recovery software like Recuva ccleaner.com/recuva

However if your file is not in the emulated SD Card, you'd need to backup the Data partition as you mentioned.

To do that, you can either use the device itself to run a DD or CAT command to write the data to a .img file on your SD Card..

On Device
Using Terminal Emulator

  • locate your -by-name partition directory

    getprop ro.frp.pst

( This will get the /dev/block/platform/DEVICE/by-name directory for frp - change the name to data )
You can just use /data otherwise.

dd if=/data of=/sdcard/data.img   

If = Input file - Of = Output file

You could also use ADB

Via Computer

  • Install ADB ( not the entire SDK but just ADB )

Using command prompts or power shell

adb shell dd if=/data of=/sdcard/data.img

You may need to locate your correct directory.

Then you can Mount the .img on a PC and do the recovery.. I'm not sure how to mount the .img file if the partition is ext4 so that's as far as this answer goes.

You can alternatively use an App called Disk Digger .. It has the capability to scan the data partition live, .. Root Access is needed

  • if=/data won't work, it's just a mountpoint, not the block device. dd dumps files, not directories. Secondly, USB Mass Storage can also be used to mount or dump complete data partition from custom recovery directly to PC. Commented Feb 21, 2019 at 12:16
  • I'm sorry, I didn't realize you are using a Custom Recovery... That's extremely simple, just back it up ! .... I know if=/data won't work, that's why I said find the by-name directory. Commented Feb 24, 2019 at 22:02
  • I have a perception that nandroid backups (usually created by tarring) contain only files/directories, not the inode level details of block devices that's required to undelete something. Commented Feb 25, 2019 at 8:39
  • 1
    No don't use TAR, use DD or Cat to create the image. Commented Feb 25, 2019 at 8:58
  • you misunderstand the naming, dd does not work on directories only on files, by-name is a symlink to a file not a directory. on linux everything is a file. if= stands for input file
    – alecxs
    Commented Aug 12, 2019 at 17:46

You must log in to answer this question.

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