backup.page 2.9 KB

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