Backup-Konzept

Das Backup-Konzept dient der Sicherheit der Daten und der Gewährleistung einer kontinuierlichen Leistungserbringung, auch wenn ein grösserer Schadenfall eingetreten ist. Das Backup-Konzept beschreibt nicht den Schutz der Daten (Verhinderung von unerlaubtem Zugriff, Verbreitung etc.)

Folgende Risiken versuchen wir primär zu begegnen:

• Benutzerfehler (Benutzer löscht oder überschreibt eine wichtige Datei oder eine Information in der Datenbank)
• Total-Ausfall des Servers durch Fehlschaltung / Blitzschlag / Fremdeinwirkung
• Ausfall des gesamten Standorts (durch Brand, Terror, höhere Gewalt)

Auf dem Server läuft während der Arbeitszeit stündlich ein Script, welches den gesamten Dateibestand mit einem Spiegel vergleicht und die in der Zwischenzeit veränderten Daten in eine History-Struktur wegspeichert. Möchte man eine ältere Version einer Datei zurückholen, startet man die Filestation (https://server06:7246/, Administrator-Rechte erforderlich). Nun kann man in der Dateisuche oben rechts nach der Datei suchen lassen und es werden sämtliche verfügbaren Versionen angezeigt. Mit einem Klick lässt sich die Datei einfach herunterladen.

Eingaben in der Datenbank KSDB werden grundsätzlich vollautomatisch aufgezeichnet. Jede Tabelle hat eine History-Tabelle mit gleichem Namen und der Endung $hi. Darin wird nach jeder Aktualisierung der Datenstand vor Aktualisierung abgelegt und auf dem gültigen Datensatz wird das Modifikationsdatum und der Anmeldeuser in den Feldern sys_update_user und sys_update_time abgelegt. Wird ein Datensatz gelöscht, wird er in die $hi-Tabelle geschoben und die sys_delete_user / sys_delete_time Felder werden abgefüllt.

An vielen Orten ist in der Applikation hinter der Taste F4 eine Anzeigefunktion hinterlegt, welche alle Versionen des Datensatzes anzeigt.

Obwohl der Server mit 5 Harddisks bestückt ist und noch zu 100% funktioniert, wenn 2 Harddisks gleichzeitig ausfallen, kann der Server komplett ausfallen. Beispiele dafür sind Blitzschlag (in diesem Fall könnte noch einer der anderen Netzwerk-Anschlüsse ausprobiert werden - häufig wird bei Induktions-Überspannungen nur der Netzwerkanschluss verschmort). Nimmt aber jemand eine Axt in die Hand und schlägt alle 5 Disks kaputt, läuft der Server nicht mehr und die Daten sind nicht mehr zu retten.

Für diesen Fall läuft im Datencenter der plan-bee.ch ag in Zürich ein baugleicher Server (server08, 192.168.22.22), der sofort als neuer Produktionsserver eingesetzt werden kann. Scripts sorgen dafür, dass der Backup-Server einsatzbereit bleibt.

Seit 2018 ist der Standort des Servers nicht mehr mit dem Standort der Firma identisch. Er steht in einem Datencenter im Kanton Zug und ist über eine VPN-Leitung mit dem Standort Bahnhofstrasse 11 permanent verbunden.

Daher sind zwei Ausfall-Arten zu betrachten:

Ist der gesamte Standort nicht mehr verfügbar (infolge Brand, Hochwasser, Sperrung infolge Terrorgefahr, höhere Gewalt…), so kann an einem Ersatzstandort direkt mit dem Produktiv-Server die Arbeit wiederaufgenommen werden. Der Datenverlust beträgt dabei nur die papiergebundenen Daten.

Ist das Datencenter nicht mehr verfügbar (infolge Brand, …), so wird mit dem Backup-Server in Zürich weitergearbeitet. Die Umschaltung erfolgt manuell. Der Datenverlust beträgt dabei die Daten seit dem letzten erfolgreichen Backup-Vorgang, also in der Regel nicht mehr als ein Tag.

Die Backup-Scripts müssen dafür sorgen, dass der Backup-Server jederzeit mit wenigen Handgriffen zum Hauptserver umgewandelt werden kann. Es werden

• täglich um 23:00 Uhr die Datenbanken des Produktionsservers in Zip-Dateien gespeichert (Produktionsserver)
• Di-Sa um 02:40 Uhr (Backupserver, im Script all_backup_jobs.sh):
  1. die Benutzer- und Gruppenkonfigurationen verglichen
  2. die Dateien gespiegelt
  3. die Rechte korrekt gesetzt
  4. die Zip-Datei der Datenbanken auf dem Backup-Server eingelesen
• täglich um 05:10 Rechte korrekt gesetzt (Produktivserver)

Die Prozesse werden auf den Servern zeitgesteuert über die Aufgabenplanung ausgeführt und sind so ausgelegt, dass sie im Fehlerfall eine E-Mail an operating@plan-bee.ch senden. Bei ordnungsgemässer Durchführung melden sie nichts, sodass die Fehlermails sofort auffallen.

Die Prozesse sind so gestaltet, dass der Backup-Server tagsüber heruntergefahren werden kann, wenn dies gewünscht wird. Hierzu wird am Ende des Scripts, welches die Datenbank um 05:15 lädt, der Befehl shutdown -p now angefügt, am besten in der Form

[ $err == 0 ] && shutdown -p now

dann bleibt der Server am Laufen, wenn ein Fehler aufgetreten ist und man sowieso nachschauen muss, was los ist.

Der wichtigste Prozess, die Dateispiegelung, erzeugt zudem auf einem externen Webserver eine neue Flag-Datei, die mit ihrem Erstellungsdatum angibt, wann der Prozess zuletzt erfolgreich beendet wurde. Ein Timer überwacht dort, ob diese Flag-Datei zu alt ist, und alarmiert walter@vandergeest.ch direkt. Diese Überwachung nutzt bewusst andere Infrastruktur.

Die Scripts sind auf der Freigabe backupsystem gespeichert, im Unterverzeichnis /scripts. In /config finden sich Konfigurationsinformationen, namentlich

• serverconfig.sh: Ein script, welches die Servernamen von Produktions- und Backupserver enthält
• my_dump.cnf: Die Anmeldedaten für den Backup-Prozess an die Datenbank
• ksco_excluded.txt: Datei, die die Dateimuster enthält, welche von der Datei-Spiegelung ausgeschlossen werden

Es ist wichtig, dass die Scripts und Konfigurationen auf dem gleichen Stand gehalten werden!

/mysql enthält die Zip-Dateien der Datenbank-Speicherung

/history enthält die Vor-Versionen der Datei-Spiegelung und sorgt damit für eine Versionsgeschichte

Das Script dump_databases.sh meldet sich mit den Anmeldedaten der Datei my_dump.cnf an und liest alle Datenbanken aus. Die System-Datenbanken information_schema und performance_schema werden ausgeschlossen, alle anderen Datenbanken werden mittels mysqldump in SQL-Befehle gewandelt und in eine Zip-Datei gespeichert. Dies sind gegenwärtig

• servername_ksdb_tag.zip: Enthält die KSCO-Datenbank
• servername_mysql_tag.zip: Enthält die MYSQL-Benutzertabelle und die Berechtigungen

servername wird durch den Servernamen ersetzt. tag wird entweder durch den Tag des Monats oder am Monatsende durch das volle Monatsdatum ersetzt. Dadurch entsteht eine Historie der letzten 30 Tagesbackups sowie aller Monatsenden.

Die Zip-Dateien werden im Verzeichnis backupsystem/mysql abgelegt. Wird das Script versehentlich auf dem Backup-Server ausgeführt, endet es sofort mit Fehler. Er erkennt dies anhand der serverconfig.sh-Datei.

Da wir in 2017 einen Server-Ausfall erlebt haben, haben wir bemerkt, dass die Benutzerberechtigungen etwas umständlich sind, um sie im Ernstfall von Hand zu erfassen. Wir haben uns daher entschlossen, diese auf beiden Servern auf dem gleichen Stand zu halten.

Zu diesem Zweck führen wir das Vergleichs-Script compare_config.sh aus, welches prüft, ob

• die Gruppen
• die Benutzer
• die Gruppen-Zugehörigkeiten
• die gid und uid

auf beiden Servern gleich konfiguriert sind. Wenn nicht, meldet er dies durch Fehlercode –> E-Mail an operating@plan-bee.ch. Sollte also ein neuer Benutzer eröffnet worden sein, so taucht dies spätestens in der Folgenacht auf und kann umgehend korrigiert werden.

Das Script backup_ksco.sh sorgt mittels rsync dafür, dass die Dateien vom Produktionsserver auf den Backupserver gespiegelt werden. Gelöschte und geänderte Dateien werden, bevor sie überschrieben werden, in das Verzeichnis /history/yyyy-mm-dd/freigabe/pfad weggesichert, sodass eine Versionsgeschichte entsteht.

Die ksco_excluded.txt Datei enthält Dateimuster, die nicht gesichert werden. Das umfasst gegenwärtig

• die @eaDir-Verzeichnisse das Indexservers
• die #recycle-Verzeichnisse (Papierkorb)
• die Thumbs.db Dateien mit den Vorschaubildern

Der Zugriff auf den Produktionsserver erfolgt über ssh und rsync. Deshalb muss in der Systemsteuerung unter Dateidienste der Dienst rsync aktiviert werden, siehe Einrichten der Synology DS Stationen.

Die beiden Server kommunizieren direkt über die IP-Adresse durch den VPN-Tunnel und mit zertifikatsbasierter Authentifizierung. Diese muss eingerichtet werden siehe hier.

Wird das Script versehentlich auf dem Produktionsserver ausgeführt, bricht es ab mit Fehlermeldung.

Aufgrund unserer Grundsätze der Rechte-Vergabe führen wir das Script, welche alle Rechte enthält, täglich auf beiden Servern aus, um sicherzustellen, dass unsere Rechte auch durchgesetzt werden.

Die Rechte sind im Script reset_all_acl.sh fest eingepflegt und können nur durch den Administrator geändert werden.

Das Script restore_databases.sh erlaubt es, einen bestimmten Datenstand zurückzuspielen. Das Script restore_last_databases.sh sucht zuerst den neuesten Stand und liest es dann ein.

Das Script löscht die Datenbank, legt sie neu an und liest sie anschliessend aus der ZIP-Datei ein. Das Script verwendet den in my_load.cnf angegebenen Benutzernamen und Passwort für die Anmeldung an mysql.

Wird das Script versehentlich auf dem Produktionsserver ausgeführt, bricht es ab mit Fehlermeldung.

Für die Umschaltung der Server gibt es die Checkliste Umschaltung Produktionsserver. Dazu wird eine Person mit technischer Erfahrung benötigt.