OptiYummy-System 3: Unterschied zwischen den Versionen

Aus OptiYummy
Zur Navigation springenZur Suche springen
K (Die Seite wurde neu angelegt: '''Siehe auch:''' "Installation des Basis-Systems" / "Wiki-System individuell konfigurieren" == System- und Datensicherung ...)
 
KKeine Bearbeitungszusammenfassung
Zeile 11: Zeile 11:




=== Abzug der Systemplatte ===
== 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 Zielfestplatte (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.
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 Zielfestplatte (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.
Zeile 38: Zeile 38:




=== Backup der Datenbank ===
== Backup der Datenbank ==


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

Version vom 17. März 2008, 11:37 Uhr

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 aktuellen Inhalten 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 Zielfestplatte (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 ist dafür die Knoppix Live-Distribution [1], welche als DVD z.B. regelmäßig als Beilage 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:

  • Insgesamt kommen für die Sicherung des Systems im Beispiel zur Zeit drei identische Festplatten zum Einsatz. Man sollte jeder 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 erhlten.
  • 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 versehen und räumlich getrennt vom Wiki-System sicher aufbewahren.
    • Die 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. 1 Minute nach dem Datenbank-Backup aktiviert wird.
  • 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 6 * * * /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;