Subversion: Unbeabsichtigte Zeitreise

[Alexander (HH)]

Moin Moin!

"Mit git wäre das nicht passiert"
Das hab ich mir auch für'n paar Sekunden gedacht. Trotzdem bleibe ich bei SVN, das eigentliche Problem war wieder einmal ein Hardware-RAID-Controller.

Ja, stimmt schon, aber nachdem ich mir Git angesehen und erste Erfahrungen damit gemacht hatte, kann ich ein Bleiben bei SVN nur noch mit Konservativismus begründen (oder mit dem Bauern, der etwas nicht isst, nur weil er es nicht kennt).

Sei es drum. Ich will dich jetzt nicht (unbedingt) überzeugen, aber ein paar mehr Worte, warum Git hier im Vorteil gewesen wäre, werde ich doch noch verlieren.

[Schneid ich jetzt mal raus, sonst wird das Posting zu lang. "Fachlich hilfreich" mit Sternchen hast Du ja schon bekommen, und zu recht!]

Es gibt eine noch viel einfachere Begründung für SVN:

1. Ich kenne SVN.
2. Ich habe keine Zeit, mich in git einzuarbeiten.
3. Der Zentralismus von SVN ist Teil des Backup-Konzepts.

Zu 2: Neben dem Tagesgeschäft liegen mindestens zwei Projekte für drei bis vier Leute für die nächsten paar Jahre auf meinem Tisch. Außer mir ist schlicht und ergreifend kein anderer da, der diese Themen bearbeiten kann. Und nein, ich habe nicht darum gebeten, mir diese Projekte zu geben! EDV-Leitung gibt's bei meinem Arbeitgeber nur auf dem Papier. Andere Geschichte.

Zu 3: Ich arbeite nach dem Motto "commit early, commit often", so dass ich auf dem Arbeitsrechner dem Repository auf dem Server immer höchstens einen logischen Schritt voraus bin. So habe ich immer eine saubere Source-Version im HEAD, und die wird im Laufe der Nacht auf dem Server gesichert. Vom Arbeitsrechner selbst gibt es kein Backup, weil der leicht wiederhergestellt werden kann (OS installieren, Browser installieren, Editor installieren, SVN installieren). Die Testumgebung liegt in einer VM auf dem Server und wird regelmäßig nachts mit gesichert.

Ich arbeite ja nicht erst seit gestern so, sondern schon länger, als man mir für mein Hobby Geld bezahlt. Dieses eine Mal habe ich mich nicht an eine meiner eigenen Regeln gehalten, die lautet: Kein Hardware-RAID!

Meine Entwicklungsserver waren - wenigstens anfänglich - immer irgendwelche geschnorrten oder ausgemusterten Maschinen, teilweise alte Desktops, teilweise alte Server, die ich mit zusammengesammelten Teilen so weit wie möglich aufgemotzt habe, immer nach dem gleichen Prinzip: Software-RAID, externe Platte für ein rsync-Hardlink-Backup. Und das hat immer funktioniert, weil dieses Setup sehr unanfällig für Hardware-Schäden ist. Wenn der Server tatsächlich kaputt geht, steckt man die Platten stumpf in einen anderen. Plattenausfäle deckt das RAID ab, und kaputte Controller stören dank Software-RAID ebenfalls nicht. Und im blödsten aller Fälle (nämlich genau diesem) hat man die externe Platte mit dem Stand von gestern.

Bei diesem Job habe ich mich von der Hardware blenden lassen. Der Server (große Marke) ist gebaut wie ein Panzer, wenn man den versehentlich fallen läßt, fällt der ohne eine Schramme bis zum Fundament durch alle Zwischendecken. Fast alles ist redundant ausgelegt, keine Elko-Pest, alles extrem sauber und ziemlich durchdacht aufgebaut. Ich habe schlicht und ergreifend übersehen, dass erstens der RAID-Controller nicht in andere Maschinen paßt und zweitens alle Ersatzteile mindestens mit Gold aufgewogen werden, wenn man nicht sogar seine Erst- und Zweitgeborenen verpfänden muß.

Und wie immer, wenn Murphy zuschlägt, schlägt er an der schwächsten Stelle zu. Das Mainboard ist nicht redundant, der RAID-Controller paßt nur zu diesem Mainboard, und die Daten lagen auf einem RAID-5 verteilt über vier Platten.

Platten aus einem RAID-1 lassen sich bei diesem Controller (zufällig?) direkt an anderen Rechnern lesen, der speichert bei einem RAID-1 die Meta-Daten offensichtlich in den letzten paar Sektoren der Platte, der Rest ist mit dem identsch, was das Betriebssystem als RAID-Verbund sieht.

RAID-5 ist bei dieser Controller-Generation nur mit exakt diesem Controller-Typ lesbar. DDF, mit dem man notfalls auch mit Linux-Bordmitteln Platten aus einem Hardware-RAID-Verbund auslesen kann, gibt's erst bei der nachfolgenden Controller-Generation, die natürlich NICHT in den Server paßt.

Hätte ich mich an meine eigene Regel gehalten, hätte ich jetzt 6 SCA-Platten, von denen zwei ein RAID-1 mit dem Betriebssystem und vier ein RAID-5 mit den Daten bilden. Mit sechs SCA-zu-SCSI-Adaptern bekäme ich die sechs Platten problemlos mit jedem beliebigen SCSI-Controller auf jedem beliebigen Mainboard zum Laufen, so lange Linux nur einen Treiber für den SCSI-Controller hat. Linux könnte problemlos alle Daten vom RAID-5 irgendwo anders hin kopieren oder notfalls auf einer völlig anders aufgebauten Ersatzmaschine mit den Original-Platten weiter laufen.

Alexander