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. > 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. > 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). > 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. > 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 :-) > 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. >> >> Naja, die Backup Platte im laufenden Betrieb zu ziehen ist >> >> nat�rlich nicht ordentlich. Du wirst sie schon mindestens ro >> >> mounten m�ssen, besser das Raid ganz anhalten. >> > �hm, las ich da nicht irgendwo anders, dass du gerade den Wechsel >> > im laufenden Betrieb als Vorteil ansiehst, weshalb du auch >> > Hot-Swap-Rahmen emfiehlst? Kann mich aber auch irren. >> Zwischen die Platte unmounten und Rechner runterfahren ist doch ein >> kleiner Bequemlichkeitsunterschied. > Aber ein sehr kleiner. Es reicht ja nicht aus, eine Platte zu umounten, > du musst das RAID umounten. Um zu verhindern dass Daten von B nach A flie�en sicher nicht. s.o. >> >> > Woher wei�t du, dass nicht die Platte, die gerade gezogen werden >> >> > soll, nicht gerade die ist, die Sektoren-Fehler auf der anderen >> >> > f�r das System ausgleicht?(um nur mal ein Beispiel zu nennen). >> >> > In einem gespiegelten System mit synchronen Platten sind beide >> >> > total gleichberechtigt. >> >> Kann ich nicht ganz nachvollziehen. Das ist bei kaputten B�ndern >> >> im Rotationsbetrieb ja wohl auch so? Nur dass die Platte kaputte >> >> Sektoren vielleicht intern ausgleicht (ich bin davon ausgegangen >> >> das man im Normalbetrieb immer die gleiche Platte nutzt und nur >> >> manchmal f�r kurze Zeit einer der Backupplatten einschiebt. Dabei >> >> fallen Fehler in den Backupplatten ja hoffenlich beim Schreiben >> >> auf die betroffenen Stellen auf, und wenn die Hauptplatte kaputt >> >> geht - daf�r ist das Backup ja da) >> > 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. >> 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. > 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. > 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. >> 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. >> 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. >> > 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). 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?) >> 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. >> 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). >> 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. >> h�ufiger. Deshalb sichere ich meine Daten mit einem t�glichen tar >> (und das Ergebis wird b�serweise sogar komprimiert - weil ich dann >> einfach eine l�ngere Zeitspanne aufheben kann). > Tip: erst komprimieren, dann archivieren. > Sonst b�ses Erwachen, wenn geziptes Tar-Archiv defekt, weil ab dieser > Stelle alles weg. Ja ich wei� (mach ich vielleicht auch irgendwann mal). >> Seit mir meine >> Bootplatte mal verendet ist liegt mein System zus�tzlich noch auf >> einem Raid1 damit ich ihm Fall der F�lle nicht so lange Ausf�lle >> habe. > ... und ein boses Programm (gibt es auch unter Linux) killt dir auf > einen Schlag Original und Kopie, weil es eben 2 Originale sind. Nur dass das Raid1 hier auch als Raid1 benutzt wird und ich wie gesagt �ber tar sichere (was aber andere Nachteile hat). >> Ob Du mit DVDs gl�cklich wirst wird sich zeigen. Viele meiner ersten >> selbstgebrannten CDs konnte ich schon vor Monaten nicht mehr lesen - > Mein Mitleid. Macht nix, ich wollte sie vor der Vernichtung nur noch mal durchsehen. >> ich f�rchte mal mit DVDs wird das eher schlechter sein. > Geht noch prima. Auch nach 3 Jahren. War bei mir sehr herstellerabh�ngig. Mfg Thorsten -- http://www.tgunkel.de -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
