This topic is a heads up from a lesson I have learned in the last week or so. I ordered two x SD cards with NOOBS when I also purchased the RPi 4. 1 x 16GB and 1 x 32 GB. I live on a boat and do not have regular access to the web (mobile phone only) or shops (reasoning behind 2 copies).
I am building a data management server with NMEA 2000, (including navigation, track and AIS) and Victron Energy electrical data intending to be stored and distributed for use by iOS devices. So I had imagined that the larger card might be needed.
A week later I was part way through some of the build aspects and had made some major changes to the OS/configuration of the RPi (ie. added Python libraries etc) and decided to do a backup and image copy. This ‘challenge’ is what prompted this piece of advice (mainly for newbies like myself).
ADVICE.
Always have a spare SD card of the same size as the one you intend to back up as almost (if not all) ‘standard’ approaches to cloning or imaging an SD card will make a ‘copy’ of the same size as the whole disk not just the ‘used’ data component. I had at some time in the whole process always been backing up images from the 16GB to the 32 GB one so did not come across this ‘problem’ earlier but at some time I must have swapped them (16GB vis 32GB) around.
Getting into the command line field of trying to ‘shrink’ the image so that it would only be the size of the ‘actual data used’ space which then be ‘cloned’ was unnecessarily was stressful. [Post Ed due to some feedback: let me explain further; I had read extensively the various options and ways to shrink the image - to my current understanding they ALL involved CL (command line) process. I tried a couple but none of the ones that were relevant to my situations had any ‘examples’ in their ‘helpful’ code. The authors are undoubtedly far more experienced than I; perhaps too experienced that they have forgotten what a wide variety of interpretations are in the mind of the total novice. So I copied EXACTLY the command string from one and hit enter. I started breathing a few minutes later - you ask why. Remember: I am on a MAC OS which has almost identical OS and operates on most of the CL instructions that the RPi does… cost me earlier not being clear which device (MAC or RPi) but nothing destructive. I also only have ONE 32GB RPiOS image with about 30 hours of work in total which I am trying to shrink. Go count the number of cautions on the web about how it doesn’t always work and that a ‘backup’ should be had before trying this… how. I have a copy of the files but this is not a bootable drive and I am yet to understand how to achieve this. Tried a few times with different variations but no luck. I am now embarking on a CL instruction that to me does not seem ‘right’. i.e. no ‘identity’ or point to which is the ‘target’ SD card for this instruction (AAto my MAC OS drive). Anyway I hit enter and after several seconds get another prompt ‘>’ and nothing further; I wait and I wait. Finally CTRL C out and back to my normal Mac Terminal CL prompt. My MAC (with all sorts of s/w installed -240 GB worth) is at risk; and whilst all backed up this is a weeks worth of hard work just to reinstate if I blow this instruction.
So I repeat my original question: If there is a ‘GUI’ (NOT cl] way to shrink images on SD cards…]
If anyone has a ‘clean’ and stable way of using a ‘gui’ to make a bootable image of your RPi4 image from a larger SD card to a smaller one please drop a line here - it will come in handy I am sure. Judging by all the ‘puff and splutter’ on the various forums etc. this is definitely an opportunity for someone with far better skills than I go create a program - say in Python for cross platform options - to perform this function.
Adding to this perhaps from an experienced operator - how do you go about (headless perhaps with MacBook e.g.) keep your current ‘boot’ image backed up so that if you next ‘operation’/update/configuration or whatever, goes south you can simply bring in the spare, make a copy and go from there.
