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:

 DatenbankBackupPfad=/srv/smb/freigabe/OrgaMon/Datensicherung/

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. 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.

SicherungsPfad=<SicherungsPfad>

Gesamtsicherung von .\ nach "Sicherung_<BACKUP_TAN>.zip")

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

• Lebensdauer dieser Dateien = 3 Tage
• In Zukunft werden anstelle der ZIP Dateien, ausführbare Setup-OrgaMon-Backup-nnnnnnnnnn.exe erstellt.

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

weitere Ideen

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.

Datensicherungs-Algorithmus für Abbild-Begrenzungen

Vorgeschichte

• Nehmen wir an wir machen mit rsync Abbilder vom Dateisystem
• Es sollen vollständige Verzeichnis-Kopieen sein, ein Optimierungsversuch "Diff" soll hier keine Rolle spielen
• Habe ich die Möglichkeit z.B. 10 Versionen des vollständigen Dateisystems zu halten

BAND=$((($(date +%s)/86400)%10))

• Kann ich über BAND die Verzeichnisnamen "0" bis "9" erhalten.
• Ich habe so immer die heutige Sicherung und 9 zurückliegende

Nachteil war: Im unbemerkten Verlustfall von Dateien war es nicht immer möglich damit zu helfen, in dem Fall wäre es besser gewesen weiter zurückliegende Datensicherungen zu haben

Natürlichere Verteilung

• Gibt es z.B. wöchentliche Arbeiten, kann es passieren, dass an einem Freitag auffällt, dass Freitag vor 2 Wochen ein Problem war. Die unversehrte Datei sollte also von einer Sicherung kommen die zwischen 14 und 20 Tagen alt ist.
• Wenn dies als feststehende Forderung aufgestellt ist

Backup(dmin=14,dmax=20)

• kann man mal die Backup-Geschichte aufrollen

01 A(0) 
02 B(0) A(1)
03 C(0) B(1) A(2)
04 D(0) C(1) A(3)
05 E(0) D(1) A(4) 
06 F(0) E(1) A(5)
07 G(0) F(1) A(6)
08 H(0) G(1) A(7)
09 I(0) H(1) A(8)
10 J(0) I(1) H(2) A(9)
11 K(0) J(1) H(3) A(10)
12 L(0) K(1) H(4) A(11)
13 M(0) L(1) H(5) A(12)
14 N(0) M(1) H(6) A(13)
15 O(0) N(1) H(7) A(14)
16 P(0) O(1)  H(8) A(15)
17 Q(0) P(1) O(2) H(9) A(16)
18 R(0) Q(1) O(3) H(10) A(17)
19 S(0) R(1) O(4) H(11) A(18)
20 T(0) S(1) O(5) H(12) A(19)
21 U(0) T(1) O(6) H(13) A(20)
22 V(0) U(1) O(7) H(14) A(21)
23 W(0) V(1) O(8) H(15)
24 X(0) W(1) O(9) H(16)
25 Y(0) X(1) W(2) O(10) H(17)
26 Z(0) Y(1) W(3) O(11) H(18)
27 A(0) Z(1) W(4) O(12) H(19)
28 B(0) A(1) W(5) O(13) H(20)
29 C(0) B(1) W(6) O(14) H(21)

• Jeden Tag Wird eine Datensicherung gemacht, sie werden A, B, C genannt
• Ganz links steht die Nummer des Tages seit der ersten Datensicherung
• In Klammer steht immer das Alter der Datensicherung in Tagen
• Grün: Das brauchen wir, das wollen wir haben
• Rot: Kann gelöscht werden
• Tag 01..08: Unsere aller erste Datensicherung muss noch reifen, aktuellere Datensicherung kann gelöscht werden
• Tag 09: Unser Kandidat "A" wird nicht ewig jung bleiben, im Alter von 21 Tagen wird er unnütz werden, wir müssen an einen Nachfolger denken, der an dem Tag der Übernahme optimalerweise 14 Tage alt ist. Nachfolger wird "H" werden
• Tag 10..14 A und H müssen reifen
• Tag 15: "A" erfüllt erstmals unsere Regel
• Tag 22: "A" erfüllt unsere Regel nicht mehr, zum Glück erfüllt "H" die Regel

• Erste Mutmasungen:
  • Am Tag dmin+1 haben wir die erste Sicherung, die wir brauchen
  • Ist dmax-dmin=0 muss jeden Tag ein neuer Nachfolger gehalten, es gibt dann bis zu dmax parrallel zu haltende Datensicherungen
  • Ist dmax unendlich muss kein Nachfolger erstellt werden, erreicht ein Kandidat die Reife ist die Regel erfüllt
  • In der Spitze brauchen wir dmax / succ(dmax - dmin) Datensicherungen

eldorado

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 120 Euro (Stand 2010, unglaublich für eine vollständige Linux-Box mit 1 TB). 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: Es wurde der Systemdienst "cron" nachinstalliert Es wurde der Editor "joe" nachinstalliert Es wurde der Mail Client "nail" nachinstalliert Folgende Ziele wurden erreicht: Da ich einen Linux-Server als Datei-Server verwende, wird mit "rsync" gesichert Das NAS initiert selbsttätig die Sicherung um 12 Uhr und 20 Uhr Die Sicherungs-Zielverzeichnisse wechseln täglich von "1" bis "6" es werden somit 6 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

Setup

ipkg installieren

Zitate sind aus [1]

feed=http://ipkg.nslu2-linux.org/feeds/optware/cs05q1armel/cross/unstable
cd /tmp
wget http://ipkg.nslu2-linux.org/feeds/optware/mssii/cross/unstable/ipkg-opt_0.99.163-10_arm.ipk
tar -xOvzf ipkg-opt_0.99.163-10_arm.ipk ./data.tar.gz | tar -C / -xzvf –
mkdir -p /opt/etc/ipkg
echo "src armel http://ipkg.nslu2-linux.org/feeds/optware/cs05q1armel/cross/unstable" > /opt/etc/ipkg/armel-feed.conf
/opt/bin/ipkg update

joe

/opt/bin/ipkg install joe
ln -s /opt/bin/joe /bin/joe

cron

/opt/bin/ipkg install cron 
ln -s /opt/etc/init.d/S10cron /etc/init.d/S10cron

• Die crontab muss neu angelegt werden (Ist nicht vorhanden)

joe /opt/etc/crontab

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/opt/sbin:/opt/bin
MAILTO=""
HOME=/
# ---------- ---------- Default is Empty ---------- ---------- #
05 13 * * 0-6 root /root/backup.sh
35 18 * * 0-6 root /root/backup.sh
# ---------- ---------- End              ---------- ---------- #

nail

/opt/bin/ipkg install nail
ln -s /opt/bin/nail /bin/nail

Backup-Skript

echo date >/root/body.txt 

echo 7 >/sys/class/leds/oxnas-wd810-leds\:st/brightness

#
# Modulo 5 des Datums ergibt Band "0" bis "4"
#
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::sxx/ $DEST

#
# /etc
#
DEST=$BACKUP_PATH./etc
mkdir $DEST
chmod 777 $DEST
rsync $OPTIONS 192.168.115.91::exx/ $DEST

#
# /named
#
DEST=$BACKUP_PATH./named
mkdir $DEST
chmod 777 $DEST
rsync $OPTIONS 192.168.115.91::nxxxx/ $DEST

#
# /mail
#
DEST=$BACKUP_PATH./mail
mkdir $DEST
chmod 777 $DEST
rsync $OPTIONS 192.168.115.91::mxxx/ $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]" axdrxas.fixinxer@oxgxmxn.cxm < /root/body.txt

nail Konfiguration nail.rc

/opt/etc/nail.rc

# This is the configuration file for nail, a mail user agent.
# See nail(1) for further options.
# This file is not overwritten when 'make install' is run in
# the nail build process again.
 
set smtp=raib91.lummerland
set from="ELDORADO" <oxgxtxx@orxmxn.dx>
set smtp-auth=login
set smtp-auth-user=mail-ot1
set smtp-auth-password=9xGxxx8x

# ... 
# usw. Rest der Datei habe ich unberührt gelassen ...

LED Kontrolle

• normal: echo 1 >/sys/class/leds/oxnas-wd810-leds\:st/brightness
• backup: echo 7 >/sys/class/leds/oxnas-wd810-leds\:st/brightness

Dienst Deaktivierung

/etc/init.d # mv S55mini_httpd _S55mini_httpd
/etc/init.d # mv S97twonkyserver _S97twonkyserver
/etc/init.d # mv S9M_mionet _S9M_mionet