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


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:
5 15 * * * /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 Dateien herunterladen. Im Beispiel werden die 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.

Für die Anmeldung des PSCP-Tools sollte im OpenSuse ein separater Nutzer mit einem sicheren Passwort eingerichtet werden. Das erledigt man im Yast-Kontrollzentrum:

  • 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, soll dafür das Script "/bin/wiki-images-backup.sh" für das Kopieren der Bilddateien um eine Zeile erweitert werden:
chmod 775 /backup/*.sql


.... Die erforderliche Konfiguration wird noch beschrieben.

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