Re: Frage zu Software-Raid oder: Wie Datensicherung organisieren.
Am Dienstag, den 15.02.2005, 16:56 +0100 schrieb Matthias Houdek:
> Am Dienstag, 15. Februar 2005 15:21 schrieb Küchler, Peter:
> > Am Dienstag, den 15.02.2005, 13:37 +0100 schrieb Mario Holbe:
> > > Matthias Houdek <linux@houdek.de> 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!
[...]
> > 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.
>
> Sicher?
> Ich bin kein Hardwarespezialist, daher frage ich.
Macht doch nix;-)
> Für mich stellte sich die Sache bisher so dar, dass die schreibdefekte
> Stelle gesperrt wird und die Daten an anderer physischer Stelle (aber
> mit gleicher logischer Adresse) abgelegt werden.
Das ist auch richtig, aber:
Jetzt kommt es darauf an, wie das implementiert ist. Wie Mario in einer
Paralellmail schon sehr richtig schrieb, macht die Platte intern erstmal
"Sektor Relokation" sofern sie das noch kann. Es könnte ja auch sein,
das sie keine Reserversektoren mehr hat.
Wo Mario meiner Erfahrung nach nicht recht hat ist, das der Kontroller
davon nichts mitbekommt. Die Platte meldet das und der Kontroller
bekommt das sehr wohl mit. Weiterhin kannst dich von solchen Ereignissen
sogar unterrichten lassen (je nach Kontroller funktioniert das etwas
unterschiedlich). Das bedeutet wiederum, das es Sache des
Kontrollerbetriebssystems ist darauf in irgend einer Art und Weise zu
reagieren. Auch hier reagieren die Konroller wieder unterschiedlich.
Beispiel ICP-Vortex:
Wenn die Platte in irgend einer Form Schreibfehler o.ä. gemacht, dann
wurde der Raidverbund sofort als kritisch und die Platte selbst als
defekt markiert. Jetzt kannst Du 2 Sachen machen:
1.)Diese Platte entweder austauschen (natürlich wärend des Betriebs),
dann wird die neue Platte initialisiert und die Daten der verbliebenen
Platte neu gespiegelt.
2.)Du lässt die alte Platte drin, initialisierst sie neu (damit ist es
für den Kontroller eine neue Platte) unddann werdein die Daten der
verbliebenen Platte neu gespiegelt.
Ich konnte noch nicht beobachten das der Kontroller einen Sync zwischen
alter un neuer Platte gemacht hat.
Ich will damit nicht sagen, das Mario unrecht hat. Mir ist es nur bis
jetzt nicht bekannt. Wenn ich Zeit habe werde ich da mal drum kümmern.
> > 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.
>
> OK, das ist logisch.
> Aber das passiert doch nur, wenn eine Platte wirklich komplett
> ausgefallen ist (und deshalb getauscht wurde). Bedingt jeder
> Schreibfehler einen totalausfall der Platte?
S.o.
Es ist die Frage, wie das der Kontrollerhersteller das sieht;-)
Wenn Du mich fragst, so wäre es mir lieber wenn die Platte sofort
rausgenommen wird. Ich kann dann als Admin entscheiden, was zu tun ist:
Z.B. Platte erstmal tauschen und die defekte Platte an einem sichern Ort
Testen. Oder aber neu initialisieren und neu spiegeln. Hab ich auch
schon gemacht, die Platte ist noch ewig weiter gelaufen. Sowas passiert
halt auch mal.
[...]
> > 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.
>
> Jepp.
> Naja, oder ich baue sie dann in einen USB-Käfig und schließe darüber an
> - das hält sich preislich in Grenzen.
Oops, an steckbare USB-Platte hab ich in diesem Zusammenhang noch
garnicht gedacht. Und das obwohl ich welche hier habe...;-)
> > Ich muß ein RAID betreiben das in einem unsicheren Zustand läuft.
>
> Jepp. Aber es suggeriert u.U. mehr Sicherheit.
>
> > 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.
>
> Meine Worte.
>
> Entweder, ich habe ein ordentliches RAID - oder ich "missbrauche" es, um
> damit Backup-Spiegels zu fertigen. Aber dann fällt in dem Augenblick
> mein RAID flach. Und das Handling dieses Backups ist nicht einfacher
> oder preiswerter als mit anderen Mitteln.
>
> Und wir kommen zurück zur anfänglichen Behauptung: "RAID ist kein
> Backup" (q.e.d.) ;-)
--
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
Reply to: