Is this the right way to use dd for a full backup?

Question

Sadly my device (sm-g3185) isn't supported by either CWM or NANDbackup, so I am trying to do a backup manually. I found this thread which tells me to open a terminal (I'm on Arch Linux) and run:

adb forward tcp:5555 tcp:5555
adb shell
su
/system/xbin/busybox nc -l -p 5555 -e /system/xbin/busybox dd if=/dev/block/mmcblk0

And then open another terminal and run:

adb forward tcp:5555 tcp:5555
cd /path/to/store/the/backup
nc 127.0.0.1 5555 | pv -i 0.5 > mmcblk0.raw

I did all this and it seems to be working. However, there was a delay of a few seconds between launching the dd command in terminal1 and the nc command in terminal2.

Can I trust the backup I created in this way? Doesn't this mean that I've lost some of the output of dd? Shouldn't these be run concurrently or, at least, shouldn't the nc command be started before the dd one?

Answer 1

Can I trust the backup I created in this way?

Yes, of course! This is the most accurate backup method.

Data integrity can be verified by comparing the outputs of running md5sum(1) on both the /dev/block/mmcblk0 volume on your device and the mmcblk0.raw disk image on your computer.

Additionally, you can use parted(8) to list all the partitions on the backup file:

parted /path/backup/mmcblk0.raw print

There you will find your system and userdata partitions, among many others containing bootloaders, firmware and recovery images.

There was a delay of a few seconds between launching the dd command on the device and the nc on the host computer. Doesn't this mean that I've lost some of the output of dd? Shouldn't these be run concurrently or, at least, shouldn't the nc command be started before the dd one?

Don't worry! When you run nc -l, it will listen for an inbound connection, blocking the pipe and keeping dd from sending data until you establish the connection from your computer.

---

Note: you don't need to run adb forward tcp:5555 tcp:5555 twice.

Warning

Most of the modern devices encrypt all your data. Make sure that you can decrypt the backup file and access your data before erasing the phone.

Answer 2

I let it run and after it finished, dd reported:

7818182656 bytes (7.3GB) copied, 1245.237601 seconds, 6.0MB/s

And ls -l mmcblk0.raw on my computer shows:

-rw-r--r-- 1 terdon terdon 7818182656 Nov 10 14:45 mmcblk0.raw

Since the file is the right size, presumably the backup was successful.

Answer 3

Here's the output of busybox nc -h from the Kindle Fire HDX I'm working on:

BusyBox v1.20.2 (2013-01-21 11:34:41 CET) multi-call binary.

Usage: nc [-iN] [-wN] [-l] [-p PORT] [-f FILE|IPADDR PORT] [-e PROG]

Open a pipe to IP:PORT or FILE

        -e PROG Run PROG after connect
        -l      Listen mode, for inbound connects
                (use -l twice with -e for persistent server)
        -p PORT Local port
        -w SEC  Timeout for connect
        -i SEC  Delay interval for lines sent
        -f FILE Use file (ala /dev/ttyS0) instead of network

So, the entire image is received because netcat waits for the connection to be established before running busybox dd if=/dev/block/mmcblk0, that connection being established by nc 127.0.0.1 5555 in the second terminal window.