Image verkleinern mit pishrink

L I V E Stammtisch ab 20:30 Uhr im Chat
  • @RTFM

    Das ich ein Rasbian image nicht weiter verkleinern kann ist mir schon klar.

    Jedoch geht es mir darum, dass wenn ich ein Backup mache nicht immer die ganze SD-Karte (inkl. ungenutzten Speicherplatz) sichern muss.

    D.h. ich ggf eine Sicherung von einer grösseren SD Karte auch auf eine kleinere schreiben kann.

    Bei dem Konventionellen Backup wird ja immer die ganze SD-Karte kopiert und nicht nur der Teil mit Daten.

    Dafür ist doch PiShrink gedacht?

    Oder habe ich in der Funktion von PiShrink was falsch verstanden?

    Anbei das log vom letzen Durchgang mit einer 32GB Karte

    pishrink1.log

    pishrink1.sh v0.1

    Copying /home/pi/backup/piager/betarelease_Denni.img to /home/pi/backup/piager/betarelease_Denni_klein-20190204-204842.img......

    Gatherin data...

    Line 110

    beforesize: 30G

    Line 117

    parted_output: 2:48234496B:31914983423B:31866748928B:ext4::;

    Line 121

    partnum: 2

    partstart: 48234496

    Mounting image...

    Line 136

    tune2fs_output: tune2fs 1.43.4 (31-Jan-2017)

    Filesystem volume name: rootfs

    Last mounted on: /

    Filesystem UUID: 72bfc10d-73ec-4d9e-a54a-1cc507ee7ed2

    Filesystem magic number: 0xEF53

    Filesystem revision #: 1 (dynamic)

    Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file dir_nlink extra_isize

    Filesystem flags: signed_directory_hash

    Default mount options: user_xattr acl

    Filesystem state: clean

    Errors behavior: Continue

    Filesystem OS type: Linux

    Inode count: 1881152

    Block count: 7779968

    Reserved block count: 314113

    Free blocks: 7303336

    Free inodes: 1833784

    First block: 0

    Block size: 4096

    Fragment size: 4096

    Reserved GDT blocks: 106

    Blocks per group: 32768

    Fragments per group: 32768

    Inodes per group: 7904

    Inode blocks per group: 494

    Flex block group size: 16

  • Jedoch geht es mir darum, dass wenn ich ein Backup mache nicht immer die ganze SD-Karte (inkl. ungenutzten Speicherplatz) sichern muss.

    D.h. ich ggf eine Sicherung von einer grösseren SD Karte auch auf eine kleinere schreiben kann.

    Temporär schon, Du sicherst ERST die komplette Karte und eliminierst DANACH mit pishrink leere Bereiche. Wenn das passiert ist, kannst Du die Imagedatei noch zusätzlich packen.

  • @RTFM

    Bei dem Konventionellen Backup wird ja immer die ganze SD-Karte kopiert und nicht nur der Teil mit Daten.

    Dafür ist doch PiShrink gedacht?

    Ein Speicherabbild vom ersten bis zum letzten Sektor einer HD/SD zu ziehen ist schonmal kein konventionelles Backup. Das machen nur Datenforensiker und pi User.

    Pi-User deshalb, weil der "Hauptrechner" auf Windows läuft und der mit Linuxfiles ind -Partitionen nicht umgehen kann und deshalb als Workaround für eine Komplettsicherung der gesamte Speicher der SD als Speicherabbild verwendet wird.

    Bei einem konventionellen Backup wird üblicherweise tar oder rsync verwendet.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Jedoch geht es mir darum, dass wenn ich ein Backup mache nicht immer die ganze SD-Karte (inkl. ungenutzten Speicherplatz) sichern muss.

    raspiBackup hat eine Option mit der beim dd Backup nur die definierten Partitionen gesichert werden. D.h. wenn man eine 32GB SD Karte hat, aber nur zwei Partitionen mit zusammen 8GB definiert hat ist das dd Backup auch nur 8GB gross. Weiss nicht ob das fuer Dich eine Alternative ist.

    Bei pishrink sichert man erst die 32GB und verkleinert danach das Image. Dieses wird dann aber je nach Belegung noch kleiner als 8GB

  • Ein Speicherabbild vom ersten bis zum letzten Sektor einer HD/SD zu ziehen ist schonmal kein konventionelles Backup. Das machen nur Datenforensiker und pi User.

    Anbei eine Statistik welche Backuptypen mit raspiBackup im Januar benutzt wurden:

    Code
    --- Types:
                   percent
    dd:            17.4 %
    ddz:           18.6 %
    rsync:         32.7 %
    tar:           17.5 %
    tgz:           13.6 %

    Ich frage mich auch immer warum so viele dd bzw ddz benutzen. Ein wesentlicher Grund scheint zu sein dass man ein dd Backup unter Windows mit windisk32imager oder noch einem anderen Tool restoren kann.

  • man ein dd Backup unter Windows mit windisk32imager oder noch einem anderen Tool restoren kann.

    das unterschreibe ich mal so. Zurückschreiben, fertig. Für rsync brauchst Du ja immer ein FS, was die Rechte abbilden kann. Hat nicht jeder.

  • Ich frage mich auch immer warum so viele dd bzw ddz benutzen.

    Das dient auch mehr dem ruhigen Gewissen ("Ich habe eh was getan"). Wenn die wüssten, dass die dd - Sicherung teilweise gar nicht funktioniert. Z.B. wenn ein (dateiintensiver) Cronjob beim dd-en läuft, Von den Badblocks rede ich noch gar nicht.

    Dein raspiBackup hat sich ja inzwischen schon ganz schön gemausert. Aber ohne lesen der Dox (die hervorragend sind) kommt ein leseggeschwächter Windower halt auch nicht zurecht, und er greift zu dem, was halt "funktioniert".


    Servus !

    RTFM = Read The Factory Manual, oder so

  • das unterschreibe ich mal so. Zurückschreiben, fertig. Für rsync brauchst Du ja immer ein FS, was die Rechte abbilden kann. Hat nicht jeder.

    Ja, aber tar kann alles, auch das Anhängen der geänderten Dateien an ein bereits vorhandenes tar Archiv, das auf einem Netzlaufwerk oder einer NTFS Partition liegen kann. Warum tar am Pi nicht öfters zum Einsatz kommt, weiss ich nicht.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Warum tar am Pi nicht öfters zum Einsatz kommt, weiss ich nicht.

    Ich übrigens auch nicht, wiewohl ich mir beim lesen vorhin die gleiche Frage gestellt habe. Muss ich demnächst mal probieren.

  • Ein Archiv zu erstellen (ggf. packen) oder zu entpacken dauert doch vermutlich länger als normales kopieren mit z.B. rsync? Und Archive erhöhen die Komplexität, die nicht immer gewünscht ist bei einem Backup.

  • Hallo,

    Ich habe ein Raspberry Pi Image mit Win32DiskImager auf eine externe Festplatte ntfs gespeichert.

    Ich habe PiShrink auf dem Raspberry installiert, die Festplatte mit dem Image am Raspberry angeschlossen und möchte jetzt das Image mit PiShrink kleiner machen. Wenn ich in das LXTerminal nur $ pishrink.sh eingebe, werden mir die Optionen angezeigt.

    Wenn ich $ pishrink.sh und den Dateinamen des Images eingebe, bekomme ich diese Fehlermeldung:

    "pishrink.sh: ERROR occured in line 123: test.img is not a file..."

    Schreibrechte auf der externen Festplatte habe ich mit sudo nano text.txt getestet, das hat funktioniert.

    Ich bin Anfänger und kenne mich auf linux nicht gut aus.

  • Hallo hyle,

    diesen Befehl habe ich eingegeben. Die Datei auf der externen Festplatte ist test.img

    pi@raspberrypi:~ $ pishrink.sh test.img

    pishrink.sh v0.1.2

    pishrink.sh: ERROR occured in line 123: test.img is not a file...

    pi@raspberrypi:~ $

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!