I have a 32Gb SD card and I want to make a light copy of my os to make it work on a 16Gb SDcard.

I wanted to copy just the allocated space so I used gparted to resize my rootfs partition.

enter image description here

after that I used Disks to create the image:

  • I selected the rootfs partition
  • there is an option under settings Create partition image

and now I have .img of the rootfs partition

I did the same for my boot partition.

is it the right way ? I have just one SD card so I couldn't test because I don't want to lose my data so I wanted to make sure that it is correct.

If I execute this everything will work fine ? I intend to resize the root partition after copying the .img

sudo dd bs=4M if=PiOSrootfs.img of=/dev/mmcblk0p2
sudo dd bs=4M if=PiOSboot.img of=/dev/mmcblk0p1

Thank you for helping

  • This question makes no sense. You claim to want to copy SD Cards but not have a second. You claim to have done impossible things.
    – Milliways
    Commented Jan 13, 2021 at 9:10
  • Assuming your using Raspberry Pi OS, why not use the ‘SD Card Copier’ application?
    – CoderMike
    Commented Jan 13, 2021 at 10:40
  • @Milliways right now I just have a 32Gb SD card, and I don't want to lose my os .. I have also to test something on a fresh install of os . I forgot my 16Gb SD card so I don't have it now and I don't want to lose my time so I have to make a copy of my os before installing the new one on the 32GB SD card .. I want my copy size to be at maximum 16Gb ..
    – mina
    Commented Jan 13, 2021 at 11:05
  • @CoderMike I am working on a lite version of os. is it possible to use it ?
    – mina
    Commented Jan 13, 2021 at 11:06

3 Answers 3



I have a 32Gb SD card and I want to make a light copy of my os to make it work on a 16Gb SDcard.

Answer - use image-backup

Perhaps the easiest way to do this is with the image-backup utility - part of image-utils. If you are running RPi OS, image-backup has these advantages:

  • image-backup may be done on a "live" system: no need to shut down the system, or unmount the device.

  • image-backup is fast: 3min:55sec elapsed time to create a bootable image on RPi 4B from a 32GB SD card; activities included in elapsed time:

    • Includes interactive dialog w/ image-backup & USB HDD I/O (USB-3 port).
    • Includes 3x resize2fs and e2fsck on the finished ext4 partition - part of image-backup
    • On a RPi 3B: 13min:42sec from a 16GB SD card to USB "thumb" drive (USB-2 port).
    • Elapsed times measured as follows:
    $ echo $(date) && sudo ./image-backup && echo $(date)  
  • image-backup produces a small raw image file:

    • image file contains only actual data on SD card - not the entire partition (à la dd)
    • 32GB GB SD card --> 4.05GB
      For comparison:
    $ df -h
    Filesystem             Size  Used Avail Use% Mounted on
    /dev/root               29G  5.0G   23G  18% /
    /dev/mmcblk0p1         256M   47M  209M  19% /boot
  • image-backup produces an .img file that can be flashed to another SD card, USB drive, etc using common tools such as etcher and rufus.

  • image-backup is free (no cost) and open sourced bash script.

As its name implies, the primary purpose of image-backup is making a live backup of an RPi. Coincidentally, it's also a good solution to shrinking the OS to fit on a smaller SD card.

You can download a copy of image-utils from this location (see the link at the bottom of the original post) - or if you prefer using git, you can get a copy from this GitHub repo. The instructions for using image-backup (in the README file) may be a bit fuzzy at first, but it's very simple to use. If you have problems, you can post questions to the author in the forum, or ask a specific question here.

How will image-backup address my question?

Once you've "installed" it, you can make a complete backup of your entire system to an image file. By "image file", I mean a file that can be flashed to your (smaller) SD card using etcher or rufus (for example), and then booted in your RPi.

image-backup compresses the image file, and installing to a smaller (32GB->16GB) SD card will not be a problem based the info in your question.

Show me how...

There is no package for image-utils, so apt cannot be used to install it. However, image-utils is just a collection of scripts (text files), and very easy to install; you may install manually, or via git:

Manual installation of image-utils on your RPi:

Open a terminal window (or via SSH) in your RPi, and from your home directory (/home/pi):

cd && mkdir image-utilities && cd image-utilities
wget -O image.zip "https://forums.raspberrypi.com/download/file.php?id=63044&sid=58c9d2d90272e5ae96c12a58a30731d9"
unzip ./image.zip 
chmod a+x image-*

ALTERNATIVELY, use git to d/l & install:

git clone https://github.com/seamusdemora/RonR-RPi-image-utils
sudo install --mode=755 ./RonR-RPi-image-utils/image-* /usr/local/sbin

run image-backup

At this point, image-backup is ready to use, but you will need to have a USB drive mounted (or any drive under /mnt) as a destination for the image file it will create. Once your USB drive is mounted, you may create the image file as follows:

sudo image-backup
  • image-backup will prompt you for the options needed:

    Image file to create? /mnt/Passport2TB/img_backups/20210113_Pi4B_imagebackup.img

NOTE: A full path specification to the image file you want to create. The drive must be mounted under /mnt or /media. I have embedded a date & machine id in my filename. Then, ↵

Initial image file ROOT filesystem size (MB) [5933]?

NOTE: Accept default ( ↵ )

Added space for incremental updates after shrinking (MB) [0]?

NOTE: Accept default ( ↵ )

Create /mnt/Passport2TB/img_backups/20210113_Pi4B_imagebackup.img (y/n)? y

NOTE: Enter y, then ↵

Starting full backup (for incremental backups, run: ./image-backup /mnt/Passport2TB/img_backups/20210113_Pi4B_imagebackup.img)

NOTE: The instructions for making an incremental backup are N/A here because you are running image_backup on a one-time basis.
Additional output will show 3 iterations of resize2fs to reduce the image file to its smallest possible size, and upon completion, e2fsck will be run to verify the integrity of the filesystem.

  • You should now have an image file that is ready to be flashed to your spare SD card.

Verify & inspect the image file

I have used an external drive mounted at /mnt/Passport2TB to store my backup image - in a folder named img_backups. Your external drive will likely be different than mine. You can verify your external drive is mounted by using the lsblk --fs command.

List the contents of /mnt/Passport2TB/img_backups to verify the image file is there, and check its size:

$ ls -l /mnt/Passport2TB/img_backups 
total 28533608


-rw-r--r-- 1 root root  3921674240 Jan 13 18:48 20210113_Pi4B_imagebackup.img

Note that the size of my image file is 3.92GB. Yours will likely be a different size based on which version of the OS you've installed (I use the Lite version of RPi OS). To provide some context for comparison, let's look at how much space is being used on my RPi 4B:

$ df -h -t ext4
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G  4.9G   23G  18% /

And so, in my case, image-backup reduced 4.9GB to a 3.92GB .img file - or about a 20% reduction.

  • 1
    I'm pretty certain the difference between 4.9 and 3.9GB corresponds to 5% of the entire filesystem size. That's the space which is reserved for the root user on an EXT file system. Commented Feb 15, 2021 at 8:11
  • 1
    the tool (raspberrypi.org/forums/download/file.php?id=39167) is 404. archive.org link Commented Jun 1, 2022 at 17:10
  • @luckydonald: Thanks, I've edited the link, but you can also find it on this GitHub site
    – Seamus
    Commented Jun 1, 2022 at 20:57
  • Does the image-backup script support working on a non-live filesystem (e.g., from an SD card mounted on a desktop computer)? This would ensure write-heavy items like live databases are copied without error. Commented Jun 18, 2022 at 18:52
  • 1
    @slm: I fixed it (again). I think I'm going to change that link to the general forums page w/ instructions to search... but I'll do that later. For now, this gets you to "post # 1" of the forum topic which contains the d/l link.
    – Seamus
    Commented Feb 5 at 3:02

I assume you have a 32 GB SD Card with a productive installation that should be handled save and a spare 16 GB SD Card. You want to transfer the productive installation to the 16 GB SD Card. I would do it manual without special image copying programs. So you are free with partitions, filesystems and its sizes and you have control on each step to be sure that nothing goes wrong.

The idea is to take an uncompressed backup image of the 32 GB SD Card. That is always a good thing to save your productive installation. After copying the installation from it you can compress it for archival storage. We have to use a computer with a Linux operating system. I use one with Debian. I assume you can the SD Cards attach to the computer with a SD Card reader to e.g. device file /dev/sdb. For this example I also assume you are using a Raspberry Pi OS.

We will just partition and format the 16 GB SD Card to the sizes you want, mount its partitions, then mount the partitions of the 32 GB image and just copy it files to the 16 GB SD Card. Here are the steps just in short:

Backup card32 to an image and mount its partitions as following:

pc ~$ sudo -Es
pc ~# dd if=/dev/sdb of=./card32.img bs=4M conv=fsync

pc ~# losetup --show --find --partscan ./card32.img
pc ~# ls /dev/loop0*
/dev/loop0  /dev/loop0p1  /dev/loop0p2
pc ~# fsck -f /dev/loop0p1
pc ~# fsck -f /dev/loop0p2

pc ~# mkdir /mnt/card32
pc ~# mount /dev/loop0p2 /mnt/card32
pc ~# mount /dev/loop0p1 /mnt/card32/boot

Attach card16, partition, format, and mount it:

pc ~# parted /dev/sdb mktable msdos
pc ~# parted /dev/sdb mkpart primary fat32 2048s 257MiB
pc ~# parted /dev/sdb mkpart primary ext4 257MiB 100%

pc ~# mkfs.vfat -F 32 -n BOOT /dev/sdb1
pc ~# mkfs.ext4 -L rootfs /dev/sdb2

pc ~# mkdir /mnt/card16
pc ~# mount /dev/sdb2 /mnt/card16
pc ~# mkdir /mnt/card16/boot
pc ~# mount /dev/sdb1 /mnt/card16/boot

Copy the installation from card32 to card16:

pc ~# cp -a /mnt/card32/* /mnt/card16/

Because the installation is now starting from another SD Card, its PARTUUID has changed and it will not find the root partition. You have to correct this. By about 99 % it is the most critical modification if the new SD Card doesn't boot. If so, have a double check at the partitions name in /mnt/card16/boot/cmdline.txt and in /mnt/card16/etc/fstab. I don't use the PARTUUID, but instead the device name.

pc ~# sed -i 's/root=PARTUUID=[a-z0-9]*-02/root=\/dev\/mmcblk0p2/' /mnt/card16/boot/cmdline.txt
pc ~# sed -i 's/^PARTUUID=[a-z0-9]*-01/\/dev\/mmcblk0p1/' /mnt/card16/etc/fstab
pc ~# sed -i 's/^PARTUUID=[a-z0-9]*-02/\/dev\/mmcblk0p2/' /mnt/card16/etc/fstab

pc ~# umount -R /mnt/card16
pc ~# fsck -f /dev/sdb1
pc ~# fsck -f /dev/sdb2

Compress card32.img for the archive if you like:

pc ~# dd if=/dev/zero of=/mnt/card32/boot/nullfile bs=4M conv=fsync
pc ~# dd if=/dev/zero of=/mnt/card32/nullfile bs=4M conv=fsync
pc ~# rm /mnt/card32/boot/nullfile
pc ~# rm /mnt/card32/nullfile

pc ~# umount -R /mnt/card32
pc ~# fsck -f /dev/loop0p1
pc ~# fsck -f /dev/loop0p2
pc ~# losetup --detach-all

pc ~# gzip ./card32.img
pc ~# exit
pc ~$
  • Why do you mount a partition before you run dd on it?
    – Seamus
    Commented Jan 16, 2021 at 18:34
  • @Seamus Where? Have I overseen something?
    – Ingo
    Commented Jan 16, 2021 at 18:40
  • I don't use dd much, but I thought it was common knowledge that the dev/part used as if was to be un-mounted before using dd. This was due to the risk of data corruption. Like many things, risk depends on the situation. I posted the comment because it wasn't clear to me that mounting the drive was necessary to your solution.
    – Seamus
    Commented Jan 16, 2021 at 18:58
  • @Seamus In my answer I find 3 lines with dd. What line do you mean?
    – Ingo
    Commented Jan 16, 2021 at 19:23
  • You have a line that says: Backup card32 to an image and mount its partitions:
    – Seamus
    Commented Jan 16, 2021 at 19:52

Copying one file system (that obviously doesn’t take up the entire disk) to another, smaller filesystem is quite a common problem, especially in these times where GB’s come in large quantities for no price at all.

I had to look for a bit but remembered a question on the Ubuntu stack exchange: https://askubuntu.com/questions/409204/how-to-clone-to-a-smaller-harddisk

Basically what you proposed is the right way to go but be careful to respect the original layout of your disk if you’ve set it up like this.


  • 1
    @mina no problem, I have struggled with this myself recently
    – YVbakker
    Commented Jan 13, 2021 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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