wiki/Technik/Netzinfrastruktur/Supernodes/backup.page

---
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. 

Aktuell benötigen wir mindestens 4 Instanzen die außerhalb der Freifunk-Infrastruktur laufen.

# Aktuelle minio-Instanz-Betreiber

| Name des Betreibers | URL der Instanz |
|---------------------|-----------------|
| Till | https://minio.akuz.de |