Datenbanksicherheit, Kassensicherungsverordnung und lockport.online – Wochenrückblick KW 12/24

In der Woche vom 18. März 2024 durfte ich mit zwei neuen Projekten beginnen. Zum einen geht es um die Absicherung von Maria-DB-Servern und zum anderen um eine neue Aufgabe die mit der Kassensicherungsverordnung zu tun hat. Außerdem gibt es eine Neuerung bei lockport.online.

Zwei Datenbankserver zum mitnehmen … äh absichern, bitte!

In dieser Woche standen alle Zeichen auf Datensicherheit, denn meine Hauptaufgabe besteht aktuell darin, Maria-Datenbankserver eines Kunden abzusichern – und ja… die heißen wirklich so.

Datenbank absichern… was ist damit eigentlich gemeint?

Da ich diesen Rückblick auch für Nicht-Datenbank-Admins schreibe, hier eine kurze Erklärung: Online-Shops, Warenwirtschaftssysteme und selbst einfache Websites müssen irgendwo Daten speichern. Das tun sie häufig in einer Datenbank. So eine Datenbank kann man sich wie eine (große) Excel-Tabelle mit vielen Blättern oder Tabs vorstellen – nur dass eine Datenbank 1.000 oder 100.000 Mal mehr Daten verwalten kann, als eine Excel-Tabelle. Eine Excel-Tabelle erreicht bei ca. 1 Million Zeilen ihr absolutes Limit und läuft im roten Drehzahlbereich. Ein Datenbankserver schaltet da erstmal in den zweiten Gang und ist noch nicht mal auf Temperatur.

Wenn man eine Datenbank bzw. einen Datenbankserver absichert verfolgt man dabei zwei Ziele:

1. Datensicherheit
   Selbst wenn der Datenbankserver abstürzt und nicht wieder zu beleben ist, sollen die Daten trotzdem erhalten bleiben und nicht verloren gehen.
2. Verfügbarkeit
   Wenn der Datenbankserver abstürzt, sollte der Nutzer das am besten gar nicht bemerken, sondern nahtlos im System weiterarbeiten können.

Wie kann man eine solche sogenannte Hochverfügbarkeit aber erreichen? Durch Datensicherung und Replikation. Vereinfacht ausgedrückt, legt man regelmäßig (z. B. einmal täglich) eine Sicherungskopie der gesamten Datenbank an und speichert diese auf einem anderen Server ab. Warum auf einem anderen Server? Es könnte ja sein, dass der Datenbankserver komplett stirbt und kein Zugriff mehr möglich ist. Wenn die Sicherungskopie räumlich getrennt abgelegt wurde z. B. in einem anderen Rechenzentrum, bleibt sie in der Regel auch bei einem Crash des Datenbankservers erhalten.

Bei Datenbanken die jedoch täglich hunderte oder tausende Datenänderungen erhalten – wie z. B. bei Online-Shops – reicht ein tägliches Backup nicht aus. Wenn der Server eine halbe Stunde vor dem nächsten Backup abstürzt, hat man fast einen gesamten Tag Daten verloren! Das könnten zigtausende an Datensätzen sein. Um dies zu vermeiden setzt man zusätzlich auf Replikation.

Wenn zwei sich einig sind … Thema: Datenbankreplikation

Bei einer Datenbankreplikation sagt gewissermaßen ein Server zum andern: „Du machst mir ja alles nach!“ 🙂 Bei einer Replikation betreibt man nicht nur einen Datenbankserver, sondern mindestens zwei. Der zweite bleibt mit dem ersten in Verbindung und fragt ständig: „Hat sich was geändert?“, „Soll ich was machen?“, „Hast du neue Daten für mich?“, „Bitte, bitte, bitte …“ Wie so ein kleiner Hund, der bettelt … 😀 Sobald Server 1 eine Änderung an den Daten vornimmt, macht Server 2 das bei seinen Daten auch und damit sind die Daten im Idealfall nahezu zeitgleich mehrfach vorhanden (= synchron, ok, nicht ganz… es ist eher eine asynchrone Synchronisation, aber das würde hier zu weit führen). So kann im Fehlerfall einfach auf den anderen Server umgeschaltet werden, und die Party kann weitergehen.

Von der Theorie zur Praxis

Meine Aufgabe war es in den vergangenen Tagen, die Datenbankserver aufzusetzen (im Prinzip: die benötigten Programme zu installieren) und so zu konfigurieren, dass die regelmäßigen Datensicherungen automatisiert durchgeführt werden und Server 2 Server 1 repliziert.

Die regelmäßigen Datensicherungen (Backups) werden dabei über zeitgesteuerte Befehle (sogenannte Cron-Jobs) einmal täglich durchgeführt und mehrere Tage für einen schnellen Zugriff aufbewahrt. Um das Löschen der alten Backups kümmert sich dann das Linux-Tool logrotate. (Ich glaube, dazu schreibe ich mal ein deutschsprachiges Tutorial 🙂 ).

Da es im Fehlerfall schnell gehen muss, habe ich außerdem kleine Tools für die Kommandozeile geschrieben, die innerhalb von wenigen Minuten einen neuen Datenbank-Slave-Server aus einem bestehenden Backup hochziehen können. Für ein kleines Datenbankbackup in der Größenordnung von 2 Gigabyte dauert das gerade einmal 5 Minuten. Das ist noch kein Wert, den man in der Industrie als „Hochverfügbarkeit“ bezeichnet, aber es ist auf alle Fälle besser, als manuell eine Reihe von Befehlen einzutippen 🙂

Doch genug von Datenbanken …

Hello again, Kassensicherungsverordnung

In dieser Woche kam der Entwickler eines Kassensystems auf mich zu, da er personelle Unterstützung bei der Pflege der Finanzamtsschnittstelle (DSFinV-K) benötigt. Die DSFinV-K hängt eng mit der Kassensicherungsverordnung (KassenSichV) zusammen. Während es bei der Kassensicherungsverordnung unter anderem darum geht, dass alle Kassiervorgänge lückenlos aufgezeichnet und kryptographisch signiert werden müssen, damit sie nicht manipulierbar sind, geht es bei der DSFinV-K um die Darstellung der Kassiervorgänge und Stammdaten in einem standardisierten Datenformat.

Um mir erstmal einen Überblick über das Datenformat zu verschaffen, galt es 130 A4-Seiten DSFinV-K-Dokumentation durchzuarbeiten. Klingt auf den ersten Blick viel. Wenn man jedoch gewohnt ist, Datenformat-Beschreibungen und technischen Dokumentationen durchzuarbeiten, ist das gar nicht so schlimm 🙂 Zudem hatte ich mir über diese Dokumentation bereits vor einigen Monaten für ein anderes Projekt einen Überblick verschafft.

Meine Aufgabe wird sein, den Export sämtlicher Kassenvorgänge aus einer MySQL-Datenbank in das Format DSFinV-K umzusetzen. Ein sehr spannendes Projekt, auf das ich mich schon freue.

Wieviele Gepäckschließfachanlagen gibt es eigentlich in Deutschland?

Diese Frage kann ich leider auch nicht beantworten – aber ich weiß wo man welche findet: Seit einigen Monaten darf ich an dem Projekt lockport.online mitarbeiten. Lockport.online war ursprünglich nur als Buchungsportal für ein paar Fahrradboxen (oder Fahrradgaragen) in Chemnitz gedacht. Hinter lockport.online steht jedoch der Schließfachhersteller Locktec, dessen Schließfachanlagen und Fahrradgaragen weltweit an mehreren hundert Standorten stehen.

In der vergangenen Woche wurde nun damit begonnen, auch Gepäckschließfächer und Fahrradboxen von anderen Standorten auf der Website einzupflegen. Bis heute sind bereits 16 verschiedene Standorte in Deutschland auf der Karte zu sehen. Bei manchen ist eine Online-Reservierung möglich.

Aktuell arbeiten wir daran, den Anmelde- und Registrierungsprozess zu verbessern. Außerdem werden wir die Website etwas kommunikativer gestalten, damit sich die Nutzer besser zurecht finden. Anregungen sind stets willkommen.

Und in der nächsten Woche?

Die Themen Datenbankreplikation und DSFinV-K werden mich auch in der nächsten Woche begleiten.

Da das DSFinV-K-Format aus mehreren CSV-Dateien besteht, werde ich wohl ein kleines Tool schreiben, dass aus bestehenden CSV-Beispiel-Daten entsprechende Model-Klassen für Java erstellt. Warum? 1. Automatisiere ich gerne 🙂 und 2. hätte ich so ein Tool schon häufig brauchen können.