Proper Backups of PiHole & Shrink Image for Backup/Storage Purposes

Hello again,

This is a fork of the original topic from me posted a few months back. I do appreciate the assistance but still having some trouble making a smaller size image of my RaspberryPi SD card.

Overview:
Currently have a RasPi 3 running PiHole on a 32GB card.
Today I am backing up this card using Win32 Disk Imager. As you know this program makes a 1:1 block copy of the card resulting in a 30GB (or so image file) which I store on my NAS.

@RamSet As explained before from the community there were some scripts designed to allow for smaller partition/image files, that worked. However, When attempting this I couldn't quite get it going. Forgive me my scripting knowledge is so-so.

Again today I am backing up the full SD card (32GB). I do not mind doing a block copy image of the SD card, however when I do these backups quarterly, they tend to take up much un-needed space on my NAS.

Is this script the only method that results in a successful smaller image? I may need to suck it up (so to speak) if I cannot wrap my head around getting it to work and keep performing the same 1:1 block copy as I have been doing

Any further insight is appreciated.

Thank you kindly.

Given the minor cost difference between 32 GB and smaller cards, what do you hope to gain by using a smaller card?

A larger card has more write locations for wear leveling, which will extend the life of the card compared to a smaller card.

I use 32 GB cards with a few 64 GB cards when I had only the larger size available.

An effective backup strategy is to buy two cards of equal size for each Pi. One is in the Pi, the other is a mirror backup. If primary fails, reboot with the backup. You can also rotate them at some periodicity to share the wear.

Sometimes, even pulling an image from an sd card and tyring to copy it to a new sd card of the same size may fail.
This can happen because sd card capacities are approximative values, and even a single byte difference may result in the target card being to small to accomodate the image. This may even happen for exact same model sd cards.

I am using pishrink to shrink my image files. (I do this routinely upon creating a backup image of Pi-hole when updating, for both the old and the freshly upgraded new version).

This has two immediate benefits:
It will drastically reduce the image size on your computer's disk, and this in turn will speed up writing that image file to your new sd card.

Also, a pishrinked image will by default automatically expand the root partition and filesystem to make use of the entire available space on first boot.

1 Like

I understand the cost, and for sure I agree with you there.
Also, not a bad idea to mirror the SD to another.

I was trying to minimize the backup size basically. It takes over 1h to dump the card doing a block copy 1:1.

I will implement this strategy for sure though :slight_smile:

Hello,

> This can happen because sd card capacities are approximative values, and even a single byte difference may result in the target card being to small to accomodate the image. This may even happen for exact same model sd cards.

That is true, and I was aware of this and kind of why I wanted to shrink the backup image down

This looks to be a great solution as well. I don't have a workstation handy right now with Linux on it to run this from at the moment, I could easy grab one and install ubuntu on it.

So basically I could plug in my card reader to the Linux distro, and learn to use pishrink?

Thanks,

@Bucking_Horn

Would you mind giving me an example of your method and use of pishrink?

  • can you use the script directly from the pi?

  • the image is created to a new location on the pi local SD card?

  • once created you can pull the image off the SD card and store for safe keeping?

  • How would the restore process be performed?

Thanks again :slight_smile:

Hi.

The script iā€™m using to this day, is working only on Stretch. Buster does not.

If you are on buster, i have nothing that works for that :frowning:

OK. I will have to look up the command to check what version / distro I am running on the PiHole SD. I will circle back when I figure this out.

Looks like I am on Buster :frowning:
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian

pishrink manipulates existing Raspbian image files, it doesn't create or extract them from an sd card.

The process of reading an image from an sd card as well as writing an image to an sd card has to be performed separately.

You may create such an image file by your favourite sd card imaging tool, e.g. using dd or Balena Etcher or Win32 Disk Imager or whatever tool you prefer.
I'd recommend to extract the image file to a hard drive.

Also, consider running sudo apt-get autoclean and sudo apt-get clean on the sd card OS before you extract an image.
This will remove packages from your apt cache, saving some additional space later at the cost of having to download stuff again if you choose to reinstall or reconfigure a package.

can you use the script directly from the pi?

Yes, I've sucessfully run pishrink on Raspbian image files under Raspbian Buster in my RPis as well as under GParted Live on my PC.

While there is no notable performance difference when using pishrink in its default mode, it will typically take significantly longer on an RPi when using some of the advanced options.

the image is created to a new location on the pi local SD card?

No, pishrink will alter the existing file by default.
This is also the fastest way to run pishrink: It completes in about 30 seconds for a 15G image.
Though it's usually safe to do so, it's always wise to create a backup copy just in case.

If you decide to provide a target file as second parameter, it can create a new file at that location.
It will do so by first copying the file to that location and then apply its shrinking to that copy.

Note that copying a file with an RPi may take quite a while when you are using the internal sd card or a USB hard drive, e.g. copying a 15G file on a USB drive to another location on the same drive may take over 10 minutes when attached to USB2 or still around 3 minutes via USB3.
Running pishrink on a PC, copying usually is even faster than USB3, especially if you are using an SSD.

How would the restore process be performed?

With the same preferred imaging tool of yours that was used to extract the image, presumably.

I've been using pishrink for my Raspbian -pardon me: Raspberry Pi OS- images for all my RPi projects.
As NOOBS partition layout differs significantly from Raspberry Pi OS, pishrink would have refused to operate on respective images in the past, but has started to support NOOBS as well recently.
However, I personally have never tried to use it with images based on NOOBS.

OK awesome.

You may create such an image file by your favourite sd card imaging tool, e.g. using dd or Balena Etcher or Win32 Disk Imager or whatever tool you prefer.
I'd recommend to extract the image file to a hard drive.

OK so this process I have been doing so far with Win32 Disk Imager, making a 30GB image. Once I have this image I can use the Pishrink script which should shrink it down for storage purposes? Assuming I am understanding this correctly.

Also, consider running sudo apt-get autoclean and sudo apt-get clean on the sd card OS before you extract an image.
This will remove packages from your apt cache, saving some additional space later at the cost of having to download stuff again if you choose to reinstall or reconfigure a package.

This I never knew, so I will use this going forward for sure.

As for the restore, as you said you can write the Pishrink image back to the SD card with Win 32 Disk imager?
Insert the SD into the pi and boot?

I suppose the best method for me to understand the restore process will be to attempt the restore write on a separate 32GB SD card, and see if it boots

Thank you for the detailed responses, very kind of you!

1 Like

Here is a related link:

Here is what I do, to avoid having the problem, not being able to clone an SD card. Unfortunately, it doesn't work for existing installations, only usable for new installations (install new, keeping backup in mind...)

Three yeses. :wink:

Have you had a look at clonezilla? I am using clonezilla for all of my raspberry pi backups. It saves only the used space. The backup of my freshly setup buster system with my smarthome solution and some more stuff on it only consumes 1.5GB. You can restore to bigger (but not smaller) SD cards if you please.

If you're happy with backing up only the ext4-partition and don't care about the partition layout and the small dos partition you can also plug in your sd card to an existing linux pc and run partclone on it.

Thanks fore the response. Unfortunately the link to the PDF doesn't work.

Hello,
I have used clonezilla in the past to clone windows. Perhaps I will look into it again. Many suggestions here which is great. Need to find some time on which works best.
Appreciate it!

Link works. Domain (users.telenet.be) is probably blocked...

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.