Einstellungen und RAID-Konfiguration nach Systemabsturz (?) verloren

  • Also erstmal Backup, ganz klar!

    Am DOM scheint es mir nicht zu liegen, die Meldung deutet ja auf das (eventuell gar nicht vorhandene) Systemvolume hin.


    Ich würde Backup machen und neu einrichten, dann weiterschauen was kommt.


    Dass auf den Disks angeblich das Werksimage installiert ist (v1. 0) gibt mir sehr viele Rätsel auf... Das muss einfach neu gemacht werden.


    Zur Info:

    Ein Werksimage kann überhaupt gar nicht mit eingebauten Disks umgehen, das ist nur für den nackten DOM im NAS... Daher sehr sehr fraglich, wie das angeblich auf die Disks gekommen sein soll.

    2 Mal editiert, zuletzt von tiermutter () aus folgendem Grund: Ein Beitrag von tiermutter mit diesem Beitrag zusammengefügt.

  • Also erstmal Backup, ganz klar!

    Ist vorhanden. Nur die Containerstation-Daten sind leider nicht komplett auf Dateiebene gesichert, wegen der weiter oben beschriebenen Probleme. Hast du hier ggf. noch eine Idee, wie ich mit den symbolischen Links umgehen kann?


    Am DOM scheint es mir nicht zu liegen, die Meldung deutet ja auf das (eventuell gar nicht vorhandene) Systemvolume hin.

    Das hätte ich an sich auch erstmal so vermutet.


    Dass auf den Disks angeblich das Werksimage installiert ist (v1. 0) gibt mir sehr viele Rätsel auf... Das muss einfach neu gemacht werden.

    Ich denke, bei den vielen nun auftretenden Fehlern ist ein komplett neu aufgesetztes System die beste Lösung. Gerne würde ich hier aber so wenig Aufwand wie möglich haben, was das Einspielen von Daten in die Containerstation angeht, da das ansonsten immer sehr viel Rumgefrickel wird, selbst wenn ich nur einen Container neu aufsetze (oder ich stelle mich zu doof an). Hast du hier vielleicht noch Tipps, wie ich die Daten vom aktuellen System hier noch bestmöglich übernehmen kann, jedoch ohne auf die App der Containerstation zugreifen zu können?

  • Grundsätzlich habe ich von Containern keine Ahnung und daher auch überhaupt keinen Plan, was man davon genau sichern muss... Und wie man das machen muss, damit es später auch funktioniert...


    Wie sicherst du die denn sonst? Auf diese Weise sollte es jetzt ja auch funktionieren...

    Und was genau für Probleme treten beim Versuch der Sicherung auf?

  • Wie sicherst du die denn sonst? Auf diese Weise sollte es jetzt ja auch funktionieren...

    Manche Sachen sichere ich auf Dateiebene, z.B. die Daten von einem nginx-Webserver. Da weiß ich, wenn die ganzen Source-Dateien da wieder reinkommen, wird das ganze wieder laufen.

    Komplizierter ist es bei so Anwendungen wie einem MySQL-Datenbankserver. Hier weiß ich nicht, ob ein einfaches Zurückkopieren sämtlicher Dateien ausreichen wird. Normalerweise ziehe ich mir hier bei laufender Datenbank einen Export, was ja jetzt nicht möglich ist, da ich den Container nicht starten kann. Hier ist dar letzte Export ca. 10 Tage alt, was bei der Datenbank schon echt doof ist, da es dann zu Inkonsistenzen zu anderen Anwendungen kommen kann.

    Und selbst das Rücksichern von Dateien z.B. im Webserver dauert für mich ca. 30min für einen Container, da ich in den langen Dateiverzeichnissen, die alle aus hexadezimalen Namen bestehen, die richtigen Verzeichnisse finden muss und zwischendurch den Container noch ein paar mal Neustarten muss, bis alles passt.
    Also alles ein recht großer Aufwand bei ca. 15 Containern. Aber wenn es keinen besseren Weg gibt bzw. hier niemand einen besseren Weg kennt, werde ich das eben alles händisch machen.


    Und was genau für Probleme treten beim Versuch der Sicherung auf?

    Die Fehlermeldungen beim Kopieren von symbolischen Links mittels cp hatte ich weiter oben beschrieben. Leider kenne ich mich zu wenig mit Linux hinsichtlich der solcher Dinge aus, um selbst das Problem zu verstehen. Von Windows her kenne ich ja nur die Verknüpfungen als .lnk-Dateien, aber Linux ist hier ja leider anders.

    Ich werde nun aber nochmal versuchen, ob ich irgendwie per Samba oder (S)FTP draufkomme, jetzt wo ich aufs Webinterface komme.

  • An der Stelle würde ich mal auf den Rat von Anthracite hoffen... vielleicht kannst Du das Problem ja nochmal kurz zusammenfassen und/oder die Posts verlinken, damit sie nicht suchen muss...

  • Dann hast du Conti und Daten nicht getrennt.


    Mit einer XAML Datei kann man die ja vollkommen automatisch erstellen lassen, hier muss man aber 1 mal die Zeit investieren und das sauber aufbauen.

    Dann sind auch Updates kein Problem mehr, da die Daten direkt extern in den eingebundenen shares liegen.


    Könnte man jetzt nutzen, das mal so neu auf zu bauen.

    Mit eh ein Rätsel, wie mit einer Firmware von 2021 noch arbeiten und ggf. Dienste über das LAN hinaus anbietet.

  • Dann hast du Conti und Daten nicht getrennt.

    Wie mache ich das denn am sinnvollsten?


    vielleicht kannst Du das Problem ja nochmal kurz zusammenfassen und/oder die Posts verlinken, damit sie nicht suchen muss...

    Letztendlich ist das Problem im Wesentlichen, dass versuche, die Daten der Containerstation zu sichern, aber Schwierigkeiten mit den symbolischen Links habe. Kopieren per cp klappt nicht, wie bereits weiter oben beschrieben. Per WinSCP über SFTP bekomme ich die Fehlermeldung

    Code
    Die Datei „/share/CACHEDEV1_DATA/Container/container-station-data/lib/docker/overlay2/d9a0b5d2f5cfc90a2eed3e51646c3a7812529d9f2d34f0729163dc031f399c74/diff/etc/ssl/certs/06dc52d5.0“ kann auf der Gegenstelle nicht geöffnet werden.
    Datei oder Verzeichnis nicht gefunden.
    Fehlercode: 2
    Fehlernachricht vom Server : No such file

    Und wenn ich direkt über Windows darauf zugreife, schafft er es nichtmals die Verzeichnisgröße zu berechnen, da er scheinbar irgendwo im Kreis läuft, denn auf einem RAID5 aus 4x256GB werden sicher nicht über 16PB (=16.000TB) liegen.

    pasted-from-clipboard.png



    Mit eh ein Rätsel, wie mit einer Firmware von 2021 noch arbeiten und ggf. Dienste über das LAN hinaus anbietet.

    Solange ich das System in meinem eigenen Netz nutze, wollte ich einfach immer nur so wenig wie möglich verändern, da ich ja ein stabil lauffähiges System hatte, was ja auch über 1000 Tage problemlos lief.

  • Aktuell gab es bei Daten der Containerstation beim Kopieren mittels cp -r -a -l Probleme mit symbolischen Links, als ich versucht habe, einfach den kompletten Inhalt des RAID5 auf ein gemountetes Samba-Netzlaufwerk eines anderen NAS von mir zu kopieren.

    Erstmal falsche Optionen

    Mit -l legst du Hardlinks an. Das willst du nicht.

    Lt. Doku sind -r und -R gleich, aber ich erinnere mich dunkel daran, mit -r schon mal Probleme mit symbolischen Links gehabt zu haben. -R geht in jedem Falle, also cp -aR.


    SMB (Samba) kann keine symbolischen Links. Du musst das Laufwerk mit nfs mounten, wenn du symbolische Links kopieren willst.


    Bei nfs muss du darauf achten, dass beide NAS für dieselben User dieselben User-IDs haben. Notfalls kann man die User-IDs der Dateien nachträglich korrigieren.

    Ab nfs4.0 kann man statt User-IDs auch über gleiche Usernamen gehen.

  • Lt. Doku sind -r und -R gleich, aber ich erinnere mich dunkel daran, mit -r schon mal Probleme mit symbolischen Links gehabt zu haben. -R geht in jedem Falle, also cp -aR.

    Vielen Dank für den Tipp. Ich hatte immer nur das kleine "r" versucht. Erstaunlich, dass es mir dem großen "R" nun klappt, denn damit hat das Kopieren auf ein NFS4.0 Share auf einem anderen NAS ohne Fehlermeldung funktioniert. Ob die Containerstation die Daten am Ende dann auch so übernimmt, sehe ich, wenn ich nach der Neueinrichtung des NAS alles zurück kopiert habe.


    Aktuell habe ich jedoch bei der Einrichtung mit 4 komplett neuen SSDs das Problem, dass sich das NAS irgendwie merkwürdig verhält. Ich habe schon etliche QNAP NAS eingerichtet, aber diesmal ist es irgendwie komisch. Das Display am NAS hängt auf einmal, Verbindungen zum NAS (SSH, Samba, Webinterface) sind plötzlich nicht mehr möglich, eine laufende SSH Sitzung funktioniert jedoch noch, IP Adressen sind kurzzeitig weg und auf dem Display vom NAS stehen statt einer IP nur noch kryptische Zeichen. Nach einem Neustart geht kurz alles wieder, dann kommt es wieder zu so "komischem Verhalten".


    Meine Vermutung ist, dass die Firmware im DOM (oder der DOM) selbst doch irgendwie einen Fehler hat, wie dolbyman weiter oben ja schonmal vermutet hatte. Anfangs sprach vieles dagegen, aber jetzt fällt mir dafür keine andere Erklärung ein.

    Daher werde ich mal versuchen, nochmal die Firmware per Webinterface drüber zu spielen und hoffen, dass das die Fehler behebt. Ansonsten wird es wohl ein Firmware Recovery geben.

    Ich werde berichten.

  • Meine Vermutung ist, dass die Firmware im DOM (oder der DOM) selbst doch irgendwie einen Fehler hat

    Halte ich für sehr unwahrscheinlich, da das OS auf dem DOM nur dafür genutzt wird von den Disks zu booten.

    Es scheint eher, als hätte das NAS hardwaretechnisch ein Problem... wobei ich mir solch ein Fehlerbild hardwarechnisch nicht erklären kann... Wurde hier eine Sicherung der alten Config eingespielt? Das könnte es erklären.

  • Wurde hier eine Sicherung der alten Config eingespielt?

    Nein.


    Ich habe jetzt einfach mal die 4.3.6 nochmal drüber installiert (nur ein neuerer Build, da ich den Build von 2021 nicht mehr herunterladen konnte) und bislang läuft das NAS seit 2h stabil, vorher traten die Probleme jeweils nach spätestens 10min auf. Also mal beobachten.


    Und der Tipp von Anthracite für das Kopieren der Containerstation Daten war echt Gold wert. Konnte so die Daten komplett wieder einspielen und es scheinen alle Container komplett funktionsfähig kopiert worden zu sein.