Webseitenbetreiber, Inhaber und deren Admins sind letztlich in gleicher Weise betroffen von diesem Thema – Backups. Wie wichtig diese wirklich sind, muss an dieser Stelle wohl nicht mehr diskutiert werden. Sie sind einfach wichtig. Egal ob nun „nur“ die Dateien, aus denen eine Webseite besteht, gesichert werden, oder die Datenbank. In einem Backup sollten immer alle Daten enthalten sein. Ein solches Backup ist natürlich einfacher, wenn man direkten Zugriff auf den Server hat und nicht nur per FTP, wie bei einem reinen Webhoster. Dieser Artikel setzt demnach diesen Direktzugriff via SSH voraus und auch die Möglichkeit Cronjobs einzurichten.
Bevor man eine Webseite online stellt, ist es natürlich wichtig, sich Gedanken über die grundlegende Verzeichnisstruktur zu machen. Denn je übersichtlicher diese gehalten ist, desto einfacher ist das Backup.
Einige Grundideen:
Das Verzeichnis des Seitenbetreibers liegt beispielsweise unter:
/var/customers/webs/seitenbetreiber
Somit ist eine strukturelle Aufteilung der Webseiten des Seitenbetreibers sehr einfach möglich. Webseite A liegt nun zum Beispiel unter /var/customers/webs/seitenbetreiber/webseite-a und Webseite B unter /var/customers/webs/seitenbetreiber/webseite-b und so weiter und so fort. Das Backupverzeichnis ist demnach unter /var/customers/webs/seitenbetreiber/backups.
Daraus ergibt sich also folgende Struktur auf dem Server, wird das Verzeichnis des Seitenbetreibers aufgelistet.
1 2 3 4 5 6 7 | server seitenbetreiber # ll insgesamt 16K -rwxr-xr-x 1 root root 1,2K 4. Nov 18:29 backup-webseite-a.sh -rwxr-xr-x 1 root root 1,2K 4. Nov 18:29 backup-webseite-b.sh drwxr-xr-x 3 root root 4,0K 4. Nov 02:06 backups drwxrwxr-x 4 10001 10001 4,0K 4. Nov 18:29 webseite-a drwxrwxr-x 2 10001 10001 4,0K 4. Nov 00:00 webseite-b |
Wie hier zu sehen ist, liegen auch in diesem Verzeichnis die Backupscripte für die einzelnen Webseiten. Ich persönlich bevorzuge es, die Seiten einzeln zu „verarbeiten“ da sie sich so auch separierter wieder herstellen lassen, wenn zum Beispiel ein Datenverlust nur eine Seite betrifft.
Das Backupscript
Dieses ist ein reines Bash-Script welches letztlich als Cronjob ausgeführt wird. Also nach einem festgelegten Zeitplan. Zur Übersicht wird durch das Script im Backupverzeichnis wieder eine eigene Verzeichnisstruktur erstellt, welche dem Schema backups/webseite/Jahr-Monat folgt. Also backups/webseite-a/2010-11 als Beispiel. Auch wird in diesem Script gleich die Datenbank der Seite mit berücksichtigt und dem Backuparchiv als mySQL-Dump hinzugefügt.
Hierfür müssen im Script zunächst einige Variablen definiert werden.
1 2 3 4 5 6 7 8 9 10 11 12 13 | # setting variables DATE=`/bin/date '+%Y-%m-%d'` MONTH=`/bin/date '+%Y-%m'` CUSTOMER_DIR="/var/customers/webs/seitenbetreiber/" SOURCE_DIR="webseite/" BACKUP_DIR="backups/webseite" MYSQLDUMP_FILENAME="webseite-backup-datenbank.sql" BACKUP_FILENAME="webseite-backup-filesystem.tar.gz" DB_NAME="" DB_USER="" DB_PASSWORD="" DB_HOST="localhost" |
Diese variablen werden im Laufe des Scriptes benötigt, damit man nicht immer alle Pfadangaben hinschreiben muss. Da dieses Script durch einen Cronjob gestartet wird, muss man natürlich sicher gehen, dass es auch im richtigen Ordner ausgeführt wird.
1 | cd $CUSTOMER_DIR |
Damit werden alle im Script folgenden Operationen im CUSTOMER_DIR ausgeführt.
Als nächstes folgt die Datenbank. Dazu wird ein mySQL-Dump erstellt. Im gleichen Atemzug wird sicher gestellt, dass der Dump auch im UTF-8 Format ist und die Daten bei der Wiederherstellung ebenfalls als UTF-8 in die Datenbank geschrieben werden.
1 2 | # dumping mysql and storing dump in $SOURCE_DIR /usr/bin/mysqldump --opt -Q -u$DB_USER -p$DB_PASSWORD -h$DB_HOST $DB_NAME | sed s'/DEFAULT CHARSET=.*;/DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;/g' > $SOURCE_DIR$DATE-$MYSQLDUMP_FILENAME |
Dar Dump der Datenbank wird hierbei direkt im Verzeichnis der Webseite abgelegt und ist somit im Backup enthalten. Nun können die Dateien zu einem Archiv zusammen gefasst und im Backupordner gespeichert werden.
1 2 3 4 5 6 7 | # tar $SOURCEDIR if [ ! -d "${BACKUP_DIR}/${MONTH}/" ]; then mkdir $BACKUP_DIR/$MONTH/ fi /bin/tar -cpzf $BACKUP_DIR/$MONTH/$DATE-$BACKUP_FILENAME $SOURCE_DIR |
Somit liegt nun eine .tar-gz-Datei im dafür vorgesehenen Ordner. Versehen mit Datum und allem was dazu gehört.
Im nächsten Schritt wird der mySQL-Dump, welcher ja immer noch im Verzeichnis der Webseite liegt, wieder gelöscht, denn der soll ja nicht einfach da, er wäre ja momentan downloadbar.
1 2 | # removing mysql-dump from $SOURCE_DIR rm -f $SOURCE_DIR$DATE-$MYSQLDUMP_FILENAME |
Damit wäre das Script eigentlich schon fertig. Doch, was ist mit der Bereinigung von „Altlasten“? Also was ist mit den alten Backups? Natürlich können Backups, wenn man sie nicht mehr braucht gelöscht werden. So ist es zum Beispiel, wenn dieses Script täglich ausgeführt wird, nicht notwendig mehr als 3 Tage zu speichern. Also kann alles was älter ist doch gelöscht werden. Dateileichen auf einem Server mag man doch sowieso nicht. Auch eventuelle leere Verzeichnisse, die durch das Löschen der Dateien entstehen können entsorgt werden.
1 2 3 4 5 6 7 8 9 10 11 | # deleting backups older than 3 days if [ "$(find $BACKUP_DIR/ -type f -mtime +2)" ]; then find $BACKUP_DIR/ -type f -mtime +2 | xargs rm fi # removing empty directorys if [ "$(find backups/ -type d -empty)" ]; then find $BACKUP_DIR/ -type d -empty | xargs rm -r fi |
Damit sind nun auch sämtliche Dateileichen entfernt.
Der Cronjob
Damit das Script auch wirklich dann zeitgesteuert ausgeführt wird, empfiehlt es sich, dies über einen Cronjob erledigen zu lassen. In diesem Beispiel wird das Script täglich um 1:30 Uhr nachts ausgeführt.
Der Aufruf um Cronjobs bearbeiten zu können ist
1 | crontab -e |
Danach gibt man nur noch die „Zeitsteuerung“ und das auszuführende Script an
1 2 | ######## File Backup ######## 30 1 * * * sh /var/customers/webs/seitenbetreiber/backup-webseite.sh # Backup täglich um 1:30 nachts |
Nachdem das nun abgespeichert wurde, muss man eigentlich nur noch bis 1:30 Uhr in der Nacht warten und kann den Erfolg begutachten.
Das komplette Script
Wem es nun zu mühsam ist, sich die Teile des Scriptes hier einzeln zusammenzubauen, hier das gesamte Script.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | #!/bin/bash # setting variables DATE=`/bin/date '+%Y-%m-%d'` MONTH=`/bin/date '+%Y-%m'` CUSTOMER_DIR="/var/customers/webs/seitenbetreiber/" SOURCE_DIR="webseite/" BACKUP_DIR="backups/webseite" MYSQLDUMP_FILENAME="webseite-backup-datenbank.sql" BACKUP_FILENAME="webseite-backup-filesystem.tar.gz" DB_NAME="Name der Datenbank" DB_USER="Datenbanknutzer" DB_PASSWORD="Passwort" DB_HOST="localhost" # starting backup cd $CUSTOMER_DIR # dumping mysql and storing dump in $SOURCE_DIR /usr/bin/mysqldump --opt -Q -u$DB_USER -p$DB_PASSWORD -h$DB_HOST $DB_NAME | sed s'/DEFAULT CHARSET=.*;/DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;/g' > $SOURCE_DIR$DATE-$MYSQLDUMP_FILENAME # tar $SOURCEDIR if [ ! -d "${BACKUP_DIR}/${MONTH}/" ]; then mkdir $BACKUP_DIR/$MONTH/ fi /bin/tar -cpzf $BACKUP_DIR/$MONTH/$DATE-$BACKUP_FILENAME $SOURCE_DIR # removing mysql-dump from $SOURCE_DIR rm -f $SOURCE_DIR$DATE-$MYSQLDUMP_FILENAME # deleting backups older than 3 days if [ "$(find $BACKUP_DIR/ -type f -mtime +2)" ]; then find $BACKUP_DIR/ -type f -mtime +2 | xargs rm fi # removing empty directorys if [ "$(find backups/ -type d -empty)" ]; then find $BACKUP_DIR/ -type d -empty | xargs rm -r fi |
Es sei hier noch gesagt, das dieses Script immer nur die in den Variablen angegebene Webseite sichert. Will man mehrere Webseiten sichern, so erstellt einfach mehrere Scripte und passt die entsprechenden Variablen an. Natürlich sind auch die Variablen für die Datenbank noch anzupassen :-)
Warum ich das so mache, habe ich eingangs ja schon erläutert. Ich finde es so einfach komfortabler.
Update
09. November 2010
Kleinen Syntaxfehler in der Abfrage der alten Dateien und leeren Verzeichnisse behoben.
