[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Frage zu Software-Raid oder: Wie Datensicherung organisieren.



Matthias Houdek <linux@houdek.de> wrote:
> Am Mittwoch, 9. Februar 2005 12:39 schrieb Thorsten Gunkel:
>> Matthias Houdek <linux@houdek.de> wrote:
>> > Am Dienstag, 8. Februar 2005 15:42 schrieb Thorsten Gunkel:
>> >> Matthias Houdek <linux@houdek.de> wrote:
>> >> > Am Dienstag, 8. Februar 2005 13:44 schrieb Thorsten Gunkel:
>> >> >> Küchler  Peter <Peter.Kuechler@pvfrm.de> 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



Reply to: