Differences

This shows you the differences between two versions of the page.

--- backup-konzept [22.10.2017 16:58] – 192.168.77.1
+++ backup-konzept [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-====== 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.)
-===== Risiken =====
-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)
-==== Benutzerfehler ====
-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.
-==== Total-Ausfall des Server ====
-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.
-==== Standort-Ausfall ====
-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 Backup-Server die Arbeit wiederaufgenommen werden. Der Datenverlust beträgt dabei
-  - die papiergebundenen Daten
-  - alle seit der letzten Sicherung - also am letzten Tag - erfassten elektronischen Daten
-===== Backup-Scripts =====
-==== Prozessübersicht ====
-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 [[#Speicherung der Datenbanken in Zip-Dateien|Datenbanken des Produktionsservers in Zip-Dateien gespeichert]] (Produktionsserver)
-  * Di-Sa um 02:40 Uhr (Backupserver, im Script all_backup_jobs.sh):
-    - die [[#Vergleich der Benutzerkonfigurationen|Benutzer- und Gruppenkonfigurationen verglichen]]
-    - die [[#Spiegelung der Dateien|Dateien gespiegelt]]
-    - die [[#Rechte korrekt setzen|Rechte korrekt gesetzt]]
-    - die [[#Datenbank-Dump auf Backup-Server einspielen|Zip-Datei der Datenbanken auf dem Backup-Server eingelesen]]
-  * täglich um 05:10 [[#Rechte korrekt setzen|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
-<code>
-[ $err == 0 ] && shutdown -p now
-</code>
-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.
-==== Ort der Scripte, Konfiguration etc ====
-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
-==== Speicherung der Datenbanken in Zip-Dateien ====
-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.
-==== Vergleich der Benutzerkonfigurationen ====
-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.
-==== Spiegelung der Dateien ====
-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 [[wie_wurde_der_synology_server_aufgesetzt|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 [[ssh_via_zertifikat|siehe hier]].
-Wird das Script versehentlich auf dem Produktionsserver ausgeführt, bricht es ab mit Fehlermeldung.
-==== Rechte korrekt setzen ====
-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.
-==== Datenbank-Dump auf Backup-Server einspielen ====
-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.
-===== Umschaltung auf den Backup-Server =====
-Für die Umschaltung der Server gibt es die [[Checkliste Umschaltung Produktionsserver]]. Dazu wird eine Person mit technischer Erfahrung benötigt.

Tools

menus and quick search

quick search

site status

Page Tools

meta data for this page

Differences