Why my images created with DD have different sizes

Question

I am working on cloning my Raspberry PI microSD cards in order restore then quickly. I use DD linux tool with SSH because they are difficult to access physically.

From my computer, my command is : ssh root@rpi-one "dd if=/dev/mmcblk0 bs=64K conv=noerror,sync status=progress | gzip --fast " | dd of=~/rpi-clones/$(date %Y-%m-%d)_$(hostname).gz

This one give me best result : 3.9GB in 18 minutes for a 32GB microSD

My two raspberries are pretty close :

RPI 1 :

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G  3,0G   25G  11% /
devtmpfs        1,8G     0  1,8G   0% /dev
tmpfs           1,9G   16K  1,9G   1% /dev/shm
tmpfs           1,9G  8,8M  1,9G   1% /run
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           1,9G     0  1,9G   0% /sys/fs/cgroup
/dev/mmcblk0p1  253M   49M  204M  20% /boot
log2ram          40M   11M   30M  28% /var/log
tmpfs           384M     0  384M   0% /run/user/1000
tmpfs           384M     0  384M   0% /run/user/0

RPI 2 :

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G  3,0G   25G  11% /
devtmpfs        1,8G     0  1,8G   0% /dev
tmpfs           1,9G   16K  1,9G   1% /dev/shm
tmpfs           1,9G  137M  1,8G   8% /run
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           1,9G     0  1,9G   0% /sys/fs/cgroup
/dev/mmcblk0p1  253M   49M  204M  20% /boot
log2ram          40M   13M   28M  32% /var/log
tmpfs           384M     0  384M   0% /run/user/1000
tmpfs           384M     0  384M   0% /run/user/0

So :

RPI 1 : 3.9GiB in 1103s

RPI 2 : 6,8GiB in 1337s

At the beginning of my test, RPI1 && RPI2 was identical at 3.9GO with same time.

I wanted to make a test on local RPI2 to see if dd then scp will make me gain time but not.

So in my history :

  159  dd if=/dev/mmcblk0 bs=64K status=progress | gzip -9 > /opt/backups/$(date +%Y%m%d\_%H%M%S)\_$(hostname).gz
  160  ll /opt/backups/
  161  rm -rf /opt/backups/

I wonder even if this test was deleted, if something like sectors are still 'occupy' but available like we can see with df -h command above.

I made several tests with pishrink, e4defrag etc, and I still have the same results (just gain 0.4GiB after e4defrag).

I use these RPIs with screenly-OSE to diffuse images and videos.

If you have any suggestions ... thank you :)

Answer 1

The images are probably of the same size (if the cards are of the same size), but you are not storing the images themselves. The phrase "my images created with DD have different sizes" is most likely false. The compressed archives (which are different than the images) are of different sizes.

You have read the entire block devices with dd, including sectors being free in the understanding of the respective filesystems. A free sector does not necessarily contain data that compresses well, the respecitve filesystem just considers it free and ready to be overwritten. See Clone only space in use from hard disk, especially this answer where free space is deliberately filled with zeros to make the image compress better.

If /opt/backups/ is physically on /dev/mmcblk0 (and I suspect this), the file you had created in /opt/backups/ and deleted is the most probable reason some parts of now free space don't compress well in case of RPI2.

There are some fundamental flaws in your method though:

1. Copying a block device when the filesystem(s) on it are mounted and can be written to may give you an incoherent image, a binary equivalent of panorama fail where different parts of the image (photo) come from different states of the source (reality). Not only /dev/mmcblk0p1 was mounted; I suspect /dev/root is equivalent to /dev/mmcblk0p2 or so, also mounted. Unless they were mounted read-only at the time, the image may be corrupted.

   I also suspect /opt/backups/ is physically on /dev/mmcblk0. If so, your attempt to store the compressed image in this directory had virtually no chance of creating a totally coherent image.

2. Do not use conv=sync,noerr, unless you really know what you're doing. In your case it was probably harmless, but one day you may use it in less forgiving circumstances (example) and get a totally broken image.

A good way to copy a block device is ddrescue, definitely from an OS that doesn't write to the device. I understand your Pis are difficult to access physically. Additionally ddrescue needs the image to be seekable, so you cannot pipe to gzip. Nevertheless ddrescue is the Right Thing.

^{Hints: use Btrfs with compress-force=zlib:9 or so to store seekable images; an independent improvement is ddrescue -S which creates a sparse image.}

If you really need to image a device holding an OS from within the running OS, then you should remount all the relevant filesystems as read-only (sudo mount -o remount,ro …). This may be not as easy as you wish (and this question may help: Device is busy. Why?).

Answer 2

I managed to reduce size with DD zero fill.

I login in on each RPI and I launch :

dd if=/dev/zero of=/root/zero when finished, rm -f /root/zero

After this, my compressed DD images are 1.4G for 861s for RPI1 et RPI2 :)