Am Dienstag, den 15.02.2005, 13:37 +0100 schrieb Mario Holbe: > Matthias Houdek <[EMAIL PROTECTED]> wrote: > > Am Dienstag, 15. Februar 2005 09:25 schrieb Mario Holbe: > >> RAID: O1 O2 O3 O4 > >> Mirror 1: O1 O2 > >> Mirror 2: O1 O4 [...]
Ich quote mit Absicht jetzt mal (fast) nichts, ich gelange langsam zu der Ansicht, das die sache inzwischen zu kopmliziert geraten ist. Komplizierter, als die Realit�t eigentlich ist! Meine absichtlich kurz gehaltenen Beschreibungen beziehen sich sich jetzt erstmal nur auf Hardwareraid. In wie weit das auf Softwareraid �bertragbar ist kann sp�ter gekl�rt werden. Also, wir gehen von einem funktionierenden, intakten RAID1 aus. Beide Platten sind als OK markiert bzw. vermerkt. Das Betriebssystem schreibt und liest Daten von dem Device, bzw. erteilt die Auftr�ge dazu (diese Zusatzbemerkung wird sp�ter noch wichtig) Pl�tzlich tritt auf Platte A ein hardwarebedingter Schreibfehler auf. Was passiert: Die Platte wird vom Kontroller als defekt markiert bzw. vermerkt. Er wird diese Platte nicht mehr anr�hren und schreibt nur noch auf Platte B weiter. Jetzt tauscht der Admin die defekte Platte gegen eine andere aus. Was passiert: Der Kontroller wird niemals hingehen und versuchen, event. auf der neuen Platte vorhandenen Daten auf die alte zu kopieren. Grund: Er hat sich _gemerkt_ welche Platte Heil geblieben ist und nur das z�hlt f�r ihn!!! Auch wenn die Daten neuer sind, was praktisch nicht m�glich ist. Denn, nachdem die Platte kaputt ist, k�nnen ja keine Daten mehr dorthin geschrieben werden. Dabei sind auch Zeitstempel auf den Dateien uninteressant, denn die haben nur G�ligkeit f�r das Betriebssystem, nicht f�r den Kontroller. Bei ruhiger �berlegung wird einem klar, das es nur so funktionieren kann, alles andere ist bei der gestellten Aufgabe (RAID) unlogisch. Was sagt uns das: Bei der Idee, das RAID-System auf diese Art und Weise als Backupsystem zu benutzen, _zwinge_ ich den Kontroller in einen f�r ihn _unat�rilchen_ Zustand. Warum: Gehen wir davon aus, das aus irgend welchen Gr�nden das Betriebssystem oder der User wichtige Daten gel�scht hat. Jetzt versuche ich, �ber den Mechanismus des spiegelns die Daten von einer alten Platte wieder herzustellen. Damit _zwinge_ ich den Kontroller eine alte, f�r ihn nicht mehr bekannte Platte zu akzeptieren und Daten aus dieser Quelle auf eine Platte zu kopieren, die f�r in die Heile Platte ist! Das w�rde jeder Logik des RAIDs wiedersprechen und man k�nnte es nur erzwingen. Ich gehe mal davon aus, das uns das allen klar ist. Abgesehen davon h�tte ich den nicht unerheblichen Nachteil, das dann _alle_ Daten wieder auf dem alten Stand sind, nicht nur die defekten! Was k�nnte ich noch tun? Ich k�nnte die Platte mit den alten Daten als zus�tzliche Oneway Mirror anmelden, ich h�tte dann praktisch zwei unabh�ngige, aber auch unvollst�ndige Spiegel. Dort k�nnte ich jetzt die Daten mit einem cp von einer Platte auf die andere kopieren. Das w�rde gehen und den Kontroller nicht interessieren, da es sich _nicht_ auf seiner Ebene abspielt und mit RAID nichts zu tun hat. Es ist Sache des Betriebssystems. Wenn ich mir jetzt die Vor und Nachteile ansehe, dann sieht das meinemr Meinung nach so aus: Vorteile: ----------- Livebackup, da die Daten auch beim schreiben und lesen abgeglichen werden. Nachteile: ----------- Ich kann die Daten auf die gleiche Art und weise nicht mehr zur�ckspielen, denn entweder wird alles zur�ckgespielt oder nichts. Ein RAID-System weis nun mal nichts von Dateisystemen. Ich habe das aufwendige Handling des Plattentauschens. Entweder aufwendige Hardware um die Platten im laufenden Betrieb zu wechseln, oder ich mu� die Kiste jedesmal f�r ein Restore 2 mal anhalten, einmal vorher, einmal nachher um die Backupplatte wieder auszubauen. Ich mu� ein RAID betreiben das in einem unsicheren Zustand l�uft. Es m�ge mir keiner �bel nehmen, aber wenn ich die Vorteile gegen die Nachteile abw�ge, dann kann ich der Backupl�sung per RAID in der Praxis nicht den Vorzug vor einem konventionellen Backup geben. -- mfg Peter K�chler, Planungsverband Ballungsraum Frankfurt/Rhein-Main Am Hauptbahnhof 18 ab 18. April 2005: Poststra�e 16 60329 Frankfurt am Main Tel.: 069-2577-1301
