Defekten PC virtualisieren

d2boxSteve schrieb:
Du kannst doch das ISO von Clonezilla der VM als Bootmedium geben.
Das Image kannst du z.B. über eine USB Platte an die VM weiterreichen.

Wie schaffe ich es,dass Clonezilla eine ISO Datei anfertigt?
 
Hast du die ISO schon heruntergeladen? Wenn nicht, da: Unbenannt.jpg

Hier der Direktlink zu Clonezilla auf SourceForge
 
Zuletzt bearbeitet:
powerfx schrieb:
Ohne Weiteres und vor allem ohne Kenntnisse, was sich auf der HDD befindet, geht das nicht.



?? Mir ist kein Weg bekannt, in dem beim Booten einer Linux-Live CD, Daten auf der Platte verändert werden bevor diese überhaupt eingehängt und gemounted ist?

Linux bietet genau dafür auch die Möglichkeit (NTFS-) Platten RO (Read-Only) zu mounten. Da passiert genau 0,0 nichts mit dem Inhalt der Platte.
 
Ähm, das image wird keine ISO, du sollst die iso von Clonezilla selber zum booten der VM verwenden .... das Image auf einen der beschriebenen Wege der VM zugänglich machen (USB-Platte, Netzwerkshare, ...) und damit dann die Wiederherstellung auf die VM Platte machen.
 
Gängige Dateisysteme haben einen Journal und zusätzliche Metadaten wie die Zugriffszeit. Diese werden auch verändert, wenn man selbst nicht aktiv schreibend zugreift.
Sun_set_1 schrieb:
Linux bietet genau dafür auch die Möglichkeit (NTFS-) Platten RO (Read-Only) zu mounten. Da passiert genau 0,0 nichts mit dem Inhalt der Platte.
Hier ist z.B. die Doku von ext4. Wenn man ro benutzt:
Mount filesystem read only. Note that ext4 will replay the journal (and thus write to the partition) even when mounted "read only".
Also wird sehr wohl etwas geschrieben und der Inhalt somit verändert. Jetzt müsste man solche Infos und Workarounds für jeder erdenkliche Dateisystem finden und genau mit der eigenen Version der Treibers vergleichen. Weil NTFS-3G könnte sich hier ganz anders verhalten. Jedenfalls sind Software-seitige Lösungen nicht zufriedenstellend. Genau deshalb gibt es auch Writeblocker.
 
powerfx schrieb:
Gängige Dateisysteme haben einen Journal und zusätzliche Metadaten wie die Zugriffszeit. Diese werden auch verändert, wenn man selbst nicht aktiv schreibend zugreift.

Also wird sehr wohl etwas geschrieben und der Inhalt somit verändert. Jetzt müsste man solche Infos und Workarounds für jeder erdenkliche Dateisystem finden und genau mit der eigenen Version der Treibers vergleichen. Weil NTFS-3G könnte sich hier ganz anders verhalten. Jedenfalls sind Software-seitige Lösungen nicht zufriedenstellend. Genau deshalb gibt es auch Writeblocker.

Das Journaling bei ext3/4 funktioniert aber komplett anders und ist daher nicht zu vergleichen. Ext4 wird vom Kernel beim booten automatisch eingehangen, NTFS nicht. Die sind normalerweise nicht eingehängt. Fürs Journaling ist aber auch ein Journaling-Bereich festgelegt. Der wird nicht größer oder kleiner. Somit besteht keine Gefahr das die Platte, auch für ein VM Anwednungszenario unbrauchbar wird.

Beim Speichern von Metadaten wird ein Journal geführt, das bedeutet, dass eine geplante Aktion zuerst in das Journal geschrieben wird. Dann wird der eigentliche Schreibzugriff auf die Daten ausgeführt, und abschließend wird das Journal aktualisiert. Wenn ein Schreibzugriff nicht vollständig beendet wird, zum Beispiel wegen eines Absturzes, braucht das Dateisystem nur die Änderungen im Journal zurückzunehmen und befindet sich anschließend wieder in einem konsistenten Zustand.
 
Das hat nichts damit zu tun, dass der Journal größer oder kleiner wird. Es geht z.B. um die Integrität aller Daten (etwa für Forensik) oder um das Verhindern jedes Schreibzugriffs (etwa bei defekter Hardware). Software schützt davor nicht zuverlässig. Wichtig ist es daher zu wissen, aus welchem Grund man Schreibzugriffe verhindern möchte. Und das war hier bei der Fragestellung nicht ganz klar.
 
Zurück
Oben