Hello Everyone,

I am doing Backup images of my SD-Card before updating the SM-OS.
Therefore, my SD-Card has a size of 128 GB the backup-files are quite large (~ 128 GB ☹) and take a lot of time.

I use Win32DiskImager.
Is there a way to shrink the image or to only save the OS-System and not the empty space of the SD-card?

Best Regards
Sven

Hi Sven,

Do you happen to have a modern, large thumb drive (modern = fast usb3) ?
If yes, look into rpi-clone utility.
github.com/billw2/rpi-clone

It only clones used space, skipping temp files/directories created by the kernel/utilites and not needed across boots

If your PI4 is up to date firmware wise, rpiclone can give you a bootable thumbdrive which could be cloned back to the SD card if needed, or mounted after boot if need something off of it.

How much space is being used currently, a 'df -k' command in a shell will show percentages.

Gene

Gene,
thank you.
I will give that a try.
Best Regards
Sven

Attach the image to a loop device using losetup . ...
Using gparted , shrink the first partition to less than 50% of original size. ...
Move the second partition to the newly created free space, shrink to <50%. ...
Ensure that the second partition ends before the 8 GB.
Detach the loop device.

TigerIsHome

Sara, this is a great advice for shrinking backups after they're created, but this thread is about backup time at image creation.

There's another possibility, by using the "sparse" option of dd:

serverfault.com/questions/439128/dd-on-e...t-want-empty-portion

However, i didn't test it (yet), but seems worth a try if you have some time to enter commands and let the system do the work.
Append calls of "date" pre and post execution like so:

date && someothercommand && date

It will echo start and finish date/time before and after someothercommand is being executed. So you can leave the screen while dd is running.
Writing back the dd image to sdcard would be best with omitting the "sparse" option, i guess.

Thank you both,

Saras option is great after creating the image.
As Mr. Mister said perfectly would be if it didn’t get big at all.
I’ll check the suggested solutions.
If anyone has experienced with one method or another one, I would be glad to hear it.

Best Regards
Sven

I also have experience with tar and zlib, which is best suited for backups of data of all sorts, but it's just not really convenient to backup whole partitions/disks, because it doesn't respect device files, as well as mountpoints or mounted partitions. But if you want to backup user data, like fits/raw image files, this is the go-to command. It can also work incrementally, so you don't need much space for more than one multiple full backups on your backup space/medium.

When i was dealing with Unix in enterprise environments, i used a mix of dd images of base installs and incremental/differential tar archives, which got zipped on the fly. I also upgraded my Pi4 with a SDD, which sped up Stellarmate significantly. This, however, adds the burden to do some extra filecopy work in the process of freshly installing Stellarmate OS from official sd-crad image files, but on the upside, backups of the SSD (root partition) are lightning fast, only the boot-partition is still needed on the sd-card for the OS, to know to mount the root partition from the SSD.

Please post back your findings of using dd with the "sparse" option set, thanks