komplette Reinstallation einer fehlerhaften Installation

    • OMV 4.x
    • Resolved
    • komplette Reinstallation einer fehlerhaften Installation

      Leider hatte es mir meine NAS während eines Updates zerschossen, die anfänglichen Fehler mit superblocks ließen sich zwar beheben, aber nach unbestimmter Zeit beendet sich das System mit unterschiedlichen Fehlern. Kurz: Ich möchte die Zeit lieber investieren in eine saubere Neuinstallation, statt weiter Fehler zu suchen. Gerne hätte ich Eure Meinung, ob mein geplantes Vorgehen zweckdienlich bzgl. sinnvoll wäre:

      Aufbau der NAS:
      1. Debian mit OVM auf einer SSD installiert
      2. Daten liegen auf mehreren ext4-Festplatten, KEIN Raid
      3. Verschiedene Skripte (gesichert) für Dateioperationen (rotierende Backups)
      4. Dienste: neben den üblichen wie (ssh, rsync, minidlna, samba etc): Docker (!)
      5. Verschiedene Samba-Freigaben
      Geplantes Vorgehen:
      1. Eine Paket-Liste anlegen und etwas von Hand überarbeiten (siehe Skript unten, lässt sich offenbar nicht in die Liste aufnehmen)
      2. Von allen OMV-Konfig-Seiten ein screenshot erstellen, um die Einstellungen zu übernehmen.
      3. Die geplanten Tasks inkl. der Shell-Befehle sichern (bspw. Start von Docker-Containern).
      4. Debian neu aufsetzen und OMV 'normal' installieren
      5. Die Paketliste wieder einspielen (siehe unten)
      6. IP im Router statisch definieren
      7. Laufwerke unter gleichem Namen neu einbinden und Samba-Freigaben wiederherstellen
      8. Alle weiteren Einstellungen übernehmen (Grundlage: Screenshots)
      9. Docker zum Laufen kriegen? ?(

      Shell-Script: paketliste-erstellen.sh

      1. dpkg -l | egrep ^ii\|^hi | awk '{ print $2 }' > paket-liste.txt

      Source Code: pakete-installieren.sh

      1. apt install $(cat paket-liste.txt)

      Abgesehen von Docker: macht das so Sinn oder gibt es ggf. ein besseres oder einfacheres Vorgehen?

      Und bzgl. Docker (ist mir wichtig): kann ich da was falsch machen? Angenommen, die Freigabepfade stimmen alle und die Dateien sind unbeschädigt, lassen sich die Container dann wieder im gleichen Zustand auf gewohnte Weise starten? Ich möchte einfach den aktuellen Stand nicht verlieren...

      Vielen Dank für Eure Hilfe!!
    • getName() wrote:

      Wenn die Container zur Laufzeit keine Änderungen außerhalb der Freigabepfade hatten, ist das kein Problem. Ansonsten kann man auch container stoppen und den Zustand exportieren, das wifärd dann als weitere layer behandelt.
      Danke! Die Container würde ich vor der Neuinstallation also manuell stoppen, sollte kein Problem sein. Gestartet werden sie sowieso über die bash (geplante Aufgaben). Das mit dem Exportieren der Container werde ich mal noch recherchieren, wäre sicher eine sehr sinnvolle Sache. Stelle ich mir vor wie ein Sicherungszustand in Virtualbox? Bzw. generiere ich aus einem Container (mit aktuellem Datenstand) damit quasi ein neues (bzw. modifiziertes) Image?
    • Das mit Docker habe ich soweit wohl schon ganz gut begriffen und habe die Container sowohl mit 'docker commit' als image gesichert, als auch mit 'docker save' als .tar exportiert.

      Ansonsten: hat jemand noch Hinweise, ob es überflüssige, falsche oder fehlende Punkte oben geben könnte? Paketlisten und Backups der Einstellungen (nur als Screenshot) sind erledigt, eigentlich könnte ich die NAS wohl jetzt neu aufsetzen.
    • Abschließende Rückmeldung:
      • Wie sich bei der Neuinstallation herausstellte, war die (schon etwas ältere) SSD defekt, auf der ich OMV installiert hatte. Auf einer anderen läuft es wunderbar :thumbsup:
      • Docker lief unmittelbar, was fast schon irritierend war (Backups hatte ich dennoch angefertigt). Nachdem die Freigaben wiederhergestellt waren, hatte ich in der Docker-GUI lediglich den korrekten alten Pfad angegeben und das Plugin aktiviert - sofort wurden alle Images/Container gefunden und die Container korrekt gestartet. Genial!!
      • Nur einen Punkt hatte ich oben vergessen: ich hätte über 'crontab -e' mal noch schauen sollen, ob jenseits von OMV Tasks programmiert waren, was bei mir der Fall war. Glücklicherweise fand ich die notwendigen Daten noch in einem alten Backup (die entsprechende cron-Datei befindet sich unter /var/spool/cron/crontabs