Elmars Notizen

Im letzten Artikel beschrieb ich, wie ich meine MySQL-Datenbanken sichere mit dem Programm mysqldump. Für jede Sicherung gilt das Prinzip: Prüfe, ob die Sicherung in Ordnung ist!

Für MySQL-Datenbanken bedeutet das: Schreibe das Backup in eine andere MySQL-Datenbank und prüfe, ob der Inhalt in Ordnung ist. Einsgepielt wird eine mysqldump-Sicherung mit folgendem Befehl:

cat datenbank-Fri.sql.gz | gzip -d | mysql andere_datenbank

Im Beispiel schreibt das Programm mysql den Inhalt der Datenbank datenbank-Fri.sql.gz in die Datenbank andere_datenbank . datenbank-Fri.sql.gz wurde geschrieben von mysqldump und komprimiert mit gzip,

Bislang prüfte ich einmalig für eine Datenbank per Durchsicht: Ich konfigurierte beispielsweise das Weblog so, dass es die andere Datenbank benutzte. Anschließend rief ich ein paar Seiten auf und klickte auf ein paar Links. Wollte ich den Inhalt genau prüfen, würde ich ein Tool suchen oder schreiben, das die Tabellen und Inhalte zweier Datenbanken automatisch vergleicht und bei Abweichungen mich per E-Mail informiert.

Ob eine aufgespielte Sicherung nach Umzug auf einen anderen Webserver sofort funktioniert, hängt ab davon, wie das Weblog, Content Management-System oder Wiki URLs behandeln. WordPress beispielsweise schreibt in die Tabelle options den URL des Blogs in die Spalte option_value in die Zeilen, für die die Spalte option_name die Werte siteurl und home enthält. Dieser sollte überprüft und gegebenenfalls geändert werden. Das gleiche gilt für die Option upload_url_path.

Etliche Weblogs, Wikis und Content Management-Systeme speichern den Inhalt - alles was ich schreibe - in MySQL-Datenbanken. MySQL-Datenbanken sind Dateien auf der Festplatte eines Webservers, diesen besitzt ein Internet-Dienstleister.

Spätestens nach einem Wechsel des Webservers will ich den Inhalt der alten Datenbanken einfügen in neue MySQL-Datenbanken mit wenig Aufwand.

Dazu sichere ich die Datenbanken des Webservers auf meinen lokalen Rechner. Weitere Gründe für die lokale Sicherung:

1. Die Datenbank könnte beschädigt werden und nicht mehr (vollständig) wiederhergestellt
2. Cracker und Schadsoftware könnten die Datenbank verändern
3. Der Internet-Dienstleister könnte seinen Dienst einstellen ohne dass ich vorher meine Daten auf irgend eine Weise retten kann

In einem Artikel über die Prinzipien der Datensicherung schrieb ich, Backups sollen automatisch ablaufen. Bei mir sieht das so aus:

1. Einmal täglich sichert auf dem Webserver das Programm mysqldump meine MySQL-Datenbanken mit den kompletten Einfügebefehlen
2. Nach einer Woche wird die älteste Sicherung überschrieben, es existieren bis zu 7 Sicherungen, eine für jeden Wochentag
3. Auf meinem lokalen Rechner ruft Cron täglich (automatisch) ein Skript auf; dieses veranlasst auf dem Webserver SQL-Dumps (1.) und speichert die SQL-Dumps auf die lokale Festplatte
4. Inhalte, die das Weblog, Wiki, Content Management-System nur auf die Webserver-Festplatte speichern und nicht in die Datenbank, werden heruntergeladen und auf die lokale Festplatte gespeichert, sofern noch nicht geschehen oder diese auf dem Webserver modifiziert wurden
5. Die Daten der lokalen Festplatte werden täglich auf eine externe Festplatte gesichert, die nur während der Sicherung eingeschaltet ist; wäre Geld kein Thema, würde ich die lokale Festplatte auf ein LTO 4-Streamerband sichern lassen

Der Webserver muss folgende Programme anbieten und auf irgend eine Weise ausführen lassen:

• mysqldump
• gzip, die Komprimierung von mysqldump könnte nicht funktionieren
• mail

Dies berücksichtige ich bei der Auswahl eines Webservers.

Besser ist ein Webserver, bei dem ich zeitgesteuert Programme ausführen lassen kann, es reicht aber einer, der CGI-Skripte erlaubt, unter anderem Bash-Skripte, die sich für diese Aufgabe eignen.

Für den SQL-Dump schrieb ich zwei Bash-Skripte: Eines, das die Datenbank sichert und bei Fehlern eine E-Mail schickt und ein anderes, das für alle Datenbanken dieses Skript aufruft. Sie können beide herunterladen:

1. Skript, das eine Datenbank sichert
2. Skript, das für alle Datenbanken Skript 1 aufruft

Aus den Skripten löschte ich: Skript 1 verlangt ein Passwort, wird keines oder ein falsches überreicht, unternimmt es nichts und Skript 2 ruft Skript 1 mit einem Passwort auf.

Das Skript, das cron täglich aufruft auf meinem lokalen Rechner, ruft das CGI-Skript 2 auf mit dem Webbrowser lynx und dem Parameter --dump. Lynx zeigt die Skriptausgabe an und beendet sich, die Ausgabe wird umgeleitet in eine Logdatei.

Die Dateien, die im Dateisystem der Webserver-Festplatte gespeichert sind - die WordPress-, MediaWiki-, … -Installationsverzeichnisse - sowie die mysqldump-Backupdateien spiegelt das Perl-Skript mirror auf meine lokale Rechnerfestplatte (täglich aufgerufen durch cron). Es gibt weitere Programme, die Dateien eines Webservers spiegeln können, spontan fallen mir diese ein: wget und ncftp.

Ein Prinzip beim Schreiben von Computerprogrammen lautet: Don’t repeat Yourself, als Akronym: DRY. Bei guten Programmen gilt dieses Prinzip auch für die Bedienung: Der Benutzer soll nicht wieder und wieder die gleichen stupiden Schritte unternehmen zum Erledigen einer Aufgabe.

Adobe Photoshop Lightroom berücksichtigt das bei vielen Aufgaben, als Beispiel beschreibe ich kurz das Ausdrucken von Bildern. Früher benutzte ich dafür Photoshop (die Bildbearbeitung, nicht Lightroom), was mich nach jedem Neustart oder Wechseln der Papiersorte viel (unnötige) Arbeit kostete:

• Druckertreiber einstellen: Treiber-Dialog aufrufen, dort mehrere Mausklicks
• Überprüfen, ob das Farbmanagement in Photoshop richtig eingestellt ist (Übernahme dieses, ICC-Profil, Rendering Intents - siehe Artikel Farben umrechnen zwischen Farbräumen), korrigieren, wenn nicht
• Größe des Ausdrucks einstellen (Druckauflösung und damit Bildskalierung)
• Bild für den Ausdruck schärfen anhand der Druckauflösung

Im Treiberdialog lassen sich Einstellungen speichern. Dort (Treiber für Epson R2400) darf der Bezeichner nur etwa 12 Buchstaben enthalten, was zu kryptischen Namen führt und mir so nicht die Kontrolle aller Einstellungen erspart.

In Lightroom ist das so gelöst: Alle Einstellungen kann ich als Vorlage speichern unter einem mir bedeutungsvollen Namen:

• Sämtliche Druckertreiber-Einstellungen, insbesondere: Papiersorte, Papiergröße, Druckqualität, Farbmanagement deaktiviert
• Farbmanagement in Lightroom: ICC-Profil für den Ausdruck und Rendering Intents
• Auflösung für den Ausdruck (Skalierung des Bilds)
• Größe des Rands
• Größe der längsten Bildseite
• Schärfung

Ich wähle die Vorlage aus (bei Wechsel von Papiersorte und -Größe), das ist ein Mausklick und klicke der Reihe nach alle Bilder an, die ich ausdrucken will. Hoch- und Querformat werden automatisch ermittelt, ebenso die Größe der Bilder. Was noch fehlt, ist Softproofing - hoffentlich hat das die nächste Version von Lightroom.

Ausschnitt: Einige meiner Druckvorlagen in Lightroom.

Eine weitere schöne Eigenschaft von Lightroom: Die Bilder (Originale) werden für den Ausdruck nicht modifiziert. Wollte ich in Photoshop die Druckeinstellungen nicht verlieren, müsste ich für jede unterschiedliche Druckgröße eine extra Datei (-version/-variante) speichern (Schärfung und Druckauflösung).

Grob angepasst habe ich Inhalt (PHP-Dateien) und Aussehen (CSS) des Wordpress-Blogs. Es wird hier und da noch ein englischer Text aus den (Theme-) PHP-Dateien erscheinen, was ich nach und nach korrigiere, falls ich es bemerke oder jemand mich freundlicherweise darauf hinweist.