Howto georedundantes Backup

Nachdem vom Homeserver die ersten SMART-Warnungen kamen, war es an der Zeit, über eine neue Backup-Lösung nachzudenken. Nachdem wir als Firma 2020 lernen durften, dass ein Raid kein Backup ist, sollte die Wahl dieses Mal auf ein echtes Backup fallen. Und da der Trend natürlich zum Zweitstandort geht, war klar, dass eine echte Georedundanz dabei nicht fehlen durfte. Denn was bringen mir schließlich zwei Homeserver mehr als einer? Maximal, dass die Panzerknacker mehr zu tragen haben, wenn sie mir die Bude ausräumen möchten.

Als Standort für einen zweiten Knoten schien mir das Haus meiner Eltern ganz brauchbar – ein paar Terabyte Nutzlast sicherten dann auch die Bereitschaft zu, selbigen zu finanzieren, also war als zweites Ziel jedoch geboren, die goldenen Platten im Laden zu lassen und eine Lösung zu finden, die auch noch halbwegs erschwinglich sein sollte. Um den Panzerknackern dann ob des geringen Warenwerts den Coup zusätzlich zu vermiesen, sollte zudem eine Vollverschlüsselung mitgedacht sein.

Nach einiger Überlegung ergaben sich damit die folgenden Anforderungen an das Backup-System:

  • georedundante Speicherung
  • relativ erschwingliche Kosten
  • Möglichkeit zur Nutzung herkömmlicher DSL-Leitungen
  • Vollverschlüsselung der Daten
  • verschlüsselte Datenübertragung
  • Trennung der Nutzerdaten für mehrere Nutzer
  • ausschließliche Nutzung von Open Source
  • keine Einbindung von Drittanbieterdiensten
  • Datentransfer für Nutzer via SFTP
  • lokaler Datenzugriff, volles Backup
  • Im Fehlerfall einfache Wiederherstellung der Dienste
  • 10TB Nutzlast + Möglichkeit zur Erweiterung
  • geringer Stromverbrauch
  • Möglichkeit zur Erweiterung durch weitere Standorte
  • Unterstützung von Gruppenordnern

Plattform

Um die Kosten und den Stromverbrauch gering zu halten, fiel die Wahl auf je einen Raspberry Pi 4B mit 8GB RAM pro Standort. Als Datenspeicher wurde je eine WD Red 10TB gewählt. Um die Wärmeentwicklung bestmöglich abführen zu können, wurde statt eines herkömmlichen Gehäuses ein Festplattendock mit USB 3.0-Anschluss gewählt. Das wiederum würde die Möglichkeit bieten, bei Bedarf auch gleich eine zweite 10TB-Platte beherbergen zu können.

Systemstruktur

Da über die Raspberry-Lösung der Nutzspeicher nur als externes Medium zur Verfügung stand, fiel die Wahl darauf, das System auf die interne MicroSD-Karte zu schreiben und nicht zu verschlüsseln. Die externe Festplatte wurde mittels LUKS verschlüsselt. Das Setup hat somit zum Vorteil, dass der Raspberry Pi selbstständig durchbooten kann und im Falle eines Defekts eine MicroSD-Karte einfach per Post verschickt werden kann. Im Fall eines Diebstahls kann zwar auf das System, jedoch nicht auf die Nutzlast der externen Festplatte zugegriffen werden. Da die Platte nicht mit einem System bespielt werden muss, kann sie im Fehlerfall lokal neu beschafft werden. Als wesentliche Nachteile sind der eher geringe Datendurchsatz von Raspberry Pi zur Festplatte und die Möglichkeit zur unentdeckten Kompromittierung des Systems auf dem Raspberry Pi zu sehen: Wer unbemerkt Zugriff hat, könnte Zusatzsoftware installieren, über die ein Mitschneiden der LUKS-Keyeingabe oder ein Kopieren der Daten von der entschlüsselten Festplatte ermöglicht. Auch war zu Projektbeginn unklar, ob der Raspberry Pi dem Umfang an Datentransfer und -verschlüsselung gerecht wird, diese Sorge stellte sich jedoch als unbegründet heraus.

Für die Verwaltung von Nutzern und Gruppen (für geteilte Ordner) sollte die Linux-Benutzerverwaltung zum Einsatz kommen, um die bewährte systemseitige Sicherheit zu haben und keinen unnötigen Overhead zu betreiben.

Software

Die Vernetzung beider Knoten sollte möglichst leichtgewichtig sein und wenig Overhead generieren. Außerdem sollte das System autark abseits der bereits bestehenden OpenVPN-Infrastrukturen funktionieren, um einerseits die Anzahl der involvierten Systeme klein zu halten und andererseits den Angriffsvektor auf mein Netzwerk zu minimieren. Daher fiel die Wahl auf Wireguard – die Konfiguration ist denkbar einfach:

# NODE 1
[Interface]
Address = 10.0.0.1/32
PrivateKey = H34dsf36LKgmrigFDttezt345/wfds=
ListenPort = 51820

[Peer]
PublicKey = MIOijs894ejk23Kmk43dtMFGr34)JIf=
AllowedIPs = 10.0.0.2/32


# NODE 2
[Interface]
Address = 10.0.0.1/32
PrivateKey = Hrewg5(4ffdsvh5JKHUr43rfdsbg0=

[Peer]
PublicKey = WDS334fvGbdft54/(4tfdsdsq34RFD=
AllowedIPs = 10.0.0.0/24
EndPoint = public-domain-of-node1.de:51820
PersistentKeepalive = 25 

Mittels wg genkey lässt sich dabei ein passendes Schlüsselpaar generieren, das auf die jeweiligen Configs zu verteilen ist und wg-quick up wg0 startet die Verbindung – fertig. Wichtig ist dabei nur, nicht zu glauben, AllowedIPs würde eine Liste an IPs führen, denen ein Verbindungsaufbau erlaubt ist. Stattdessen verbirgt sich hinter der Direktive nämlich die zu routenden Subnetze des Peers – wer hier 0.0.0.0 einträgt, kann sich damit also sehr gut selbst ausschließen (für Sie getestet!)

Bei der Art der Synchronisierung habe ich lange über verteilte Dateisysteme nachgedacht, was mir aufgrund der hohen Netzwerklatenz letztendlich jedoch zu unstabil erschien. Stattdessen sollte Syncthing zum Einsatz kommen – hier stellte sich jedoch leider heraus, dass Syncthing keinen Mehrbenutzermodus anbietet, stattdessen können nur Dateien des Users synchronisiert werden, unter dem der Dienst läuft. Neue Dateien werden dann auch grundsätzlich mit UID und GID dieses Nutzers geschrieben, was den Einsatz als root unmöglich macht (von dem ohnehin abgeraten wird). Dokumentierte Abhilfe ist, für jeden Nutzer eine Syncthing-Instanz laufen zu lassen, was mir jedoch recht aufwendig erschien und zudem auch noch für jeden gemeinsamen Ordner eine weitere Instanz bedurft hätte.

Stattdessen ist die Wahl final auf Unison gefallen – auch die recht schmucke Website im Retrodesign konnte mich nicht davon abhalten. Somit konnte ich den Wunsch, die Linux-Benutzerverwaltung auch zur Verwaltung und Trennung der einzelnen Benutzerordner zu nutzen (und nicht noch einen separaten FTP-Server o.ä. mit eigener Benutzerverwaltung on top zu verwenden). Die Konfiguration von Unison gestaltet sich dabei ähnlich einfach wie die von Wireguard:

root = /mnt/usb0/sync
root = ssh://user@10.0.0.2//mnt/usb0/sync
batch = true
auto = true
servercmd = sudo unison
group = true
owner = true
times = true
confirmbigdeletes = true
fastcheck = true
silent = true
prefer = newer
xferbycopying = false

Mittels der beiden root-Direktiven werden dabei die zu synchronisierenden Verzeichnisse angegeben. Die flags group, owner und times sorgen dafür, dass UIDs, GIDs und Erstellungszeiten mit synchronisiert werden, als kleiner Bonus sorgt confirmbigdeletes dafür, dass eine Synchronisierung nicht durchgeführt wird, wenn einer der beiden root-Ordner leer ist – praktisch für den Fall, dass nach einem Stromausfall zwar der Raspberry Pi neu bootet, die LUKS-Partition jedoch noch nicht wieder entschlüsselt wurde, der Mountpoint somit leer ist und eine Synchronisierung somit wunderbar die MicroSD-Karte vollschreiben würde!

Zu guter Letzt letzt wurde Zabbix verwendet, um den Zustand der Knoten zu überwachen und einen Ausfall mitzubekommen. Ein kleines eigenes Template ermöglicht zudem einen minimalen Einblick in den Zustand der Synchronisierung:

UserParameter=backup.filecount_local,df -i /dev/mapper/usb0 | grep mapper | awk '{split($0,a); print a[3]}'
UserParameter=backup.lastrun,stat -c %Y /var/log/unison.log
UserParameter=backup.laststate,cat /var/log/unison.log

Ursprünglich kam hier find zum Zählen der Dateien auf beiden Knoten zum Einsatz, allerdings kam das mit steigender Dateianzahl schnell an seine Grenzen, weshalb das Zählen der verwendeten Inodes über df eine deutlich bessere Alternative darstellte. Als kleines Gimmick lassen sich die Informationen aus Zabbix natürlich auch entsprechend in Grafana auswerten:

Synchronisierungs-Dashboard in Grafana

Zur kompletten Einrichtung der Knoten wurde Ansible gewählt – sowohl zur Grundeinrichtung des Systems, zur Verwaltung der Benutzer und Gruppenordnern, als auch zum Mounten und Unmounten der USB-Platten, um zu vermeiden, dass die LUKS-Keys auf den jeweiligen Raspberrys hinterlegt werden müssten.

Fazit

Die Einrichtung der Systeme gelang insbesondere durch die sehr einfache Konfiguration von Wireguard und Unison sehr einfach – die Nutzung von Ansible tat ihr übriges.

Ein erster Stresstest mit mittlerweile fast 2 Mio. Dateien und knapp 2TB Daten klappt erstaunlich gut, selbst über wackelige belgische DSL-Leitungen mit gelegentlichen Abbrüchen. Es macht geradezu Spaß, Unison beim Synchronisieren zuzuschauen – auch die Menge der Dateien hat bislang keinen erkennbaren Einfluss auf die Belastung der Systeme. Es bleibt abzuwarten, wie sich der Langzeittest entwickelt, bis dato kann ich die Lösung aber durchaus als stabil weiterempfehlen!

Wenn Weihnachten ist…

„Und es geschah also, dass zu jener Zeit des Jahres alle Töchter und Söhne an die Stätten ihrer Geburt zurückkehrten, damit sie die IT-Probleme ihrer Eltern richteten.“

Lukas 2,1-3

Auch vor der IT-Beratung macht Weihnachten nicht halt, daher ergeben sich jedes Jahr aufs Neue schöne Muster in den Serverstatistiken:

LDAP-Zugriffe zwischen 10.12.2021 und 01.01.2021

Hier in blau zu sehen die Zugriffe auf das LDAP, das zentrale Verzeichnis aller Nutzerdaten bzw. Passwörter. Schön erkennbar, wie ab dem 22.12. die Zugriffe massiv sinken, da für viele zwei Tage vor Weihnachten die Urlaubszeit losging.

Wenn dann die IT-Probleme gelöst sind und der Weihnachtsbraten vertilgt ist, beginnt das schwarze Loch zwischen Weihnachten und Neujahr, von dem keiner so genau weiß, was in der Zeit eigentlich passiert. Auch dieses mehrtägige Food-Coma lässt sich in den Daten recht gut erkennen:

Proxy-Zugriffe auf frachtwerk.de zwischen 29.11.2021 und 11.01.2022

Dargestellt sind hier alle ein- und ausgehenden Verbindungen unseres zentralen Proxies, der alle IT-Systeme unserer Kunden und unsere öffentlich erreichbaren Tools zugänglich macht. Deutlich zu sehen sind die einzelnen Kalenderwochen mit jeweils fünf Peaks von Montag bis Freitag und den dazwischenliegenden Wochenenden. Ebenfalls gut erkennbar die abflauende Woche vor Weihnachten und quasi keine erkennbaren Peaks ab dem 23.12. mehr. Insbesondere die Woche nach Weihnachten ab dem 27.12. lässt kaum mehr als das übliche Grundrauschen erkennen. Erst ab dem 03.01. kehrt die Welt unserer Kunden und Kolleg:innen zur Normalität zurück – wenngleich auch nicht auf Dezember-Niveau.

Von wegen Dezember-Niveau:

Proxy-Zugriffe auf frachtwerk.de zwischen 11.01.2021 und 11.01.2022

Wirft man einen Blick auf den gesamten Jahresverlauf zeigt sich, was jeder Berater ohnehin weiß: Gegen Jahresende wird’s stressig! Für die Steigerung zum Jahresende dürften allerdings einige Faktoren verantwortlich sein: Die klassische Jahresend-Ralley, aber auch die Einstellung neuer Kolleg:innen und/oder der Launch neuer Systeme und Tools.

In diesem Sinne ein frohes neues Jahr! 🙂

Wann brauche ich eigentlich einen AV-Vertrag?

Herzlich Willkommen zu einer neuen Folge aus dem DSGVO-Urwald! Heute möchten wir uns der Frage widmen, wann genau man eigentlich einen dieser ominösen AV-Verträge abschließen muss. AV-Verträge (“Auftragsverarbeitungsvertrag”) sind ein bisschen wie böse Herbidize: Keiner kann sie leiden, viele müssen sie trotzdem nutzen und wer sie falsch verwendet, bekommt Ausschlag und eine Menge Ärger. Keiner weiß, was sie in der Praxis wirklich bringen und man verwendet lieber ein bisschen zu viel als zu wenig – nicht, dass am Schluss der Landesdatenschutzbeauftragte auf der Matte steht und lässig im Bußgeldkatalog blättert!

Keep Reading

Schienengebundene innerstädtische Logistik!

In vielen Berliner Bahnhöfen (z.B. Schönhauser Allee, Jannowitzbrücke, …) zeugen große Bilder von der Zeit der goldenen Zwanziger. Neben vielen spannenden Dingen, die es dort zu entdecken gibt, während man auf die immerpünktliche Bahn wartet, fasziniert insbesondere, dass im Vergleich zu Heute das Stadtbild nicht in allen Aspekten von Autos dominiert war! Aber wie kämen wir heute ohne Autos, Transporter, LKW, Taxis und Busse aus? Eine häufig übersehene mögliche Lösung wäre eine effektivere Nutzung der – zumindest in Berlin – überall vorhandenen Schieneninfrastruktur. Aber wie soll das genau gehen?

Keep Reading

DSGVO-Kuriositätenkabinett Teil 2

Weil die Erinnerung an die letzte Kuriosität ja schon langsam verblasst, gibt’s heute mal wieder ein wunderschönes Gewächs aus dem Garten des großen weiten WWW. Wie so üblich, kommt auch diese Schlingpflanze anfangs wieder ganz unscheinbar daher…

Keep Reading

Brand bei OVH – eine kleine Analyse

Hinweis: Der Vorfall bei OVH in Strasbourg ist noch keine Woche alt. In diesem Beitrag haben wir uns große Mühe gegeben, zwischen Fakten, Vermutungen und unserer eigenen Meinung zu unterscheiden. Noch immer gibt es viele Unklarheiten, insbesondere auch zur Brandursache. Wir haben sämtliche Informationen, soweit wie möglich, mit Belegen versehen, sodass eine eigene Meinungsbildung möglich ist.

Tobi & Fiete

In der Nacht vom 10. März 2021 brach im OVH-Rechenzentrum SGB2 in Strasbourg ein Feuer aus. Man würde erwarten, dass das in Rechenzentren mit ihren ausgeklügelten Brandmelde- und Bekämpfungsanlagen nichts Dramatisches sein sollte: häufig werden beispielsweise feuerbeständige Materialien mit einer Brandfrüherkennung und einer Gaslöschanlage kombiniert, welche innerhalb kürzester Zeit die Raumluft mit einem nicht-brennbaren Gasgemisch ersetzt. In diesem Fall fraß sich der Brand jedoch rasch durch alle Stockwerke und vernichtete das komplette Gebäude. Über 10.000 Server in SGB2 und SGB1 wurden Raub der Flammen, außerdem mussten die Gebäude SBG3 und SBG4 aufgrund der Löscharbeiten stillgelegt werden. OVH als günstiger Anbieter für dedizierte Server und Cloud-Produkte wird gerne von Resellern aller Art als Infrastrukturanbieter genutzt, die wiederum Dienstleistungen an Privatpersonen, kleinere Betriebe und Agenturen anbieten. Viele davon dürften bisher selten bis nie Backups gemacht haben, wodurch der Brand umso verheerendere Auswirkungen haben dürfte. Insgesamt sollen durch den Vorfall 3,6 Millionen Websites auf mehr als 460.000 Domains betroffen sein.

Keep Reading

DSGVO-Kuriositätenkabinett Teil 1

Es gibt ja so Tage, da ist man sich der eigenen Wahrnehmung nicht mehr so ganz sicher. So ein Tag war neulich, als ich nichtsahnend ein paar Zutaten googelte und mich wenig später auf einer Website mit einem Cookie-Banner konfrontiert war. Nichtsahnend, dass ich es hier mit meinem persönlichen Endgegner zu tun haben sollte, wählte ich als guter Datenschützer natürlich den Punkt „Einstellungen“…

Keep Reading

Was muss eigentlich in eine Datenschutzerklärung?

Im finsteren Mittelalter konnte man mit dem Aberglauben der Menschen als böser Mensch tolle Dinge tun: Amulette verkaufen, Ablassbriefe schreiben und hin und wieder mal einen Dämon austreiben. Dämonen haben es bis in die heutige Serverwelt geschafft und wenn man sich die Datenschutzerklärungen mancher Websites anschaut, ist der Aberglaube der Menschheit maximal digital aber mitnichten weniger geworden… Aber was muss denn nun wirklich in eine Datenschutzerklärung?

Keep Reading

WordPress von seiner besten Seite

Eine Monitoring-Meldung machte uns letzte Woche auf unseren externen Hosting-Server aufmerksam, dem so langsam die Swap-Partition voll lief. Ungewöhnlich für ein System, das eigentlich kaum Last generieren sollte…

Beim genaueren Hinschauen zeigte sich, dass der MySQL fast den kompletten RAM belegte. Also kurz in die Serverüberwachung von PhpMyAdmin geschaut mit einem ungewöhnlichen Ergebnis…

Keep Reading

Was das Ende des Privacy Shields für Unternehmen bedeutet

Kaum ein Thema beherrscht die digitale Rechtswelt so sehr, wie die DSGVO. Für Endanwender zeigt sich das insbesondere durch eine unendliche Flut an Cookie-Boxen, zumeist mit schönen großen, grünen Buttons, um alle Cookies zu akzeptieren und einen alternativen, verwundenen Pfad durch die Untiefen vieler Tabs, um auch ohne diese Wahl leben zu können.
Doch die wirkliche Macht der DSGVO zeigt sich momentan an ganz anderer Stelle: Durch den Datenschutz wird mal wieder deutlich, dass sich das Internet selten an die Grenzen von Staaten und Staatenbündnissen halten möchte. Und so ist es nicht verwunderlich, dass sich Anwender in Europa an einer Vielzahl schöner, digitaler Dienste aus den USA erfreut. Für viele Privatanwender, aber auch für viele Firmen ist eine Welt ohne Google, Microsoft, Apple & Co. gar nicht mehr vorstellbar.

Aber was bedeutet das für den Datenschutz?

Keep Reading