Artikel mit ‘synology’ getagged

Wenn sonst nichts mehr beim kaputten RAID5 hilft

Donnerstag, 25. März 2010

Ein Kundeskunde ist stolzer Besitzer einer Synology CubeStation. Das sind kleine NAS-Server für daheim, auf Linux-Basis mit einem proprietären Webinterface, aber immer noch mit einer Shell. Je nach Modell sind unterschiedlich viele Platten verbaut; hier konkret vier. Jede Platte hat drei Partitionen, wobei die ersten beiden kleineren jeweils ein kleines RAID1 für die Root- bzw. Swap-Partition darstellen (und hier ergo dreifache Redundanz haben); die jeweils dritten – großen – Partitionen sind zu einem RAID5 ohne Spare zusammengefasst, das als /volume1 gemountet wird, was bei den Synology-Boxen offensichtlich für die eigentliche Ablage von Daten benutzt wird.

Eine der Platten ging kaputt. Kein Problem, dafür hat man ja das RAID. Beim Ausbau der defekten Platte wurde allerdings offensichtlich das Stromkabel einer der weiteren Platten gelockert. Wir wissen nicht genau, was passiert ist, aber der Zustand war der, dass die ersten beiden RAIDs problemlos zusammengesetzt werden konnten; das dritte aber nicht. /dev/sda3 und /dev/sdc3 waren da, /dev/sdb3 fehlte (weil ausgebaut), und /dev/sdd3 – die Platte mit dem Wackelkontakt am Strom – hatte zwar einen md-superblock, der aber nicht mit den anderen harmonierte. Zwar stimmte die UUID; allerdings war der Update-Timestamp nicht ganz synchron. Ein

mdadm --assemble /dev/md2 /dev/sd[acd]3

schlug von daher fehl. Nun ist das an sich kein großes Problem: Man kann mdadm einfach zwingen und die md-superblocks dann wieder neu schreiben. Also:

mdadm --assemble --force /dev/md2 /dev/sd[acd]3

Denkste. Zwar bereitet sich mdadm schon korrekt vor und informiert darüber, dass es den abweichenden update count der dritten Partition anzupassen gedenkt. Dann jedoch stirbt es mit einem Segmentation Fault.

Offensichtlich ein bekanntes Problem. Und zwar nicht spezifisch für die Syno-Box; auch der Ubuntu-Bugtracker findet:
mdadm seg faults when forced to assemble array. Das Problem scheint also spezifisch für mdadm 2.6.7 zu sein – schon bei der 2.6.7.1 soll es angeblich wieder gehen.

Nun ist auf der Syno-Box aber eben die 2.6.7 – und ein Update ist nicht in Sicht. Was also tun? Mein erster Gedanke dazu (und ich bleibe dabei, so schlecht war er nicht): IPKG installieren, und darüber dann eine hoffentlich wahlweise ältere oder neuere Version von mdadm installieren, die diesen Bug nicht hat. Und wenn’s keine gibt, bliebe immer noch die Möglichkeit, über IPKG einen Compiler zu installieren und mdadm 2.6.7.1 aus den Sourcen zu kompilieren.

Es gibt ein mdadm in IPKG. Ein 2.6 – also älter. Nur behauptet /opt/sbin/mdadm --examine (also das via IPKG installierte, im Gegensatz zum vorinstallierten /sbin/mdadm) bei allen Partitionen, dort keinen md-superblock vorzufinden. Hm, vielleicht zu alt? Also doch die Variante mit dem Compiler, und dann ein mdadm aus den Sourcen kompiliert. Noch eine neuere Version genommen. Und dann noch eine. Und noch eine ältere. Aber es half nichts: Alle Versionen fanden keinen md-superblock. Nicht mal eine aus den Sourcen kompilierte 2.6.7, obwohl das doch nun die identische Version zur offiziell installierten ist.

(Gängige Reparaturanleitungen empfehlen, die Platten aus der Syno in einen normalen PC zu bauen – wofür man erstmal entsprechend viele freie SATA-Ports bräuchte – und dann dort den Superblock von der little-endian-Byteorder der ARM-CPU der Syno auf big endian einer Intel-CPU zu ändern, damit das RAID auf einem Intel-PC wieder zusammengesetzt werden kann. Mein Bauchgefühl sagt mir, dass das Problem mit den überhaupt nicht mehr erkannten md-superblocks etwas damit zu tun haben könnte. Allerdings habe ich das mdadm ja auf der Syno kompiliert, also auch mit deren Headerfiles. Insofern müsste die Byteorder eigentlich stimmen. Hm.)

Lange Rede, kurzer Sinn: Nichts half. Bis auf das RAID-Wiki bei kernel.org, das den entscheidenden Tipp gab:

When an array is created, the data areas are not written to, *provided* the array is created in degraded mode; that is with a ‘missing’ device.

Ich denke, man kann sich das in etwa so vorstellen wie eine defekte Partitionstabelle auf einer Festplatte: Es scheint alles weg; keine Partition ist mehr lesbar. Dabei ist klar, dass die Daten an sich alle noch auf der Platte vorhanden sind – man kommt nur ohne Partitionstabelle nicht mehr dran. Man muss es also “nur” schaffen, die paar Bytes Partitionstabelle wiederherzustellen, und das Problem ist gelöst.

So auch hier: Wird bei einem mdadm --create ein Device als “missing” angegeben, wird der Datenbereich der Platten in Ruhe gelassen und nur der Superblock neu geschrieben. Das ist natürlich nur was für echte Männer. Naja, oder für Männer wie mich, die sich vorher versichert haben, dass der Kunde Images der Platten gesichert hat, falls bei den Arbeiten am RAID irgendetwas schief geht. Auf jeden Fall muss man für so ein “Reparatur-create” allerdings wissen, wie dieser Superblock auszusehen hat: Welcher RAID-Level? Wieviele Platten? Welche Platte in welchem RAID-Slot? Welche Chunk-Size? Welche Symmetrie? Das war in diesem Fall einfach: Alle drei Partitionen haben ja schließlich noch einen md-superblock, der all diese Parameter verrät. Letztlich war es also nur das hier:

mdadm --create /dev/md2 --chunks=64 --level=5 --raid-devices=4 \
  /dev/sda3 missing /dev/sdc3 /dev/sdd3

mdadm bemerkte korrekt, dass auf den Partitionen bereits etwas drauf sei, was nach einem RAID riechen würde. Okay, wissen wir ja. Nach einer entsprechenden Bestätigung wurden die Superblocks neu geschrieben. Keine Fehlermeldung. Ein

mount /dev/md2 /volume1

funktionierte anstandslos. Alle Daten vorhanden; auch nach einem Reboot erkennt die Syno-Box das RAID5 jetzt wieder von selbst und bindet es ein. Nach einer jetzt natürlich umgehend anstehenden Datensicherung wäre es von daher im Bereich des Möglichen, nun wieder die vierte, noch fehlende Platte einzubauen und einen Resync zu wagen.

Mein Kunde berichtet vom Kundeskunden, dieser sei “grad total hingerissen davon (echt jetzt)”. Schöne Sache, wobei es hier weniger um ein geschäftliches Desaster gegangen wäre, sondern “nur” etliche Gigabyte an Fotos über den Jordan hätten gehen können. Aber die sind manchmal ja noch viel wertvoller. Ich gehe davon aus, ab heute macht der Kundeskunde Backups.

Synology-Netzwerksicherung: Doppel-FAIL

Freitag, 13. November 2009

Synology baut nette kleine NAS-Boxen für Daheim oder fürs Büro. Die laufen mit Linux, haben ein Webinterface drauf, damit man nicht mit der Shell in Berührung kommen muss, und sind von daher auch bei Einsteigern sehr beliebt.

Nun gibt es hier und da Bedarf, den Datenbestand der Syno an einem externen Ort zu sichern, und wie das nun mal so ist, bietet sich da Speicherplatz im Internet an. Die Syno unterstützt praktischerweise laut Dokumentation Backups auf “rsync-kompatible Server”. Nun kenne ich zugegebenermaßen keine Serversoftware, die “rsync-kompatibel” wäre außer eben rsync selbst, aber was soll’s, rsync ist ja prima und macht seinen Job.

Die Syno möchte allerdings, dass man rsync als Daemon betreibt, und man muss bei der Einrichtung des Backup-Profils ein Modul benennen, das man in der rsyncd.conf angelegt hat. Nun muss ich zugeben, dass ich rsync noch nie als eigenständigen Daemon habe laufen lassen, und zwar schon aus einem Grund: Die Verbindungen sind unverschlüsselt. Lediglich die Zugangsdaten werden rudimentär verschlüsselt; so rudimentär, dass selbst die man page sagt, das sei “fairly weak”. Die übertragenen Daten selbst werden überhaupt nicht verschlüsselt. Von daher taugt diese Variante maximal für lokale Netze, und für die Übertragung via Internet hat sich eingebürgert, rsync über SSH laufen zu lassen. Dabei läuft serverseitig dann gar kein rsync-Daemon, sondern es wird aus der SSH-Verbindung heraus ein Quasi-rsync-Daemon für diesen User gestartet, der dann auch nicht die /etc/rsync.conf benutzt, sondern die ~/rsync.conf – falls vorhanden. Mit dem Ende der SSH-Verbindung wird auch der Quasi-rsync-Daemon wieder beendet. Sehr aufgeräumt, und kommt ohne root-Rechte aus.

Ich hätte auf die Dokumentation achten sollen, die ganz klein in der Liste der benutzten Ports verrät, dass die verschlüsselte Netzwerksicherung nicht nur Port 22, sondern auch Port 873 – den Standardport für den unverschlüsselt laufenden rsync-Daemon – benötigt. Das erschien mir völlig unlogisch, aber es stimmt: Ohne einen rsync-Daemon geht es einfach nicht. Nun wollte ich natürlich vermeiden, dass über die unverschlüsselte Verbindung die Zugangsdaten verschickt werden, und habe mir deshalb mittels tcpdump angesehen, was die Syno da eigentlich macht. Ergebnis: Sie checkt mittels der list-Funktion von rsync, ob das ausgewählte Modul vorhanden ist. Ergo habe ich mir überlegt: Dann packe ich doch einfach die reale Konfiguration des Backup-Moduls in ~/rsync.conf, und in die /etc/rsync.conf packe ich ein Modul gleichen Namens (damit der Wizard befriedigt ist), aber mit /var/empty/rsyncd als Pfad, read-only, und vor allem: ohne irgendwelche Zugangsdaten anzufordern. Mit Erfolg: Die Dyno schaut, ob’s das Modul gibt, ist zufrieden, und macht dann alles weitere per SSH. Die Gegenprobe lässt mir einen Schauer über den Rücken laufen: Fordert man in der /etc/rsyncd.conf Zugangsdaten an, schickt die Syno sie bereitwillig rüber, über die unverschlüsselte Verbindung auf Port 873, obwohl man im Webinterface Verschlüsselung aktiviert hat. Sowas geht einfach gar nicht. Betrug am User. FAIL #1.

(Apropos: Im deutschsprachigen Webinterface der Syno heißt die fragliche Option “Verschlüsselung von Sicherungskopien aktivieren”. Hand aufs Herz, für mich klingt das weniger nach einer verschlüsselten Verbindung, sondern vielmehr danach, dass die Dateien verschlüsselt würden – was nebenbei eine äußerst gute Idee wäre, wenn man diese bei einem fremden Provider unterbringen will, dem man nicht seine privaten Dateien zur gefälligen Unterhaltung nach Feierabend bereitstellen will. Leider ist dem nicht so. Es geht in Wirklichkeit nämlich doch um die Verbindung, und die Daten liegen auf dem Zielserver dann für den Provider lesbar.)

Nun ist dieser Part aber gemeistert: Die /etc/rsyncd.conf verlangt einfach kein Passwort mehr, die Syno ist glücklich damit und fabriziert das Backup dann auch tatsächlich über SSH. Damit ich es nicht vergesse: In der ~/rsyncd.conf muss man beim Modul zusätzlich zum Pfad noch einstellen:

use chroot = false
read only = false

chroot funktioniert nämlich nur, wenn rsync als Standalone-Daemon als root läuft, und read only ist standardmäßig true, was für einen Backup-Speicherplatz natürlich Unsinn ist – auf den will man ja gerade etwas schreiben können. Das mit dem fehlenden chroot ist zu verschmerzen, da ja die ganz normalen Unix-Berechtigungen dafür sorgen, dass der User nicht woanders reinkommt; da die User ohnehin Shell-Zugang per SSH haben, reißen wir uns hier somit auch keine größere Sicherheitslücke auf.

Nun ist nach dem Backup natürlich noch zu testen, wie es so mit dem Zurückspielen klappt. Also mal einen Testordner angelegt, ein paar Dateien hinein, Sicherung angelegt, alles prima. Nun ein Klick auf “Wiederherstellen”. Es öffnet sich ein Fenster mit einem Wizard. Lustigerweise muss ich sämtliche Daten noch einmal eingeben, was mich schon mal ein wenig erstaunt, denn die angelegten Profile definieren ja bereits, welchen lokalen Ordner man mit welchen Zugangsdaten auf welchen Server sichern will – da wäre es doch an sich am einfachsten, bei einem Restore einfach das gewünschte Profil zu wählen, denn dann hätte die Syno ja schon alle Angaben, um die Daten zurückzukopieren. Nun, ist aber offensichtlich nicht so: Bei einem Restore spielen die angelegten Profile einfach keine Rolle. Stattdessen fragt mich der Wizard auch hier wiederum nach Servername oder IP-Adresse, Backupmodul, Anwendername, Passwort und …

Und jetzt der Haken: Nichts “und …”. Es gibt beim Restore keine Möglichkeit, eine verschlüsselte Verbindung zu benutzen. Nein, ich habe nichts übersehen. Da ist einfach nichts. Keine Checkbox. Man kann also zwar Backups per rsync über SSH machen – aber man bekommt sie auf diesem Weg niemals wieder. Also, von Hand auf der Shell per SSH natürlich schon, klar, aber eben nicht über das Webinterface: Restores gehen einfach nur unverschlüsselt. Und da auf dem unverschlüsselten Port 873 ja nur mein Dummy-Modul hinterlegt ist, ist da natürlich nichts zu holen, denn auf dem SSH-Port versucht die Syno es gar nicht erst. FAIL #2.

Und das alles wegen der Verschlüsselung, als wenn der Wunsch nach vertraulicher Datenübermittlung nur etwas für Geheimagenten wäre. Ich gehe davon aus, würde ich rsync als Server laufen lassen, schön mit root-Rechten, alle Module zentral in /etc/rsyncd.conf erfassen und mir einfach keinen Kopf darum machen, dass meine Zugangsdaten dann leicht zu knacken und mein gesicherter Datenbestand gleich ganz unverschlüsselt durchs Internet übertragen würde … dann, ja dann wäre bestimmt alles ganz einfach.

Aber, Synology: Wir leben nicht mehr in den Neunzigern! Hier besteht wohl noch dringender Nachholbedarf.


Impressum