Backup von einer XP Installation machen?
Bevor ich das ausprobiere frag ich mal lieber hier. Ich könnte mir dann die Ausgabe für Trueimage sparen. Hardware Thinkpad 60 mit 80GB Platte und XP prof. USB Platte mit 250GB.
fbe
Linux 14.981 Themen, 106.341 Beiträge
dl7awl 
KarstenW „Was mich an dd immer gestört hat ist, das dd überhaupt keine Fehlerprüfung...“
Ich würde die gesicherten Daten zumindest noch mit md5sum auf ihre Fehlerfreiheit testen.
Wie soll das gehen, wenn man die Daten gleich "on the fly" komprimiert hat?
Da fiele mir als einzig möglicher Weg eigentlich nur ein, zwei Kopien auf gleiche Weise anzulegen und diese dann mit diff oder md5sum zu vergleichen. Bei Gleichheit kann man davon ausgehen, dass die Daten korrekt geschrieben wurden und kann dann eine der komprimierten Imagedateien bedenkenlos wieder löschen.
Aber zugegeben, dieser Weg ist so umständlich, dass ich das nur mache, wenn ich der einwandfreien Funktion von Software, Treibern, Festplatte, Controller, RAM, DMA-Chips usw. generell misstraue bzw. solange ich die noch nicht für erwiesen halte. Also um hier - etwa bei neu erworbener Hardware - erstmal ein gewisses "Grundvertrauen" zu gewinnen, sind solche Tests sicher empfehlenswert.
Ansonsten aber bringen mich theoretische Überlegungen eher zu der Überzeugung, dass eine routinemäßige Prüfung keinen hohen Wert hat, weil man sich letztlich sowieso auf Gedeih und Verderb darauf verlassen muss, dass das System richtig arbeitet und Daten korrekt geschrieben werden.
Warum? Nun, es geht ja schon damit los, dass jedes moderne OS mit dem Konzept "virtuellen" Speichers arbeitet und den so verwaltet, dass man aus Anwendersicht gar nicht weiß, welcher Teil des vermeintlichen "RAM" im Moment gerade wirklich im echten physikalischen RAM steht und welcher auf der Platte - das ist hinter den Kulissen ein ständiges Hin und Her ("Swappen"). Zu den "bewussten" Schreibvorgängen - und nur die könnte ein Anwendungsprogramm ja prüfen -, kommen also unzählige durch das OS bzw. die Speicherverwaltung, von denen das Programm gar nichts weiß und für die es "blind" ist. Wenn sich dabei ein Fehler einschleicht, könnte der u.U. für das Programm sogar trotz Prüfung "unsichtbar" bleiben, weil es ja beim Schreiben wie bei der Prüfung von den gleichen Mechanismen abhängt. Eine Prüfung könnte somit auch eine falsche Scheinsicherheit vorgaukeln und würde im Übrigen auch nur einen geringen Teil der tatsächlich geschriebenen Daten erfassen können.
Es ist ein Teufelskreis: Jeder Prüfvorgang in einem Anwendungsprogramm hängt auch selbst von den Komponenten ab, deren Intaktheit er prüfen soll. Es fehlt eine unabhängige "Meta-Ebene", von der aus man jeden einzelnen Schreibvorgang - einschließlich derer, die das OS ständig hinter den Kulissen macht - prüfen könnte. Eine solche Meta-Ebene könnte konsequent nur mit separater Hardware realisiert werden. Ein redundanter RAID-Verbund wäre z.B. ein Schritt in diese Richtung.
Man mag sich gar nicht vorstellen, was geschieht, wenn sich statistisch auch nur bei jedem millionsten Schreibvorgang ein Bitfehler einschleicht: man würde sich über gelegentliche "unerklärliche" Abstürze wundern (bzw. tut es schon nicht mehr...), und, viel schlimmer noch, die eigenen Datenbestände würden durch den wahllos sich ausbreitenden "Mottenfraß" nach und nach unbemerkt und schleichend wertlos werden!
Server mit Uptimes von einem Jahr und mehr - mit Linux bekanntlich keine Seltenheit, und das alles mit ungeprüften Schreibvorgängen! - müssen jeden Sicherheitsfanatiker erschaudern lassen und ihm wie blanker Leichtsinn erscheinen. Sie sind andererseits aber auch ein eindrucksvoller Beleg dafür, dass auf das korrekte Zusammenspiel aller Komponenten normalerweise tatsächlich Verlass ist.
Also Prüfung gut und schön, das mag punktuell beruhigen, aber auch MIT Prüfung ist man letztlich verraten und verkauft, wenn das Gesamtsystem nicht verlässlich arbeitet. Was habe ich davon, wenn mir eine Prüfung die korrekte Sicherung von Daten bestätigt, die vielleicht unbemerkt längst korrupt sind?
Gruß, Manfred
Wie soll das gehen, wenn man die Daten gleich "on the fly" komprimiert hat?
Da fiele mir als einzig möglicher Weg eigentlich nur ein, zwei Kopien auf gleiche Weise anzulegen und diese dann mit diff oder md5sum zu vergleichen. Bei Gleichheit kann man davon ausgehen, dass die Daten korrekt geschrieben wurden und kann dann eine der komprimierten Imagedateien bedenkenlos wieder löschen.
Aber zugegeben, dieser Weg ist so umständlich, dass ich das nur mache, wenn ich der einwandfreien Funktion von Software, Treibern, Festplatte, Controller, RAM, DMA-Chips usw. generell misstraue bzw. solange ich die noch nicht für erwiesen halte. Also um hier - etwa bei neu erworbener Hardware - erstmal ein gewisses "Grundvertrauen" zu gewinnen, sind solche Tests sicher empfehlenswert.
Ansonsten aber bringen mich theoretische Überlegungen eher zu der Überzeugung, dass eine routinemäßige Prüfung keinen hohen Wert hat, weil man sich letztlich sowieso auf Gedeih und Verderb darauf verlassen muss, dass das System richtig arbeitet und Daten korrekt geschrieben werden.
Warum? Nun, es geht ja schon damit los, dass jedes moderne OS mit dem Konzept "virtuellen" Speichers arbeitet und den so verwaltet, dass man aus Anwendersicht gar nicht weiß, welcher Teil des vermeintlichen "RAM" im Moment gerade wirklich im echten physikalischen RAM steht und welcher auf der Platte - das ist hinter den Kulissen ein ständiges Hin und Her ("Swappen"). Zu den "bewussten" Schreibvorgängen - und nur die könnte ein Anwendungsprogramm ja prüfen -, kommen also unzählige durch das OS bzw. die Speicherverwaltung, von denen das Programm gar nichts weiß und für die es "blind" ist. Wenn sich dabei ein Fehler einschleicht, könnte der u.U. für das Programm sogar trotz Prüfung "unsichtbar" bleiben, weil es ja beim Schreiben wie bei der Prüfung von den gleichen Mechanismen abhängt. Eine Prüfung könnte somit auch eine falsche Scheinsicherheit vorgaukeln und würde im Übrigen auch nur einen geringen Teil der tatsächlich geschriebenen Daten erfassen können.
Es ist ein Teufelskreis: Jeder Prüfvorgang in einem Anwendungsprogramm hängt auch selbst von den Komponenten ab, deren Intaktheit er prüfen soll. Es fehlt eine unabhängige "Meta-Ebene", von der aus man jeden einzelnen Schreibvorgang - einschließlich derer, die das OS ständig hinter den Kulissen macht - prüfen könnte. Eine solche Meta-Ebene könnte konsequent nur mit separater Hardware realisiert werden. Ein redundanter RAID-Verbund wäre z.B. ein Schritt in diese Richtung.
Man mag sich gar nicht vorstellen, was geschieht, wenn sich statistisch auch nur bei jedem millionsten Schreibvorgang ein Bitfehler einschleicht: man würde sich über gelegentliche "unerklärliche" Abstürze wundern (bzw. tut es schon nicht mehr...), und, viel schlimmer noch, die eigenen Datenbestände würden durch den wahllos sich ausbreitenden "Mottenfraß" nach und nach unbemerkt und schleichend wertlos werden!
Server mit Uptimes von einem Jahr und mehr - mit Linux bekanntlich keine Seltenheit, und das alles mit ungeprüften Schreibvorgängen! - müssen jeden Sicherheitsfanatiker erschaudern lassen und ihm wie blanker Leichtsinn erscheinen. Sie sind andererseits aber auch ein eindrucksvoller Beleg dafür, dass auf das korrekte Zusammenspiel aller Komponenten normalerweise tatsächlich Verlass ist.
Also Prüfung gut und schön, das mag punktuell beruhigen, aber auch MIT Prüfung ist man letztlich verraten und verkauft, wenn das Gesamtsystem nicht verlässlich arbeitet. Was habe ich davon, wenn mir eine Prüfung die korrekte Sicherung von Daten bestätigt, die vielleicht unbemerkt längst korrupt sind?
Gruß, Manfred
