ls -a /home/andwil
(Komplettes Archiv)
Ab und an schreibe ich als @sumpfsuppe bei Twitter und Identi.ca.
(Zeige alle Links)
Gezeigt werden nur Blog-Artikel, die mit dem Schlagwort webhosting versehen sind. Wenn du alle Blog-Artikel lesen möchtest, wechsle direkt in die Sektion Blog.
Verfasst am 5. November 2010, früh morgens.
Gestern war urplötzlich eine meiner MySQL-Datenbanken „verschwunden“. Höchst ärgerlich, deshalb wendete ich mich gleich an den Support meines Hosters.
Dieser erkannte, dass das Problem mit dem Namen der Datenbank zusammenhing und meinte:
Sie hätten gar keine Datenbank mit diesem Namen erstellen können sollen. Ich werde den Inhalt der genannten Datenbank unter einem anderen Datenbank-Namen für Sie verfügbar machen […]
Der Grund für das Problem war schnell gefunden: Durch einen Bug wurden falsche Datenbanknamen erzeugt. Dieser Fehler wurde behoben und dabei meine Datenbank versehentlich ins Nirwana befördert.
Ärgerlich, aber der Support reagierte prompt auf meine Anfrage und löste das Problem schnell und unkompliziert.
Außerdem:
kommentieren |
weitersagen
Verfasst am 27. März 2010, abends.
Im folgenden erkläre ich, wie Kunden von Webhostern bequem die Daten ihrer Internetseiten sichern können.
Dass sich rsync hervorragend für zeit- und übertragungsdaten-sparende Backup-Lösungen eignet, erzählte ich bereits in einem umfangreicheren Artikel. Es wäre doch auch toll, diese Technik für den FTP-Server zu benutzen! Leider kann rsync ohne Weiteres nicht auf FTP-Server zugreifen. Wie es trotzdem funktioniert, lernte ich dort. Auch als Gedächtnisstütze für mich, werde ich hier erläutern, wie es gemacht wird:
Zunächst benötigen wir das Programm curlftpfs, das in den Repositorien der meisten Distributionen unter selbem Namen vorliegen sollte. Mit diesem Werkzeug kann man FTP-Server fast genau wie beliebige Laufwerke in das heimische Dateisystem einbinden.
Um den ganzen Vorgang ein wenig zu beschleunigen, bietet sich ein kleines Skript an, das in etwa so aussehen könnte und bereits einen beispielhaften rsync-Befehl enthält:
#!/bin/bash# „mounte“ den FTP-Server unter /media/ftp. Dieses # Verzeichnis vorher ggf. mit „sudo mkdir /media/ftp“ # erstellen!curlftpfs ftp.meinbeispielhoster.de /media/ftp# Jetzt die Sicherung mit rsync vornehmen. Folgende # Parameter werden verwendet: # # --delete-after: Alte Backup-Dateien werden nach der # Übertragung gelöscht. # -r: sichere auch Unterverzeichnisse # -P: Gibt eine Fortschrittsanzeige aus # --exclude-from: Verweise auf eine Text-Datei, in # der vom Backup auszuschließende # Dateien und Ordner vermerkt sindrsync -rP --delete-after --exclude-from=$HOME/rsync_exclude.txt /media/ftp $HOME/Webseiten-Backups# Einbindung des FTP-Servers wieder lösenfusermount -u /media/ftp
Weitere Erläuterungen:
Dein FTP-Server ist vermutlich passwortgeschützt. Du kannst die Zugangsdaten entweder direkt in den Befehl einbauen (curlftpfs benutzername:passwort@ftp.meinbeispielhoster.de /media/ftp) oder in der Datei ~/.netrc ablegen. Die Datei muss nach diesem Schema aufgebaut sein:
machine ftp.meinbeispielhoster.de login MeinBenutzername password MeinPasswort
Die im Skript genannte Exclude-Datei ist natürlich optional. Ich verwende sie, um bspw. temporäre Dateien und Log-Files nicht zu sichern. Dateien und Ordner mit rsync auszuschließen, ist ein wenig ungewohnt. Die genannte rsync_exclude.txt könnte etwa so aussehen:
# Ich gehe von der folgenden beispielhaften Ordner- # Struktur aus: # # . # |-- meineseite # | |-- piwik # | | `-- tmp # | | # | `-- textpattern # | `-- tmp # | # `-- logs # # Es können alle tmp-Verzeichnisse ignoriert werden. # Außerdem möchte ich den Ordner „logs“ im # Stammverzeichnis aus dem Backup ausschließen. # So könnte man dies bewerkstelligen:- **/tmp - logs
Wie gezeigt müssen alle Pfade relativ sein. Die Benutzung von „Wildcards“ (*) ist dabei erlaubt. Genauere Details zu den sogenannten Exclude-Patterns finden sich in der Manpage von rsync (siehe unter „INCLUDE/EXCLUDE PATTERN RULES“). Das Ganze sieht komplizierter aus, als es ist. Notfalls versucht man eben per Versuch und Irrtum die richtige Ausschlussregel zu formulieren oder verzichtet komplett darauf.
Und damit haben wir auch schon alles, was wir für ein schlankes Backup brauchen. Wer will, kann aus dem Skript natürlich einen Cronjob machen und es auf diese Weise bspw. täglich oder wöchentlich automatisch ausführen lassen.
Noch ein wenig Lektüre zum Thema:
rsyncBetreiber von Blogs, Gästebüchern, Foren, etc. pp., möchten vielleicht auch den Inhalt ihrer MySQL-Datenbank bequem sichern. Über dieses Thema habe ich mich auch schon ausgelassen.
Außerdem:
kommentieren |
weitersagen
Verfasst am 26. Februar 2010, früh abends.
Kürzlich zeigte ich, wie man bequem an tägliche MySQL-Backups kommt. Dafür verwendete ich einen Cronjob, der auf dem heimischen System lief. Doch nicht jeder Webhoster erlaubt es Kunden (oder auch Hackern) von „zuhause aus“ auf seinen Datenbank-Server zuzugreifen – so auch meiner seit einigen Tagen.
Dafür bieten viele Hoster jedoch ihren Kunden ebenfalls Cronjobs auf ihren Servern an. In meinem Fall ist ein Cronjob, der alle 24 Stunden ausgeführt wird und den Prozessor maximal eine eine Minute lang foltert, sogar kostenlos und Bash-Skripte sind neben PHP auch erlaubt.
Unseren alten Bash-Zweizeiler kann man mit minimalen Änderungen per FTP hochladen. So könnte er aussehen:
#!/bin/bash
mysqldump -hdatenbank.meinhoster.example -ubenutzername-pgeheimespasswort -C --all-databases > MeineDatenbank.sql
Wichtiger Hinweis: Achte unbedingt darauf, dieses Skript an eine Stelle hochzuladen, an die niemand ohne Passwort per http kommen kann! Damit meine ich: Wenn jemand einfach über http://www.meineseite.de/mysqlsicherung.sh o.ä. an das Skript kommt (in dem deine Datenbank-Zugangsdaten im Klartext stehen) ist Holland in Not!
Die Bash-Datei muss man jetzt noch im Administrations-Backend bei seinem Hoster als Cronjob einrichten. Daraufhin wird bspw. alle 24 Stunden eine Datei MeineDatenbank.sql erzeugt (die alte Datei wird jeweils überschrieben).
Jetzt müssen wir das Backup nur noch nachhause holen. Linux-Nutzer erledigen das wieder ganz bequem mit einem Skript, das auf dem heimischen Rechner z.B. unter /etc/cron.daily/ abgespeichert ist. Dort wird es täglich automatisch ausgeführt und lädt z.B. per wget den tagesaktuellen Datenbank-Dump herunter. Hier ein primitives Beispiel:
#!/bin/bashcd /home/benutzername/Backups/Datenbank wget ftp://benutzername:passwort@ftp.meinhoster.de/MeineDatenbank.sql mv MeineDatenbank.sql `date +"%Y-%m-%d"`.sql
Nicht elegant, aber zur Veranschaulichung genügt es. Der Dump wird im Ordner Backups/Datenbank abgelegt und nach Datum umbenannt. Heute würde zum Beispiel die Datei Backups/Datenbank/2010-02-26.sql angelegt.
Beachte, dass die Code-Beispiele bewusst simpel gehalten sind und in Sachen Sicherheit eine mittelschwere Katastrophe auslösen können. Ich möchte nur die Möglichkeit dieser Vorgehensweise erläutern und Raum für deine eigene Ideen und Optimierungen lassen (Rückmeldungen willkommen!). Denkbar wäre z.B. die Möglichkeit, den Webmaster per E-Mail über fehlgeschlagene Backups zu informieren.
Ein weiterer Punkt, an den man ansetzen kann: Die gezeigte Backup-Lösung ist für die Katz, wenn dein Rechner nicht wenigstens alle paar Tage läuft, um sich das neue Backup herunterzuladen.
Es sei außerdem daran gedacht, dass ein Hacker, der sich Zugriff auf deinen FTP-Server verschafft hat, jetzt auch an deine Datenbank-Zugangsdaten kommen kann. Das Sicherheitsprinzip, für FTP und Datenbank verschiedene Passwörter zu verwenden, ist damit ausgehebelt.
Wohl also denen, die sich lieber einen Server mieten und damit volle Kontrolle und nahezu unbegrenzte Möglichkeiten für ihre Backup-Konzepte haben (doch mit großer Macht kommt auch große Verantwortung; außerdem passt gemieteter Webspace deutlich besser ins Budget eines Studenten ;-)).
Außerdem:
kommentieren |
weitersagen