Plötzlich werden Failover Strategie & Backups benötigt
-
Hallo zusammen,
am letzten Samstag war es soweit - ich war auf meine Backups angewiesen. Gut wenn man vorbereitet ist - "schlecht" wenn einer der einzigen nicht 100% abgesicherten Fälle passiert. Die Geschichte in kurz: Ich war nicht mehr in der Lage Docker Container auf der Synology DS918+ zu Starten und somit haben mir auch meine Backups erstmal nicht weiter geholfen.Hier ein kleiner Erfahrungsbericht:
Was ist passiert? Irgendwann letzte Woche gab es ein Update des Docker-Packetes für die Synology. Das habe ich dann auch installiert. Am Samstag wurden, automatisch ausgelöst durch meinen ouroboros / watchtower Container, diverse Container aktualisiert. Diese blieben im Status "werden Entfernt" hängen.
Als ich dann in die Garage gehen wollte und das Tor nicht über den HomeMatic Schalter hochgefahren werden konnte, viel mir dieser Zustand auf und Ich schaute ich mir das ganze an (das Fleisch lag zu diesem Zeitpunkt schon aufm Grill :)). Die Container in diesem Status konnte ich entfernen und wollte sie danach neu starten. Am Rande: Ich steuere Docker auf der Synology zu 100% von der Shell. Das neu Starten war aber leider nicht möglich.
Es hagelte beim Starten der Container diverse Fehlermeldungen bzgl. Rechten und Subvolumes unter /volume1/@docker/btrfs/subvolumes/...
Irgendwas muss also an dieser Stelle den subvolumes von btrfs nicht gefallen haben.In der Folge habe ich dann alle Container entfernt, das Docker Paket deinstalliert, wieder neu installiert, die lokalen Docker Images gelöscht, versucht /volume1/@docker zu löschen - und wahrscheinlich noch einiges mehr. Auch der Paket-Dienst der Synology hat zwischendurch mal gesponnen und es waren einige neustarts notwendig.
Ich habe dann irgendwann Abends die Versuche Docker wieder zum Leben zu bekommen sein Gelassen und auf meinem alten i7 3770K, auf dem zur Zeit meine Testumgebung mit Proxmox läuft, eine VM mit Docker installiert und dort die Container wieder in Betrieb genommen. Somit war zumindest die Grundlegende Funktion wieder hergestellt und Zeit gewonnen. Immerhin war es auch schon 2Uhr :) Leider habe ich es bisher nicht mehr hinbekommen Docker auf der Synology 918+ zum Laufen zu bekommen - diese Baustelle gehe ich die Tage nochmal an. Das NAS selbst läuft stabil, die Volumes sind in Ordnung, die S.M.A.R.T Werte ebenso. Weis der Geier was da los war/ist.
In der ganzen Situation habe ich auch festgestellt, das ich zwar bzgl. Backups gut aufgestellt bin (3-2-1 Methode und die lokalen Sicherungen sind je 6h Stunden alt), aber blöderweise die Daten der Docker-Container nur über Hyper-Backup auf einem weiteren NAS und in der C2 Cloud habe. Ein schneller Restore war darüber leider nicht möglich (das Warten war mit das nervigste bei der ganzen Geschichte). D.h. in Zukunft gibt es davon auch eine direkt Verfügbare Kopie auf einer lokalen Festplatte.
Das ganze läuft nun seit Samstag stabil in der VM mit den Docker Container bzw. zum Teil auch bereits ausgelagert in LXCs. Für die Zukunft sollte Morgen ein Intel NUC i5 eintreffen und wird dann entsprechend aufgebaut und eingerichtet - sehr wahrscheinlich ebenfalls mit Proxmox. Sobald Docker dann auf der Synology wieder läuft habe ich eine weitere Möglichkeit manuell reagieren/ausweichen zu können.
Frage an alle, ich denke aus der Diskussion können einige etwas mitnehmen und lernen:
Wie habt ihr euch abgesichert?
Habt ihr Hochverfügbarkeit Lösungen im Einsatz und wie schauen diese aus (gibt es Sinnvolle Lösungen für den Heimgebrauch, ggf. proxmox-Cluster)?Bin auf eure Antworten gespannt, die Fragen können auch gerne ergänzt werden :)
Proxmox-ioBroker-Redis-HA Doku: https://forum.iobroker.net/topic/47478/dokumentation-einer-proxmox-iobroker-redis-ha-umgebung
-
Hallo zusammen,
am letzten Samstag war es soweit - ich war auf meine Backups angewiesen. Gut wenn man vorbereitet ist - "schlecht" wenn einer der einzigen nicht 100% abgesicherten Fälle passiert. Die Geschichte in kurz: Ich war nicht mehr in der Lage Docker Container auf der Synology DS918+ zu Starten und somit haben mir auch meine Backups erstmal nicht weiter geholfen.Hier ein kleiner Erfahrungsbericht:
Was ist passiert? Irgendwann letzte Woche gab es ein Update des Docker-Packetes für die Synology. Das habe ich dann auch installiert. Am Samstag wurden, automatisch ausgelöst durch meinen ouroboros / watchtower Container, diverse Container aktualisiert. Diese blieben im Status "werden Entfernt" hängen.
Als ich dann in die Garage gehen wollte und das Tor nicht über den HomeMatic Schalter hochgefahren werden konnte, viel mir dieser Zustand auf und Ich schaute ich mir das ganze an (das Fleisch lag zu diesem Zeitpunkt schon aufm Grill :)). Die Container in diesem Status konnte ich entfernen und wollte sie danach neu starten. Am Rande: Ich steuere Docker auf der Synology zu 100% von der Shell. Das neu Starten war aber leider nicht möglich.
Es hagelte beim Starten der Container diverse Fehlermeldungen bzgl. Rechten und Subvolumes unter /volume1/@docker/btrfs/subvolumes/...
Irgendwas muss also an dieser Stelle den subvolumes von btrfs nicht gefallen haben.In der Folge habe ich dann alle Container entfernt, das Docker Paket deinstalliert, wieder neu installiert, die lokalen Docker Images gelöscht, versucht /volume1/@docker zu löschen - und wahrscheinlich noch einiges mehr. Auch der Paket-Dienst der Synology hat zwischendurch mal gesponnen und es waren einige neustarts notwendig.
Ich habe dann irgendwann Abends die Versuche Docker wieder zum Leben zu bekommen sein Gelassen und auf meinem alten i7 3770K, auf dem zur Zeit meine Testumgebung mit Proxmox läuft, eine VM mit Docker installiert und dort die Container wieder in Betrieb genommen. Somit war zumindest die Grundlegende Funktion wieder hergestellt und Zeit gewonnen. Immerhin war es auch schon 2Uhr :) Leider habe ich es bisher nicht mehr hinbekommen Docker auf der Synology 918+ zum Laufen zu bekommen - diese Baustelle gehe ich die Tage nochmal an. Das NAS selbst läuft stabil, die Volumes sind in Ordnung, die S.M.A.R.T Werte ebenso. Weis der Geier was da los war/ist.
In der ganzen Situation habe ich auch festgestellt, das ich zwar bzgl. Backups gut aufgestellt bin (3-2-1 Methode und die lokalen Sicherungen sind je 6h Stunden alt), aber blöderweise die Daten der Docker-Container nur über Hyper-Backup auf einem weiteren NAS und in der C2 Cloud habe. Ein schneller Restore war darüber leider nicht möglich (das Warten war mit das nervigste bei der ganzen Geschichte). D.h. in Zukunft gibt es davon auch eine direkt Verfügbare Kopie auf einer lokalen Festplatte.
Das ganze läuft nun seit Samstag stabil in der VM mit den Docker Container bzw. zum Teil auch bereits ausgelagert in LXCs. Für die Zukunft sollte Morgen ein Intel NUC i5 eintreffen und wird dann entsprechend aufgebaut und eingerichtet - sehr wahrscheinlich ebenfalls mit Proxmox. Sobald Docker dann auf der Synology wieder läuft habe ich eine weitere Möglichkeit manuell reagieren/ausweichen zu können.
Frage an alle, ich denke aus der Diskussion können einige etwas mitnehmen und lernen:
Wie habt ihr euch abgesichert?
Habt ihr Hochverfügbarkeit Lösungen im Einsatz und wie schauen diese aus (gibt es Sinnvolle Lösungen für den Heimgebrauch, ggf. proxmox-Cluster)?Bin auf eure Antworten gespannt, die Fragen können auch gerne ergänzt werden :)
-
@darkiop
Ich repliziere zwischen 2 NUCs. unter diesem Stichwort solltest Du auch einige Beiträge hier im Forum finden@BBTown Ja, das ist eine Option. Ich werde den NUCmit Proxmox frisch einrichten und sobald dieser dann Produktiv läuft auch den PC mit dem i7 neu mit Proxmox aufsetzen und verbinden.
Auf welches Dateisystem hast du bei deiner Installtion gesetzt? ZFS ist aktuell noch keine Option, da nur eine nvme SSD verbaut wird.
Hast du dein Storage für die Container/VM extern auf einem NAS liegen?
Desweiteren suche ich noch einen Pest Practice Ansatz um auf das Filesystem der LXCs von Windows Clients aus zuzugreifen. In jedem Container einen smbd installieren oder auf über den Host selbst?
Proxmox-ioBroker-Redis-HA Doku: https://forum.iobroker.net/topic/47478/dokumentation-einer-proxmox-iobroker-redis-ha-umgebung
-
@BBTown Ja, das ist eine Option. Ich werde den NUCmit Proxmox frisch einrichten und sobald dieser dann Produktiv läuft auch den PC mit dem i7 neu mit Proxmox aufsetzen und verbinden.
Auf welches Dateisystem hast du bei deiner Installtion gesetzt? ZFS ist aktuell noch keine Option, da nur eine nvme SSD verbaut wird.
Hast du dein Storage für die Container/VM extern auf einem NAS liegen?
Desweiteren suche ich noch einen Pest Practice Ansatz um auf das Filesystem der LXCs von Windows Clients aus zuzugreifen. In jedem Container einen smbd installieren oder auf über den Host selbst?
-
Hallo zusammen,
am letzten Samstag war es soweit - ich war auf meine Backups angewiesen. Gut wenn man vorbereitet ist - "schlecht" wenn einer der einzigen nicht 100% abgesicherten Fälle passiert. Die Geschichte in kurz: Ich war nicht mehr in der Lage Docker Container auf der Synology DS918+ zu Starten und somit haben mir auch meine Backups erstmal nicht weiter geholfen.Hier ein kleiner Erfahrungsbericht:
Was ist passiert? Irgendwann letzte Woche gab es ein Update des Docker-Packetes für die Synology. Das habe ich dann auch installiert. Am Samstag wurden, automatisch ausgelöst durch meinen ouroboros / watchtower Container, diverse Container aktualisiert. Diese blieben im Status "werden Entfernt" hängen.
Als ich dann in die Garage gehen wollte und das Tor nicht über den HomeMatic Schalter hochgefahren werden konnte, viel mir dieser Zustand auf und Ich schaute ich mir das ganze an (das Fleisch lag zu diesem Zeitpunkt schon aufm Grill :)). Die Container in diesem Status konnte ich entfernen und wollte sie danach neu starten. Am Rande: Ich steuere Docker auf der Synology zu 100% von der Shell. Das neu Starten war aber leider nicht möglich.
Es hagelte beim Starten der Container diverse Fehlermeldungen bzgl. Rechten und Subvolumes unter /volume1/@docker/btrfs/subvolumes/...
Irgendwas muss also an dieser Stelle den subvolumes von btrfs nicht gefallen haben.In der Folge habe ich dann alle Container entfernt, das Docker Paket deinstalliert, wieder neu installiert, die lokalen Docker Images gelöscht, versucht /volume1/@docker zu löschen - und wahrscheinlich noch einiges mehr. Auch der Paket-Dienst der Synology hat zwischendurch mal gesponnen und es waren einige neustarts notwendig.
Ich habe dann irgendwann Abends die Versuche Docker wieder zum Leben zu bekommen sein Gelassen und auf meinem alten i7 3770K, auf dem zur Zeit meine Testumgebung mit Proxmox läuft, eine VM mit Docker installiert und dort die Container wieder in Betrieb genommen. Somit war zumindest die Grundlegende Funktion wieder hergestellt und Zeit gewonnen. Immerhin war es auch schon 2Uhr :) Leider habe ich es bisher nicht mehr hinbekommen Docker auf der Synology 918+ zum Laufen zu bekommen - diese Baustelle gehe ich die Tage nochmal an. Das NAS selbst läuft stabil, die Volumes sind in Ordnung, die S.M.A.R.T Werte ebenso. Weis der Geier was da los war/ist.
In der ganzen Situation habe ich auch festgestellt, das ich zwar bzgl. Backups gut aufgestellt bin (3-2-1 Methode und die lokalen Sicherungen sind je 6h Stunden alt), aber blöderweise die Daten der Docker-Container nur über Hyper-Backup auf einem weiteren NAS und in der C2 Cloud habe. Ein schneller Restore war darüber leider nicht möglich (das Warten war mit das nervigste bei der ganzen Geschichte). D.h. in Zukunft gibt es davon auch eine direkt Verfügbare Kopie auf einer lokalen Festplatte.
Das ganze läuft nun seit Samstag stabil in der VM mit den Docker Container bzw. zum Teil auch bereits ausgelagert in LXCs. Für die Zukunft sollte Morgen ein Intel NUC i5 eintreffen und wird dann entsprechend aufgebaut und eingerichtet - sehr wahrscheinlich ebenfalls mit Proxmox. Sobald Docker dann auf der Synology wieder läuft habe ich eine weitere Möglichkeit manuell reagieren/ausweichen zu können.
Frage an alle, ich denke aus der Diskussion können einige etwas mitnehmen und lernen:
Wie habt ihr euch abgesichert?
Habt ihr Hochverfügbarkeit Lösungen im Einsatz und wie schauen diese aus (gibt es Sinnvolle Lösungen für den Heimgebrauch, ggf. proxmox-Cluster)?Bin auf eure Antworten gespannt, die Fragen können auch gerne ergänzt werden :)
@darkiop
Das Update von Docker auf der Syno wurde mir auch am WE angeboten. Ich dachte dann so, ach ne, heute nicht, sonst geht nachher irgendwas nicht....
Ich habe es bis jetzt noch nicht gemacht. Meinst Du das ist/war die Ursache des "Übels" ? Sollte man das Update erstmal sein lassen ? -
@darkiop
ich glaube für die Replikation ins zfs Voraussetzung.
Ist das Thema NVMe nicht seit Proxmox v6.x Geschichte?Alles was nicht Produktiv ist (Dateiablage, Backups) wird bei mir auf einein NAS abgelegt
@BBTown sagte in Plötzlich werden Failover Strategie & Backups benötigt:
@darkiop
ich glaube für die Replikation ins zfs Voraussetzung.
Ist das Thema NVMe nicht seit Proxmox v6.x Geschichte?
Alles was nicht Produktiv ist (Dateiablage, Backups) wird bei mir auf einein NAS abgelegtIch hab gerade gesehen, das man auch mit einer SSD (dann als pseudo Raid0) ein ZFS Dateisystem einrichten kann. Das werde ich mal testen.
Was meinst du mit Geschichte? Gab es da Probleme?
@dslraser sagte in Plötzlich werden Failover Strategie & Backups benötigt:
@darkiop
Das Update von Docker auf der Syno wurde mir auch am WE angeboten. Ich dachte dann so, ach ne, heute nicht, sonst geht nachher irgendwas nicht....
Ich habe es bis jetzt noch nicht gemacht. Meinst Du das ist/war die Ursache des "Übels" ? Sollte man das Update erstmal sein lassen ?Ich bin mir ziemlich sicher das dies der Auslöser war - das System lief vorher nun fast 2 Jahre 100% stabil ... und das Changelog in der neuen Version hat ja auch darauf hingewiesen (2.):
Beim bereinigen der hängenden Container muss dann irgendwas in den Subvolumes von BTRFS kaputt gegangen sein ... Ich werde die Tage mal versuchen das ganze noch zu retten.
Proxmox-ioBroker-Redis-HA Doku: https://forum.iobroker.net/topic/47478/dokumentation-einer-proxmox-iobroker-redis-ha-umgebung
-
@BBTown sagte in Plötzlich werden Failover Strategie & Backups benötigt:
@darkiop
ich glaube für die Replikation ins zfs Voraussetzung.
Ist das Thema NVMe nicht seit Proxmox v6.x Geschichte?
Alles was nicht Produktiv ist (Dateiablage, Backups) wird bei mir auf einein NAS abgelegtIch hab gerade gesehen, das man auch mit einer SSD (dann als pseudo Raid0) ein ZFS Dateisystem einrichten kann. Das werde ich mal testen.
Was meinst du mit Geschichte? Gab es da Probleme?
@dslraser sagte in Plötzlich werden Failover Strategie & Backups benötigt:
@darkiop
Das Update von Docker auf der Syno wurde mir auch am WE angeboten. Ich dachte dann so, ach ne, heute nicht, sonst geht nachher irgendwas nicht....
Ich habe es bis jetzt noch nicht gemacht. Meinst Du das ist/war die Ursache des "Übels" ? Sollte man das Update erstmal sein lassen ?Ich bin mir ziemlich sicher das dies der Auslöser war - das System lief vorher nun fast 2 Jahre 100% stabil ... und das Changelog in der neuen Version hat ja auch darauf hingewiesen (2.):
Beim bereinigen der hängenden Container muss dann irgendwas in den Subvolumes von BTRFS kaputt gegangen sein ... Ich werde die Tage mal versuchen das ganze noch zu retten.
@darkiop
ich habe noch eine alte Syno bei mir im Büro, da läuft noch (ungenutzt) ein Container mit iobroker drauf. Ich glaube noch js-controller 1.4 irgendwas und noch node 8
Diese Syno steht auf auto update und hat das Docker Update schon gemacht. Ich habe da vorhin mal drauf geschaut, iobroker scheint da noch ganz normal zu laufen...(Buanet Image steht auf latest) Ich habe da aber noch nicht genau nachsehen können. -
@darkiop
ich habe noch eine alte Syno bei mir im Büro, da läuft noch (ungenutzt) ein Container mit iobroker drauf. Ich glaube noch js-controller 1.4 irgendwas und noch node 8
Diese Syno steht auf auto update und hat das Docker Update schon gemacht. Ich habe da vorhin mal drauf geschaut, iobroker scheint da noch ganz normal zu laufen...(Buanet Image steht auf latest) Ich habe da aber noch nicht genau nachsehen können. -
@BBTown sagte in Plötzlich werden Failover Strategie & Backups benötigt:
@darkiop
ich glaube für die Replikation ins zfs Voraussetzung.
Ist das Thema NVMe nicht seit Proxmox v6.x Geschichte?
Alles was nicht Produktiv ist (Dateiablage, Backups) wird bei mir auf einein NAS abgelegtIch hab gerade gesehen, das man auch mit einer SSD (dann als pseudo Raid0) ein ZFS Dateisystem einrichten kann. Das werde ich mal testen.
Was meinst du mit Geschichte? Gab es da Probleme?
@dslraser sagte in Plötzlich werden Failover Strategie & Backups benötigt:
@darkiop
Das Update von Docker auf der Syno wurde mir auch am WE angeboten. Ich dachte dann so, ach ne, heute nicht, sonst geht nachher irgendwas nicht....
Ich habe es bis jetzt noch nicht gemacht. Meinst Du das ist/war die Ursache des "Übels" ? Sollte man das Update erstmal sein lassen ?Ich bin mir ziemlich sicher das dies der Auslöser war - das System lief vorher nun fast 2 Jahre 100% stabil ... und das Changelog in der neuen Version hat ja auch darauf hingewiesen (2.):
Beim bereinigen der hängenden Container muss dann irgendwas in den Subvolumes von BTRFS kaputt gegangen sein ... Ich werde die Tage mal versuchen das ganze noch zu retten.
@darkiop sagte in Plötzlich werden Failover Strategie & Backups benötigt:
Was meinst du mit Geschichte? Gab es da Probleme?
(Gedächtnisprotokoll) Ich meine mich zu erinnern, dass es mit der Proxmox v5.x beim NUC Probleme beim Booten einer NVMe gabe wenn diese zfs als Dateisystem hatte.
Ist aber schein eine Weile her und ich nutze eine SSD und habe die NVMe hintendran
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden539
Online32.8k
Benutzer82.9k
Themen1.3m
Beiträge