staging.inyokaproject.org

Hallo Forum,

Ich möchte für ein SSD-Backup nur den tatsächlich genutzten Speicherplatz auslesen. Das soll die Zeit verkürzen, die SSD schonen und zu besserer Komprimierbarkeit führen. Dafür Möchte ich auf der Ziel-HDD ein leeres Image erstellen, den Inhalt formatieren und die zu sichernden Dateien hineinkopieren. Hinterher soll dieses "Image" dann evtl nachträglich komprimiert werden.

Leider habe ich Probleme, das Image zu formatieren. Es ist egal, ob ich Ext3, Ext4 oder NTFS probiere. Ich bekomme immer so etwas:

#losetup /dev/loop2 ./sda5_Daten_Ext4.img

#mkfs.ext4 /dev/loop2

mke2fs 1.43.4 (31-Jan-2017)
Ein Dateisystems mit 14155776 (4k) Blöcken und 3538944 Inodes wird erzeugt.
UUID des Dateisystems: 7511e222-61ce-4109-a492-422e14b7e70f
Superblock-Sicherungskopien gespeichert in den Blöcken: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424

beim Anfordern von Speicher für die Gruppentabellen: erledigt                        
Inode-Tabellen werden geschrieben: erledigt                        
Das Journal (65536 Blöcke) wird angelegt: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden
geschrieben:        
Warning, had trouble writing out superblocks.

Die Image-Datei ist 54 GB groß, liegt es vielleicht irgendwie daran?

Es wurde erstellt mit dd. Habe die langsame und die schnelle Methode probiert: Kein Unterschied hinsichtlich des Problems.

Schnelle Methode:

dd if=/dev/zero of=./sda5_Daten_NTFS.img bs=1G skip=54

Langsame Methode (Füllt das Image mit Nullen und braucht mehrere Stunden):

dd if=/dev/zero of=./sda5_Daten_Ext4.img bs=1G count=54

Beim mounten nach einer gescheiterten Formatierung kommt diese Meldung:

mount /dev/loop2 /media/sda5-backup
NTFS signature is missing.
Failed to mount '/dev/loop2': Das Argument ist ungültig
The device '/dev/loop2' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

Habe es auf zwei verschiedenen Computern probiert. Kein Unterschied. Die HDD ist extern.

Habe gerade die Formatierung einer 1GB-Image-Datei über ein Loop-Device auf der selben HDD versucht: Keine Probleme!

Ich möchte für ein SSD-Backup nur den tatsächlich genutzten Speicherplatz auslesen.

Ich würde von einem Livesystem aus mit fsarchiver die Dateisystem-Inhalte der Partition(en) auslesen und in Datei(en) speichern. Da wird dann für die Imagedatei wirklich nur der im Quell-Dateisystem belegte Platz minus Komprimierung benötigt.

Ok, danke. Das werde ich mir genauer ansehen. Klingt genau nach dem was ich suche.

Irgendeine Idee, warum dieses Formatierungsproblem kommt? Das macht mich ja schon ein bißchen nervös.

Wenn es sektorbasiert sein soll, schau dir folgenden Link an:

https://www.thomas-krenn.com/de/wiki/Dd_unter_Linux#Komprimiertes_Archiv_einer_Partition

Die fsarchiver-Geschichte hat den Charme, daß du auch auf kleineren Zielpartitionen wiederherstellen kannst. Mindestgröße eben soviel, wie in der Quellpartition belegt war.

Jaja, danke. Wie man beim Kopieren komprimiert, weiß ich. Ich will wissen, warum die Formatierung bei großen Images fehlschlägt.

Obwohl, eine Frage habe ich doch: Bislang habe ich komprimierte Images immer so gezogen:

dd if=/dev/sdc1 bs=1M conv=noerror,sync | pv -s50G -cN "sdc1" | gzip -c -9 > ./sdc1-backup.img.gz

die Blocksize von 1M macht das Backup natürlich langsam, doch ich befürchte, dass bei einem größeren Wert gzip nicht schnell genug komprimiert. Gleichzeitig zeigt mir pv jedoch schwankende Übertragungsraten an. Wartet dd also doch auf die Fertigstellung der Ausgabe? Ich möchte also verhindern, dass dd mehr Daten rausgibt, als gzip abspeichern kann, deshalb auch "sync,noerror". Davon raten viele Tutorials jedoch ab. Unvollständige Blöcke würden so mit Nullen aufgefüllt. Habe ich mir mit dem Befehl potentiell beschädigte Backups erzeugt?

Habe ich mir mit dem Befehl potentiell beschädigte Backups erzeugt?

Kann ich dir nicht sagen. Nie eine Wiederherstellung getestet? Sowas nenne ich dann aber Gottvertrauen. Oder sollte man besser Leichtsinn sagen?

Was willst Du da testen? Du kannst das gezogene Image mounten und gucken, ob sfcheck Fehler findet. Zurückspielen ist eine schlechte Idee, denn dann hast Du das Original überschrieben. Extra eine weitere HDD kaufen, nur zum zurückspielen? Nee. Was soll da außerdem anders sein, als beim Mounten?

Kann es sein, dass das Formatierungsproblem irgendwie mit dem externen Gehäuse zusammenhängt? Wenn ich fsck laufen lasse, bekomme ich E/A-Fehler! Wenn ich die 54GB-Datei dann im Dolphin lösche, bekomme ich auch einen E/A-Fehler. Aktualisiere ich die Ordneransicht, ist die Datei dann aber doch gelöscht.

Diese externen USB-Gehäuse für Festplatten haben in der Regel einen Translation-Chip verbaut, der 4K-Sektoren emuliert. Meine Vermutung ist, dass es beim Formatieren einer Imagedatei irgendwie zu einem Glitch kommt. Normalerweise formatiert man ja nur Partitionen oder ganze HDDs. Habe ich vielleicht einen Bug im Linux gefunden? An der Platte kann es nicht liegen. Es ist eine brandneue Enterprise-Festplatte für Server.

Gebe ich die Fehlermeldung von mkfs in eine Suchmaschine ein, kommen keine Ergebnisse:

Warning, had trouble writing out superblocks.

Sieht so aus, als wäre das in der Tat eine seltene Fehlermeldung.