Das Tool starship hatte ich schon mal in einem Blog-Artikel erwähnt und genauer beschrieben:

Der Standard-Prompt ist zu langweilig? Die Befüllung der Variablen PS1 ist zu kompliziert und unflexibel? Es sollen mehr Informationen dargestellt werden?

Kein Problem, ich habe jetzt das Tool Starship für mich entdeckt…

Vor einiger Zeit habe ich die Installation des Tool inklusive mit meiner Konfiguration in eine Ansible-Rolle gegossen.

Bei einem dateibasierten Backup wollte ich nicht immer alle Dateien und Unterverzeichnisse in die Sicherung mit aufnehmen.

Viele Tool wie restic, backup oder auch tar unterstützen eine externe Datei, wo diese Ausnahmen gepflegt werden können.

Allerdings vergesse ich manchmal diese Datei zu pflegen oder die Syntax ist etwas umständlich.

Manchmal möchte man auch nur-mal-eben-schnell ^(tm) ein Verzeichnis ausschließen.

Dafür gibt es die Möglichkeit über eine Datei namens CACHEDIR.TAG zu nutzen.

Letztens habe ich ein weiteren Kniff gelernt, der in Zusammenhang mit ssh-Verbindungen hilfreich ist.

Wenn man wie ich mit mehreren Servern jongiert, wird die ssh-Konfigurationsdatei irgendwann recht voll und unübersichtlich. Mittels eines Paramters, kann ich die Konfigurationsdatei allerdings in unterschiedliche Dateien aufteilen.

Ich stand vor der Herausforderung, dass ich wissen wollte, ob es für Docker-Images, die ich verwende, Updates bzw. eine neue Image-Version gibt. Der Klassiker ist latest wie z.B. bei jellyfin/jellyfin:latest. Aber auch Haupt-Versionen werden zum Teil benannt: postgres:13 .

Bei der Verwendung von docker compose sind die Docker-Images sind z.B. in einer docker-compose.yml-Datei hinterlegt, wo ich das selbstgeschrieben Script update_docker_images.sh verwende, um die Container zu aktualisieren.

Heute möchte ich über das Thema Datensicherung aka Backups schreiben. Hier und da wurde ich gefragt, wie ich das löse bzw. umgesetzt habe.

Mariannes Blog-Artikel gab den Ausschlag dieses nun endlich mal aufzuschreiben.

Es wird eine kleine Reise werden. Ich werde über die grundsätzlichen Gedanken berichten, die ich mir gemacht habe, als auch etwas in technische Details gehen. Ebenso werde ich Dinge niederschreiben, die sich nicht bewährt haben, da dies evtl. für andere ebenfalls hilfreich erweisen sein.

Dieser Artikel wird länger ;-)

Vor einigen Wochen hatte ich das Problem, dass ich den DNS-Server eines RedHat-System ändern musste. Dabei bin ich über einige Fallstricke gestolpert, die ich hier kurz darstellen möchte. Ich habe wieder einiges gelernt und vielleicht hilft es ja auch jemand anderen.

Beim Arbeiten mit vielen docker-compose.yml Dateien habe ich öfter die Anforderung gehabt, einzelne Images neu zu pullen. In der Regel reicht ein docker compose pull, was aber heißt, dass er alle images zieht.

Es gibt jedoch bei mir durchaus öfters den Fall, dass ich dies nicht möchte. Zudem hatte ich einige Container, wo nur auf ein bestimmtes Versions-Tag (z.B. mysql:8) gepulled wird oder ich sogar mit latest arbeite. Dies bedeutete, dass ich mir jedes Image einzeln aus der docker-compose-datei rauspfriemeln musste. Damit ich im Wiederherstellungsfall das alte Image schneller wiederfinde, wollte ich das speziell taggen. In der Regel habe ich an den Namen des Tags ein _backup dran gehängt. Vorher musste das vorherige Image mit diesem Tag gelöscht werden. Diese manuelle Arbeit habe ich nun in ein Script gegossen.

Update 30.11.2023: siehe unten Changelog

Die letzten Tage habe ich etwas unter der Haube der Homepage geschraubt. Ich habe an Kleinigkeiten gearbeitet und ein paar Dinge im Hintergrund optimiert und verändert.

Was ich gemacht habe, bzw. was passiert ist:

Ich habe hier einige Backup-Scripte, die auch mal etwas länger laufen, wo ich eine Benachrichtigung haben wollte. Unter anderem muss nach einem Backup-Lauf die externe USB-Festplatte für mein Offsite-Backup wieder abgezogen werden.