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>


5 Answers 5


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, 2020 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, 2020 at 12:46

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, 2020 at 10:35

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 only needed a simple window solution, using Win32 Disk Imager, and then 7zip it. It turned 32gb SD to 1.08gb BK file:

enter image description here

And actual size in pi:

enter image description here

Note: Used default configuration. 7zip can be taken to "Ultra" zipping config.


Backup Pi Image


I use this to backup my Raspberry Pi SD card to my Linux computer every 1st and 15th of the month.

This script when run for the first time will create a full disk image of the SD card from which the Pi is running. This image will not contain empty space and thus will be smaller than the full size of the SD card.

On subsequent runs the script will add to the existing image any changes made in the Pi SD card. In other words the script modifies the existing backup image file.


  1. A Raspberry Pi running Buster or Bullseye.
  2. Another computer with ssh setup.
  3. The Pi and the computer connected by LAN or WLAN.
  4. The Pi user should be able to ssh into the computer using key based authentication.

In the Pi:

We will use sshfs to mount the remote folder in the computer in the Raspberry Pi, so that the SD card image can be written directly in the remote folder. Install sshfs with the command:

sudo apt install sshfs

Download RonR-RPi-image-utils-master zip file from

Either: the GitHub repo

Or: the Raspberry Pi Forum Post

Unzip the image-utils.zip file in ~/bin/image-utils/

sudo mkdir /mnt/backup
sudo chmod 777 /mnt/backup

Create ~/bin/pibackup.sh as:

# /home/username1/bin/pibackup.sh
# By: user68186
# Date: Jan 24, 2022
# Purpose: Backup the whole SD card running Pi to the computer
# Requires sshfs, RomR's image-utils: https://github.com/seamusdemora/RonR-RPi-image-utils
/usr/bin/sshfs username2@computer.local:/path/to/PiDiskImage /mnt/backup
/home/username1/bin/image-utils/image-backup /mnt/backup/mybullseye.img
/usr/bin/sleep 10
/usr/bin/umount /mnt/backup

Make the following changes to the above script:

  1. Replace username1 with the username of the Pi user.
  2. Replace username2 with the username of the computer user.
  3. Replace /path/to/PiDiskImage to the actual folder in the computer where the image will be saved.
  4. Replace mybullseye.img with the file name of your choice.

Run the script to see if it works and create the initial image backup.

sudo ~/bin/pibackup.sh

If all goes well you will have an image file, /path/to/PiDiskImage/mybullseye.img

Finally automate the backup process

Add in root’s crontab using the command:

sudo crontab -e 

the following line:

0 23 1,15 * * /home/username/bin/pibackup.sh

This will run as root on 1st and 15th of each month at 11 PM.

In the Computer

Create a folder PiDiskImage where you will be keeping the Pi SD card image backup.

mkdir /path/to/PiDiskImage

Make sure the computer has sufficient disk space to keep at least one copy of the Pi disk image.

If you want a fresh full backup for some reason, rename the file mybullseye.img in the computer to something else. A new mybullseye.img will be created on the next run.

Hope this helps

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.