Am Mittwoch, 9. Februar 2005 20:24 schrieb Thorsten Gunkel: > Matthias Houdek <[EMAIL PROTECTED]> wrote: > > Am Mittwoch, 9. Februar 2005 12:39 schrieb Thorsten Gunkel: > >> Matthias Houdek <[EMAIL PROTECTED]> wrote: > >> > Am Dienstag, 8. Februar 2005 15:42 schrieb Thorsten Gunkel: > >> >> Matthias Houdek <[EMAIL PROTECTED]> wrote: > >> >> > Am Dienstag, 8. Februar 2005 13:44 schrieb Thorsten Gunkel: > >> >> >> K�chler Peter <[EMAIL PROTECTED]> wrote: > >> >> >> > Am Dienstag, den 08.02.2005, 08:57 +0100 schrieb Thomas Sommer: > >> >> >> >> [RAID als Datensicherung] > >> > > >> > Nein, du verwendest immer wieder dein Backup, um es zu restoren. > >> > Ist es fehlerhaft, spielst du den Fehler u.U. immer wieder > >> > erneut in dein System ein. > >> > >> Versteh ich immer noch nicht. Wenn Du eine Platte dauerhaft im > >> Rechner l��t und nicht rotierst machst Du das nicht? > > > > Hast du IMHO gerade gesnipt. > > Ich bin kurz davor das ganze umzusetzen um die Machbarkeit zu > demonstrieren.
Aha, und wie demonstierst du den St�rfall? *g* > > Bei gespiegelten Platten gibt es keine erste und zweite Platte. > > Beide sind gleichberechtigt und werden gleichzeitig beschrieben. > > Nur beim > > Es gibt keine zwei Platten. Nur eine. Die ist die erste, oder A. Ach. Und wo ist da das RAID? > > Synchronisieren werden die Daten abgeglichen. > > Jetzt gibt es eine zweite Platte. B. > > > Wei�t du genau, was dort abgeglichen wird? > > Die Raidtools stellen fest dass es eine aktuelle Platte A gibt und > eine veraltete B und kopieren transparent im Hintergrund A auf B. Von > B nach A flie�t dabei genau nix (alles andere w�re doch sehr > �berraschend, sinnlos und falsch). Nicht unbedingt. Ein gutes RAID-System kopiert nicht von A nach B, sondern synchronisiert. > > Was passiert, wenn die im Rechner verbliebene Platte einen Fehler > > hat, die Daten aber auf der zweiten Platte (allerdings mit > > veraltetem Inhalt) vorhanden sind? > > Was passiert wenn Du Deine kaputte Platte auf ein Bandlaufwerk > kopierst auf dem das letzte intakte Backup war? Das passiert halt > wenn man rotiert. Das ist kein Nachteil nur dieser L�sung. Ja. Deshalb sollte man wenigstens einmal im Zyklus die Konsistenz der Daten pr�fen. > > Die Art der Synchronisation h�ngt sicher auch stark vom verwendeten > > System ab (Firmware des RAID-Controllers, Software-RAID). Aber so > > lange ich keine Garantie habe, dass immer nur in eine Richtung > > kopiert wird, w�re ich da sehr zur�ckhaltend. > > Wenn Dein Raid die aktuellen Daten mit veralteten Daten �berschreibt > wirf es weg :-) Es synchronisiert. Synchronisieren heist, einen Zustand auf einen anderen abgleichen. Die einfachste und zugleich auch wiederum langwierigste und belastendste Art ist es, dabei einfach den gew�nschten Zustand dem neuen System �berzub�geln. > > Au�erdem bleibt das Problem des Bediener-/Programmfehlers, der > > immer beide Platten gleichzeitig betrifft. > > Nur w�hrend die 2. Platte drinne ist, das Problem hast Du beim Band > genauso, wenn Du Mist mit den Daten machst w�hrend sie gerade aufs > Band kopiert werden ist auch das Band mit Mist gef�llt. Wieder kein > Nachteil den nur diese L�sung hat. Was du jetzt beschreibst, ist kein RAID-System, sondern ein Backup, was du mit Hilfe eines RAID-Kontrollers (oder einer entsprechenden Softwarel�sung) herstellst. Ein wenig oversized, oder? Aber klar, man kann sich ja die Petersilie zum Salat ja vielleicht auch �ber Fleurop bestellen ;-) [...] > >> > Wenn beide Platten im System sind - welche von beiden ist dann > >> > die Backup-Platte? F�r das System sind beide gespiegelten > >> > Platten gleichberechtigt. > > Sind sie nicht, eine ist aktuell, die anderen werden erneuert. Du > musst schon zeigen dass Fehler von den nicht aktuellen auf die > aktuelle flie�en. Eine Frage der Art der Synchronisation. > >> Sagen wir mal wir haben 3 Platten. A B C. Am Anfang ist nur A im > >> Rechner. Jetzt steckst Du B rein wartest bis Dein Raid wieder > >> synchron ist, entfernst sie (ordentlich) und packst sie in den > >> Schrank. Irgendwann sp�ter machst Du das mit C und wieder sp�ter > >> wieder mit B. Jemand anders nutzt statt B und C die B�nder b und > >> c. Welche Platten muss wann kaputt sein damit der Bandbenutzter > >> besser dasteht? (Was passiert Deiner Meinung nach wenn sie kaputt > >> ist? Man liest einfach fehlerhafte Daten ohne es zu merken?) > > > > Nicht der Bandbenutzer - der Backupbenutzer. > > Mir reicht es ein etabliertes Backupsystem einzuholen um zu zeigen > dass man damit Backups machen kann. Es muss nicht alle anderen in > allen Punkten �bertreffen. Das hat keiner bestritten. Aber es ist aufw�ndiger, teurer, unflexibler und letztendlich auch unsicherer, das �ber eine RAID-Spiegelung zu tun. Warum sollte man es dann? > > Ein wie auch immer aufgerufenes rm -rf (z.B.) l�scht dir immer auf > > beiden Platten, nie aber ein echte Backup. > > Und in einem RAID laufen beide Platte parallel. Hat ja auch seine > > Vorteile. Wenn du jetzt nat�rlich kommst und sagst: OK, ich stoppe > > (fast) alle Prozesse, stecke meine 2. Platte rein und lasse �ber > > RAID die erste auf die zweite speigeln, um sie danach wieder > > rauszunehmen, so gibt es keinen Unterschied mehr zum Backup. > > Aber so in der Art ist die Idee. Auch wenn ich mich wiederhole: Warum so umst�ndlich? Und es hat mit einem RAID-System nicht mehr viel zu tun, du verschenkst die Vorteile der h�hreren Verf�gbarkeit. > > Aber dann kannst du dir das ganze RAID-Ged�ns sparen und gleich ein > > ordentliches Plattenbackup machen. > > Tja, f�r meinen Rechner w�rde ich die Bedenken �ber kaputte Sektoren > auf einer Platte, die dann ohne Fehlermeldung falsche Daten ausgibt, > die dann die Raidtools auf die intakte Platte kopieren, obwohl da > viel aktuellere Daten sind, als viel zu abwegig einstufen und k�nnte > ein Backup machen ohne alle Dienste anzuhalten. Und falls das > wirklich mal passiert sagt mir das integrit schon. Ferner k�nnte ich > sogar w�hrend dem Backup fleissig auf die Platte schreiben und die > Raidttools sorgen daf�r dass das Backup konsistent bleibt bis ich es > entferne. Und wenn man sowieso schon Raid1 hat geht das ganz ohne > extra Software. OK, das ist ein "Vorteil". Die Daten sind aktuell f�r den Zeitpunkt der Entnahme des Datentr�gers und nicht f�r den fr�heren Zeitpunkt des Starts des Backups. Aber dann brauche ich ja nur das Backup sp�ter starten, und schon bin ich besser dran ;-) Und wenn ich schon RAID1 habe (dann brauche ich es ja auch - warum h�tte ich es sonst), dann nehme ich die zus�tzlich ben�tigten Platten, um darauf ein gezieltes Backup zu fahren. Es ist einfacher, flexibler, sicherer (weil steuerbar). > >> Mir fiele da nur ein Szenario ein: B und b sind kaputt, die willst > >> eine Datei lesen und dann wieder schreiben und durch Pech liest > >> die Raidsoftware einen Teil der von der kaputten Platte und Du > >> schreibst sie fehlerhaft zur�ck. Zugegebenma�en ein Nachteil, man > >> m�sste ro mounten um das zu verhindern > > > > Was willst du denn da mounten? Ein RAID ist f�r das Dateisystm > > transparent. > > Ohne Schreiben - Lesen - Schreiben kein Datenflu� von B nach A. s.o. > - wenn man das wirklich f�rchtet. Du hast mich nicht verstanden: Wie mountest du eine einzelne Platte eines RAID-Systems? Wie hei�t der Befehl, der das kann? Ich kenne keinen. > >> und k�nnte dann genauso gut rsync > >> benutzten - oder m�sstes alle Dateien die sich w�hrend dem > >> synchronisieren ver�ndert haben �berpr�fen. Das Problem w�rde aber > >> nur auftauchen wenn die Platte keine Fehlermeldung wirft (smart?) > >> sondern einfach falsche Daten ausspuckt. Keine Ahnung wie > >> wahrscheinlich das ist. > > > > Genau f�r diese F�lle, die so unwahrscheinlich sind, macht man > > Datensicherungen. > > Naja. Ja. > >> > Bei defekten B�ndern ist eventuell auf einem Band ein Fehler, > >> > eine Datei defekt (vielleicht auch mehrere). Das eine Backup ist > >> > unvollst�ndig. Wird diese Stelle wirklich gebraucht, ist sehr > >> > wahrscheinlich auf anderen B�ndern noch vorhanden oder aber sehr > >> > neu (h�ngt vom Backupzyklus ab). > >> > >> Du argumentierst also dass man (aus kostengr�nden) mehr B�nder als > >> Festplatten nutzt? > > > > Nein, ich argumentiere mit einer wesentliche besseren Handhabung > > beim Restore, besonders beim Restore einzelner > > Dateien/Verzeichnisse. Das hat auch nix mit Band oder Platte zu > > tun, sondern mit RAID-Spiegelung oder Backup. > > Hast Du schon mal eine Platte aus einem Linux SoftwareRaid1 > herausgenommen und in einen anderen Rechner geh�ngt? AFAIR kann man > die auch ohne irgendwelche Raidtools v�llig normal mounten und lesen > (im Gegensatz zu anderen Raidformen oder irgendwelchen > Hardwarel�sungen). Kann ich bei meinem Hardware-RAID-Controller auch. Halt, k�nnte ich, wenn ich auf dem RAID ein bootf�higes System h�tte. Meine Boot-Partition incl. System liegt auf einer anderen Platte. ;-) Au�erdam hat das noch lange nix mit "einer wesentliche besseren Handhabung beim Restore, besonders beim Restore einzelner Dateien/Verzeichnisse" zu tun (s.o.) > Wo soll da die schlechter Handhabung sein? Dieses > Backup kannst Du in einen Rechner stecken und er bootet sogar davon, > bei einem Band geht das nicht (das erkl�rt vielleicht mit warum Du > das so kritisch siehst?) Was du immer vom Band redest? Wenn ich ein Plattenbackup mit dd auf eine andere Platte mache, kann ich davon genau so gut booten. > >> Da stimm ich Dir halt nicht zu. Die L�sung wie ich sie mir > >> vorstelle hilft sehr wohl gegen pl�tzlichen Plattenausfall und > >> versentliches L�schen, und wenn Du im Schrank 10 Platten liegen > >> hast ist es sehr wohl redundant. Der anf�ngliche Einwurf Raid ist > >> kein Backupersatz war hier einfach daneben. > > > > Ist es nach wie vor nicht, es ist eine unvollst�ndige Alternative, > > deren Grenzen man klar erkenne sollte. > > Genau wie die aller anderen Alternativen. Welche da w�ren? (Alternativen zum Backup, nicht alternative Datentr�ger f�r ein Backup - da hat jeder seine spezifischen Vor- und Nachteile). > >> Gerade f�r Privatanwender die ihre riesen Platten schwer sichern > >> k�nnen eine kosteng�nstige L�sung die dazu noch einfach zu > >> bedienen ist - vor allem wenn wirklich ein Ausfall da ist - > >> einfach kaputt Platte raus, Backuplatte rein, bootet wieder. > > > > Regelm��iges dd auf externe Platten erf�llt den gleichen Zweck. Und > > ist noch kosteng�nstiger. Und auch sehr einfach zu handhaben > > (automount mit entsprechendem Script). > > Nur dass dd mit Schreibzugriffen �berhaupt nicht klarkommt (und genau > das gleiche kostet). Nur im Vergleich zum Software-RAID. Und wer macht denn sowas? > >> Also f�r mich w�re die Raidl�sung gar nichts, > > > > Ach, aber verteidigst sie, als w�re sie das ideale Backupmittel. > > ;-) > > Mir hat es nur nicht gepasst dass Peter K�chler den IMHO originellen > Ansatz von Thomas mit einem standard Spruch (RAID ersetzt kein > Backup) niedergemacht hat, ohne ihn meiner Meinung nach auch nur im > Ansatz verstanden zu haben (und mir jetzt vorwirft ich w�rde so tun > als sei die originelle Idee seinem Geiste entsprungen ;-)). Genauso > k�nnte man hier argumentieren dd/cp/tar/usw. ersetzten kein Backup - > weil alle mindestens gleich schwerwiegende Probleme haben. Nein. RAID ersetzt kein Backup. Nie. Never. Der Satz gilt nach wie vor und wird leider viel zu selten betont. Etwas anderes ist es, wenn man _�ber_ eine RAID-Spiegelung eine Komlettsicherung einer Platte anfertigt (man beachte den feinen Unterschied!). Das ist eine Art Backup, allerdings genau so unflexibel und undifferenziert wie ein dd. Es gibt einfachere und bessere L�sungen, warum sollte man die nicht nutzen? Du machst es ja selbst auch. EOT -- Gru� ����������������MaxX Hinweis: PMs an diese Adresse werden automatisch vernichtet.
