Warum sind meine Clonezilla-Images ohne ersichtlichen Grund auf einmal mehr als 2,5x so groß als üblich?

[Andi07]

Hallo zusammen!

Ich mache nun schon seit einer halben Ewigkeit komplette lokale Backups meines Datenträgers mit Clonezilla. Und diese Clonezilla-.img meines 1 TB großen Datenträgers hatte immer eine Größe von 83,9 GiB. Neuerdings sind sie aber 220,5 GiB groß.
Ausgewählt wurde bei diesen Backups immer die gzip-Komprimierung.

Festgestellt habe ich das mit der aktuellsten Clonezilla-Version. Aber auch mit der alten Version tritt das Problem auf einmal auf.
Ich habe sogar mehrfach die Datenträger auf dem diese Images gespeichert werden gelöscht und neu formatiert.
Geändert hat sich aber nichts. Die Images sind mehr als 2,5x so groß als üblich.

Warum ist das so und wie kann man es beeinflussen, dass diese Images nicht mehr so groß werden?
Wie gesagt, bis vor kurzem waren die Images immer 83,9 GiB groß und der originale Datenträger ist nicht wesentlich mehr mit Daten belegt. Und jetzt sind diese Images jeweils 220,5 GiB groß.

Vielen Dank!


Gruß Andi

 

[BFF]

Hat sich die Groesse der Quelle eventuell geaendert?
Versteckte Dateien falls Windows, kein TRIM bei SSD usw. kann Grund sein.

Oder halt mal die Entwickler von CloneZilla anfragen, falls die Ursache nicht bei der Quelle ist.

 

[b1nb4sh]

Clonezilla kopiert ja nur Blöcke, die in Verwendung sind. Kann es sein, dass du irgendwelche Reste auf der SSD hast? Diese erscheinen zwar nicht in der Belegungsstatistik, weil Windows weiß, dass die Blöcke wieder überschrieben werden dürfen, aber Clonezilla prüft nur, ob der Block in Verwendung ist.

 

[tollertyp]

Wieviel ist denn tatsächlich belegt auf dem Datenträger?

Hat sich am Inhalt signifikant was geändert?

 

[Andi07]

Hallo zusammen und herzlichen Dank!

Der Inhalt des Original-Datenträgers hat sich wie erwähnt nicht wesentlich geändert.
Dieser Datenträger ist ohne die Boot-Partition zu 7 % belegt. Gesamtgröße des Datenträgers 1 TB. (Unter Linux, nicht Windows).

Weil eine manuelle Kernel-Installation mit einem Fehler beendet wurde, habe ich das 220,5 GiB große Image zurückspielen müssen. Und danach war die Hauptpartition wieder zu 7 % belegt.
Und wenn ich mal früher ein übliches 83,9 GiB großes Clonezilla-Image wiederhergestellt habe, dann war die Hauptpartition auch wieder zu 7 % belegt.

Das einzige, was sich wesentlich geändert hat, ist die Größe des Clonezilla-Image. Sonst nichts weiter.

Für mich sieht es so aus, ich weiß aber nicht weshalb, dass die Komprimierung über Clonezilla nicht mehr richtig funktioniert.


Gruß Andi

 

[eYc]

Clonezilla schreibt doch auch ein Logfile, hast du da mal reingeschaut, und verglichen?

 

[Andi07]

Hallo eYc und Hallo zusammen!

Dankeschön!

Da ich die Datenträger, auf dem die Clonezilla-Images gelöscht und formatiert habe, kann ich leider nicht mehr vergleichen.
Und im 220,5 GiB großen Image kann ich mit den .txt-Dateien nichts anfangen, da ich sie nicht lesen kann.
Der Text ist eine Mischung aus vorwiegend scheinbar chinesischen Schriftzeichen und das gemischt mit irgendwelchen Ziffern und europäischen Buchstaben.

Das einzige, was ich lesen kann, ist ecryptfs.info

# This image was saved with ecryptfs
disk_of_img="sda"
parts_of_img="sda1 sda2"
time_of_img="2021-1228-0429"
disks_size_all_of_img="_1024GB"

Die anderen .txt-Dateien, wie Info-dmi.txt, Info-img-id-txt, Info-lshw.txt, Info-lspci.txt, Info-OS-prober.txt, Info-packages.txt, Info-saved-by-cmd.txt und Info-smart.txt kann ich nicht lesen.

Vielleicht liegt es ja daran, dass das Image verschlüsselt ist. Ansonsten sind diese Text-Dateien kodiert mit Westeuropäisch ISO 8859-15. Anders kodiert, z. B. mit UTF 8, sieht der Inhalt noch schlimmer aus.
Die Inhalte bleiben unlesbar.

Herzlichen Dank!


Gruß Andi

 

[Nolag]

Vielleicht liegt es ja daran, dass das Image verschlüsselt ist.

Verschlüsselte Inhalte lassen sich jedenfalls nicht mehr komprimieren. Dann sollte da bei den kleineren Backups aber ein anderes Filesystem stehen.

 

[Andi07]

Hallo Nolag und Hallo zusammen!

Danke, aber ich verstehe das leider nicht!

Die Images wurden schon immer komprimiert und verschlüsselt.
Nur dass das Image, bei nahezu gleicher Ausgangslage, diesmal 220,5 GiB groß ist. Anstatt wie sonst 83,9 GiB groß ist.

Gruß Andi

 

[Nolag]

Ja, mein Kommentar war auch Quatsch. Das ist das Filesystem das Clonezilla für die Speicherung verwendet. Es müsste sich das Filesystem des Datenträgers geändert haben. Das sollte Clonezilla auch irgendwo in das log file geschrieben haben.

 

[Andi07]

Hallo Nolag und Hallo zusammen!

Dankeschön!

Am Filesystem des Original-Datenträgers und der Backup-Datenträger hat sich absolut nichts geändert.


Gruß Andi

 

[Nolag]

Am Filesystem des Original-Datenträgers und der Backup-Datenträger hat sich absolut nichts geändert.

Was hat Clonezilla denn für ein Filesystem erkannt? Beim Raw abziehen sind die Backups z.B. nur klein, wenn die unbelegten Sektoren mit Nullen gefüllt sind.

 

[Andi07]

Hallo Nolag und Hallo zusammen!

Kann ich das auch im Nachhinein sehen und wie meinst Du das bitte genau?
Ich weiß jetzt nur, dass vor dem eigentlichen Starten des Backups sda1 und sda2 erkannt wurden.
Und während des Backups stand irgendetwas von RAW in der laufenden Clonezilla-Anzeige, bin mir aber nicht sicher.

Vielen Dank!


Gruß Andi

 

[Nolag]

Und während des Backups stand irgendetwas von RAW in der laufenden Clonezilla-Anzeige, bin mir aber nicht sicher.

Das sollte auch im Log file stehen. Wenn er die Partition RAW abzieht, dann muss man für ein minimales Backup die unbelegten Sektoren mit einem Wipe Tool nullen.

 

[Fusionator]

Gibts denn unter Linux bzw. Clonezilla keine intelligente Sektorkopie? Da kriegt man ja Kopfschmerzen beim mitlesen. Eine Raw Kopie für normale Backup Zwecke ist ja reichlich sinnfrei.

 

[Nolag]

Gibts denn unter Linux bzw. Clonezilla keine intelligente Sektorkopie?

Macht er normalerweise schon, aber es ist halt die Frage ob es hier möglich war.

 

[Andi07]

Hallo zusammen und vielen Dank!

Es handelt sich hier um Vollbackups des Original-Datenträgers. Und so weit ich gesehen habe, sichert Clonezilla Blöcke. In der laufenden Clonezilla-Sitzung stand jedenfalls immer fortlaufend x-Datenblöcke von x-Datenblöcke gesichert. Und Clonezilla verwendet für das Backup dd (disk dump).

Und ich musste noch nie unbelegte Sektoren manuell nullen oder wipen.

Ach ja @Nolag, als Filesystem wurde von Clonezilla sda1 als FAT32 und sda2 als Crypt. Der externe Datenträger (Partition) als ext4.

Gruß Andi

 

[Nolag]

als Filesystem wurde von Clonezilla sda1 als FAT32 und sda2 als Crypt.

Die Crypt Partition wird wohl eine Bitlocker Partition sein, die er mit dd klonen muss. Da gibt es dann keine Erkennung der belegten Sektoren mehr und Kompression sollte eigentlich auch nichts mehr bringen.

 

[Andi07]

Hallo Nolag und Hallo zusammen!

Vielen Dank!

Dann frage ich mich aber, weshalb es dann jahrelang und bis vor kurzem keine Probleme unter gleichen Bedingungen gegeben hat?!


Gruß Andi

 

[Nolag]

Dann frage ich mich aber, weshalb es dann jahrelang und bis vor kurzem keine Probleme unter gleichen Bedingungen gegeben hat?!

Wenn ich das richtig verstehe, dann verschlüsselt Bitlocker zunächst nur belegte Sektoren. Ein Backup ist dann so groß wie der belegte Platz auf der Partition, weil der Rest der Platte noch genullt ist. Wenn man dann mit der Platte arbeitet, hängt es vermutlich davon ab, ob Trim freigegebene Sektoren wieder nullt. Wenn das nicht der Fall ist, sammelt man mit der Zeit immer mehr verschlüsselte Sektoren auf, die aber nicht mehr belegt sind und die Backups werden größer. Wenn Trim auf der Platte funktioniert, könnte es vielleicht helfen einfach vor dem Backup die Laufwerkoptimierung laufen zu lassen.