|
|
@@ -0,0 +1,56 @@
|
|
|
+---
|
|
|
+format: markdown
|
|
|
+categories: Netz-Infrastruktur, Backbone, Supernodes
|
|
|
+title: Serverbackup
|
|
|
+...
|
|
|
+
|
|
|
+Dies ist nur eine vorläufige Version
|
|
|
+
|
|
|
+# Was soll gesichert werden?
|
|
|
+
|
|
|
+In der FFDO-Infrastruktur gibt es ein paar Dienste die State erzeugen. Geht dieser verloren, gehen eventuell
|
|
|
+wertvolle Informationen verloren, die sich auf anderem Wege nicht rekonstruieren lassen. State wie der Inhalt
|
|
|
+unseres Wikis wird über ein verteiltes SCM gehalten und liegt daher bei den meisten Leuten, die das Wiki editieren
|
|
|
+in einem halbwegs aktuellen Stand vor. Allerdings lässt sich dies nicht für alle Datenbestände so realisieren.
|
|
|
+Das Wiki z.B. hat eine eigene Nutzerverwaltung, die nicht im git liegt. Diese muss gesichert werden, da sonst nach
|
|
|
+einem Ausfall des Wiki-Servers Web-Benutzer sich nicht mehr einloggen können.
|
|
|
+
|
|
|
+Aktuell sichern wir den folgenden State:
|
|
|
+
|
|
|
+* Gogs (git server)
|
|
|
+ * SQLite Datenbank mit Nutzern etc.
|
|
|
+ * Repository-Verzeichnis mit den Repositories und evtl. erzeugten git hooks
|
|
|
+
|
|
|
+* gitit (Wiki)
|
|
|
+ * Benutzerdatenbank in Form einer Datei
|
|
|
+
|
|
|
+# Wie soll gesichert werden?
|
|
|
+
|
|
|
+Aktuell wird der Einsatz von [restic](https://restic.github.io/) evaluiert. Die Vorteile sind, dass es ohne
|
|
|
+Abhängigkeiten installierbar ist und bisher schnell und einfach funktioniert.
|
|
|
+
|
|
|
+# Wohin soll gesichert werden?
|
|
|
+
|
|
|
+Der Ort wo wir gesicherte Daten ablegen sollte zum einen eine gewissen minimale Verfügbarkeit aufweisen und zum anderen
|
|
|
+nicht auf den Server laufen, die wir sichern wollen.
|
|
|
+
|
|
|
+Aus diesem Grund soll der Speicher zur Sicherung der Daten von Freiwilligen außerhalb der Freifunk-Infrastruktur
|
|
|
+bewerkstelligt werden. Die Software die diesen Speicher bereitstellt soll Ausfälle einzelner Instanzen bis zu einem
|
|
|
+gewissen Grad tolerieren können und möglichst lange zumindest lesenden Zugriff bereitstellen können. Aktuell
|
|
|
+wird daher [minio](https://minio.io) getestet. minio stellt einen Dataobject-Store bereit, der API-kompatible
|
|
|
+zu Amazon S3 ist und daher eine breite Toolingunterstützung hat.
|
|
|
+
|
|
|
+# Wie stelle ich eine minio-Instanz für Freifunk bereit?
|
|
|
+
|
|
|
+minio hat den Nachteil, dass bei einem verteilten betrieb im vornherein alle Instanzen bekannt sein müssen. Um sinnvoll
|
|
|
+zur Backupinfrastruktur von Freifunk beitragen zu können sollten folgende Punkte beachtet werden.
|
|
|
+
|
|
|
+* minio sollte per HTTPS auf dem Standardport für HTTPS (443) erreichbar sein
|
|
|
+* Das verwendete Zertifikat sollte von gängigen Betriebssystemen, Browsern etc. akzeptiert. Daher am besten von Let's
|
|
|
+ Encrypt o.ä. signiert sein und nicht selbstsigniert.
|
|
|
+* Die minio-Instanz sollte idealerweise an einem Breitbandigen Anschluss (d.h. in der Regel nicht zu Hause) gehostet
|
|
|
+ werden.
|
|
|
+* Die minio-Instanz sollte in der Regel verfügbar sein.
|
|
|
+
|
|
|
+Der Betrieb einer minio-Instanz kann also vorbereitet werden, muss dann aber mit Infrastruktur-Team abgesprochen
|
|
|
+werden, da Access Key und Secret Access Key ebenso wie die Liste der verbundenen Instanzen gleich sein müssen.
|
