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

[Matthias Houdek <linux@houdek.de>]

Am Mittwoch, 9. Februar 2005 20:24 schrieb Thorsten Gunkel:
> 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.

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.