Notfall-Backup - Direktleitung zur Container-Befehlszeile

Installation
1

Ich habe etwas gelernt, das anderen helfen könnte.

Hintergrund: Wie anderswo detailliert beschrieben, wurde meine Discourse-Installation auf einem VPS gehostet, dessen Festplatte zu klein war, um ein Upgrade abzuschließen. Zuerst klickte ich im Admin-Kontrollfeld auf „Upgrade“. Das Upgrade schlug fehl und die GUI funktionierte nie wieder. Danach meldete ich mich an der Konsole meines VPS an und gab den berühmten Befehl ./launcher rebuild app ein. Auch dieser wurde nie vollständig ausgeführt: Mir ging der Festplattenspeicher entscheidend aus. Um mehr Speicherplatz zu erhalten und im Budget zu bleiben, beschloss ich, mein gesamtes Setup auf einen neuen VPS bei einem anderen Hosting-Unternehmen zu verschieben. Die Sicherung der wertvollen Website-Daten hatte hohe Priorität.

Fehler: Die beiden offensichtlichsten Methoden zur Sicherung funktionierten nicht:

  • Mein ursprünglicher Versuch, das Upgrade durchzuführen, beschädigte die webbasierte GUI, sodass es keine Möglichkeit gab, auf das Admin-Kontrollfeld zuzugreifen und von dort aus eine Sicherung zu initiieren.
  • Der Versuch, in den Docker-Container zu gelangen und ihm einige Shell-Befehle zu geben, funktionierte ebenfalls nicht. Der empfohlene Befehl dafür ist /var/discourse/launcher enter app. Aber zumindest in meinem Fall versuchte das launcher-Skript, die App neu zu erstellen, bevor es mir erlaubte, sie zu betreten, und die Neuerstellungen schlugen durchweg fehl, sodass dieser Befehl mir nie einen Container verschaffte, geschweige denn eine Shell darin.

Erfolg: Ich wollte schon aufgeben, als ich eine angenehme Überraschung erlebte. Als ich auf der Kommandozeile meiner kleinen VM arbeitete, gab ich docker ps ein und stellte fest, dass ein aktiver Container namens app vorhanden war. Und Docker hat eine direkte Möglichkeit, in einen laufenden Container zu gelangen: Der Befehl lautet docker exec -it app bash.

Innerhalb des Containers konnte ich Fortschritte machen: Ich gab den Befehl discourse backup ein, wartete ein paar Minuten und kopierte dann die Datei <backup>.tar.gz an einen sicheren neuen Ort. Mit einer aktuellen Sicherung war es möglich, die Migration meines Setups an seinen neuen Standort abzuschließen. (Es gibt andere Threads in diesen Foren, die zeigen, wie das geht.)

Der entscheidende Punkt hier ist, dass der obige docker-Befehl zum Betreten des Containers funktionierte, auch wenn der Discourse-spezifische ./launcher-Befehl dies nicht tat.

Vielen Dank an die Erfinder und Betreuer dieses hervorragenden Produkts.

3 „Gefällt mir“
2

Haben Sie versucht,

./launcher cleanup

oder einige Backups zu löschen?

1 „Gefällt mir“
3

Danke für die Nachfrage.

Während der Tage, an denen ich versuchte, mein ursprüngliches Setup zum Laufen zu bringen, dachte ich, ich hätte alles Mögliche getan, um Speicherplatz freizugeben, sicherlich einschließlich ./launcher cleanup, aber auch viel mehr … alte Kernel entfernt, den apt-Cache geleert, nicht essentielle Software verworfen usw. usw.

Nachdem ich mich entschlossen hatte, meine gesamte Website umzuziehen und viel Zeit in den Prozess investiert hatte, fragte ich mich, ob ich mehr hätte tun können … aber da hatte ich die Motivation verloren, weiter zu recherchieren. (vgl. „Sunk-Cost-Fehlschluss“.) Genauer gesagt, hatte der VPS, den ich gerade aufgeben wollte, eine Nennfestplattengröße von 25 GB. Etwa 19 GB davon waren dem Verzeichnis /var/lib/docker/overlay2 gewidmet. Und die einzigen Docker-Container, die ich ausführte, waren Discourse und sein zugehöriger Mail-Empfänger. Die Erfahrung zeigt, dass Discourse, so leistungsfähig es auch ist, mit deutlich weniger als 19 GB auf der Festplatte laufen sollte. Aber Internetrecherchen schienen darauf hinzuweisen, dass Änderungen im overlay2-Verzeichnis unsicher seien, daher fühlte ich mich an diesem Punkt gestoppt.

In meinem neuen, frischen Setup belegt das Verzeichnis /var/lib/docker/overlay2 13 GB. Immer noch riesig.

Ich habe mich für Discourse entschieden, um die Foren auf meiner kleinen Hobby-Website zu betreiben, in der Hoffnung, dass es „einfach funktioniert“ – d. h., dass es super einfach zu verwalten ist, ohne viele neue Dinge lernen zu müssen. Das scheint größtenteils richtig zu sein, wenn man über ausreichend (übermäßige?) Ressourcen verfügt, die man zuweisen kann.

Mein neuer Plan ist, blind darauf zu hoffen, dass das overlay2-Verzeichnis im Laufe der Zeit nicht wächst und die 50 GB Festplatte meines neuen VPS überflutet. Wenn Sie (oder jemand anderes) wissen, wie man die Größe des Docker- und Discourse-Dynamikduos unter Kontrolle hält, würde ich es gerne erfahren. Es wäre ein schöner Abschluss für den Rest des Lernens, das ich in den letzten Tagen gemacht habe. Nochmals vielen Dank.

4

Schön, dass Sie sich selbst retten konnten. Ich betreibe zwei kleine Foren, eines für 20G-Speicher und das andere für 25G. Ich muss manchmal ziemlich viel Zeit und Einfallsreichtum aufwenden, um das am Laufen zu halten. Aber ich scheine auch immer wieder die gleichen Taktiken anzuwenden (und darüber zu posten). Siehe unten.

Die Entwicklung von Discourse ist auf andere Dinge optimiert als auf den Betrieb auf kostengünstiger Hardware – obwohl sie für mich in meiner eingeschränkten Umgebung gerade noch funktioniert. Möge es lange so bleiben.

Der Schlüssel zur Arbeit in kleinen Speichersystemen ist die Messung dessen, was vor sich geht – zu oft sehe ich Leute raten, was vor sich gehen könnte. Mein Ansatz beginnt immer mit

Für mehr suchen Sie vielleicht nach meinen Beiträgen zu prune und journalctl und kernel.

2 „Gefällt mir“