Datensicherung

Notfall Plan für die Wiederherstellung
Ausfallserver für den firebird Dienst

Datensicherung - Ein Überblick

Es wird der sehr stabile firebird SQL-Server verwendet. Dennoch sind Kopien der Datenbank und der Arbeitsverzeichnisse notwendig da die Speicherungstechnik jederzeit versagen kann. Der Datenverlust kann begrenzt werden, indem man auf Sicherungskopieen (Datensicherung) zurückgreifen kann.
Die mehrphasige Sicherung hat das Ziel ausgehend von dem letztendlich entstehenden Sicherungs-Zip die komplette OrgaMon-Umgebung neu aufsetzen zu können. Das enthält somit das Anwendungsverzeichnis, in dem OrgaMon läuft, sowie das Backup der aktuellen Datenbank.

Die Datensicherung erfolgt in 3 Phasen:

Phase A: Erstellung eines Datenbank - Backups

Jedem Backuplauf wird zunächst eine fortlaufende BACKUP_TAN zugeordnet. Nun wird der Datenbank-Server veranlasst die gesamte Datenbank in die Datei Sicherung_<BACKUP_TAN>.fbak zu sichern. Diese einzelne Datei enthält die gesamte zu sichernde Datenbank (".fdb"). Dabei kann gesteuert werden in welchem Pfad diese Datei angelegt wird. Dies erfolgt durch den Systemparameter:

#
# Beispiel 1: Linux Server speichert direkt in OrgaMon-Datensicherung
#
DatenbankBackupPfad=/srv/smb/freigabe/OrgaMon/Datensicherung/

#
# Beispiel 2: Windows Server speichert direkt in OrgaMon-Datensicherung
#
DatenbankBackupPfad=C:\Freigabe\OrgaMon\Datensicherung\

#
# best practice "Linux": fbak nach /srv/firebird
#
DatenbankBackupPfad=/srv/firebird/

Optimal ist natürlich, wenn die ".fbak" Datei sofort im .\Datensicherung Unterverzeichnis des OrgaMon landet. Dann kann Phase B übersprungen werden. Dies ist aber nur unter Voraussetzungen möglich auf die hiermit eingegangen wird: Wird das OrgaMon- Anwendungsverzeichnis durch den selben Server zur Verfügung gestellt der auch den Datenbankserver firebird betreibt, kann firebird seine Datensicherung direkt in das .\Datensicherungs - Verzeichnis des OrgaMon Anwendungsverzeichnis ablegen. Dadurch wird zusätzliches umkopieren vermieden. Beachten Sie jedoch dass die Rechte samba/firebird zusammenpassen. Ist diese Angabe leer, so wird in das selbe Verzeichnis gesichert, in dem auch die Datenbank selbst liegt. Dieses Backup wird nun durch einen Restore-Lauf in eine Zwischen- Datenbank zurückgespeichert. War dies erfolgreich, werden alle GENERATOR-Werte der "aktuellen" und der "restoreten" Datenbank verglichen. Ist der Vergleich erfolgreich wird die Zwischen- Datenbank gelöscht, das Backup wird als "GUT" markiert. Dieser Aufwand muss betrieben werden, da ein erfolgtes Backup noch lange nicht bedeutet das es auch wieder in eine funktionierende Datenbank zurückverwandelt werden kann.

Lebensdauer dieser fbak - Dateien = 10 Tage)

Phase B: Die Sicherung umlagern und komprimieren

Das Ziel von Datenbank- Sicherungs- Dateien ist das OrgaMon Unterverzeichnis .\Datensicherung. Kann der Datenbank-Server sein Backup nicht direkt in das .\Datensicherung Verzeichnis ablegen muss es dorthin umkopiert werden. Dieses umkopieren muss jedem Client möglich sein. Somit muss jedem Client ein Laufwerksbuchstabe + Verzeichnis zur Verfügung gestellt werden, worin er die von Server erstellen ".fbak" lesen und löschen kann (Berechtigungen beachten). Diesen Zugriffspfad kann man in den Systemparametern angeben unter:

 FreigabePfad=\\<ServerHostNameWoDieDatenbankLiegt>\<FreigabenameFuer_fbaks>\<Pfad>\

Mehrplatz: Nachdem der Server das Backup erstellt hat, will der Client die neue .fbak Datei sehen. Dazu wird der Parameter Freigabe-Pfad als Prefix für die Sicherungsdatei verwendet. Also "mv %FreigabePfad%Sicherung_<TAN>.fbak .\Datensicherung".

Lebensdauer dieser Dateien = 3 Tage

Phase C: Gesamtsicherung

Hier wird das ganze OrgaMon-Verzeichnis mit allen Unterverzeichnissen (und damit auch den .fbaks der Phase B) in ein ZIP-Archiv gepackt.
Aus Geschwindigkeitsgründen wird das Archiv zunächst lokal in .\Dokumente\OrgaMon\ erstellt.
Mit einem Systemparameter kann angegeben werden, wohin dieses Gesamtsicherungs-Zip nach Erstellung verschoben werden soll.

SicherungsPfad=<SicherungsPfad>

Bleibt diese Angabe leer, so erfolgt die Sicherung in das Stammverzeichnis des OrgaMon Anwendungsverzeichnisses.
Es sollte immer ein physikalisch anderes Laufwerk gewählt werden, als das des OrgaMon-Verzeichnisses, damit im Ausfall Moment nicht das Verzeichnis UND die Sicherungszips verloren sind.

400

// die400 
 
 // erstellt eine Dateiliste von gewissen Dateien
// die mit hinreichender Wahrscheinlichkeit nicht mehr benötigt werden
// es sind diverse Dateien aus unterschiedlichen Quellen
// die 400er-Zips sollten dauerhaft gespeichert werden

Datenhaltbarkeit

Täglich entsteht ja die Gesamt-Sicherung, im Laufe der Jahre kann dies ein Datenvolumen von mehreren TB ergeben
Es ist eigentlich auch nicht nötig von jedem Tag der Vergangenheit eine Sicherung zu haben
- Also wir würden jetzt den Stand vom 22.03.2017 benötigen, dann ist der 01.03.2017 oder der 01.04.2017 auch aussagekräftig genug
Je weiter der Tag entfernt ist, um so grösser dürfen "Lücken" in der Datenhaltung sein

Aufweichung des "Täglich" - Anspruches

von TÄGLICH" zu WÖCHENTLICH zu MONATLICH zu QUARTAL zu JÄHRLICH

Das Prinzip ist dass wir einen Bereich definieren in dem wir täglich Datensicherungen haben wollen, sagen wir 14 Stück, also 14 Tage
Danach wollen wir wöchentliche Datensicherungen, dann nur noch monatliche, usw.
Der Trick ist, dass wir eine tägliche Datensicherung "bewerten"
- Ist sie ein Kandidat für W, M, Q, oder gar Y?
- Die Beantwortung der Frage im Zusammenhang mit dem Alter der Datensicherung gibt Auskunft darüber ob eine Löschung erlaubt ist

Anspruch-Phasen

In unserem Beispiel haben wir in T bis T-14 den Anspruch eine tägliche Sicherung vorzuhalten
Von T-2W bis T-16W wollen wir wöchentliche Sicherungen
Von T-4M bis T-12M wollen wir monatliche Sicherungen
Von T-4Q bis T-8Q wollen wir quartalssicherung
Von T-2Y bis T-11Y wollen wir Jahressicherungen
Ab T-12Y wollen wir keine Sicherungen mehr

Unschärfe Funktion

Man kann nicht davon ausgehen, dass die tägliche Sicherung gelingt oder gültig ist
Misslungene Sicherungen müssen zudem gelöscht werden, das ist besser als sie zu behalten da sie unter umständen "gute" Datensicherungen verdrängen
Es darf nicht so sein, dass der Algorithmus versagt wenn z.B. der direkte M-Kandidat fehlt
- Angenommen die Datensicherung vom 01.04. fehlt, es muss dann die Datensicherung mit dem kürzesten Abstand zum 01.04. als M-Kandiat betrachtet werden (z.B. die vom 29.03.)