Datensicherung: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
 
(81 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 14: Zeile 14:


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:<br>
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:<br>
<br>
 
  DatenbankBackupPfad=/srv/smb/freigabe/OrgaMon/Datensicherung/
#
<br>
# 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.  
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.
Ist diese Angabe leer, so wird in das selbe Verzeichnis gesichert, in dem auch die Datenbank selbst liegt.
Zeile 38: Zeile 53:
== Phase C: Gesamtsicherung ==
== 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. Mit einem Systemparameter kann angegeben werden, wo dieses Gesamtsicherungs- Zip entstehen soll. 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.
* 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.  
<br>
<br>
  SicherungsPfad=<SicherungsPfad>
  SicherungsPfad=<SicherungsPfad>
<br>
<br>
Gesamtsicherung von .\ nach "Sicherung_<BACKUP_TAN>.zip")
* 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
 
== Haltbarkeit von Datensicherungen ==
 
* 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 oft 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
 
=== Hohe Ansprüche aufweichen ===
 
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
 
* Für den Algorithmus ist jetzt nur noch wichtig wie lange die Phasen sind
* Und zwar wird das angegeben in der grösse des Abschnittes selbst
 
  T  W  M  Q  Y
14  3  3  4  10
 
* Aus diesen Angaben kann die maximale Anzahl der Sicherungen berechnet werden
* Aus diesen Abgaben kann berechnet werden bis wie lange zurück überhaupt Datensicherungen vorgehalten werden
 
* Bemerkungen
** Eine Phase kann natürlich auch "0" sein, z.B. M oder Q
** Sind jährliche Sicherungen zu weit voneinander entfernt so könnte Q auf 40 eingestellt werden und Y auf 0
** Ist eine zeitliche Beschränkung der Datenhaltung gar nicht gewünscht kann bei der letzten Granularität ein "*" gesetzt werden
 
  T  W  M  Q  Y
14  3  3  *
 
* Somit haben wir auf ewig alle Quartalssicherungen erhalten
** Ist (vorerst) endlos Plattenplatz zur Verfügung kann


Bleibt diese Angabe leer, so erfolgt die Sicherung in das Stammverzeichnis des OrgaMon Anwendungsverzeichnisses.
=== Protegé ===


*Lebensdauer dieser Dateien = 3 Tage
* Sicherungen der Phasen X haben Protegé in den Phasen davor, sie spielen erst später eine Rolle in Phase X
*In Zukunft werden anstelle der ZIP Dateien, ausführbare Setup-OrgaMon-Backup-nnnnnnnnnn.exe erstellt.
* Beispiel, die Sicherung in Phase T vom Freitag 01.01. gerät von der T in die W-Phase und würde gelöscht da hier nur Sonntags-Sicherungen überleben
* Aber Phase "M" macht diese Sicherung zu seinem Protegé
* Die Protegé haben manchmal eine Daseinsberechtigung in einer Phase, machmal nicht. Egal sie werden nie gelöscht
* Protegés mogeln sich also durch, bis ihre grosse Stunde schlägt
 
=== Amnestie ===
 
* Ein Stern ("*") am Ende der Parameter führt dazu, dass niemals ein Vertreter dieser Phase gelöscht wird
* weitere Parameter (nach einem Stern) haben keine Bedeutung mehr


== weitere Ideen ==
=== Unschärfe-Funktion ===


Sicherung auf eine extra Backup-Platte, die unter einem Linux für disen Zweck gemountet wird, danach das Backup, danach ein umount. Einfach auch um Strom zu sparen und die Lebensdauer der Platte zu erhöhen.
* Man kann nicht davon ausgehen, dass die tägliche Sicherung gelingt oder gültig ist, wir müssen mit Lücken leben
** Ärgerlich ist natürlich der Ausfall einer Sonntags-Sicherung am 01. des Jahres, das schmerzt!! element von (T,W,Q,M,Y)
* Misslungene oder korrupte Sicherungen müssen allerdings konzequent gelöscht werden
** Sie können eine falsche Sicherheit vorgaukeln, die nicht erfüllbar ist
** sie können einen schadhaften Datenzustand darstellen, der niemals wiederherzustellen ist (Beispiel: Ein Software Release hat an d-1 schaden an der Datenbank verursacht, die Datensicherung d liegt schon vor, aus der Datensicherung d-2 konnten alle Lücken wiederhergestellt werden, unbetroffene TAbellen der Datenbank hatten sich bereits weiterentwickelt. d und d-1 sind zu löschen, da sie keinen gewünschten Stand widerspiegeln!!!)
* 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.)
** Volltreffer Kandidaten heissen ("T"|"W"|"M"|"Q"|"Y") "0", also die Datensicherung vom 01.04. ist die M0 Datensicherung für März
** Unscharfe Kandidaten heissen {"T"|"W"|"M"|"Q"|"Y"} ("+"|"-") n wobei "n" der Abstand zum M0 ist (in Tagen)
* Ist "älter" besser als "neuer", also T+1 besser als T-1?
** ganz sicher!!


== eldorado ==
==== Beispiel für "0,0,0,*" ====


{| style="background-color:transparent;"
DATE;PHASE;NUMBER;FILE;DISTANCE
|
01.10.2020;Q;1;hv_00001018.zip;50 (20.11.2020)
  [[Bild:WesternDigitalMyBook.png|120px]]
01.07.2020;Q;2;hv_00001013.zip;44 (14.08.2020)
|
01.04.2020;Q;3;hv_00001012.zip;32 (02.03.2020)
Das "eldorado" Projekt verwendet zur automatischen Datensicherung ein "My Book" Worldedition von Western Digital. Das Sicherungsvolumen das anfällt ist 160 Giga-Byte. Es wird die 1 Terrabyte Version des NAS verwendet. Die Kosten betragen 140 Euro (Stand 2010, unglaublich für eine fast vollständige Linux-Box mit 1 TB).  
01.01.2020;Q;4;hv_00001012.zip;61 (02.03.2020)
Ich denke die verwendete Technologie lässt sich auf jedes moderne Linux betriebene NAS übertragen, ein offener ssh Zugang ist jedoch erforderlich. Hilfreich ist natürlich eine hohe Verbreitung eines NAS, so dass die Linux Community gross und leistungsstark genug ist. Das NAS wurde so konfiguriert:
01.10.2019;Q;5;hv_00001011.zip;11 (12.10.2019)
01.07.2019;Q;6;hv_00001009.zip;71 (23.04.2019)
01.04.2019;Q;7;hv_00001009.zip;22 (23.04.2019)
01.01.2019;Q;8;hv_00001009.zip;112 (23.04.2019)
  01.10.2018;Q;9;hv_00001008.zip;103 (22.06.2018)
01.07.2018;Q;10;hv_00001008.zip;11 (22.06.2018)
01.04.2018;Q;11;hv_00001006.zip;45 (17.02.2018)
01.01.2018;Q;12;hv_00001004.zip;30 (04.12.2017)
01.10.2017;Q;13;hv_00001001.zip;20 (13.09.2017)
01.07.2017;Q;14;hv_00001001.zip;74 (13.09.2017)


* Es wurde der Systemdienst "cron" nachinstalliert
* Man sieht dass es eigentlich gar keine "Treffer" (DISTANCE=0) gibt, dennoch wäre es falsch Sicherungen zu löschen
* Es wurde der Editor "joe" nachinstalliert
* Machmal sind die Lücken so gross dass einzelne Sicherungen mehrfach passen (hv_00001009.zip)
* Es wurde der Mail Client "nail" nachinstalliert


Folgende Ziele wurden erreicht:
=== Anfangsphase ===


* Das ich einen Linux-Server als Daten-Server (Storage) verwende, wir mit "rsync" gesichert
* In der Anfangsphase der Datensicherungen können wir mehr T speichern als eigentlich vorgesehen
* Das NAS initiert selbsttätig die Sicherung um 12 Uhr und 20 Uhr
* z.B. bei einer Konfiguration von
* Die Sicherungs-Zielverzeichnisse wechseln täglich von "0" bis "4" es werden somit 5 Sicherungen vorgehalten
* Am Ende des Sicherungs-Laufes schickt das NAS eine eMail mit einer Übersicht über die Platzverhältnisse der Platte
* Am "White Light" des NAS kann man erkennen was es gerade macht (Sichern oder Schlafen)
* Jederzeit kann im Netz auf die Sicherungsverzeichnisse zugegriffen werden
|}


T W M Q Y
9,3,3,3,*


=== Backup-Skript ===
* es ist ja mindestens Platz für 9+3+3+3=18 Datensicherungen vorgesehen
* in der Anfangsphase werden dann - da keine Löschungen durchgeführt werden müssen - 18 T Sicherungen behalten (wobei W,M,Q,Y Kandidaten vorhanden sein können, aber es gibt keine Lücken!)


=== Ausblick ===


echo date >/root/body.txt
* Bei Datenbanksicherungen sind Phasen der minütlichen Sicherungen denkbar (Phase "S60")
* Es ist eine "T3"- Phase denkbar, also nicht tägliche Sicherungen sondern mit 2 Tagen ohne Sicherung
echo 7 >/sys/class/leds/oxnas-wd810-leds\:st/brightness
BAND=$((($(date +%s)/86400)%5))
OPTIONS="-avK --delete --force --ignore-errors --copy-unsafe-links"
BACKUP_PATH="/DataVolume/Public/$BAND/"
echo $BACKUP_PATH
mkdir $BACKUP_PATH
chmod 777 $BACKUP_PATH
touch $BACKUP_PATH
#
# /srv
#
DEST=$BACKUP_PATH./srv
mkdir $DEST
chmod 777 $DEST
rsync $OPTIONS 192.168.115.91::srv/ $DEST
#
# /etc
#
DEST=$BACKUP_PATH./etc
mkdir $DEST
chmod 777 $DEST
rsync $OPTIONS 192.168.115.91::etc/ $DEST
#
# /named
#
DEST=$BACKUP_PATH./named
mkdir $DEST
chmod 777 $DEST
rsync $OPTIONS 192.168.115.91::named/ $DEST
#
# /mail
#
DEST=$BACKUP_PATH./mail
mkdir $DEST
chmod 777 $DEST
rsync $OPTIONS 192.168.115.91::mail/ $DEST
echo 1 >/sys/class/leds/oxnas-wd810-leds\:st/brightness
df -h >>/root/body.txt
echo date >>/root/body.txt
nail -s "Datensicherungsbericht [eldorado]" andreas.filsinger@orgamon.com < /root/body.txt


=== LED Kontrolle ===
=== Beispiel ===


* normal: <code>echo 1 >/sys/class/leds/oxnas-wd810-leds\:st/brightness</code>
  #
* backup: <code>echo 7 >/sys/class/leds/oxnas-wd810-leds\:st/brightness</code>
  # Vorgabe für die Datensicherung
  #
  SicherungenAnzahl=20,3,3,8,10
  #
  # "Perfekte Liste" für den 08.11.2020
  # NUMBER=0 bedeutet dass es ein Protegé ist
  #
  DATE;PHASE;NUMBER
  08.11.2020;W;0
  08.11.2020;T;1
  07.11.2020;T;2
  06.11.2020;T;3
  05.11.2020;T;4
  04.11.2020;T;5
  03.11.2020;T;6
  02.11.2020;T;7
  01.11.2020;M;0
  01.11.2020;W;0
  01.11.2020;T;8
  31.10.2020;T;9
  30.10.2020;T;10
  29.10.2020;T;11
  28.10.2020;T;12
  27.10.2020;T;13
  26.10.2020;T;14
  25.10.2020;W;0
  25.10.2020;T;15
  24.10.2020;T;16
  23.10.2020;T;17
  22.10.2020;T;18
  21.10.2020;T;19
  20.10.2020;T;20
  18.10.2020;W;1
  11.10.2020;W;2
  04.10.2020;W;3
  01.10.2020;Q;0
  01.10.2020;M;1
  01.09.2020;M;2
  01.08.2020;M;3
  01.07.2020;Q;1
  01.04.2020;Q;2
  01.01.2020;Y;0
  01.01.2020;Q;3
  01.10.2019;Q;4
  01.07.2019;Q;5
  01.04.2019;Q;6
  01.01.2019;Y;0
  01.01.2019;Q;7
  01.10.2018;Q;8
  01.01.2018;Y;1
  01.01.2017;Y;2
  01.01.2016;Y;3
  01.01.2015;Y;4
  01.01.2014;Y;5
  01.01.2013;Y;6
  01.01.2012;Y;7
  01.01.2011;Y;8
  01.01.2010;Y;9
  01.01.2009;Y;10

Aktuelle Version vom 20. November 2020, 13:09 Uhr

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

Haltbarkeit von Datensicherungen

  • 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 oft 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

Hohe Ansprüche aufweichen

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
  • Für den Algorithmus ist jetzt nur noch wichtig wie lange die Phasen sind
  • Und zwar wird das angegeben in der grösse des Abschnittes selbst
 T  W  M  Q  Y
14  3  3  4  10
  • Aus diesen Angaben kann die maximale Anzahl der Sicherungen berechnet werden
  • Aus diesen Abgaben kann berechnet werden bis wie lange zurück überhaupt Datensicherungen vorgehalten werden
  • Bemerkungen
    • Eine Phase kann natürlich auch "0" sein, z.B. M oder Q
    • Sind jährliche Sicherungen zu weit voneinander entfernt so könnte Q auf 40 eingestellt werden und Y auf 0
    • Ist eine zeitliche Beschränkung der Datenhaltung gar nicht gewünscht kann bei der letzten Granularität ein "*" gesetzt werden
 T  W  M  Q  Y
14  3  3  *
  • Somit haben wir auf ewig alle Quartalssicherungen erhalten
    • Ist (vorerst) endlos Plattenplatz zur Verfügung kann

Protegé

  • Sicherungen der Phasen X haben Protegé in den Phasen davor, sie spielen erst später eine Rolle in Phase X
  • Beispiel, die Sicherung in Phase T vom Freitag 01.01. gerät von der T in die W-Phase und würde gelöscht da hier nur Sonntags-Sicherungen überleben
  • Aber Phase "M" macht diese Sicherung zu seinem Protegé
  • Die Protegé haben manchmal eine Daseinsberechtigung in einer Phase, machmal nicht. Egal sie werden nie gelöscht
  • Protegés mogeln sich also durch, bis ihre grosse Stunde schlägt

Amnestie

  • Ein Stern ("*") am Ende der Parameter führt dazu, dass niemals ein Vertreter dieser Phase gelöscht wird
  • weitere Parameter (nach einem Stern) haben keine Bedeutung mehr

Unschärfe-Funktion

  • Man kann nicht davon ausgehen, dass die tägliche Sicherung gelingt oder gültig ist, wir müssen mit Lücken leben
    • Ärgerlich ist natürlich der Ausfall einer Sonntags-Sicherung am 01. des Jahres, das schmerzt!! element von (T,W,Q,M,Y)
  • Misslungene oder korrupte Sicherungen müssen allerdings konzequent gelöscht werden
    • Sie können eine falsche Sicherheit vorgaukeln, die nicht erfüllbar ist
    • sie können einen schadhaften Datenzustand darstellen, der niemals wiederherzustellen ist (Beispiel: Ein Software Release hat an d-1 schaden an der Datenbank verursacht, die Datensicherung d liegt schon vor, aus der Datensicherung d-2 konnten alle Lücken wiederhergestellt werden, unbetroffene TAbellen der Datenbank hatten sich bereits weiterentwickelt. d und d-1 sind zu löschen, da sie keinen gewünschten Stand widerspiegeln!!!)
  • 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.)
    • Volltreffer Kandidaten heissen ("T"|"W"|"M"|"Q"|"Y") "0", also die Datensicherung vom 01.04. ist die M0 Datensicherung für März
    • Unscharfe Kandidaten heissen {"T"|"W"|"M"|"Q"|"Y"} ("+"|"-") n wobei "n" der Abstand zum M0 ist (in Tagen)
  • Ist "älter" besser als "neuer", also T+1 besser als T-1?
    • ganz sicher!!

Beispiel für "0,0,0,*"

DATE;PHASE;NUMBER;FILE;DISTANCE
01.10.2020;Q;1;hv_00001018.zip;50 (20.11.2020)
01.07.2020;Q;2;hv_00001013.zip;44 (14.08.2020)
01.04.2020;Q;3;hv_00001012.zip;32 (02.03.2020)
01.01.2020;Q;4;hv_00001012.zip;61 (02.03.2020)
01.10.2019;Q;5;hv_00001011.zip;11 (12.10.2019)
01.07.2019;Q;6;hv_00001009.zip;71 (23.04.2019)
01.04.2019;Q;7;hv_00001009.zip;22 (23.04.2019)
01.01.2019;Q;8;hv_00001009.zip;112 (23.04.2019)
01.10.2018;Q;9;hv_00001008.zip;103 (22.06.2018)
01.07.2018;Q;10;hv_00001008.zip;11 (22.06.2018)
01.04.2018;Q;11;hv_00001006.zip;45 (17.02.2018)
01.01.2018;Q;12;hv_00001004.zip;30 (04.12.2017)
01.10.2017;Q;13;hv_00001001.zip;20 (13.09.2017)
01.07.2017;Q;14;hv_00001001.zip;74 (13.09.2017)
  • Man sieht dass es eigentlich gar keine "Treffer" (DISTANCE=0) gibt, dennoch wäre es falsch Sicherungen zu löschen
  • Machmal sind die Lücken so gross dass einzelne Sicherungen mehrfach passen (hv_00001009.zip)

Anfangsphase

  • In der Anfangsphase der Datensicherungen können wir mehr T speichern als eigentlich vorgesehen
  • z.B. bei einer Konfiguration von
T W M Q Y
9,3,3,3,*
  • es ist ja mindestens Platz für 9+3+3+3=18 Datensicherungen vorgesehen
  • in der Anfangsphase werden dann - da keine Löschungen durchgeführt werden müssen - 18 T Sicherungen behalten (wobei W,M,Q,Y Kandidaten vorhanden sein können, aber es gibt keine Lücken!)

Ausblick

  • Bei Datenbanksicherungen sind Phasen der minütlichen Sicherungen denkbar (Phase "S60")
  • Es ist eine "T3"- Phase denkbar, also nicht tägliche Sicherungen sondern mit 2 Tagen ohne Sicherung

Beispiel

 #
 # Vorgabe für die Datensicherung
 # 
 SicherungenAnzahl=20,3,3,8,10

 #
 # "Perfekte Liste" für den 08.11.2020
 # NUMBER=0 bedeutet dass es ein Protegé ist
 #
 DATE;PHASE;NUMBER
 08.11.2020;W;0
 08.11.2020;T;1
 07.11.2020;T;2
 06.11.2020;T;3
 05.11.2020;T;4
 04.11.2020;T;5
 03.11.2020;T;6
 02.11.2020;T;7
 01.11.2020;M;0
 01.11.2020;W;0
 01.11.2020;T;8
 31.10.2020;T;9
 30.10.2020;T;10
 29.10.2020;T;11
 28.10.2020;T;12
 27.10.2020;T;13
 26.10.2020;T;14
 25.10.2020;W;0
 25.10.2020;T;15
 24.10.2020;T;16
 23.10.2020;T;17
 22.10.2020;T;18
 21.10.2020;T;19
 20.10.2020;T;20
 18.10.2020;W;1
 11.10.2020;W;2
 04.10.2020;W;3
 01.10.2020;Q;0
 01.10.2020;M;1
 01.09.2020;M;2
 01.08.2020;M;3
 01.07.2020;Q;1
 01.04.2020;Q;2
 01.01.2020;Y;0
 01.01.2020;Q;3
 01.10.2019;Q;4
 01.07.2019;Q;5
 01.04.2019;Q;6
 01.01.2019;Y;0
 01.01.2019;Q;7
 01.10.2018;Q;8
 01.01.2018;Y;1
 01.01.2017;Y;2
 01.01.2016;Y;3
 01.01.2015;Y;4
 01.01.2014;Y;5
 01.01.2013;Y;6
 01.01.2012;Y;7
 01.01.2011;Y;8
 01.01.2010;Y;9
 01.01.2009;Y;10
Abgerufen von „https://wiki.orgamon.org/index.php?title=Datensicherung&oldid=30028“