OptiYummy-System 3

Aus OptiYummy
Zur Navigation springenZur Suche springen

Siehe auch: "Installation des Basis-Systems" / "Wiki-System individuell konfigurieren"

System- und Datensicherung

Für den ernsthaften Betrieb eines Wiki-Systems muss unbedingt gewährleistet werden, dass dieses System nach einem Software- oder Hardware-Crash in angemessener Zeit mit möglichst aktuellem Inhalt wieder Online ist.

Dafür sind zwei regelmäßige Sicherungsmaßnahmen erforderlich:

  • In größeren Abständen (z.B. 2x im Jahr) eine komplette Kopie der Systemplatten. Damit kann man auch nach einem Hardware-Crash auf ähnlicher Hardware relativ schnell das Wiki-System wieder zum Leben erwecken. Allerdings sind die Wiki-Inhalte dann natürlich entsprechend veraltet.
  • In kurzen Abständen (z.B. täglich) ein Backup der Datenbank und der hochgeladenen Dateien. Damit kann man ein Wiki-System auch auf einem neu installierten System wieder mit den aktuellen Inhalten speisen.


Abzug der Systemplatte

Ideal geeignet für die Kopie einer Festplatte ist der Unix-Befehl dd. Dazu muss man die zu kopierende Festplatte (Input-File) zusammen mit der Sicherungsplatte (Output-File) in einem geeigneten Linux-System betreiben. Während dieser Zeit ist das Wiki-System natürlich für 2-3 Stunden außer Betrieb.

Ein ideales Linux-System dafür ist die Knoppix Live-Distribution [1], welche als DVD z.B. regelmäßig der Computerzeitschrift c't beiliegt. Dieses System startet fast auf jeder PC-Plattform, ohne dabei Platz auf der Festplatte zu belegen. Man kann dafür also auch die Hardware des zu sichernden Wiki-Systems direkt benutzen.

Achtung:

Die Kopie einer Festplatte ist kein exakter Klon! Original und Kopie unterscheiden sich auch bei identischen Plattentypen immer noch durch ihre Serien-Nummern. Leider benutzt OpenSUSE für das Ansprechen der Partitionen der Systemplatte nicht die logischen Bezeichner sda1, sda2 und sda3, sondern bezieht sich auf Plattentyp und Serien-Nummer. Damit bootet das System nicht mehr von einer geklonten Festplatte!

Deshalb muss man zuvor einmalig als root-Nutzer im System in 2 Dateien die individuellen Plattenbezeichner durch die logischen Bezeichner ersetzen. Im Ordner /dev/disk/by-id/ kann man zuvor zur Sicherheit die konkrete Zuordnung der Partitionen zu den logischen Geräten überprüfen!

Hinweis:

Wer ganz sicher sein will, dass durch die folgenden Änderungen das System nicht zerstört wird, sollte zuerst eine Kopie der aktuellen Systemplatte herstellen, wie es im Weiteren beschrieben wird. Dann kann man diese Kopie bei Bedarf auf die Original-Platte zurückkopieren und man verfügt wieder über ein bootfähiges System!


Datei: /etc/fstab 

/dev/disk/by-id/scsi-SATA_Hitachi_HDS7216_PVF704Z1198DTN-part2 /     ext3  acl,user_xattr  1 1
/dev/disk/by-id/scsi-SATA_Hitachi_HDS7216_PVF704Z1198DTN-part3 /home ext3  acl,user_xattr  1 2
/dev/disk/by-id/scsi-SATA_Hitachi_HDS7216_PVF704Z1198DTN-part1 swap  swap  defaults        0 0

Diese Zeilen ersetzen durch: 

/dev/sda2 /     ext3  acl,user_xattr  1 1
/dev/sda3 /home ext3  acl,user_xattr  1 2
/dev/sda1 swap  swap  defaults        0 0


Datei: /boot/grub/menu.lst

Analog dazu ersetzt man für den Systemstart 2x den by-id-Bezeichner: 

root=/dev/disk/by-id/scsi-SATA_Hitachi_HDS7216_PVF704Z1198DTN-part2

Diesen Ausdruck jeweils ersetzen durch: 

root=/dev/sda2

Wenn man sich nicht verschrieben hat, sollte das OpenSUSE-System danach wieder bootfähig sein.

Achtung: Nach einem Update des boot/grub-loaders könnte es passieren, dass die Datei menu.lst wieder neu initialisiert wird. Man merkt das daran, dass dann keine bootfähigen Plattenkopien entstehen. In diesem Fall müsste man diese Änderung erneut durchführen.


Wir kommen nun zur eigentlichen Herstellung einer Sicherungskopie:

  • Insgesamt kommen für die Sicherung des Systems drei identische Festplatten zum Einsatz. Man sollte jede Platte mit einer Nummer beschriften (1 bis 3, mit 1=Originalsystem). Für jede Platte sollte man sich zusätzlich die Seriennummer vom Typenschild notieren.
  • Während des Betriebs ist jeweils nur die aktuelle Systemplatte angeschlossen, zu Beginn also die Originalplatte mit der Nummer 1. Die Systemplatte sollte als 1. SATA-Platte betrieben werden (bzw. als Master am IDE1).
  • Nach dem Herunterfahren des OpenSuse-Systems (in der Konsole z.B. shutdown -h now) schließt man die nächste Sicherungsplatte an, zu Beginn also die Nummer 2. Die Sicherungsplatte betreibt man möglichst als 2. SATA-Platte (bzw. als Master am IDE2), wenn dieser Anschluss noch nicht durch das DVD-Laufwerk belegt ist.
  • Dann bootet man den PC von der Knoppix-DVD. Dazu muss im BIOS des PC das DVD-Laufwerk als primäres BOOT-Device eingetragen sein.
  • Zuerst sollte man sich vergewissern, welche Bezeichnung im Knoppix die beiden Festplatten besitzen:
    • Im Knoppix startet man eine Konsole und wechselt mit su in den Super-User-Modus. Ein Passwort ist dafür nicht erforderlich.
    • Serielle Platten werden vom System als sda bis sdx durchnummeriert. Parallele Platten erhalten analog die Bezeichnung hda bis hdx.
    • Benutzt man serielle Platten, so liefern z.B. die Befehle hdparm -i /dev/sda und hdparm -i /dev/sdb unter anderem die Serien-Nummern der zugeordneten Festplatten. Damit erhält man die exakte Zuordnung von aktueller System- und Sicherungsplatte zu den logischen Bezeichnern!
    • Im Normalfall müsste die serielle Systemplatte den Bezeichner /dev/sda erhalten.
  • Mit dem Befehl dd if=/dev/sda of=/dev/sdb kopiert man dann die Systemplatte auf die Sicherungsplatte. Die Verwechselung von Inputfile (if) und Outputfile (of) ist hierbei sehr unangenehm!
  • Das Umkopieren dauert bei einer 80 GB-Platte ca. 1 Stunde. Ist die Sicherungskopie fertig, so kann man den PC mit dem Knoppix einfach ausschalten.
  • Um zu gewährleisten, dass eine korekkte Sicherungskopie angefertigt wurde, ersetzt man die aktuelle Systemplatte durch die Sicherungplatte:
    • Die bisherige Systemplatte sollte man mit dem aktuellen Datum beschriften und räumlich getrennt vom Wiki-System sicher aufbewahren.
    • Die aktuelle Sicherungsplatte wird an den Port der Systemplatte angeschlossen und ist nun die aktuelle Systemplatte.
    • Die 3. Platte für die nächste Systemsicherung kann schon im Rechner montiert werden. Sie wird aber nicht elektrisch angeschlossen!
    • Nach dem Entfernen der Knoppix-DVD sollte das OpenSuse-System problemlos von der neuen Systemplatte booten.

Zusammenfassung:

Die drei Systemplatten werden zyklisch verwendet. Nach jeder Systemsicherung wird die Sicherungskopie zur neuen aktuellen Systemplatte. Die bisherige Systemplatte wird ordentlich verwahrt und die älteste Kopie wartet auf die nächste Systemsicherung.

Hinweis:

Zumindest bei größeren Festplatten ist es sinnvoll, auf ein geeigneteres Festplatten-Clone-Programm umzusteigen. Gute Erfahrungen wurden mit der Clonezilla Live CD gemacht (Download von http://clonezilla.org/download/sourceforge/ ). Im Beispiel verkürzte sich die Kopierzeit von 1h auf wenige Minuten, da nur die tatsächlich vorhandenen Daten kopiert werden.

Backup der Datenbank

Im MySQL Administrator richtet man dafür ein Backup-Projekt ein:

  • Achtung: Dazu sollte man sowohl im Linux- als auch im MySQL-System als root angemeldet sein!
  • Menüpunkt Tools - Preferences - General Options - "Store connection passsword" mit Storage Method = "Obscured".
  • Menüpunkt Tools - Preferences - Administrator - "Append timestamp to backup file names". Damit erkennt man am Dateinamen bereits das Backup-Datum.
  • Menüpunkt Tools - Preferences - Connections - Add Connection:
    • Verbindungsname: z.B. MySqlAdmin
    • Benutzername: root
    • Password: mysql-rootpassword
    • Hostname: localhost
    • Port: 3306
    • Typ: MySQL
    • Schema: z.B. optiyummy (root muss über ausreichende Privilegien für diese "Schema" verfügen)
    • Apply Changes
  • Wahl der Backup-Ansicht:
    • Registerkarte "Backup-Projekt"
      • Projektname: optiyummy (muss nicht wie das "Schema" heißen)
      • Datenbank-Schema "optiyummy" -> zu Backup-Inhalt hinzufügen
    • Registerkarte "Erweiterte Einstellungen":
      • "InnoDB Online Backup", um ein konsistentes Backup zu erhalten.
      • "Backup der ganzen ausgewählten Datenbank"
      • Backup Type: SQL-Dateien (nur dieser Typ ist möglich)
      • Markieren: "Complete INSERTs", "Comment", "Don't write full path"
    • Registerkarte "Backup planen":
      • Dieses Projekt täglich durchführen (irgendwann nachts)
      • Zielverzeichnis: /backup (in Basis-root neu anlegen)
      • Dateinamenspräfix: ohne
      • Verbindungsname: "MySqlAdmin" wählen
      • Projekt speichern und "Update Schedule" -> damit Eintrag in crontab vom root-Nutzer.
      • "Start Backup", dabei muss man Zielordner /backup im Basisverzeichnis selbst wählen. Wenn alles funktioniert, entsteht im /backup-Ordner eine .sql-Datei mit einer Größe von ca. 2MByte.


Restore eines Backup-Files

Die Nutzung von "MySQL Administrator" erfolgt wieder als root-Nutzer:

  • Man wählt die Ansicht "Restore Bakup"
  • Falls der /backup-Ordner noch nicht eingestellt ist, muss man dies über "Change Path" nachholen (links unten).
  • Es werden alle Backup-Files in diesem Ordner aufgelistet. Davon wählt man im Normalfall das letzte Backup:
    • Als Zeichensatz wählt man die Vorgabe "utf8". Danach wird das Inhaltsverzeichnis des Backup gelesen.
    • In der "General"-Registerkarte kann man festlegen, in welches Datenbank-Schema die Daten zu speichern sind.
    • In der "Select"-Registerkarte, kann man festlegen, welche Inhalte übernommen werden sollen (meist Original Schema). Für ein komplettes Restore benötigt man wahrscheinlich die kompletten Inhalte.
    • "Create schemas if they don't exist" sollte man markieren.
  • Achtung: Den Restore-Prozess sollte man vorläufig noch abbrechen, um nicht aus Versehen die aktuellen Inhalte zu überschreiben!
  • Hinweise:
    • Es gelingt jedoch scheinbar nicht, eine vorhandenes Schema durch Restore mit dem Backup-Inhalt zu überschreiben. Dazu muss man unter der Catalogs-Ansicht das Schema erst löschen!
    • Die Übertragung in anderes Wiki-System erfordert folgende Schritte:
      • Übertragung der Backup-Datei auf das Zielsystem
      • Falls der Inhalt eines Schemas überschrieben werden soll, muss man dass Schema vorher löschen.
      • Erzeugt man durch Restore ein neues Schema, so muss man anschließend in der Datei LocalSettings.php unter $wgDBname den neuen Schemen-Namen eintragen. Außerdem muss der unter $wgDBuser eingetragene wikiuser mittels des MySQL-Administrators die erforderlichen Privilegien für das neue Schema erhalten: (SELECT, INSERT, UPDATE, DELETE, CREATE_TMP_TABLE)
      • Danach sollten die Seiten auf dem neuen Wiki-System verfügbar sein. Allerdings fehlen noch die Bilder!


Sichern und Portieren der Bilder

Restore der Datenbank auf einem anderen Wiki-System ermöglicht nur die Wiederherstellung der verlinkten Texte. Es fehlen darin aber alle Bilder.

Der Ordner /images muss deshalb zusätzlich zum Backup der Datenbank regelmäßig gesichert werden:

  • dafür ist in die crontab des root-Nutzers ein copy-Befehl zu ergänzen, welcher kurz z.B. 10 Minute nach dem Datenbank-Backup aktiviert wird. Im Beispiel läuft das Datenbank-Backup um 05:05 Uhr, demzufolge wird das Kopieren der Bilder um 05:15 Uhr veranlasst.
  • Die gesamte Ordnerstruktur von /images soll als Ordner /backup/images_datum gesichert werden.
  • Da Bilder kaum komprimiert werden können, wird auf ein Verpacken in ein Archiv verzichtet.
  • Als root-Nutzer erstellt man eine Textdatei "/bin/wiki-images-backup.sh" als ausführbare Script-Datei:
#!/bin/bash
DATUM=$(date +'%Y%m%d');
rsync -r /srv/www/htdocs/mediawiki/images /backup/images_$DATUM
  • Die crontab von root ist die Datei /var/spool/cron/tabs/root
  • Dort ergänzt man vor den Zeilen:
#MySQL Administrator Backup [optiyummy] (do not change this line)
5 5 * * * /usr/bin/mabackup -d /backup -c MySqlAdmin optiyummy
  • den Aufruf des wiki-images-backup:
15 5 * * * /bin/wiki-images-backup.sh
  • Das Einfügen vor dem MySQL-Backup erfolgt in der Hoffnung, dass man damit den MySQL Admin am wenigsten beim Update dieser Anweisung stört!

Achtung: Möchte man den Inhalt von OptiYummy auf einem neuen Wiki-System wieder zum Leben erwecken, so darf dieses Wiki-System nicht die Verzeichnisstruktur "/a/ab/foo.png" für Bilder verwenden. In LocalSettings.php muss dort also folgende Anweisung wirken: 

$wgHashedUploadDirectory = false;

Backup der Inhalte auf externes Medium

Datenbank-Inhalt und Bilder werden nach dem beschriebenem Verfahren nur auf der lokalen Systemplatte gesichert. Dort nützen sie aber nichts bei einem Crash dieser Festplatte. Deshalb ist mit der gleichen Sicherungsfrequenz ein Abzug auf ein externes Medium erforderlich.

Im Beispiel existiert ein Windows 2000 Server, der mit dem Backup-System des Universitätsrechenzentrum verbunden ist. Damit werden automatisch und regelmäßig die Datenzustände gesichert.

Auf dem OpenSUSE-System läuft ein SSH-Server. Damit kann man z.B. von jedem Windows-System aus mittels PSCP.EXE Dateien herunterladen. Im Beispiel werden die aktuellen Datenbank- und Bilder-Backups auf den Windows 2000 Server kopiert. Von dort erfolgt dann das Versions-Backup in das Rechenzentrum. Nach menschlichen Ermessen müsste damit nach einem Crash ein nutzbarer Datenbestand existieren.

Die benötigte pscp.exe findet man als Freeware auf der PUTTY Download Page [2]

Für die Anmeldung des PSCP-Tools vom Windows-PC aus sollte im OpenSUSE ein separater Nutzer mit einem sicheren Passwort eingerichtet werden (im weiteren Backup-Nutzer genannt). Das erledigt man im Yast-Kontrollzentrum.

Einrichten des SFTP-Zugangs für PSCP zum OpenSUSE von Windows aus:

  • PSCP benötigt den Key des OpenSUSE auf dem Windows-PC.
  • Deshalb muss man einmalig eine SFTP-Verbindung vom Windows-PC zum OpenSUSE-System herstellen. Hierfür sollte man den zuvor eingerichteten Backup-Nutzer verwenden.
  • Dazu benutzt man die SFTP-Verbindung des Programms PUTTY.EXE.
  • Dabei wird der Fingerprint des OpenSUSE-Servers im Windowssystem gespeichert und steht dann auch für PSCP.EXE zur Verfügung.

Dieser Backup-Nutzer soll täglich vom Windows-PC aus die aktuelle Datenbank-Backupdatei und den aktuellen images-Ordner per PSCP-Tool vom OpenSUSE-System abholen. Das vorbereitende Datei-Handling auf dem OpenSUSE-System wird durch eine Erweiterung des bereits genutzten Scripts "/bin/wiki-images-backup.sh" vorgenommen:

  • Leider hat ein normaler Nutzer keine Leserechte auf die automatisch generierten Backup-Dateien der Datenbank. Damit diese Dateien nach ihrer Erzeugung die richtigen Zugriffrechte besitzen, wird der chmod-Befehl benutzt.
  • Von den täglichen Versionen der Datenbank-Datei und des Bilder-Ordners wird jeweils mit rsync-Befehl eine Kopie mit konstantem Namen erzeugt. Nur diese aktuellen Kopien werden vom PSCP-Tool dann abgeholt.
  • Die Script-Datei "/bin/wiki-images-backup.sh" hat nun folgenden Inhalt:
#!/bin/bash
# aktuelles Datumm im Format yyyymmtt
DATUM=$(date +'%Y%m%d');
# In neuem Ordner images_yyyymmtt wird der MediaWiki-Ordner images abgelegt
rsync -r /srv/www/htdocs/mediawiki/images /backup/images_$DATUM
# Loeschen der letzten images-Exportkopie
rm -r /backup/images
# Erzeugen der aktuellen images-Exportkopie
rsync -r /backup/images_$DATUM/ /backup/
# Leserechte für alle Datenbank-Dateien
chmod 775 /backup/*.sql
# Erzeugen der aktuellen Datenbank-Exportkopie
cp -f /backup/optiyummy_$DATUM'_0505'.sql /backup/optiyummy.sql

Installation eines PSCP-Task im Windows-Taskplaner:

  • PSCP.EXE muss nicht installiert werden:
    • Anlegen eines Ordners c:\programme\pscp\
    • Kopieren von pscp.exe in diesen Ordner
  • OptiYummy-PSCP.BAT als Script für das OptiYummy-Backup im gleichen Ordner erzeugen:
time /T > C:\Programme\PSCP\OptiYummy.LOG
C:\Programme\PSCP\pscp.exe -batch -r -p -q -v -pw PASSWORD BACKUP-USER@141.30.123.3:/backup/optiyummy.sql E:\optiyummy.dat >> C:\Programme\PSCP\OptiYummy.LOG
xcopy E:\optiyummy.dat\images E:\optiyummy.dat\images.bak /E/Y/I/Q
RMDIR /S/Q E:\optiyummy.dat\images
C:\Programme\PSCP\pscp.exe -batch -r -p -q -v -pw PASSWORD BACKUP-USER@141.30.123.3:/backup/images E:\optiyummy.dat >> C:\Programme\PSCP\OptiYummy.LOG
time /T >> C:\Programme\PSCP\OptiYummy.LOG
  • Dieses Script erzeugt eine LOG-Datei OptiYummy.LOG mit Start- und End-Zeit. Bei Bedarf können zur Fehlersuche die Aktionen des PSCP-Programms dort hinein geschrieben werden, wenn man den quit-Modus entfernt.
  • Der Ordner E:\optiyummy.dat muss vor der Nutzung des Scripts manuell angelegt werden.
  • Vom letzten image-Ordner wird durch das Script jeweils eine Backup-Kopie erzeugt.
  • PASSWORD und BACKUP-USER stehen für die "geheimen" Zugangsdaten.


  • Windows-Taskplaner um OptiYummy-Backup erweitern:
    • Der Aufruf des Taskplaners erfolgt am einfachsten über "Startmenü-Hilfe" Suchen nach "Taskplaner" und dort Auswahl "Planen eines neuen Task".
    • Dort steht detailliert, wie man eine neue Task hinzufügt.
    • Man wählt im Beispiel c:\programme\pscp\OptiYummy-PSCP.BAT
    • Dieses Script soll täglich ca. 15 Minuten nach den Update-Prozessen des OpenSUSE-Systems gestartet werden (z.B. 5:30 Uhr).
    • Die Task sollte mit Administrator-Rechten laufen, dazu das Passwort mit eingeben.
    • Unter den erweiterten Eigenschaften (Einstellungen) entfernt man das Häkchen für "Task beenden nach 72 Stunden".


Nun landet zumindest täglich die aktuelle Version der Inhalte auf dem Windoow-PC:

  • Das ist nur sinnvoll, wenn im Hintergrund ein Versions-Backup über größere Zeiträume z.B. zum Rechenzentrum läuft.
  • Sonst kann es passieren, dass sich in der aktuellen Version nur Müll befindet, wenn z.B. die Datenbankstruktur des Wiki-Systems aus unverhersehbaren Gründen unbemerkt zerstört wurde. Dann kann man aus dem zentralen Backup-System immer noch ältere Versionen reproduzieren.


In der Hoffnung, dass die ganzen Backup-Maßnahmen nie gebraucht werden, kann man sich nun einigermaßen beruhigt zurücklehnen.

Bereinigen der Festplatte

Durch den beschriebenen Backup-Mechanismen werden jeden Tag eine SQL-Datei und ein Bilder-Ordner auf der Festplatte abgelegt:

  • In ungefähr monatlichen Abständen sollte man bis auf die Versionen der letzten Tage alle älteren Backup-Daten löschen.
  • Damit landen diese Dateien im Papierkorb.
  • Leider wird der Papierkorb damit immer umfangreicher und irgendwann ist die Platte voll! Man sollte deshalb den Papierkorb vor dem monatlichen Löschen leeren. Dann befinden sich nur die zuletzt gelöschten Dateien im Papierkorb.

Achtung:

Läuft die Platte voll, weil man die Festplatte nicht ordentlich bereinigt hat, so kann man sich im schlimmsten Fall nicht mehr im System anmelden (weder über das Wiki-System noch als normaler Nutzer). Auch funktionieren wegen fehlenden Platzes die Sicherheitsupdates des Systems nicht mehr.

Abgerufen von „http:///index.php?title=OptiYummy-System_3&oldid=6884“