welches Linux Tool für Festplatten Image nutzen?

[Karl Heinz]

Hallo,

könnt ihr mir ein Linux Tool empfehlen mit dessen Hilfe ich ein Festplatten-Image erstellen sollte?

Gibt ja diverse wie z.B. dd, clonezilla, nwipe

So wie ist das gelesen habe ist dd mit Umsicht und Vorsicht anzuwenden und arbeitet ziemlich langsam. Wenn der Befehl mal eingegeben ist, rattert das Ding unbarmherzig los.

nwipe hat meines Erachtens den großen Vorteil einer GUI auch wenn diese GUI nur auf der Shell implementiert ist.

Ich habe bezogen auf die Tools keine Erfahrung was Geschwindigkeit, Nutzerfreundlichkeit usw. angeht.

Für Tipps wäre ich dankbar.

[Der Martin]

Moin,

könnt ihr mir ein Linux Tool empfehlen mit dessen Hilfe ich ein Festplatten-Image erstellen sollte?

Gibt ja diverse wie z.B. dd, clonezilla, nwipe

persönlich kenne und nutze ich dd, clonezilla kenne ich dem Namen nach,

So wie ist das gelesen habe ist dd mit Umsicht und Vorsicht anzuwenden und arbeitet ziemlich langsam.

Umsicht und Vorsicht ... ja, auf jeden Fall. Das gilt aber bei allen Tools dieser Art auch. Und wenn ich mal nur wortwörtlich auf die Frage eingehe: Das Erstellen von Festplatten-Backups ist ja zunächst mal eine harmlose Angelegenheit, da sehe ich noch keine Gefahr. Erst beim Zurückschreiben.

Und langsam ... nein, wenn man dd mit einer angemessenen blocksize nutzt, ist es relativ flott.

Wenn der Befehl mal eingegeben ist, rattert das Ding unbarmherzig los.

Du kannst es jederzeit mit Ctrl-C abbrechen. Der "Schaden" ist dann natürlich schon passiert, wenn du die Imagedatei versehentlich aufs falsche Medium oder in die falsche Partition schreibst. Das gilt aber für alle anderen Tools auch.

ERGÄNZUNG: dd kann problematisch sein, wenn der Datenträger nicht mehr einwandfrei ist. Dann "fehlen" einfach einzelne Sektoren im Image.
Wenn also der Verdacht besteht, dass der Datenträger schon beschädigt ist (also defekte, nicht einwandfrei lesbare Sektoren hat), dann sollte man besser dd_rescue verwenden. dd_rescue versucht bei Lesefehlern, durch geduldiges Wiederholen doch noch was zu reißen, und füllt bei Misserfolg wenigstens den nicht lesbaren Block im Image auf, so dass der Rest drumherum immerhin passt.

So long,
 Martin

[Karl Heinz]

Und langsam ... nein, wenn man dd mit einer angemessenen blocksize nutzt, ist es relativ flott.

Was meinst du mit blocksize? Wie viel RAM man dd zur Verfügung stellt?

ERGÄNZUNG: dd kann problematisch sein, wenn der Datenträger nicht mehr einwandfrei ist. Dann "fehlen" einfach einzelne Sektoren im Image.
Wenn also der Verdacht besteht, dass der Datenträger schon beschädigt ist (also defekte, nicht einwandfrei lesbare Sektoren hat), dann sollte man besser dd_rescue verwenden. dd_rescue versucht bei Lesefehlern, durch geduldiges Wiederholen doch noch was zu reißen, und füllt bei Misserfolg wenigstens den nicht lesbaren Block im Image auf, so dass der Rest drumherum immerhin passt.

Mmmm, beim Datenträger besteht in der Tat der Verdacht, das dieser nichtmehr einwandfrei ist. Bei der letzten OS Installation auf diesem Datenträger ist mir das System einfach so abgeraucht (deshalb jetzt auch das Image mit dd).

Siehe hierzu folgender Beitrag:

https://forum.selfhtml.org/self/2016/may/23/linux-bootet-nichtmehr/1667954#m1667954

Sollte ich bei dieser Situation dann besser dd oder dd_rescue verwenden?

Gibt es ein Tool bei dem ich im Vorfeld feststellen kann ob der Datenträger noch einwandfrei ist?

Wäre es dann nicht besser grundsätzlich dd_rescue zu verwenden oder gibt es bei der Verwendung von dd_rescue Nachteile?

[Der Martin]

Hallo,

Und langsam ... nein, wenn man dd mit einer angemessenen blocksize nutzt, ist es relativ flott.

Was meinst du mit blocksize? Wie viel RAM man dd zur Verfügung stellt?

nein, ich meine den Parameter bs, den man z.B. auf 1MB setzen kann:

dd if=<quelle> of=<ziel> bs=1M

Dann liest und schreibt dd immer 1MB "am Stück", andernfalls nur sehr kleine Blöcke (512 Byte, also ein Sektor). Und viele kleine Blöcke dauern länger als wenige große.

Mmmm, beim Datenträger besteht in der Tat der Verdacht, das dieser nichtmehr einwandfrei ist. Bei der letzten OS Installation auf diesem Datenträger ist mir das System einfach so abgeraucht (deshalb jetzt auch das Image mit dd).

Siehe hierzu folgender Beitrag:

https://forum.selfhtml.org/self/2016/may/23/linux-bootet-nichtmehr/1667954#m1667954

Ah, ich erinnere mich. Ob da noch was zu retten ist und mit welchen Mitteln, ist in der Tat fraglich. Einen Versuch ist es sicher wert, so nach dem Motto "Noch kaputter geht's nicht". Aber dann wird die Wiederherstellung wahrscheinlich recht aufwendig. Wie ich dem alten Beitrag entnehme, war ja die Partitionstabelle mit Unsinn überschrieben.

Hast du eine konkrete Idee, wie du vorgehen willst? Ich wüsste da nämlich im Moment nicht, wie ich anfangen sollte.

Sollte ich bei dieser Situation dann besser dd oder dd_rescue verwenden?

Lieber letzteres. Falls ein Block der Festplatte wirklich nicht auf Anhieb lesbar ist, lässt dd ihn in der Imagedatei einfach kommentarlos weg, die Zuordnung von Blocknummer und Dateioffset im Image geht dann also verloren. Und dd_rescue macht das nicht, da bleibt die Zuordnung fix (nur enthält die Imagedatei an der Stelle eben Blödsinn, aber der Rest stimmt). Es hat außerdem den Charme, bei der Arbeit einen Fortschrittsbalken und eine Zeitabschätzung anzuzeigen, während dd einfach schweigend vor sich hin werkelt.

Gibt es ein Tool bei dem ich im Vorfeld feststellen kann ob der Datenträger noch einwandfrei ist?

Nein, nicht sinnvoll. Defekte Sektoren ("bad blocks") kann man nur feststellen, indem man versucht, sie zu lesen. Das kann man dann auch gleich "auf Verdacht" mit dem Erzeugen des Images verbinden.

Wäre es dann nicht besser grundsätzlich dd_rescue zu verwenden oder gibt es bei der Verwendung von dd_rescue Nachteile?

Der einzige Nachteil, der mir einfällt: dd_rescue ist nicht in der Standardinstallation enthalten und muss separat nachinstalliert werden.

So long,
 Martin

[Karl Heinz]

nein, ich meine den Parameter bs, den man z.B. auf 1MB setzen kann:

Dann liest und schreibt dd immer 1MB "am Stück", andernfalls nur sehr kleine Blöcke (512 Byte, also ein Sektor). Und viele kleine Blöcke dauern länger als wenige große.

Warum dann nur 1MB und nicht z.B. 10MB oder 100MB das wäre doch dann noch schneller.

In der Hilfe zu dd steht folgendes:

Zur Übernahme eines bestehenden Systems auf eine SSD (Solid-State-Drive) sollte dd nur mit äußerster Vorsicht genutzt werden. In den Standardeinstellungen verwendet dd eine Blockgröße von 512 Bytes, was bei modernen SSD zu unnötigen Schreibprozessen führt. Verwendet man unter Benutzung des Parameters bs= eine Blockgrößenangabe die der Blockgröße oder einem Vielfachen davon der SSD entspricht, besteht diese Gefahr nicht. Des Weiteren sollte man beachten, dass das Alignment eingehalten wird, was ohne weitere Parameter höchstwahrscheinlich nicht der Fall ist.

Hier wird gesagt das beim Schreiben kleiner Blockgrößen auf eine SSD äußerste Vorsicht geboten ist, des weitern das eine Gefahr besteht. Es wird aber nicht gesagt wo hier die Gefahr konkret liegt. Kannst du mir sagen was gemeint ist?

Ah, ich erinnere mich. Ob da noch was zu retten ist und mit welchen Mitteln, ist in der Tat fraglich. Einen Versuch ist es sicher wert, so nach dem Motto "Noch kaputter geht's nicht". Aber dann wird die Wiederherstellung wahrscheinlich recht aufwendig. Wie ich dem alten Beitrag entnehme, war ja die Partitionstabelle mit Unsinn überschrieben.

Zum Hintergrund:

• das System ist mir vor einiger Zeit abgeraucht (siehe verlinkter Beitrag)
• ich konnte leider nichtsmehr retten
• Dachte erst die SSD ist defekt
• War Sie aber nicht, nach einer Neuinstallation läuft Mint einwandfrei
• bin mir aber trotzdem unsicher ob die Platte nicht doch einen Hau hat
• deshalb möchte ich jetzt ein Image erstellen (wenn Sie wieder abraucht kauf ich mir halt ne andere und spiele dort das Image auf)
• retten möchte ich nichtsmehr, hab das OS bereits neu installiert
• die Nutzdaten hab ich ohnehin auf einer NAS mit RAID-System
• ausgehend von dieser NAS mit RAID-System werden die Nutzdaten inkrementell auf eine andere externe Platte in einem anderen Raum täglich mit Hilfe von anacron gesichert (mit Hilfe das Tools Back in Time)

Hast du eine konkrete Idee, wie du vorgehen willst? Ich wüsste da nämlich im Moment nicht, wie ich anfangen sollte.

Wie gesagt, retten will ich nichtsmehr einfach nur ein Image ziehen um eines zu haben wenn die Platte doch einen Hau haben sollte.

Der einzige Nachteil, der mir einfällt: dd_rescue ist nicht in der Standardinstallation enthalten und muss separat nachinstalliert werden.

Dann werde ich mal auf dd_rescue umsteigen. Gut das ich gefragt habe sonst hätte ich wohl dd genutzt.

PS: Schau Dir mal nwipe an. Ist ein ziemlich cooles Tool, gerade für das bitweise Überschreiben prima geeignet. Bezogen auf Images hab ich damit aber noch keine Erfahrung.

[Der Martin]

Mahlzeit,

Dann liest und schreibt dd immer 1MB "am Stück", andernfalls nur sehr kleine Blöcke (512 Byte, also ein Sektor). Und viele kleine Blöcke dauern länger als wenige große.

Warum dann nur 1MB und nicht z.B. 10MB oder 100MB das wäre doch dann noch schneller.

kann man natürlich auch machen, aber der Gewinn durch noch größere Blöcke fällt dann nur noch gering aus.

Zur Übernahme eines bestehenden Systems auf eine SSD (Solid-State-Drive) sollte dd nur mit äußerster Vorsicht genutzt werden. In den Standardeinstellungen verwendet dd eine Blockgröße von 512 Bytes, was bei modernen SSD zu unnötigen Schreibprozessen führt. Verwendet man unter Benutzung des Parameters bs= eine Blockgrößenangabe die der Blockgröße oder einem Vielfachen davon der SSD entspricht, besteht diese Gefahr nicht. Des Weiteren sollte man beachten, dass das Alignment eingehalten wird, was ohne weitere Parameter höchstwahrscheinlich nicht der Fall ist.

Hier wird gesagt das beim Schreiben kleiner Blockgrößen auf eine SSD äußerste Vorsicht geboten ist, des weitern das eine Gefahr besteht. Es wird aber nicht gesagt wo hier die Gefahr konkret liegt. Kannst du mir sagen was gemeint ist?

Ja, und der Ausdruck "Gefahr" ist unnötig dramatisiert.

Der Grund liegt in der technischen Organisation von SSDs. Bei ihnen können immer nur Blöcke von beispielsweise 1MB oder 4MB auf einmal gelöscht bzw. neu beschrieben werden. Wenn die CPU nun also einen Schreibbefehl für einen Sektor absetzt, muss die SSD in Wirklichkeit 1MB in einen internen RAM-Puffer lesen, die 512 Bytes neue Daten hineinschreiben und dann 1MB wieder auf den Flash-Speicher zurückschreiben. Das dauert natürlich deutlich länger als es für die 512 Byte rechnerisch nötig wäre. Wenn noch dazu ein Sektor nach dem anderen einzeln geschrieben wird, muss der ganze 1MB-Block 2048 mal neu geschrieben werden. Das kostet viel Zeit und belastet die Speicherzellen, geht also auf die Lebensdauer.
Der Controller einer SSD wird zwar versuchen, den Vorgang zu optimieren, z.B. durch verzögertes und zusammengefasstes Schreiben, oder indem die Schreibvorgänge gleichmäßig über das Speichermedium verteilt und der Verschleiß so gering gehalten wird. Aber wenn das Betriebssystem bzw. die Anwendung ihre Anforderungen ungünstig stellen, geht die Performance halt doch in die Knie, und die SSD kann ihren Vorteil (ihr hohes Tempo) nicht mehr ausspielen.

• das System ist mir vor einiger Zeit abgeraucht (siehe verlinkter Beitrag)
• ich konnte leider nichtsmehr retten
• Dachte erst die SSD ist defekt
• War Sie aber nicht, nach einer Neuinstallation läuft Mint einwandfrei
• bin mir aber trotzdem unsicher ob die Platte nicht doch einen Hau hat
• deshalb möchte ich jetzt ein Image erstellen (wenn Sie wieder abraucht kauf ich mir halt ne andere und spiele dort das Image auf)
• retten möchte ich nichtsmehr, hab das OS bereits neu installiert

Okay, dann verstehe ich deine Absicht. Also keine Forensik, sondern nur Prophylaxe. Bedenke, dass du den Vorgang gelegentlich wiederholst (alle paar Wochen oder so), denn wenn du tatsächlich mal ein zehn Monate altes Image zurückspielen müsstest, dann hättest du auch alle Software-Updates seit dem Backup wieder eliminiert. Das muss ja nicht sein.

PS: Schau Dir mal nwipe an. Ist ein ziemlich cooles Tool, gerade für das bitweise Überschreiben prima geeignet.

Brauche ich das? Ich glaube nicht.

Bezogen auf Images hab ich damit aber noch keine Erfahrung.

Vielleicht hast du da was falsch verstanden. Nach meiner Schnell-Recherche ist nwipe nur zum vollständigen und "sicheren" Löschen von Datenträgern gedacht, aber nicht um Images zu erzeugen bzw. zurückzuspielen.

So long,
 Martin

[Google weiß alles]

Dann liest und schreibt dd immer 1MB "am Stück", andernfalls nur sehr kleine Blöcke (512 Byte, also ein Sektor). Und viele kleine Blöcke dauern länger als wenige große.

Warum dann nur 1MB und nicht z.B. 10MB oder 100MB das wäre doch dann noch schneller.

So simpel ist das nicht.

Ich versuche mal eine sehr volkstümliche Erklärung.

Der Festplattencontroller (Bei Spartcards und USB-Sticks findet das [teilweise] nur woanders statt) will die Daten blockweise schreiben. Diese Blöcke haben eine feste Größe, welche von den Chips auf der Platte und deren Firmware abhängt.

Kommen jetzt die Daten in Blöcken, die zu groß sind, dann muss er diese aufteilen, hat also damit Arbeit. Kommen die Daten in Blöcken, die zu klein sind, dann trifft das ebenfalls zu, denn er muss entweder auf den oder die nächsten Blöcke warten und die Daten zusammenfügen oder diesen auffüllen (Dateiende). Der Worst Case ist, wenn die logische Blockgröße des Mediums mit der, die gesendet wird überhaupt nicht in Übereinstimmung zu bringen ist, so dass die Blöcke geteilt und zusammengefügt werden müssen. Ideal sind also Blockgrößen, die der Controller ohne weitere als unbedingt notwendige Aktionen verarbeiten kann.

dd* verwendet per Default mit 512Bytes, das ist der "kleinste gemeinsame Nenner" und vermeidet das Teilen der Blöcke.

Welche Blockgröße die richtige ist hängt insbesondere von dem Gerät ab, welches zu beschreiben ist (Ausnahme ist natürlich wenn man z.B. genau 446 Bytes lesen will). Außerdem kann es derzeit als gesetzt gelten, dass eine der folgende Blockgrößen Verwendung findet:

512, 1024, 2048, 4096, 8192, 16384, 32768 (also immer das Doppelte)

Faustregel: Größere und modernere Platten haben größere Blockgrößen. Am einfachsten probiert man das, in dem man sich mit

dd if=/dev/urandom of=bigfile bs=1024 count=102400

auf einem ausreichend schnellem Dateisystem eine große Datei anlegt, diese dann mit dd* auf das Gerät kopiert und mal schaut, wie lange das dauert. Es werden hierfür Zufallsdaten benutzt.

Beispiele: (Werte bei anderen Konstellationen werden sehr(!) stark(!) abweichen)

dd if=bigfile of=outfile bs=512
204800+0 Datensätze ein
204800+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 6,58058 s, 15,9 MB/s

dd if=bigfile of=outfile bs=1024
102400+0 Datensätze ein
102400+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 3,37245 s, 31,1 MB/s

dd if=bigfile of=outfile bs=2048
51200+0 Datensätze ein
51200+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 1,77845 s, 59,0 MB/s

dd if=bigfile of=outfile bs=4096
25600+0 Datensätze ein
25600+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,963437 s, 109 MB/s

dd if=bigfile of=outfile bs=8192
12800+0 Datensätze ein
12800+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,936332 s, 112 MB/s

dd if=bigfile of=outfile bs=16384
6400+0 Datensätze ein
6400+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,928353 s, 113 MB/s

dd if=bigfile of=outfile bs=32768
3200+0 Datensätze ein
3200+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,913329 s, 115 MB/s ***

dd if=bigfile of=outfile bs=65536
1600+0 Datensätze ein
1600+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,910148 s, 115 MB/s

rm bigfile outfile

Der Gewinner ist die Blockgröße ab welcher der Datendurchsatz nicht mehr ansteigt oder sogar abfällt. Hier also 32768 Bytes. Zu beachten ist, ich bei den Tests zweimal in das gleiche Dateisystem geschrieben habe und das die Datei hierbei auch ent- und und vor allem verschlüsselt wurde. Und dass der Dateisystem-eigene Cache wirkte. Die Aussage ist also nicht allgemeingültig.

Dennoch ein Tipp: Bei modernen Platten würde ich mit einer Blockgröße von 8192 Byte testen, dann halbieren, dann verdoppeln.

Also sollte der Test realitätsnäher stattfinden. Wenn man also nicht eine Datei (in ein Dateisystem) schreibt sondern Rohdaten direkt auf die Platte, dann können diese Werte ebenfalls stark abweichen. Sogar von denen, die gemessen werden wenn auf die gleiche Platte in ein Dateisystem geschrieben wird.

Hat man das vor, dann sollte man das auch o testen. Aber Achtung: dd if=bigfole of=/dev/sda wird, wenn man es mit root-Rechten ausführt, hemmumgslos Partitionen und Daten zerstören...

Man macht das also VOR dem Partitionieren.

[Der Martin]

Mahlzeit,

Dann liest und schreibt dd immer 1MB "am Stück", andernfalls nur sehr kleine Blöcke (512 Byte, also ein Sektor). Und viele kleine Blöcke dauern länger als wenige große.

Warum dann nur 1MB und nicht z.B. 10MB oder 100MB das wäre doch dann noch schneller.

So simpel ist das nicht.

Ich versuche mal eine sehr volkstümliche Erklärung.

deine Ausführungen sind zwar korrekt, haben aber nichts mit der tatsächlichen, physikalischen Sektorgröße einer Festplatte zu tun.

Kommen jetzt die Daten in Blöcken, die zu groß sind, dann muss er diese aufteilen, hat also damit Arbeit.

Nur bedingt. Diese Arbeit erledigen nämlich schon die Treiber für die Festplatte und das Dateisystem.

Welche Blockgröße die richtige ist hängt insbesondere von dem Gerät ab, welches zu beschreiben ist

Genau hier liegt dein Trugschluss, weil die Blockgröße für dd nicht direkt mit der Blockgröße des Speichermediums zu tun hat. Es ist, um es mal salopp zu beschreiben, nur die Größe der Kiste, die ich benutze, um Akten von einem Büro ins andere zu bringen: Benutze ich eine kleine Kiste, muss ich oft hin- und hergehen, das kostet Zeit. Benutze ich eine große Kiste, spare ich Weg ein und kann unterm Strich schneller sein. Das hat aber nichts damit zu tun, wie die Akten in die Fächer im Schrank passen.

dd if=bigfile of=outfile bs=512
204800+0 Datensätze ein
204800+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 6,58058 s, 15,9 MB/s

dd if=bigfile of=outfile bs=1024
102400+0 Datensätze ein
102400+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 3,37245 s, 31,1 MB/s

dd if=bigfile of=outfile bs=2048
51200+0 Datensätze ein
51200+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 1,77845 s, 59,0 MB/s

dd if=bigfile of=outfile bs=4096
25600+0 Datensätze ein
25600+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,963437 s, 109 MB/s

dd if=bigfile of=outfile bs=8192
12800+0 Datensätze ein
12800+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,936332 s, 112 MB/s

dd if=bigfile of=outfile bs=16384
6400+0 Datensätze ein
6400+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,928353 s, 113 MB/s

dd if=bigfile of=outfile bs=32768
3200+0 Datensätze ein
3200+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,913329 s, 115 MB/s ***

dd if=bigfile of=outfile bs=65536
1600+0 Datensätze ein
1600+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,910148 s, 115 MB/s

rm bigfile outfile

Wenn du die Blockgröße weiter erhöhst, wirst du feststellen, dass die Brutto-Transferrate noch minimal weiter zunimmt; sie wird asymptotisch gegen einen Idealwert laufen. Nach deiner These müsste aber die Transferrate wieder einbrechen, wenn die Blockgröße deutlich über der des Speichermediums liegt.

Dennoch ein Tipp: Bei modernen Platten würde ich mit einer Blockgröße von 8192 Byte testen, dann halbieren, dann verdoppeln.

Die meisten Festplatten neueren Datums haben AFAIK 4kB große Sektoren.

Also sollte der Test realitätsnäher stattfinden. Wenn man also nicht eine Datei (in ein Dateisystem) schreibt sondern Rohdaten direkt auf die Platte, dann können diese Werte ebenfalls stark abweichen. Sogar von denen, die gemessen werden wenn auf die gleiche Platte in ein Dateisystem geschrieben wird.

Logisch, denn der Dateisystem-Overhead spielt auch eine wichtige Rolle.

Beispiel: Eine USB-Festplatte (USB 2.0) mit 1TB war lange Zeit in FAT32 formatiert. Sie erreichte typische Übertragungsraten von rund 30MB/s. Irgendwann habe ich sie neu mit ext3 formatiert, und plötzlich lag die Transferrate derselben Platte bei etwa 36MB/s.

So long,
 Martin

[Google weiß alles]

Nach deiner These müsste aber die Transferrate wieder einbrechen, wenn die Blockgröße deutlich über der des Speichermediums liegt.

Richtig. Hab ich irgendwann beim Schreiben von Daten direkt aufs Gerät (/dev/sdX) auch mal so gemessen. Kann es aber gerade nicht wiederholen, da ich gerade kein Medium zur Hand habe, dessen Inhalt ich killen will.

[Karl Heinz]

ERGÄNZUNG: dd kann problematisch sein, wenn der Datenträger nicht mehr einwandfrei ist. Dann "fehlen" einfach einzelne Sektoren im Image.
Wenn also der Verdacht besteht, dass der Datenträger schon beschädigt ist (also defekte, nicht einwandfrei lesbare Sektoren hat), dann sollte man besser dd_rescue verwenden. dd_rescue versucht bei Lesefehlern, durch geduldiges Wiederholen doch noch was zu reißen, und füllt bei Misserfolg wenigstens den nicht lesbaren Block im Image auf, so dass der Rest drumherum immerhin passt.

Es gibt ja drei Tools:

• dd
• dd_rescue
• ddrescue

Siehe hierzu folgender Artikel:

http://danielnoegel.de/wordpress/2010/07/05/datenrettung-mit-ddrescue/

Du würdest "dd_rescue" nutzen. Wäre "ddrescue" nicht besser?

[Der Martin]

Hallo,

Es gibt ja drei Tools:

• dd
• dd_rescue
• ddrescue

letzteres kenn ich noch nicht.

Siehe hierzu folgender Artikel:

http://danielnoegel.de/wordpress/2010/07/05/datenrettung-mit-ddrescue/

Den Server kann ich im Augenblick nicht erreichen, weiß der Geier warum.

EDIT: Jetzt geht's, meine Fritzbox hat eben gemeint, sie müsse der 24h-Zwangstrennung zuvorkommen. Merkwürdige Zeit, normalerweise passiert das in der Nacht ...

Du würdest "dd_rescue" nutzen. Wäre "ddrescue" nicht besser?

EDIT: [Schon möglich. Wie gesagt, ich kenn's noch nicht.]
Ja, scheint eine sehr schlaue Weiterentwicklung zu sein, auch wenn das Programm nichts generell Neues macht. Aber es ist wohl in einigen Dingen optimiert worden.

So long,
 Martin

[Karl Heinz]

Du würdest "dd_rescue" nutzen. Wäre "ddrescue" nicht besser?

EDIT: [Schon möglich. Wie gesagt, ich kenn's noch nicht.]
Ja, scheint eine sehr schlaue Weiterentwicklung zu sein, auch wenn das Programm nichts generell Neues macht. Aber es ist wohl in einigen Dingen optimiert worden.

So, dann leg ich mal los. OS läuft sauber mit allen nötigen Programmen auf einer 128 GB SSD. Diesbezüglich möchte ich nun mit ddrescue ein Image ziehen. Dieses Image möchte ich auf der externen NAS speichern und anschließend testen indem ich zunächst eine temporäre Datei erstelle, dann das Image wieder einspiele um zu prüfen ob die temporäre Datei wieder weg ist.

Schritt 1:

ddrescue -b2048 /dev/sda //192.168.178.71/karlheinz/images/image-karlheinz.iso logfile1

Schritt 2:

In Logfile schauen. Sollten fehlerhafte Sektoren exisiteren sollte man überlegen eine neue SSD anzuschaffen.

Schritt 3:

Eine beliebige Testdatei z.B. unter ~ erstellen. Diese sollte nach Schritt 4 wieder weg sein.

Schritt 4:

ddrescue -b2048 //192.168.178.71/karlheinz/images/image-karlheinz.iso /dev/sda logfile2

Schritt 5:

Prüfen, ob die Testdatei aus Schritt 3 wieder weg ist. Wenn ja hat das Einspielen des Images funktioniert.

Ist dieses Vorgehen so korrekt?

Noch eine Frage. In der Anleitung https://wiki.ubuntuusers.de/gddrescue/ steht folgender Satz:

Es wird eine 1:1 Kopie erstellt, kein Image.

Was ist denn der Unterschied zwischen einer 1:1 Kopie und einem Image. Ist doch identisch oder nicht?

[Matthias Apsel]

Hallo Karl Heinz,

Was ist denn der Unterschied zwischen einer 1:1 Kopie und einem Image. Ist doch identisch oder nicht?

Eine 1:1-Kopie ist die komplette Festplatte in der Ordnerstruktur, jede Datei, da wo sie hingehört. (Als Eegebnis, es werden nicht alle Dateien einzeln kopiert, sondern die physischen Blöcke des Speichers)

Ein Image ist der Festplatteninhalt komprimiert in einer Datei.

Bis demnächst
Matthias

[Der Martin]

Hallo,

Was ist denn der Unterschied zwischen einer 1:1 Kopie und einem Image. Ist doch identisch oder nicht?

Eine 1:1-Kopie ist die komplette Festplatte in der Ordnerstruktur, jede Datei, da wo sie hingehört. (Als Eegebnis, es werden nicht alle Dateien einzeln kopiert, sondern die physischen Blöcke des Speichers)

ja, genau.

Ein Image ist der Festplatteninhalt komprimiert in einer Datei.

Es kann komprimiert sein, muss aber nicht.

Ciao,
 Martin

[Der Martin]

Hallo,

So, dann leg ich mal los. OS läuft sauber mit allen nötigen Programmen auf einer 128 GB SSD. Diesbezüglich möchte ich nun mit ddrescue ein Image ziehen. Dieses Image möchte ich auf der externen NAS speichern und anschließend testen indem ich zunächst eine temporäre Datei erstelle, dann das Image wieder einspiele um zu prüfen ob die temporäre Datei wieder weg ist.

und all das machst du hoffentlich erstmal mit einer Partition, bei der es nicht weh tut, wenn doch etwas schiefgeht und die Daten futsch sind. Oder du hast wenigstens ein konventionelles Backup.

Schritt 1:

ddrescue -b2048 /dev/sda //192.168.178.71/karlheinz/images/image-karlheinz.iso logfile1

Kannst du das NAS-Laufwerk tatsächlich so ansprechen, ohne es ins lokale Dateisystem zu mounten? Finde ich zumindest ungewöhnlich.
Ach ja: Ich würde die Imagedatei nicht mit der Endung .iso anlegen, denn das suggeriert eigentlich ein CD- oder DVD-Image mit ISO-Dateisystem. In diesem Fall ist vielleicht eine generische Endung wie .img oder .bin geeigneter.

Schritt 4:

ddrescue -b2048 //192.168.178.71/karlheinz/images/image-karlheinz.iso /dev/sda logfile2

Dazu brauchst du, wie die Beschreibung sagt, den Schalter -f. Und du musst du den PC von einem externen Medium starten (Live-CD oder USB-Stick). Denn wenn die aktive Systempartition auf /dev/sda liegt, sollte ddrescue sich weigern, auf dieses Medium zurückzusichern.

Noch eine Frage. In der Anleitung https://wiki.ubuntuusers.de/gddrescue/ steht folgender Satz:

Es wird eine 1:1 Kopie erstellt, kein Image.

Ja. Beachte, dass das im Abschnitt "Partition zu Partition" steht, also bei dem Szenario, dass man beispielsweise /dev/sda1 nach /dev/sdb1 klont. Dabei entsteht ja keine Datei im eigentlichen Sinn.

Was ist denn der Unterschied zwischen einer 1:1 Kopie und einem Image. Ist doch identisch oder nicht?

Inhaltlich ja.

So long,
 Martin

[Karl Heinz]

und all das machst du hoffentlich erstmal mit einer Partition, bei der es nicht weh tut, wenn doch etwas schiefgeht und die Daten futsch sind. Oder du hast wenigstens ein konventionelles Backup.

Ich habe einen zweiten komplett baugleichen PC. Auf dem zweiten Rechner ist Mint ebenfalls installiert, wird aber noch nicht produktiv genutzt, es handelt sich hier lediglich um die Standardinstallation. Ich denke ich werde das Image von Rechner 1 auf der NAS erstellen. Anschließend werde ich dieses Image in Rechner 2 einspielen. Wenn Rechner 2 dann genauso wie Rechner 1 konfiguriert ist weiß ich, dass das Image funktioniert. Sollte doch gehen oder?

In dem Kontext noch die Frage, was ist wenn ich noch weitere Rechner hätte die NICHT baugleich zu Rechner 1 und zu Rechner 2 sind. Könnte ich das Image dann auch für diese Rechner verwenden oder geht das nur bei komplett baugleichen Rechnern?

Schritt 1:

ddrescue -b2048 /dev/sda //192.168.178.71/karlheinz/images/image-karlheinz.iso logfile1

Kannst du das NAS-Laufwerk tatsächlich so ansprechen, ohne es ins lokale Dateisystem zu mounten? Finde ich zumindest ungewöhnlich.

Ich habe das NAS-Laufwerk ja über die fstab gemounted, sprich es wird bei jedem Start automatisch auf dem Schreibtisch angezeigt. Ich weiß trotzdem nicht wie ich die NAS anders als über die IP ansprechen soll. Sicherlich könnte ich anstelle der IP auch den Namen verwenden der in die IP der NAS per DNS aufgelöst wird. Ich weiß allerdings nicht wo im Linux-System ich dieses Mapping finde, sprich ich weiß nicht wo ich nachschauen kann welcher Name der NAS IP zugrunde liegt. Kannst du mir sagen wo ich das nachschauen kann? Bei Windows ist das ja glaube ich die hosts-Datei? Wo ist den ndie hosts-Datei in Linux?

[Der Martin]

Moin,

und all das machst du hoffentlich erstmal mit einer Partition, bei der es nicht weh tut, wenn doch etwas schiefgeht und die Daten futsch sind. Oder du hast wenigstens ein konventionelles Backup.

Ich habe einen zweiten komplett baugleichen PC. Auf dem zweiten Rechner ist Mint ebenfalls installiert, wird aber noch nicht produktiv genutzt, es handelt sich hier lediglich um die Standardinstallation. Ich denke ich werde das Image von Rechner 1 auf der NAS erstellen. Anschließend werde ich dieses Image in Rechner 2 einspielen. Wenn Rechner 2 dann genauso wie Rechner 1 konfiguriert ist weiß ich, dass das Image funktioniert. Sollte doch gehen oder?

ja, das ist sogar eine sehr gute Strategie - von Kleinigkeiten abgesehen. Zum Beispiel dass der zweite Rechner ja auch alle Einstellungen, also z.B. auch den Hostnamen übernimmt. Es könnte also etwas Durcheinander geben, wenn die nachher beide gleichzeitig am Netz sind. Aber sonst ...

In dem Kontext noch die Frage, was ist wenn ich noch weitere Rechner hätte die NICHT baugleich zu Rechner 1 und zu Rechner 2 sind. Könnte ich das Image dann auch für diese Rechner verwenden oder geht das nur bei komplett baugleichen Rechnern?

Nein, die müssen nicht völlig baugleich sein. Mint ist mit seiner Ubuntu-Abstammung ein System, das sich sehr weitgehend dynamisch beim Booten konfiguriert. Also auch wenn das Zielsystem eine andere Netzwerkkarte, eine andere Grafikkarte etc. hat, sollte das trotzdem ohne großes Theater gehen. Nur die Festplatte des Zielsystems muss natürlich genau so groß oder größer als die des Quellsystems sein.

ddrescue -b2048 /dev/sda //192.168.178.71/karlheinz/images/image-karlheinz.iso logfile1

Kannst du das NAS-Laufwerk tatsächlich so ansprechen, ohne es ins lokale Dateisystem zu mounten? Finde ich zumindest ungewöhnlich.

Ich habe das NAS-Laufwerk ja über die fstab gemounted

Aber das heißt doch, dass es wie ein Verzeichnis im lokalen Dateisystem angesprochen wird. Hmm.

Ich weiß trotzdem nicht wie ich die NAS anders als über die IP ansprechen soll. Sicherlich könnte ich anstelle der IP auch den Namen verwenden der in die IP der NAS per DNS aufgelöst wird. Ich weiß allerdings nicht wo im Linux-System ich dieses Mapping finde, sprich ich weiß nicht wo ich nachschauen kann welcher Name der NAS IP zugrunde liegt. Kannst du mir sagen wo ich das nachschauen kann? Bei Windows ist das ja glaube ich die hosts-Datei? Wo ist den ndie hosts-Datei in Linux?

/etc/hosts (nur mit root-Rechten editierbar, aber für jeden lesbar)

Aber dort steht nur etwas drin, wenn du es auch eingetragen hast. Wenn nicht, kennt Linux den Hostnamen den Geräts einfach nicht.

So long,
 Martin

[Karl Heinz]

Kannst du das NAS-Laufwerk tatsächlich so ansprechen, ohne es ins lokale Dateisystem zu mounten? Finde ich zumindest ungewöhnlich.

Ich habe das NAS-Laufwerk ja über die fstab gemounted

Aber das heißt doch, dass es wie ein Verzeichnis im lokalen Dateisystem angesprochen wird. Hmm.

Ich weiß hier leider noch nicht worauf die hinaus willst. Du schreibst "Kannst du das NAS-Laufwerk tatsächlich so ansprechen..."

Wie soll ich es denn sonst ansprechen? Außer über die IP fällt mir keine Alternative ein (in der hosts-Datei habe ich nichts festgelegt).

Wie würdest du das Laufwerk denn ansprechen, sprich was wäre die für Dich gewöhnliche Vorgehensweise?

[Der Martin]

Hi,

Kannst du das NAS-Laufwerk tatsächlich so ansprechen, ohne es ins lokale Dateisystem zu mounten? Finde ich zumindest ungewöhnlich.

Ich habe das NAS-Laufwerk ja über die fstab gemounted

Aber das heißt doch, dass es wie ein Verzeichnis im lokalen Dateisystem angesprochen wird. Hmm.

Ich weiß hier leider noch nicht worauf die hinaus willst. Du schreibst "Kannst du das NAS-Laufwerk tatsächlich so ansprechen..."

ja, weil mich das überrascht, weil ich das so nicht kenne. Aber es scheint ja zu funktionieren.

Wie soll ich es denn sonst ansprechen? Außer über die IP fällt mir keine Alternative ein (in der hosts-Datei habe ich nichts festgelegt).

Wie würdest du das Laufwerk denn ansprechen, sprich was wäre die für Dich gewöhnliche Vorgehensweise?

Bei mir stünde in /etc/fstab eine Zeile, die ungefähr so aussehen könnte:

//192.168.178.71/karlheinz   /karlheinz   cifs   user=***,pass=***,file_mode=0666,dir_mode=0777

Dann kann ich den Inhalt des NAS-Servers direkt über das lokale Verzeichnis /karlheinz adressieren und brauche nicht jedesmal IP-Adresse oder sowas anzugeben, wenn ich auf das Gerät zugreifen will. Die Tatsache, dass Benutzername und Passwort direkt in den mount-Optionen stehen, ist einfach meiner Faulheit geschuldet.

Ich schrieb oben ganz bewusst "stünde" im Konjunktiv, denn ich habe da noch eine Abstraktionsstufe dazwischen: Ich lasse die Netzwerkverzeichnisse mit autofs immer erst in dem Moment mounten, wenn darauf zugegriffen wird. Andernfalls haut mir das System beim Booten dauernd Fehlermeldungen um die Ohren, wenn nicht alle Netzwerkressourcen verfügbar sind (d.h. nicht alle anderen PCs an).
Daher bin ich mir mit der exakten Syntax des fstab-Eintrags nicht sicher, aber im Prinzip ...

So long,
 Martin

[Karl Heinz]

Die Tatsache, dass Benutzername und Passwort direkt in den mount-Optionen stehen, ist einfach meiner Faulheit geschuldet.

Ich habe Login und Passwort in eine Datei gepackt die in ~/.config liegt und auf die aus fstab verwiesen wird.

[Karl Heinz]

Schritt 1:

ddrescue -b2048 /dev/sda //192.168.178.71/karlheinz/images/image-karlheinz.iso logfile1

Kannst du das NAS-Laufwerk tatsächlich so ansprechen, ohne es ins lokale Dateisystem zu mounten? Finde ich zumindest ungewöhnlich.
Ach ja: Ich würde die Imagedatei nicht mit der Endung .iso anlegen, denn das suggeriert eigentlich ein CD- oder DVD-Image mit ISO-Dateisystem. In diesem Fall ist vielleicht eine generische Endung wie .img oder .bin geeigneter.

So, nachdem nun endlich die Virtual-Box wieder funktioniert Schritt 1 mit folgender Zeile:

ddrescue -b2048 /dev/sda //192.168.178.71/karlheinz/images/image-karlheinz.img logfile1

Es kommt folgende Fehlermeldung:

ddrescue: Can't open input file: Permission denied

Kannst du mir sagen, was diese Fehlermeldung zu bedeuten hat?

[Der Martin]

Hallo,

ddrescue -b2048 /dev/sda //192.168.178.71/karlheinz/images/image-karlheinz.img logfile1

Es kommt folgende Fehlermeldung:

ddrescue: Can't open input file: Permission denied

das war zu erwarten. :-)

Kannst du mir sagen, was diese Fehlermeldung zu bedeuten hat?

Ja. Erstens mal darf nur root auf die speziellen Device-Dateien /dev/sd.. zugreifen, also müsstest du zumindest sudo verwenden.

Zweitens ist es heikel, auf einen Datenträger direkt zuzugreifen, der aktuell gemountete Dateisysteme enthält. Beim Lesen mag das mit Zähneknirschen und Backenzusammenkneifen noch akzeptabel sein, beim Zurückschreiben aber ganz sicher nicht. Das System darf also, damit das reibungslos geht, nicht von /dev/sda gebootet sein, sondern vorzugsweise von einem externen Datenträger.
Das habe ich aber vor fast einer Woche schon erwähnt.

So long,
 Martin

[Christian Kruse]

Hallo Martin,

Zweitens ist es heikel, auf einen Datenträger direkt zuzugreifen, der aktuell gemountete Dateisysteme enthält.

Heikel? Das ist desaströs. Das wird, sofern das Device nicht Read-Only gemountet ist, nahezu mit Sicherheit zu einem kaputten Dateisystem und einem inkonsistenten Zustand führen. Denn Schreibzugriffe finden immer statt und sei es nur für das Logging, auch während das dd läuft.

LG,
CK

[Karl Heinz]

Kannst du mir sagen, was diese Fehlermeldung zu bedeuten hat?

Ja. Erstens mal darf nur root auf die speziellen Device-Dateien /dev/sd.. zugreifen, also müsstest du zumindest sudo verwenden.

Zweitens ist es heikel, auf einen Datenträger direkt zuzugreifen, der aktuell gemountete Dateisysteme enthält. Beim Lesen mag das mit Zähneknirschen und Backenzusammenkneifen noch akzeptabel sein, beim Zurückschreiben aber ganz sicher nicht. Das System darf also, damit das reibungslos geht, nicht von /dev/sda gebootet sein, sondern vorzugsweise von einem externen Datenträger.
Das habe ich aber vor fast einer Woche schon erwähnt.

Das heißt für mich:

• sudo vorne dran packen
• Datenträger vor dem Image ziehen aushängen

Dann wäre es OK?

[Der Martin]

Hi,

Ja. Erstens mal darf nur root auf die speziellen Device-Dateien /dev/sd.. zugreifen, also müsstest du zumindest sudo verwenden.

Zweitens ist es heikel, auf einen Datenträger direkt zuzugreifen, der aktuell gemountete Dateisysteme enthält. Beim Lesen mag das mit Zähneknirschen und Backenzusammenkneifen noch akzeptabel sein, beim Zurückschreiben aber ganz sicher nicht.

Das heißt für mich:

• sudo vorne dran packen
• Datenträger vor dem Image ziehen aushängen

Dann wäre es OK?

Ja, wenn du das schaffst. *g*
Aber du wirst wohl kaum die Partitionen /dev/sda1, /dev/sda2 usw. aushängen können, wenn das aktive Betriebssystem selbst z.B. auf /dev/sda1 zuhause ist. Deswegen habe ich empfohlen:

Das System darf also, damit das reibungslos geht, nicht von /dev/sda gebootet sein, sondern vorzugsweise von einem externen Datenträger.

Also nimm am einfachsten die Live-CD/DVD irgendeiner aktuellen Distro, gern auch Mint, und boote das System von dieser CD/DVD. Die Netzwerkfreigabe musst du dann aber "von Hand" mounten.

So long,
 Martin

[Karl Heinz]

Beim Lesen mag das mit Zähneknirschen und Backenzusammenkneifen noch akzeptabel sein, beim Zurückschreiben aber ganz sicher nicht.

Ich dachte halt beim Image Erstellen bzw. beim Lesen geht das auch ohne Live CD, ich dachte ich brauche die Live CD nur beim Image zurueckspielen bzw. Schreiben.

Also nimm am einfachsten die Live-CD/DVD irgendeiner aktuellen Distro, gern auch Mint, und boote das System von dieser CD/DVD. Die Netzwerkfreigabe musst du dann aber "von Hand" mounten.

Hab jetzt mit einer Mint Live CD gebootet.

ddrescue installiert. Wo wurde das jetzt eigentlich hin installiert. In den RAM.

Will das Image jetzt erstmal auf dem NAS speichern, deshalb wollte ich das NAS wie folgt haendich mounten, klappt aber nicht.

sudo mount //192.168.178.71/karlheinz /media/karlheinz

Ich werde nach einem Passwort gefragt. Dachte das ist das Passwort fuer die Freigabe. Gebe ich dieses ein so bekomme ich folgende Fehlermeldung.

mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Was mache ich falsch.

bzw. warum fragt mich das System NUR nach dem Passwort der Freigabe und nicht nach dem Login der Freigabe.

PS> sorry wergen der Satzzeichen mit der Live CD funktioniert die Tastatur nicht auf Deutsch. Wie kann ich die den auf die schnelle umstellen.

[Der Martin]

Moin,

Beim Lesen mag das mit Zähneknirschen und Backenzusammenkneifen noch akzeptabel sein, beim Zurückschreiben aber ganz sicher nicht.

Ich dachte halt beim Image Erstellen bzw. beim Lesen geht das auch ohne Live CD, ich dachte ich brauche die Live CD nur beim Image zurueckspielen bzw. Schreiben.

naja, wie gesagt: Denkbar wäre das. Aber ich stimme Christian auch zu, dass man damit ein defektes Image erzeugt, das nach dem Zurückspielen mit an Sicherheit grenzender Wahrscheinlichkeit noch repariert werden muss. Also macht man's besser gleich "sauber".

Will das Image jetzt erstmal auf dem NAS speichern, deshalb wollte ich das NAS wie folgt haendich mounten, klappt aber nicht.

sudo mount //192.168.178.71/karlheinz /media/karlheinz

Ich werde nach einem Passwort gefragt. Dachte das ist das Passwort fuer die Freigabe.

Ist es auch. Normalerweise würde sudo als erstes nach dem Passwort fragen, aber AFAIK sind die Live-CDs so eingerichtet, dass man für sudo kein Passwort braucht.

Gebe ich dieses ein so bekomme ich folgende Fehlermeldung.

mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Was mache ich falsch.

Du hast mount nicht verraten, unter welchem Benutzernamen auf die Freigabe zugegriffen werden soll. Dann wird standardmäßig der Name des aktuell angemeldeten Linux-Users genommen. Gib Namen und Passwort für die Freigabe am besten direkt als mount-Option mit an:

sudo mount -o username=***,password=*** //192.168.178.71/karlheinz /media/karlheinz

Beachte, dass der gesamte String nach dem -o ohne Leerzeichen geschrieben wird.

PS> sorry wergen der Satzzeichen mit der Live CD funktioniert die Tastatur nicht auf Deutsch. Wie kann ich die den auf die schnelle umstellen.

Du benutzt doch vermutlich die Live-CD auch mit graphischer Oberfläche, oder? Dann geh ins "Control Center", klicke dort im Abschnitt Hardware auf Keyboard. Da kannst du die Tastatureinstellungen anpassen, auch das Layout.

So long,
 Martin

[Tabellenkalk]

Hallo,

sudo mount -o username=***,password=*** //192.168.178.71/karlheinz /media/karlheinz

Beachte, dass der gesamte String nach dem -o ohne Leerzeichen geschrieben wird.

öh, und was ist das jeweils zwischen "*" und "/" bzw. "z" und "/"?

Gruß
Kalk

[Shell-Erklärbär]

sudo mount -o username=***,password=*** //192.168.178.71/karlheinz /media/karlheinz

Beachte, dass der gesamte String nach dem -o ohne Leerzeichen geschrieben wird.

öh, und was ist das jeweils zwischen "*" und "/" bzw. "z" und "/"?

Martin meint, dass das das Optionsargument username=***,password=*** ohne Leerzeichen notiert werden muss, weil der auf das (erste) Leerzeichen folgend Teil sonst als erstes allgemeines Argument interpretiert wird. Notiert man username=***, password=*** dann würde das Programm mount annehmen, dass password=*** die zu mountende Ressource sei und natürlich meckern, dass es dieses Gerät bzw. Datei nicht gäbe.

Wer will kann ja mal

sudo mount -o "username=***, password=***" //192.168.178.71/karlheinz /media/karlheinz

versuchen. Das sollte eigentlich gehen. Das gleiche gilt dann für username=***. Ist vor oder nach dem = ein Leerzeichen versagt (wahrscheinlich) die Zuordnung von key=value - aber das hier Sache des konkreten Programms (mount) und ich habe das nicht getestet.

Kritik:

Der gewählte Zielordner ist nicht ohne Bedeutung. Gibt es einen Benutzer "karlheinz" dann ist /media/karlheinz der (Standard-)Ordner in welchem der Automounter des grafischen Desktops selbst Ordner zum Zweck des Mountens anlegen will. Gibt es /media/$username/ nicht legt er auch diesen an. /media/ oder /media/$USERNAME sollte man deshalb nicht für "vom User gesteuerte" Aktionen benutzen. Jedenfalls wenn man nicht sehr genau weiß was man gerade tut.

Hier könnte zum Beispiel das Einstecken eines weiteren USB-Sticks für ein recht merkwürdiges Systemverhalten sorgen: Der Automounter würde versuchen `/media/karlheinz/Label_oder_UID_des_Sticks' anzulegen...

Dann gilt: Viel Spaß bei der Fehlersuche. "Finger weg" vom /media/ ist einfacher.

[Karl Heinz]

Kritik:

Der gewählte Zielordner ist nicht ohne Bedeutung. Gibt es einen Benutzer "karlheinz" dann ist /media/karlheinz der (Standard-)Ordner in welchem der Automounter des grafischen Desktops selbst Ordner zum Zweck des Mountens anlegen will. Gibt es /media/$username/ nicht legt er auch diesen an. /media/ oder /media/$USERNAME sollte man deshalb nicht für "vom User gesteuerte" Aktionen benutzen. Jedenfalls wenn man nicht sehr genau weiß was man gerade tut.

Hier könnte zum Beispiel das Einstecken eines weiteren USB-Sticks für ein recht merkwürdiges Systemverhalten sorgen: Der Automounter würde versuchen `/media/karlheinz/Label_oder_UID_des_Sticks' anzulegen...

Dann gilt: Viel Spaß bei der Fehlersuche. "Finger weg" vom /media/ ist einfacher.

Hierzu eine schönes praktisches Beispiel was mir Kopfzerbrechen bereitet hat:

Auf dem Linux Rechner habe ich ein Netzlaufwerk eingebunden. Das eingebundene Laufwerk liegt physikalisch auf einer NAS. Der Pfad für die Einbindung ist /media/karlheinz. Wenn ich nun eine CD ins Laufwerk packe, so wird diese ja automatisch vom System nach /media/karlheinz/<cdname> gemountet. Mit Hilfe von "Back in Time" sichere ich das Verzeichnis /media/karlheinz täglich inkrementell. Dadurch, dass CDs automatisch immer unterhalb von /media/karlheinz gemounted werden führt es dazu, das eingelegte CDs automatisch von "Back in Time" mitgesichert werden.

Ziemlich dumm :-)

[Karl Heinz]

sudo mount -o username=***,password=*** //192.168.178.71/karlheinz /media/karlheinz

Beachte, dass der gesamte String nach dem -o ohne Leerzeichen geschrieben wird.

Das hat jetzt geklappt.

Nun muss ich ja auch noch die Festplatte mounten von der ich das Image erstellen moechte.

Hab dazu zunaechst das Tool Laufwerke bzw. Disks benutzt.

Laufwerke zeigt mir die SSD mit 128 GB an. Da steht dann u.a. not mounted und /dev/sda.

Deshalb wollte ich zunaechst /dev/sda wie folgt haendisch mounten:

sudo mount /dev/sda /media/sda

Bekomme dann folgende Meldung:

mount: /dev/sda already mounted or /media/sda busy

Das verstehe ich nicht. Das Tool Laufwerke sagt /dev/sda ist noch nicht gemounted. Die Shell hingegen sagt es ist gemounted.

Wer hat denn nun recht, die Shell oder das Tool Laufwerke.

Im Cinnamon Nemo wird mir eine HD angezeigt, die hat allerdings nicht 128 GB sondern nur 93 GB. Irgendwie wurden wohl nicht alle 3 Partitionen von /dev/sda gemounted sondern nur eine.

[Shell-Erklärbär]

Laufwerke zeigt mir die SSD mit 128 GB an. Da steht dann u.a. not mounted und /dev/sda.

/dev/sda mag ein Gerät sein - aber auf einer SSD hast Du gewöhnlich eine Partition, welche gemountet werden soll. Die heisst dann /dev/sda1, also /dev/sda[Nr]. Erwartest Du eine partitionierte Platte? Dann hast Du nicht richtig hingesehen. Oder ist diese noch nicht partitioniert?

Falls Du /dev/sda1 mit /dev/sda verwechselt hast kannst Du mit

df -h | grep /dev/sda
# oder
mount | grep /dev/sda

nachsehen, was los ist. Vermutlich wurde die Partition automatisch eingehangen. Lese hier unter "Kritik" nach.

Falls die Partionstabelle auf /dev/sda zerstört ist, ist Testdisk oder gpart das richtige Tool.

Beide kann man unter Ubuntu mit sudo apt-get update && sudo apt-get install testdisk gpart installieren. Bitte lese das Manual der Programme (man testdisk) und vermeide es die Partionen ohne Testlauf wieder herstellen zu lassen. Normalerweise macht man das mit einer Kopie der Platte, die mit dd oder ddrescue als Datei gesichert wurde. Gib die Datei als "Gerät" an.

[Der Martin]

Hi,

sudo mount -o username=***,password=*** //192.168.178.71/karlheinz /media/karlheinz

Beachte, dass der gesamte String nach dem -o ohne Leerzeichen geschrieben wird.

Das hat jetzt geklappt.

na also. Ein Schritt nach dem anderen.

Nun muss ich ja auch noch die Festplatte mounten von der ich das Image erstellen moechte.

Nein! Im Gegenteil, die Platte oder Partition, von der du das Image ziehen möchtest, sollte nach Möglichkeit NICHT gemountet sein.

Hab dazu zunaechst das Tool Laufwerke bzw. Disks benutzt.

Laufwerke zeigt mir die SSD mit 128 GB an. Da steht dann u.a. not mounted und /dev/sda.

Deshalb wollte ich zunaechst /dev/sda wie folgt haendisch mounten:

sudo mount /dev/sda /media/sda

Das wird nicht gehen. Abgesehen davon, dass das für deinen Zweck gar nicht gewünscht ist, muss man jedes Dateisystem (also jede Partition) für sich mounten.

Bekomme dann folgende Meldung:

mount: /dev/sda already mounted or /media/sda busy

Das verstehe ich nicht. Das Tool Laufwerke sagt /dev/sda ist noch nicht gemounted. Die Shell hingegen sagt es ist gemounted.

Wer hat denn nun recht, die Shell oder das Tool Laufwerke.

Beide. Das Gerät /dev/sda (die Platte als Ganzes) ist nicht gemountet. Eine oder mehrere Partitionen darauf aber vermutlich schon.

Im Cinnamon Nemo wird mir eine HD angezeigt, die hat allerdings nicht 128 GB sondern nur 93 GB. Irgendwie wurden wohl nicht alle 3 Partitionen von /dev/sda gemounted sondern nur eine.

Wie ist die denn partitioniert? Eine der drei Partitionen ist vermutlich swap, die wird nicht automatisch gemountet, gewöhnliche Dateisysteme aber schon.

So long,
 Martin

[Karl Heinz]

Nun muss ich ja auch noch die Festplatte mounten von der ich das Image erstellen moechte.

Nein! Im Gegenteil, die Platte oder Partition, von der du das Image ziehen möchtest, sollte nach Möglichkeit NICHT gemountet sein.

mmm, aber ich muss ddrescue doch sagen von welchem Gerät das Image erstellt werden soll. Damit ich diese Gerät ansprechen kann muss ich es doch mounten. Denn ohne mounten ist ja kein Ansprechen möglich? Auf der anderen Seite darf ich nicht mounten, weil es sonst Probleme beim Image geben kann. Ich glaub ich hab hier ein grundsätzliches Verständnisproblem.

Hab dazu zunaechst das Tool Laufwerke bzw. Disks benutzt.

Laufwerke zeigt mir die SSD mit 128 GB an. Da steht dann u.a. not mounted und /dev/sda.

Deshalb wollte ich zunaechst /dev/sda wie folgt haendisch mounten:

sudo mount /dev/sda /media/sda

Das wird nicht gehen. Abgesehen davon, dass das für deinen Zweck gar nicht gewünscht ist, muss man jedes Dateisystem (also jede Partition) für sich mounten.

Achso, das Tool Laufwerke zeigt mir auf /dev/sda drei Partitionen kann. Ich kann demnach immer nur eine Partition auf ein Verzeichnis mounten und niemals mehrere Partitionen auf ein Verzeichnis. Stimmt das so?

Das verstehe ich nicht. Das Tool Laufwerke sagt /dev/sda ist noch nicht gemounted. Die Shell hingegen sagt es ist gemounted.

Wer hat denn nun recht, die Shell oder das Tool Laufwerke.

Beide. Das Gerät /dev/sda (die Platte als Ganzes) ist nicht gemountet. Eine oder mehrere Partitionen darauf aber vermutlich schon.

Ist es denn überhaupt möglich die Platte als ganzes zu mounten?

Ich brauch doch ein Image von der ganzen Platte und nicht nur von einer Partion, sonst ist das Image ja nicht vollständig.

bzw. du schreibst ein oder mehrere Partitionen auf der Platte sind gemounted. Es dürfen aber doch keine Partitionen gemounted sein, da sonst etwas beim Erstellen des Images schiefgehen kann. Muss ich die dann aushängen bevor ich das Image erstelle?

Im Cinnamon Nemo wird mir eine HD angezeigt, die hat allerdings nicht 128 GB sondern nur 93 GB. Irgendwie wurden wohl nicht alle 3 Partitionen von /dev/sda gemounted sondern nur eine.

Wie ist die denn partitioniert? Eine der drei Partitionen ist vermutlich swap, die wird nicht automatisch gemountet, gewöhnliche Dateisysteme aber schon.

Waren halt die Standardeinstellungen bei der Mint Installation:

• Filesystem Partition 1 537 MB FAT (keine Ahnung wozu die gut ist)
• Filesystem Partition 2 93 GB Ext4 (hier ist wohl Mint installiert oder?)
• Swap Partition 3 34 GB Swap (keine Ahnung wozu die gut ist)

Noch eine andere Frage: Ich habe ddrescue ja nach dem Booten mit der Live-CD installiert. Wohin wird das denn dann installiert. Auf eine der Festplatten, sprich darf nach dem Booten von der Live-CD einfach so etwas auf eine Festplatte installiert werden bzw. ist das dann immernoch installiert wenn ich wieder normal (ohne Live-CD) boote?

[Der Martin]

Hallo,

Nein! Im Gegenteil, die Platte oder Partition, von der du das Image ziehen möchtest, sollte nach Möglichkeit NICHT gemountet sein.

mmm, aber ich muss ddrescue doch sagen von welchem Gerät das Image erstellt werden soll.

ja, richtig.

Damit ich diese Gerät ansprechen kann muss ich es doch mounten. Denn ohne mounten ist ja kein Ansprechen möglich?

Das ist ein Irrtum.

Auf der anderen Seite darf ich nicht mounten, weil es sonst Probleme beim Image geben kann. Ich glaub ich hab hier ein grundsätzliches Verständnisproblem.

Sieht so aus. Ist aber nicht schlimm.

Die Gerätedatei /dev/sda beispielsweise, die das Gerät "Erste erkannte Festplatte" repräsentiert, ist immer ansprechbar, ebenso die Partitionen auf dieser Platte /dev/sda1, /dev/sda2 usw. Das heißt, es ist jederzeit möglich, sozusagen unstrukturiert auf den Datenträger zuzugreifen.

Erst wenn du datei-orientiert auf den Inhalt einer Partition (eines Filesystems) zugreifen willst, musst du dieses Filesystem in das bereits vorhandene einbinden, also mounten.

sudo mount /dev/sda /media/sda

Das wird nicht gehen. Abgesehen davon, dass das für deinen Zweck gar nicht gewünscht ist, muss man jedes Dateisystem (also jede Partition) für sich mounten.

Achso, das Tool Laufwerke zeigt mir auf /dev/sda drei Partitionen kann. Ich kann demnach immer nur eine Partition auf ein Verzeichnis mounten und niemals mehrere Partitionen auf ein Verzeichnis. Stimmt das so?

Natürlich: Jede Partition braucht ihren eigenen sogenannten Mountpoint, also das Verzeichnis, in dem der Inhalt des Filesystems bereitgestellt wird.

Ist es denn überhaupt möglich die Platte als ganzes zu mounten?

Nein.

Ich brauch doch ein Image von der ganzen Platte und nicht nur von einer Partion, sonst ist das Image ja nicht vollständig.

Naja, man kann die Partitionen auch jede für sich "imagen". Dann muss man vor dem Zurücksichern auf ein fabrikneues Laufwerk erst neue Partitionen derselben Größe anlegen. Aber das Einzeln-Imagen hat einen anderen Vorteil: Wenn jede Imagedatei genau ein Filesystem enthält, kann man auch das Image selbst mounten, als ob es eine Partition wäre, und so auf einzelne Dateien in diesem Image zugreifen. So mache ich das normalerweise, wenn ich Daten von einer möglicherweise defekten Platte retten will: Ich erzeuge ein Image der Partition(en), mounte dann das Image und kann da in aller Ruhe die Dateien durchsuchen und analysieren, ohne die Platte selbst noch irgendwie zu stressen.

bzw. du schreibst ein oder mehrere Partitionen auf der Platte sind gemounted. Es dürfen aber doch keine Partitionen gemounted sein, da sonst etwas beim Erstellen des Images schiefgehen kann. Muss ich die dann aushängen bevor ich das Image erstelle?

Ja. Ich hatte nicht daran gedacht, dass der Desktop eines Live-Systems die Partitionen der internen Festplatte(n) ungefragt von sich aus mountet.

Wie ist die denn partitioniert? Eine der drei Partitionen ist vermutlich swap, die wird nicht automatisch gemountet, gewöhnliche Dateisysteme aber schon.

Waren halt die Standardeinstellungen bei der Mint Installation:

• Filesystem Partition 1 537 MB FAT (keine Ahnung wozu die gut ist)
• Filesystem Partition 2 93 GB Ext4 (hier ist wohl Mint installiert oder?)
• Swap Partition 3 34 GB Swap (keine Ahnung wozu die gut ist)

Hmm, mir ist schleierhaft, wozu der Installer eine FAT-Partition anlegt. Der Größe nach ist es vermutlich /boot, aber ich käme nicht auf die Idee, die als FAT anzulegen. Ähm, ja .. die swap-Partition ist quasi der "virtuelle Speicher". Kommt mir allerdings gigantisch groß vor.

Noch eine andere Frage: Ich habe ddrescue ja nach dem Booten mit der Live-CD installiert. Wohin wird das denn dann installiert. Auf eine der Festplatten, sprich darf nach dem Booten von der Live-CD einfach so etwas auf eine Festplatte installiert werden bzw. ist das dann immernoch installiert wenn ich wieder normal (ohne Live-CD) boote?

Alles, was du mit der Live-CD anstellst, ist beim nächsten Booten wieder weg. Denn da wird das gesamte Betriebssystem beim Booten in eine RAM-Disk kopiert und läuft dann dort. Auf die Festplette(n) wird nur geschrieben, wenn du das explizit willst.

Wenn man es permanent möchte, kann man zu einem andern Trick greifen: Man installiert das System "ganz normal", aber nicht auf die interne Festplatte, sondern z.B. auf einen USB-Stick. Ein 32GB-Stick würde wohl schon genügen. So ein System kann man dann direkt von USB booten, und Änderungen (Installation zusätzlicher Software oder benutzerspezifische Einstellungen) werden wie üblich gespeichert. Auf dem USB-Stick.

So long,
 Martin

[Karl Heinz]

Ich brauch doch ein Image von der ganzen Platte und nicht nur von einer Partion, sonst ist das Image ja nicht vollständig.

Naja, man kann die Partitionen auch jede für sich "imagen". Dann muss man vor dem Zurücksichern auf ein fabrikneues Laufwerk erst neue Partitionen derselben Größe anlegen. Aber das Einzeln-Imagen hat einen anderen Vorteil: Wenn jede Imagedatei genau ein Filesystem enthält, kann man auch das Image selbst mounten, als ob es eine Partition wäre, und so auf einzelne Dateien in diesem Image zugreifen. So mache ich das normalerweise, wenn ich Daten von einer möglicherweise defekten Platte retten will: Ich erzeuge ein Image der Partition(en), mounte dann das Image und kann da in aller Ruhe die Dateien durchsuchen und analysieren, ohne die Platte selbst noch irgendwie zu stressen.

Du schreibst "man KANN die Partitionen auch jede für sich "imagen"". KANN bedeutet im Umkehrschluss, dass es auch anders geht, liest sich zumindest so, sprich es sollte auch möglich sein alle drei Partitionen zusammen zu Imagen, auch wenn mir dadurch der von Dir genannte Vorteil verloren geht. Stimmt das? Falls ja, wie kann ich Mehrfach-Imagen?

Hmm, mir ist schleierhaft, wozu der Installer eine FAT-Partition anlegt. Der Größe nach ist es vermutlich /boot, aber ich käme nicht auf die Idee, die als FAT anzulegen. Ähm, ja .. die swap-Partition ist quasi der "virtuelle Speicher". Kommt mir allerdings gigantisch groß vor.

Also ich habe 32 GB RAM. Laut (Christian) soll die Swap-Partion so groß sein, dass der RAM zweimal reinpasst. Das wären dann 64 GB Swap. Dann wäre meine Swap-Parition zu klein und nicht zu groß?

[Der Martin]

Hallo,

Naja, man kann die Partitionen auch jede für sich "imagen". Dann muss man vor dem Zurücksichern auf ein fabrikneues Laufwerk erst neue Partitionen derselben Größe anlegen. Aber das Einzeln-Imagen hat einen anderen Vorteil: Wenn jede Imagedatei genau ein Filesystem enthält, kann man auch das Image selbst mounten, als ob es eine Partition wäre, und so auf einzelne Dateien in diesem Image zugreifen. So mache ich das normalerweise, wenn ich Daten von einer möglicherweise defekten Platte retten will: Ich erzeuge ein Image der Partition(en), mounte dann das Image und kann da in aller Ruhe die Dateien durchsuchen und analysieren, ohne die Platte selbst noch irgendwie zu stressen.

Du schreibst "man KANN die Partitionen auch jede für sich "imagen"". KANN bedeutet im Umkehrschluss, dass es auch anders geht, liest sich zumindest so, sprich es sollte auch möglich sein alle drei Partitionen zusammen zu Imagen, auch wenn mir dadurch der von Dir genannte Vorteil verloren geht. Stimmt das?

ja, sicher. Das ist ja genau das, was du die ganze Zeit anstrebst.

Falls ja, wie kann ich Mehrfach-Imagen?

Äh, wie meinst du das jetzt?

Dein Ansatz:
Eine Imagedatei von /dev/sda. Entspricht der gesamten Platte mit allen Partitionen.

Meine Alternative:
Mehrere Imagedateien von /dev/sda1, /dev/sda2 und /dev/sda3. Jede davon entspricht dann einer Partition.

Ähm, ja .. die swap-Partition ist quasi der "virtuelle Speicher". Kommt mir allerdings gigantisch groß vor.

Also ich habe 32 GB RAM.

Oh. Das ist'n Haufen Holz. Ich bin eher so von typischen Werten irgendwo bei 4..8GB ausgegangen.

Laut (Christian) soll die Swap-Partion so groß sein, dass der RAM zweimal reinpasst. Das wären dann 64 GB Swap. Dann wäre meine Swap-Parition zu klein und nicht zu groß?

Nein, "zu klein" ist sie nicht. Was Christian erwähnt hat, ist nur eine Empfehlung, kein Muss. Solange der PC den Anforderungen gewachsen ist und nicht auffallend Gebrauch von der Swap-Partition macht (das würde man irgendwann merken, weil die Kiste lahm wird und nur noch zäh reagiert), ist alles okay.

Ciao,
 Martin

[Christian Kruse]

Hallo Martin,

Laut (Christian) soll die Swap-Partion so groß sein, dass der RAM zweimal reinpasst. Das wären dann 64 GB Swap. Dann wäre meine Swap-Parition zu klein und nicht zu groß?

Nein, "zu klein" ist sie nicht. Was Christian erwähnt hat, ist nur eine Empfehlung, kein Muss. Solange der PC den Anforderungen gewachsen ist und nicht auffallend Gebrauch von der Swap-Partition macht (das würde man irgendwann merken, weil die Kiste lahm wird und nur noch zäh reagiert), ist alles okay.

Zuverlässiges Suspend to disk ist nur möglich, wenn der Swap 2x RAM groß ist: im worst case wird der RAM in den Swap ausgelagert und dann muss nochmal soviel Platz da sein für das suspend.

Nutzt man Suspend to disk nicht, braucht man bei 32GB eigentlich auch gar keinen Swap.

LG,
CK

[Der Martin]

Hallo,

Nein, "zu klein" ist sie nicht. Was Christian erwähnt hat, ist nur eine Empfehlung, kein Muss. Solange der PC den Anforderungen gewachsen ist und nicht auffallend Gebrauch von der Swap-Partition macht (das würde man irgendwann merken, weil die Kiste lahm wird und nur noch zäh reagiert), ist alles okay.

Zuverlässiges Suspend to disk ist nur möglich, wenn der Swap 2x RAM groß ist: im worst case wird der RAM in den Swap ausgelagert und dann muss nochmal soviel Platz da sein für das suspend.

an STD habe ich noch gar nicht gedacht, weil ich selbst das noch nie genutzt habe. Klar, dann braucht man eine entsprechende Größe.

Nutzt man Suspend to disk nicht, braucht man bei 32GB eigentlich auch gar keinen Swap.

Das hatte ich ja auch schon angedeutet.

Ciao,
 Martin

[Karl Heinz]

Naja, man kann die Partitionen auch jede für sich "imagen". Dann muss man vor dem Zurücksichern auf ein fabrikneues Laufwerk erst neue Partitionen derselben Größe anlegen. Aber das Einzeln-Imagen hat einen anderen Vorteil: Wenn jede Imagedatei genau ein Filesystem enthält, kann man auch das Image selbst mounten, als ob es eine Partition wäre, und so auf einzelne Dateien in diesem Image zugreifen. So mache ich das normalerweise, wenn ich Daten von einer möglicherweise defekten Platte retten will: Ich erzeuge ein Image der Partition(en), mounte dann das Image und kann da in aller Ruhe die Dateien durchsuchen und analysieren, ohne die Platte selbst noch irgendwie zu stressen.

Du schreibst "man KANN die Partitionen auch jede für sich "imagen"". KANN bedeutet im Umkehrschluss, dass es auch anders geht, liest sich zumindest so, sprich es sollte auch möglich sein alle drei Partitionen zusammen zu Imagen, auch wenn mir dadurch der von Dir genannte Vorteil verloren geht. Stimmt das?

ja, sicher. Das ist ja genau das, was du die ganze Zeit anstrebst.

Falls ja, wie kann ich Mehrfach-Imagen?

Äh, wie meinst du das jetzt?

Habs jetzt endlich verstanden!

Dein Ansatz:
Eine Imagedatei von /dev/sda. Entspricht der gesamten Platte mit allen Partitionen.

Meine Alternative:
Mehrere Imagedateien von /dev/sda1, /dev/sda2 und /dev/sda3. Jede davon entspricht dann einer Partition.

• Ich will zunaechst /dev/sda komplett Imagen
• Alle drei Partionen sind unmount
• Gebootet habe ich mit Live CD
• Freigabe auf dem NAS auf der das Image gespeichert werden soll ist gemounted unter /media/karlheinz im Verzeichnis /media/karlheinz habe ich das Unterverzeichnis images erstellt
• Dann folgende Zeile in die Shell:

sudo ddrescue -b2048 /dev/sda /media/karlheinz/images/image-karlheinz.img logfile1

Jaaa, es lauft los, das war eine schwere Geburt.

Nochmal vielen Dank.

[Christian Kruse]

Hallo Karl,

mmm, aber ich muss ddrescue doch sagen von welchem Gerät das Image erstellt werden soll. Damit ich diese Gerät ansprechen kann muss ich es doch mounten.

Nein, ddrescue arbeitet direkt auf dem Blockdevice, unter dem Dateisystem. Das Device sollte nicht gemountet sein.

Achso, das Tool Laufwerke zeigt mir auf /dev/sda drei Partitionen kann. Ich kann demnach immer nur eine Partition auf ein Verzeichnis mounten und niemals mehrere Partitionen auf ein Verzeichnis. Stimmt das so?

Vereinfacht ist das richtig.

Ist es denn überhaupt möglich die Platte als ganzes zu mounten?

Nur, wenn du das Dateisystem auf die Platte direkt geschrieben hast, ohne Volumes zu erstellen.

bzw. du schreibst ein oder mehrere Partitionen auf der Platte sind gemounted. Es dürfen aber doch keine Partitionen gemounted sein, da sonst etwas beim Erstellen des Images schiefgehen kann. Muss ich die dann aushängen bevor ich das Image erstelle?

Ja.

• Filesystem Partition 1 537 MB FAT (keine Ahnung wozu die gut ist)

Das wird die EFI System Partition sein.

• Filesystem Partition 2 93 GB Ext4 (hier ist wohl Mint installiert oder?)

Höchstwahrscheinlich.

• Swap Partition 3 34 GB Swap (keine Ahnung wozu die gut ist)

Das ist sowas wie die virtuelle Auslagerungsdatei bei Windows; die sollte so gross sein, dass der RAM das 2x rein passt.

Noch eine andere Frage: Ich habe ddrescue ja nach dem Booten mit der Live-CD installiert. Wohin wird das denn dann installiert. Auf eine der Festplatten, sprich darf nach dem Booten von der Live-CD einfach so etwas auf eine Festplatte installiert werden bzw. ist das dann immernoch installiert wenn ich wieder normal (ohne Live-CD) boote?

Ins RAM. Nach dem neu booten ist es wieder weg.

LG,
CK

[Karl Heinz]

Ist es denn überhaupt möglich die Platte als ganzes zu mounten?

Nur, wenn du das Dateisystem auf die Platte direkt geschrieben hast, ohne Volumes zu erstellen.

Mit "ohne Volumens" meinst du das ich nur eine Partition existiert oder?

• Filesystem Partition 1 537 MB FAT (keine Ahnung wozu die gut ist)

Das wird die EFI System Partition sein.

Das heißt hier auf jedenfall ein Image erstellen, da diese Partition notwendig ist, damit gebootet werden kann?

• Filesystem Partition 2 93 GB Ext4 (hier ist wohl Mint installiert oder?)

Höchstwahrscheinlich.

Hier logischerweiße ein zweites Image erstellen?

• Swap Partition 3 34 GB Swap (keine Ahnung wozu die gut ist)

Das ist sowas wie die virtuelle Auslagerungsdatei bei Windows; die sollte so gross sein, dass der RAM das 2x rein passt.

Von der Swap Partition brauch ich doch eigentlich kein Image, dass ist ja sowas wie ein Notfall-RAM der nur zwischenspeichert, sprich hier ist nichts was mit einem Image gesichert werden müsste. Brauch ich dann hier kein Image?

In der Ubuntu Hilfe habe ich gelesen das 1 GB reichen soll, Martin schreibt 34 GB sind zu groß, du schreibst doppelt so groß wieder RAM (das wären bei mir dann 64 GB weil ich 32 GB RAM). Bin jetzt verwirrt was richtig ist.

[Der Martin]

Hi,

Ist es denn überhaupt möglich die Platte als ganzes zu mounten?

Nur, wenn du das Dateisystem auf die Platte direkt geschrieben hast, ohne Volumes zu erstellen.

Mit "ohne Volumens" meinst du das ich nur eine Partition existiert oder?

nein, nicht "nur eine Partition", sondern gar kein Partitionsschema. Hat man damals[tm] bei Disketten so gemacht, heute noch vereinzelt bei USB-Sticks.

Von der Swap Partition brauch ich doch eigentlich kein Image, dass ist ja sowas wie ein Notfall-RAM der nur zwischenspeichert, sprich hier ist nichts was mit einem Image gesichert werden müsste. Brauch ich dann hier kein Image?

Korrekt.

In der Ubuntu Hilfe habe ich gelesen das 1 GB reichen soll

Das stammt wohl noch aus der Zeit, als 1GB RAM noch wirklich viel war.

Martin schreibt 34 GB sind zu groß, du schreibst doppelt so groß wieder RAM (das wären bei mir dann 64 GB weil ich 32 GB RAM). Bin jetzt verwirrt was richtig ist.

Es gibt kein eindeutiges "richtig". Es kommt auf die Anforderungen an. Theoretisch kann man auf Swap auch ganz verzichten, wenn man ordentlich viel RAM hat. Aber "Swap mindestens so groß wie RAM" ist eine Faustregel, die ich auch schon öfter gehört habe.

So long,
 Martin

[Karl Heinz]

Schritt 4:

ddrescue -b2048 //192.168.178.71/karlheinz/images/image-karlheinz.iso /dev/sda logfile2

Dazu brauchst du, wie die Beschreibung sagt, den Schalter -f. Und du musst du den PC von einem externen Medium starten (Live-CD oder USB-Stick). Denn wenn die aktive Systempartition auf /dev/sda liegt, sollte ddrescue sich weigern, auf dieses Medium zurückzusichern.

Nachdem ich das Image von Rechner 1 nun erfolgreich auf dem NAS gesichert habe möchte ich das Einspielen des Images natürlich testen.

Dazu bin ich wie folgt vorgegangen:

• Rechner 2 (der baugleich wie Rechner 1 ist) mit Live CD gebootet
• Freigabe auf dem NAS mit Image auf /media/karlheinz eingebunden
• Folgende Zeile in der Shell ausgeführt:

ddrescue -f -b2048 /media/karlheinz/images/image-karlheinz.img /dev/sda logfile

• Image wurde erfolgreich (ohne Fehler in der Logdatei) eingespielt
• Rechner 2 neu gebootet (diesmal ohne Live CD)

Ergebnis:

• Grundsätzlich scheint alles zu passen (alle Programme vom Image sind da)
• Während des Bootvorgangs kommt allerdings folgende Meldung die ich nicht nachvollziehen kann:

keys: Weiterhin warten, das Einhängen mit S überspringen oder eine manuelle Herstellung mit M starten

• Nach Betätigen von S während des Bootens sind die drei Freigaben von der NAS (die ich per fstab einbinde) alle einwandfrei vorhanden, der Zugriff funktioniert
• Die Datenplatte (1 TB) hingegen (die im Desktop selbst neben der 128 GB SSD als zweite Platte verbaut ist) wird nicht korrekt eingebunden. Das Einbinden der Datenplatte habe ich ebenfalls per fstab realisiert. Kann es sein, dass das Einbinden beim Booten deshalb nicht möglich ist, weil die Datenplatte auf Rechner 2 im Gegensatz zu Rechner 1 noch nicht formiert wurde, sprich ist das die Ursache für die Meldung oben, die beim Booten angezeigt wird?

[Der Martin]

Herzlichen Glückwunsch!

So wie ich das lese, hast du eben erfolgreich verifiziert, dass deine Methode der Datensicherung als Disaster Recovery geeignet ist. Sehr schön! Das macht den Büroschlaf doch wieder entspannter.

Ergebnis:

• Grundsätzlich scheint alles zu passen (alle Programme vom Image sind da)

Eventuell gibt's nun merkwürdige Netzwerk-Effekte, wenn beide PCs gleichzeitig am Netz sind, weil sie ja nun quasi identische Klone sind. IP-Adressen werden vermutlich dynamisch per DHCP vergeben, das sollte also kein Problem sein; vielleicht aber der nun identische Hostname (falls du überhaupt einen festgelegt hast).

Ist halt blöd, wenn der Chef an der Bürotür steht und sagt, "Herr Schumann, kommen Sie bitte mal", und dann stehen zwei Kollegen gleichzeitig auf, die sich auch noch wie ein Ei dem anderen gleichen. ;-)

• Während des Bootvorgangs kommt allerdings folgende Meldung die ich nicht nachvollziehen kann:

keys: Weiterhin warten, das Einhängen mit S überspringen oder eine manuelle Herstellung mit M starten

• Nach Betätigen von S während des Bootens sind die drei Freigaben von der NAS (die ich per fstab einbinde) alle einwandfrei vorhanden, der Zugriff funktioniert
• Die Datenplatte (1 TB) hingegen (die im Desktop selbst neben der 128 GB SSD als zweite Platte verbaut ist) wird nicht korrekt eingebunden. Das Einbinden der Datenplatte habe ich ebenfalls per fstab realisiert. Kann es sein, dass das Einbinden beim Booten deshalb nicht möglich ist, weil die Datenplatte auf Rechner 2 im Gegensatz zu Rechner 1 noch nicht formiert wurde, sprich ist das die Ursache für die Meldung oben, die beim Booten angezeigt wird?

Exakt. Linux möchte, dem Eintrag in /etc/fstab folgend, auch die zweite Platte einbinden, scheitert aber, weil sie kein brauchbares Dateisystem enthält. Die müsstest du also noch von Hand fermentieren ... äh, formatieren und mounten. Ich fauler Sack mache das meist mit gparted, wenn ich schon ein System mit GUI habe. ;-)

So long,
 Martin

[Karl Heinz]

Eventuell gibt's nun merkwürdige Netzwerk-Effekte, wenn beide PCs gleichzeitig am Netz sind, weil sie ja nun quasi identische Klone sind. IP-Adressen werden vermutlich dynamisch per DHCP vergeben, das sollte also kein Problem sein; vielleicht aber der nun identische Hostname (falls du überhaupt einen festgelegt hast).

Ist halt blöd, wenn der Chef an der Bürotür steht und sagt, "Herr Schumann, kommen Sie bitte mal", und dann stehen zwei Kollegen gleichzeitig auf, die sich auch noch wie ein Ei dem anderen gleichen. ;-)

• IP-Adressen werden per DHCP vergeben (wie von Dir vermutet)
• Hostname beider Rechner ist noch identisch (werde ich aber noch ändern)

Du schreibst was von "merkwürdige Netzwerk-Effekte"

Wie könnte denn so ein Netzwerk Effekt aussehen? Ein praktisches Beispiel wäre cool.

Exakt. Linux möchte, dem Eintrag in /etc/fstab folgend, auch die zweite Platte einbinden, scheitert aber, weil sie kein brauchbares Dateisystem enthält. Die müsstest du also noch von Hand fermentieren ... äh, formatieren und mounten. Ich fauler Sack mache das meist mit gparted, wenn ich schon ein System mit GUI habe. ;-)

Der Fehler ist jetzt auch weg :-). Habe es so gelöst wie von Dir vorgeschlagen.

[Der Martin]

Moin,

Ist halt blöd, wenn der Chef an der Bürotür steht und sagt, "Herr Schumann, kommen Sie bitte mal", und dann stehen zwei Kollegen gleichzeitig auf, die sich auch noch wie ein Ei dem anderen gleichen. ;-)

• IP-Adressen werden per DHCP vergeben (wie von Dir vermutet)
• Hostname beider Rechner ist noch identisch (werde ich aber noch ändern)

Du schreibst was von "merkwürdige Netzwerk-Effekte"

Wie könnte denn so ein Netzwerk Effekt aussehen? Ein praktisches Beispiel wäre cool.

mir fällt kein Beispiel ein. Ich dachte nur a) an den Fall, dass die IP-Adresse fest eingestellt wäre, dann hätten nun beide Rechner dieselbe IP-Adresse - das kann nicht funktionieren. Und b) hatte ich die leise Ahnung, dass zwei gleiche Hostnamen im Netz auch Probleme machen könnten, auch wenn das nur so'n Bauchgefühl ist.

Die müsstest du also noch von Hand fermentieren ... äh, formatieren und mounten. Ich fauler Sack mache das meist mit gparted, wenn ich schon ein System mit GUI habe. ;-)

Der Fehler ist jetzt auch weg :-).

Na prima. Das war vermutlich einer der leichtesten Schritte.

So long,
 Martin