procount
.img backup with "dd / PiShrink"
I have 3 raspberry images in the stick, but when I want to make an images (.img) file of one of them, it makes an image of the entire SD card, and not ONLY of os the system that has started up. I use PiShrink to make images with. How can I solve it. ???
Don't use PiShrink. If you create a backup using an Image tool, it generally creates an image of the entire disk, as you have found. Images contain the data files and the partition layout. This means even if you managed to make a backup image of one of your OSes, it could only be restored to EXACTLY THE SAME position on your drive.
PINN does not use image files. It uses tar files which only contain the data files. The partition layout details are stored in separate meta-files allowing PINN to create the appropriate partition layouts wherever it wants and install the data files to them. This allows it to install or restore an OS to any position on a drive, which is required for multiboot.
PINN already includes facilities to backup and restore individual OSes. Why don't you use them instead?
I have 5 RPI servers running and I have custom images with the programs that are on all servers, it's easier with .img images if they crash, then I can throw the .img on a new card and it runs again.
Are your 3 raspios images running on the SD card? You said "stick", so are you running them from a USB memory stick? Have you tried PINN's backup features? I don't see how they are any more difficult. You can name the backups and give them a date. Select a partition and just click to back your OS up or restore to/from USB.
If you insist on backing up using img files, you must backup each partition separately, so you will have 2 image files: one for boot and one for root. And you can only restore them to the same partition which must be exactly the same size as the original partition you backed up from. So you will have to backup each server's OSes individually and not have a common set. Unless you can guarantee each server has exactly the same partition sizes, which is quite unlikely unless they are clones,
NOOBS (from which PINN was derived) was partially designed to restore OSes in case they crashed. PINN added the facility to backup a working OS so you could continue from a configured OS (like your custom image) rather than from a factory reset.
Pinn run from SD card, and since I run with 5 separate rpi servers, both with sd and usb boot, I then have a backup drive where all 5 throw a backup onto. Custom images are for if they crash, then I have an image with the standard programs I run with, e.g. barrier, samba is installed on all of them. But since I run with both Buster, Bullseye 32bit and 64bit, I have 3 different images, so it would be great if you could use e.g. PIShrink to create the .img files with. Right now I have 3 sd cards. 1 with Buster, 1 with Bullseye 32bits and 1 with Bullseye 64bits, where I use PIShrink to make .img files, and would be cool if I could use PINN so I only had 1 sd card, and not 3.
Sorry, I'm not sure I have a clear picture of what you are doing, or trying to do. Are you already using PINN, or are you trying to use (or evaluate) PINN to somehow improve what you currently do? You seem to have 5 servers and 3 OS images: Buster, Bullseye32 and Bullseye64. You store a copy of each image on a separate SD card for restoration purposes? You have PINN installed on an SD card or USB stick for each server - since some boot off SD card and some boot off USB. How many OS images does each server have? Do they each just have one image, or have you used PINN to install all 3 images to each server? How do you backup your images now? What do you mean by "throw a backup at the backup drive"? I guess you are copying the entire drive to a file on the backup drive using dd. Are you doing this live from the OS, or using PINN's recovery shell to do it, or what? Have you installed PINN or PINN-lite?
If you can answer these questions and provide more information about what are trying to do, I can probably provide better answers.
Are you doing this live from the OS
In the first comment he says "it makes an image of the entire SD card, and not ONLY of os the system that has started up", so yes it sounds like he's creating a backup from within the live OS. @The-Exterminator I think this is generally unsafe to do, because there might be data still in the write-buffers that hasn't been flushed to disk yet, and so by trying to create a backup from within the live OS, you may be creating an inaccurate (or possibly non-working?) backup.
Since I first started using RPi as daily driver (2013), every time I do OS upgrade, I make image of my current sd-card, mount that with loop and PartEd the image, reducing the partition size, write/confim that, unmount, then truncate image file down to a newer size
The technique I use (PartEd) allows to easily calculate "minimum truncate recommended".
