RAW Images verkleinern

  Michel   Lesezeit: 6 Minuten  🗪 5 Kommentare

Wie verkleinere ich RAW IMG Dateien.

raw images verkleinern

Aktuell habe ich ein Image einer Festplatte erstellt. Zwei Probleme haben sich dabei ergeben. Zum einen ist das IMG viel zu gross. Darin sind nur 10 % des Speichers belegt. Zum anderen bekomme ich das nicht auf die Zielplatte, die leider etwas kleiner ist.

Was mache ich nun?

Meine ersten Recherchen haben bedauerlicherweise nichts ergeben. Doch vor kurzem bin ich zufällig auf eine mögliche Lösung gestossen, als ich herausfinden wollte, wie das automatische Expandieren der Festplatte bei Raspberry Pi Images funktioniert. Dabei kommt ein geniales Werkzeug zum Einsatz, namentlich PIShrink.

Zur Nutzung übergibt man dem Tool ein Quell und ein Zielimage und lässt es seine Arbeit tun.

pishrink.sh {QuellIMG} {ZielIMG}

Das Ergebnis ist ein in der Grösse deutlich reduziertes Image.

Bei zwei Tests bin ich allerdings auf Probleme gestossen. Zum einen kann PiShrink wohl kein BTRFS verkleinern, zum anderen klappt die Verkleinerung nur, bei der letzten Partition im IMG. Bei einem meiner Tests war die letzte Partition eine SWAP Partition.

Was tut man da? Ganz klar. Man löscht die SWAP.

Während ich so weiter zu PiShrink recherchiert habe, sind mir zwei hilfreiche Werkzeuge aufgefallen. kpartx zusammen mit gparted.

kpartx erlaubt den Schreibzugriff auf ein Image. Gnome Disks z.B. bindet IMG Dateien nur lesend ein.

sudo kpartx -av {IMGDatei}

Im Terminal wird durch Angabe von -v die loop Nummer der Partitionen angezeigt, beispielsweise loop28p1. Nun kann ich das IMG mit gparted bearbeiten. Damit gparted die Partition bearbeiten kann, muss diese schon beim Starten von gparted mit angegeben werden. z.B. gparted /dev/loop28

loop28 repräsentiert das IMG bzw. die Festplatte. Mit p1 wäre eine Partition innerhalb des Images gemeint.

Nun kann die SWAP Partition gelöscht werden. Dabei sollte zudem nachgeprüft werden, ob auch wirklich die zu schrumpfende Partition die Letzte im IMG ist. Wenn ihr möchtet, könnt ihr aber gerne auch mit gparted die Partitionen verkleinern. Leider wird PiShrink auch dann gebraucht, wenn die Partition in gparted verkleinert wird. Der Grund ist der, dass ja auch das .img File verkleinert werden muss. Wer möchte, kann dazu alternativ den Befehl truncate nutzen. Man sollte sich dabei einfach bei der erforderlichen Grösse nicht verrechnen. Da ich kein Bock auf Mathe-Fehler habe, lasse ich das dennoch PiShrink erledigen. Ich verkleinere also nur Partitionen mit gparted welche PiShrink eh nicht bearbeitet.

Nach dem Mounten mit kpartx stehen sofort die Partitionen auch im Dateibrowser zur Verfügung. Unter Gnome kann ich nun die Partition öffnen und dann die Daten modifizieren. Ich lösche den Inhalt von ~/.cache/ und prüfe den Inhalt von ~/.local/share/Trash/files/ und lösche auch diese gegebenenfalls.

Unter / lösche ich mindestens den Inhalt von /tmp/ (Ich lösche noch mehr, siehe WICHTIG weiter unten).

Weil ich dafür Root-Rechte benötige, wechsle ich mit CTRL+L in die Adresszeile des Dateibrowsers und hänge ein admin: vor den Ordnerpfad.

Nach Abschluss unmounte ich mit folgendem Befehl das IMG:

 sudo kpartx -d {IMGDatei}

Daraufhin führe ich wie eingangs erwähnt PiShrink aus:

pishrink.sh -s {QuellIMG} {ZielIMG}

Mit dem Parameter -s verhindere ich, dass PiShrink das automatische Erweitern der Partition ins System schreibt. Meine Images, mit denen ich gerade arbeite, sind keine Images von RaspberryPI.

WICHTIG:
Das Wiederherstellen eines modifizierten solchen Systems habe ich nicht getestet. Meine Backups verfolgen das Ziel, die wichtigen User Verzeichnisse unter /home/ und die Daten in /etc zu sichern. Und solange ich entweder mit GNOME Disks oder mit kpartx darauf zugreifen kann, sind die Images für mich nutzbar.

Tatsächlich habe ich nach dem Artikel bislang keinen Restore durchgeführt. Ich gehe eher hin und lösche die grossen unnötigen Dateien wie /usr/lib/, /usr/share/, /var/lib/ und /var/log/ den Rest belasse ich. Es braucht nicht so viel Speicher, und viele Backups in Images mache ich nicht. Am Ende weiss man eh nicht, was man wirklich für Daten braucht. Das hypothetische Szenario hätte ich vor zwei Jahren mal gebraucht. Zurzeit aber nicht.

Nun kann ich aber meinen Mediacenter-Pi in voller Grösse sichern und dann shrinken, wenn ich den Fall hätte, dass ich ein Backup auf einen kleineren Datenträger wiederherstellen muss. Gleichzeitig kann ich aber, ohne Probleme auch mehrere Versionen sichern, ohne Platzprobleme zu bekommen. Die ältere verkleinere ich und halte die dann auch noch vor.

Quellen:
PiShrink: https://github.com/Drewsif/PiShrink
kpartx: https://github.com/opensvc/multipath-tools
gparted: https://gparted.org/

Tags

kpartx, gparted, PiShrink, dd, cli, bash, backup, shrink, compress

benno
Geschrieben von benno am 24. Januar 2023 um 13:16

Überschrift etwas irreführend? Ich dachte es geht um RAW-Images, sprich Fotos im DGN- oder PEF-Format. Trotzdem interessant.

jan
Geschrieben von jan am 24. Januar 2023 um 13:53

gnome-disks (mit s) in DE Laufwerke, glaub ich

The_Raven
Geschrieben von The_Raven am 24. Januar 2023 um 15:24

Witzig: Gerade letzte Woche hatte ich genau das gleiche Problem. Konkret ging es darum ein Image der microSD-Karte eines Raspberrys zu erstellen. Alle Tools die es gibt erstellen ein RAW-Image. Heisst wenn man eine 64GB Karte hat aber nur 3GB belegt sind wird das Image ebenfalls 64GB. Man könnte es dann zwar mit dd erstellen und die Ausgabe mit einer | Pipe zusätzlich komprimieren, aber auch dann müssen die ganzen 64GB gelesen werden. Mein Ansatz war dann ein Script, welches zuerst die Partition auf das Minimum verkleinert, dann ein RAW-Image davon erstellt und anschliessend die Partition wieder auf die volle Grösse aufbläst. Das funktioniert nun soweit ganz gut. Man kann das auch manuell machen: Zuerst mit gparted alle Partitionen verkleinern und an den Anfang schieben. Dann schaue ich mit "fdisk -l" wo das Ende der letzten Partition ist. Diese Zahl verwendet man dann in dd um ein Image zu erstellen: dd if=/dev/sdX of=Image.img bs=512 count=ENDZAHL status=progress

Michel
Geschrieben von Michel am 24. Januar 2023 um 16:09

Auch spannend. Dabei wird dann halt das zu sichernde System erstmal in einer weise modifiziert die halt auch gefährlich sein kann.

Wenn du da ein brauchbares Skript hast, könntest du es ja unter https://github.com/Drewsif/PiShrink zur Integration einreichen. Könnte in bestimmten Situationen eine gute alternative sein.

The_Raven
Geschrieben von The_Raven am 27. Januar 2023 um 11:03

Das ist absolut richtig, nicht ganz ungefährlich das ganze... 😬 Bin gerade ziemlich busy, sobald ich Zeit finde lade ich es hoch. Möchte es allerdings erst noch weiter testen. Allenfalls baue ich noch die Option ein zu wählen ob es verkleinert werden soll oder "nur" via Pipe komprimiert.