PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Samba Datenverlust über einen Monat wegen Hardwarefehler



Rasenmäher
17.08.19, 15:35
Ich habe auf meinem Server ubuntu 18.04 laufen mit smbd 4.7.6. Das Samba-Share liegt auf einem USB 3.0-Stick, der an einem USB 3.0 Port des Server-Mobos angesteckt ist. Auf das Share greife ich über Windows 10 zu. Samba-Server und Windows-Client stehen im lokalem Netz.

Das Problem, welches aufgetreten ist, ist, dass alle Daten innerhalb eines Monats verlorengegangen sind. Am 08.07.2019 stellte ich fest, das auf dem Server keine Datei mehr zu finden war, deren Änderungsdatum später als 03.06.2019 war.
Also alle Änderungen an Dateien, sowie neue Dateien die nach dem 03.06.2019 erzeugt wurden, sind verloren gegangen. Ob Dateien noch vorhanden sind, die nach dem 03.06.2019 gelöscht wurden konnte ich Mangels Beispiels nicht überprüfen.

Als Fehlerursache konnte ich einen Hardwarefehler beim Schreiben auf den USB-Stick feststellen.

Was war passiert? Die Daten konnten nicht auf den USB-Stick geschrieben werden. Der Samba Dämon hat davon nichts gemerkt, weil er die Daten ja nur ins Filesystemjournal und in den Laufwerkscache geschrieben hat.
Das Problem hat dann der Kernel bekommen, als er den Cache synchronisieren wollte und die geänderten Daten nun wirklich auf den Stick schreiben wollte. Deshalb hat er auch lauter Fehlermeldungen ausgegeben,
die man mit dmesg hätte sehen können. Leider hat das nichts genützt, weil die Fehlermeldungen nicht bis zum Windowsrechner durchgereicht wurden, wo ich sie hätte sehen können.
Auf den Linuxserver zu gehen und nachzukucken, dazu bestand ja keine Notwendigkeit. Von Windows aus hat ja alles funktioniert. Ich habe Dateien geändert, gespeichert (auf den USB-Stick aber eigentlich in den Laufwerkscache) und die geänderten Dateien wieder geladen (vom USB-Stick aber eigentlich aus dem Laufwerkscache). Alles war konsistent und hat tadellos funktioniert. Solange, bis zuviele Cacheänderungen aufgetreten sind und der Windowsrechner gehangen hat.
Als ich dann auf den Server gegangen bin, den smbd gekillt und neugestartet habe und auch den Server herunter- und wieder hochgefahren habe, ist das Problem offensichtlich geworden.

Meine Frage ist nun, was muss man machen, damit sich so ein Szenario nicht wiederholt? Datenverlust über Zeit ist eine richtig üble Sache. Ein Monat Arbeit ist verlorengegangen.
Als Lösung kommt mir folgendes in den Sinn: Wenn der Kernel merkt, dass er den Cache aufgrund eines aufgetretenen Hardwarefehlers nicht synchronisieren kann, müsste er dem smbd Bescheid sagen:

Hey smbd, ich kann deine Cache-Änderungen nicht auf das Laufwerk schreiben. Blockiere bitte alle Schreibzugriffe, denn ich kann nicht sicherstellen, dass dass die Änderungen aufs Laufwerk geschrieben werden, so dass der Daten-
verlust aller folgenden Schreibzugriffe nicht auszuschließen ist.

In diesem Fall hätte sich der Fehler sofort bemerkbar gemacht und ich hätte nur eine oder wenige Dateien verloren, nämlich die die ich gerade geändert habe und der unauffällige Datenverlust über einen Monat wäre nicht aufgetreten.

Hat jemand ebenfalls diesen Fehler schon erlebt? Bei mir hats 30 Jahre Linuxleben gedauert, bis ich den eben geschilderten Fehler erleben durfte.
Am liebsten würde ich mich mit den Kernelprogrammierern und Sambaprogrammierern über dieses Problem auseinandersetzen.

Wenn ein User eine Lösung hat, wäre ich auch dankbar. Aber bitte keine trivialen Lösungen wie: Benutz einfach kein USB, benutz einfach kein Samba, schmeiß alle Computer weg oder ähnliches.
Das System soll so weit wie möglich erhalten bleiben. Also ich will USB-Sticks benutzen, ich bin gezwungen alte Mobos zu nutzen, bei denen das USB-3.0 noch nicht ausgereift ist, Ich habe billige Sticks, die Hardwarefehler erzeugen können.

Aus Ärger habe ich den USB-Stick dann zerstört. Nach weiteren Tests um die Fehlerursache herauszufinden, gingen auch andere USB-Sticks nicht. Also war der Stick höchstwarscheinlich in Ordnung gewesen, und der Fehler liegt am USB-Port
des Mobos oder irgendwo anders auf der Datenstrecke zwischen Laufwerkscache und USB-Stick.

stefan.becker
22.08.19, 07:32
Wenn die Hardware schrott ist, wie sollen wir dir da helfen? Das Problem ist ja nicht Samba, sondern das Drumherum. Ein alter Rechner mit defektem Mainboard/USB 3 Ports und dazu unzuverlässige USB-Sticks. Sorry, aber das ist keine Basis für ein NAS.

Ich würde den ganzen Krempel entsorgen. Dann ein richtiges NAS aufsetzen:

https://www.elefacts.de/test-94-kleines_nas_fuer_den_guenstigen_24_7_einsatz_mit_d em_raspberry_pi_3

https://sourceforge.net/projects/openmediavault/files/Raspberry%20Pi%20images/

Das ganze auf der Basis eines RASPI 4 mit OMV. Dazu eine 1 TB Festplatte. Dann hast für knapp 120 EUR eine gute Lösung, die im 1 GB Netz auch eine gute Performance bietet. OMV bietet eine einfach zu nutzende Weboberfläche an.

Das ganze kann ich nur empfehlen. Gibt sichere bessere Lösungen als diese (Synology, Q-Nap, ...), aber nicht für den Preis.

nopes
22.08.19, 10:39
Sehe ich krass anders, gerade die Krümmel-Hardware knotet fast alles per USB dran, nur weil etwas USB ist, ist es nicht auch direkt für die Tonne. Für viel ist eine externe Festplatte auch nichts weiter als ein USB Stick.

Datenbanken haben mit diesem verhalten auch so ihre Probleme: https://www.postgresql.org/docs/devel/wal-reliability.html bzw https://www.postgresql.org/docs/current/wal-reliability.html

...
Recent SATA drives (those following ATAPI-6 or later) offer a drive cache flush command (FLUSH CACHE EXT), while SCSI drives have long supported a similar command SYNCHRONIZE CACHE. These commands are not directly accessible to PostgreSQL, but some file systems (e.g., ZFS, ext4) can use them to flush data to the platters on write-back-enabled drives. Unfortunately, such file systems behave suboptimally when combined with battery-backup unit (BBU) disk controllers. In such setups, the synchronize command forces all data from the controller cache to the disks, eliminating much of the benefit of the BBU. You can run the pg_test_fsync module to see if you are affected. If you are affected, the performance benefits of the BBU can be regained by turning off write barriers in the file system or reconfiguring the disk controller, if that is an option. If write barriers are turned off, make sure the battery remains functional; a faulty battery can potentially lead to data loss. Hopefully file system and disk controller designers will eventually address this suboptimal behavior...

https://askubuntu.com/questions/5051/how-to-switch-off-caching-for-usb-device-when-writing-to-it sollte dein Problem lösen, https://www.postgresql.org/docs/devel/pgtestfsync.html bzw https://www.postgresql.org/docs/current/pgtestfsync.html könnte man zum Testen verwenden, erstmal so lassen wie es ist und es sollten Fehler auftreten, dann das Caching deaktivieren und prüfen, ob die Fehler beim testen verschwunden sind - https://askubuntu.com/questions/5051/how-to-switch-off-caching-for-usb-device-when-writing-to-it

stefan.becker
22.08.19, 10:44
- ich bin gezwungen alte Mobos zu nutzen, bei denen das USB-3.0 noch nicht ausgereift ist
- Ich habe billige Sticks, die Hardwarefehler erzeugen können.
- und der Fehler liegt am USB-Port des Mobos ...


OK, das sind natürlich hervorragende Eigenschaften für ein NAS ...

nopes
22.08.19, 11:13
Ui das sind aber wirklich böse Nebensätze, die hatte ich überlesen, da sollte man dann wohl wirklich nur unwichtiges drauf ablegen. Fehlererkennung anpassen, schadet trotzdem nicht ;)

stefan.becker
22.08.19, 11:54
Halte ich für zwecklos. Bevor man an der Software dreht, sollte wenigstens die Hardware in Ordnung sein.

Ich finde diese Raspberry PI Geschichte als NAS genial. Preiswert, gut. Und den Aufpreis spart man langfristig über den Strom gegenüber einer x86 Uraltmöhre wieder ein.