I've got a RPi 3b+, usually I do a backup of the SD card to my Mac using sudo dd bs=4m if=/dev/rdisk2 of=raspbian.img, which creates an image file of the whole card. The RPi SD card used to be 16gb, but as that card crashed I restored a previous backup to a spare 64gb card I had laying around.

If I run the same command for backups now though, dd naturally wants to create a 64gb image file. But since the card only contains 16gb of stuff, I'd like to only backup the part that's being used. Otherwise it won't fit on to a new 16gb later (also I don't have that much hdd space available on my Mac).

It seems the SD card has 2 partitons, boot (46mb) and the actual RPi linux partition 15.9gb). Is there a way to only backup these two partitions and disregard the 48gb of unused / unpartitioned space? The result needs to be a single image file (to be used with Etcher for restoration).

<code>diskutil list</code>

  • 1
    Can you use ApplePi-Baker? It supports shrinking .img files during SD card backup. Source
    – M. Rostami
    Mar 25 '20 at 12:06
  • Another nice procedure.
    – M. Rostami
    Mar 25 '20 at 12:09
  • Please don't post pictures of text. Instead paste the text direct into the question.
    – Ingo
    Mar 25 '20 at 14:19
  • Please don't answer your question in the question (EDIT1 and EDIT2). Instead make that an answer. You can just cut and paste it.
    – Ingo
    Mar 26 '20 at 10:40

One thought is to back the whole card up and then zip the resulting file. Etcher will then unzip the file as it creates the image. Note that Etcher requires an SD card the same size or larger than the original.

Could you pipe the output of DD to a zip along these lines:

dd if=/dev/source conv=sync,noerror bs=64K | gzip -c > /path/image.gz

If you have a Mac, I would recommend using ApplePi-Baker as that can handle changing the sizes of partitions - very handy when the new SD card is slightly smaller than the original.

  • ApplePi-Baker worked great! I now have a 11gb backup file (to save on a backup drive) and managed to expand that file back to a new 32gb SD card. Very simple tool to use, can def recommend for mac users. Note: I managed to clear more than 64gb on my mac hard drive before starting this process, as the documentation said that it would copy the entire card before starting the shrinking process. However it seems like APB never used all of that space during the process and the end result was only 11gb. Still I would recommend to clear enough space for the full card to be copied just to be sure.
    – Martin
    Mar 26 '20 at 12:46
  • I experienced some issues trying to restore the image to a second card, ABP came back with an error message about the disk (sd card) being missing. I tried unplugging/plugging back in and erasing/formatting the card with Disk Utility to FAT, which seemed to do the trick.
    – Martin
    Mar 26 '20 at 12:46

You only want to take an image of 16 GB from 64 GB SD Card. For this we use as usual the dd command. The problem is only to get the correct block sizes. I will use parted to look at it, for example:

mngmt ~$ sudo parted /dev/sdb unit s print
Model: Mass Storage Device (scsi)
Disk /dev/sdb: 15759360s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End        Size       Type     File system  Flags
 1      8192s   96663s     88472s     primary  fat32        lba
 2      98304s  15759359s  15661056s  primary  ext4

Here I find the end of the last partition with 15759359s. Unit s means sectors with one sector of 512 bytes. Because parted counts from 0 we have to add one to the size, so we will get 15759360s. Now just copy this size from the SD Card:

mngm ~$ sudo dd if=/dev/sdb of=backup.img bs=512 count=15759360 conv=fsync

bs=512 is set to the blocksize of a sector.


I have been successfully using a script called pishrink by Drew Bonasera ('Drewsif') to back up a headless Raspberry Pi 4 (it works for all models). It is useful because after using dd to make the image it optionally shrinks the image with resize2fs to a little above the data size, and also can optionally insert a run-once command into the image to make Raspbian expand the file system when the image is flashed to a card and used for the first time to boot a Pi.

This means you could flash a smaller card than the original, provided the shrunk image size is smaller than the new card.


It is nice to compress the image to a zip archive (Balena Etcher can use these) but... it is painfully slow if you let the Pi hardware do the compression. From a 32 GB sd card I am making 11 GiB images which the Pi takes around 50 minutes to compress to around 5.5 GiB using not very severe compression options. The finished image ends up in a Windows shared folder mounted on the Pi so I tried WinRar and 7zip command line utilities on Windows to do the compressing. Still around 15 minutes. This seemed OK until I found out about a parallel compressor called pigz. On my i7 4790 PC with 16 GB RAM the images compress 11 GiB to a 5.5 GiB zip archive in around 2 minutes 30 seconds. I enabled OpenSSH on Windows 10 and after a bit of fooling around I got the Rpi to use sshpass to command the Windows PC to do the compression, so the whole thing -- dd backup - image shrink - image compress to zip, happens from one script on the Pi and takes around 25 minutes:

Latest run:

On Pi:
dd makes 30 GiB image on USB3 external hard drive: 12 mins
pishrink shrinks image to 11 GiB: 4.5 mins
move shrunk image to shared Windows folder on PC: 4.5 mins

On Windows:
pigz compress image to 5.5 GiB zip file: 2.5 mins
7za test zip file: 1 min

pigz for Windows

  • If you want say pigz aloud, the writer says you should say 'pigzee'. May 26 '20 at 10:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.