SMFPortal.de - Wiki
Start Forum Wiki Parser Übersetzungen

Datensicherung

Aus SMFPortal.de Wiki

Wechseln zu: Navigation, Suche

Für den Fall der Fälle sollte man sein SMF regelmäßig sichern. Das SMF speichert fast alle relevanten Informationen in der MySQL-Datenbank ab. Daher sollte zumindest die Datenbank in regelmäßigen Abständen gesichert werden. Folgende Daten werden nicht in der Datenbank abgespeichert und sollten daher ebenfalls in regelmäßigen Abständen gesichert werden:

  • Attachments (Datei-Anlagen)
  • Avatare (Benutzerbilder)


Inhaltsverzeichnis

Sicherung der Datenbank

Interne Funktion des SMF

Zur Sicherung der Datenbank bringt das SMF von Hause aus eine Funktion mit. Diese findet sich im Admin-Interface im Wartungsbereich unter Wartung des Forums 1).

ACHTUNG: Zu beachten ist hier allerdings, dass die SMF-interne Backup-Funktion nicht immer fehlerfrei arbeitet. Insbesondere bei größeren Foren kann sie zu Problemen führen. Es emfpiehlt sich eine Sicherung der Datenbank über die weiteren Sicherungsvarianten, die nachfolgend beschrieben werden.

Generell sollte man immer die Tabellentruktur 2) und die Tabellendaten 3) sichern weil die Wiederherstellung damit deutlich vereinfacht wird.

Durch Klick auf den Download-Button 4) werden alle in der Datenbank gespeicherten Daten in eine SQL-Datei geschrieben (und ggf. als ZIP), die dann auf den lokalen Computer runtergeladen wird.

Datensicherung smf.jpg

Sicherung mit phpMyAdmin

phpMyAdmini ist ein Werkzeug zur Administration von MySQL-Datenbanken. Dieses wird üblicherweise vom Provider zur Verfügung gestellt. Nach dem Einloggen in phpMyAdmin sollte die folgende Maske sichtbar sein:

Wichtige Hinweise zu Umlauten

Vor der Datensicherung mit phpMyAdmin sollte auf jeden Fall der Artikel Der richtige Zeichensatz‎ gelesen werden, da es unter Umständen zu Problemen mit Umlauten kommen kann falls man auf die Datensicherung zurückgreifen muss.

Zunächst wechselt man auf die Maske Export.

Phpmyadmin sicherung01.gif

Auf der nun folgenden Maske sollten zunächst die Tabellen ausgewählt werden. Hier einfach "Select All" auswählen 1). Sind alle Tabellen ausgewählt kann man ggf. den Kompatiblitätsmodus anpassen. 2) Diese Anpassung ist erforderlich, wenn man die Datenbank später auf einer älteren Version von MySQL importieren will. Andernfalls kann man die Option ignorieren.

Unter 3) wählt man nun die Struktur (Structure) aus. Das ist die Tabellen-Struktur (Namen der Tabellen, Felder und Indexe) Unter 4) kommen nun die wirklich wichtigen Daten (Data). Das sind die Inhalte der Tabellen (Beiträge, Mitglieder, Themen etc des Forums).

Phpmyadmin sicherung02.gif

zur Erklärung:

Complete Inserts: Es wird ein Dumpfile erzeugt bei dem für jedes INSERT auch die Feldnamen mit angegeben werden. Das erzeugt ein größeres Dumpfile.

Extended Inserts: Ist der Haken gesetzt wird das INSERT zu einem Befehl zusammengefasst, das erzeugte Dumpfile wird also kleiner.

Maximal Length of created query: Es kommt beim Rücksichern eines Backups mit Extended Insert häufig zu Problemen weil das Statement zu lang ist für den Server. Hier kann man Einstellen ab welcher Befehllänge ein neues Insert Statement begonnen wird, so kann man die Dateigröße kleiner halten UND trotzdem sicherstellen das es beim Restore keine Probleme gibt.

Eine generelle Empfehlung für oder gegen Complete/Extended Inserts kann man nicht geben, es kommt im einzelnen immer darauf an was man erreichen möchte. Das kleinste Dumpfile bekommt man ohne Complete aber mit Extended Inserts. Falls die SQL-Datei manuell verändert werden soll / muss ist es empfehlenswert die Daten mit Complete Inserts aber ohne Extended Insert zu exportieren, so wird das resultierende Dumpfile zwar deutlich größer, ist aber auch einfacher zu lesen.


Hat man alles ausgewählt kann man im unteren Teil der Maske die Sicherung anstossen:

Phpmyadmin sicherung03.gif

Dazu wählt man zunächst "Save as File" 5) und unter Compression "Zipped" 6) aus. Das hat den Vorteil, daß die Datensicherung als Datei zum Runterladen an den Browser geschickt wird. Die SQL-Datei wird dabei in ein ZIP-Archiv verpackt und ist dadurch erheblich kleiner als eine unkomprimierte Sicherung.

Jetzt noch auf "Go" klicken und einen kurzen Augenblick Geduld haben, die Datei wird dann zum Download angeboten.

Phpmyadmin sicherung04.gif

Das Backup ist damit fertig.

Sicherung mit MySQLDumper

Mit dem MySQLDumper steht uns ein weiteres Werkzeug zur Sicherung unserer Datenbanken zur Verfügung. Bei Bedarf kann damit auch eine Wiederherstellung der Datenbank(en) durchgeführt werden. Hilfestellung zur Installation und Konfiguration finden sich auf der Webseite.

Ist man eingeloggt wechselt man auf die Seite "Backup" 1).

Unter 2) kann man die zu sichernde Datenbank auswählen, sofern mehrere vorhanden sind.

3): hier wählt man die passende Zeichenkodierung des Backups aus. Die Standardkodierung des MySQL Servers steht direkt darunter.

Im unteren Teil kann noch eine letzte Überprüfung erfolgen, ob alles nach seinen Wünschen eingestellt ist, z.B. Multipart Backup.

Nach Klick auf 4) "Neues Backup starten" kommt man auf eine weitere Seite, wo der Status des Backups angezeigt wird.

Mysqldumper sicherung01.jpg


Statusanzeige des aktuellen Backups

Mysqldumper sicherung02.jpg

Nach Beendigung des Backups wird man auf eine Seite weitergeleitet, wo das Backup (oder die Backups, falls Multipart gewählt wurde) angezeigt wird.

Sicherung mittels Cronjob /MySQL-Kommandozeile

Die Sicherung mittels Cronjob / Kommandozeile richtet sich ausschließlich an Server-Betreiber oder Personen, die zumindest Shell-Zugang zum Server haben und innerhalb der Linux-Kommandozeile auch Cronjobs erstellen können. Zusätzlich dazu sollte man ein bißchen Erfahrung im Umgang mit Unix/Linux und der Kommandozeile (Shell) mitbringen - eigentlich eine Grundvorraussetzung für alle, die ihr SMF auf einem eigenen Server betreiben.

Zur Sicherung der Datenbanken auf der Shell gibt es das Kommando mysqldump. Mit diesem kann man schnell und einfach mysql Datenbanken auslesen und in eine SQL-Datei speichern. Das Ganze werde ich anhand einer Beispieldatenbank (backuptest) erklären, Datenbankname und Zugangsdaten müssen natürlich entsprechend angepasst werden. Zuerst lege ich mir eine Spielumgebung an:

stard@vs2349:~$ mkdir -p /tmp/backup         
stard@vs2349:~$ cd /tmp/backup
stard@vs2349:/tmp/backup$ mysql -uroot -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 26516
Server version: 5.0.51a-24+lenny1 (Debian)
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> create database backuptest;
Query OK, 1 row affected (0.00 sec)
mysql> use backuptest;
Database changed
mysql> create table blablupp (id TINYINT NOT NULL);
Query OK, 0 rows affected (0.00 sec)
mysql> select * from blablupp;
Empty set (0.00 sec)
mysql> insert into blablupp values (1),(2),(3);
Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0
mysql> select * from blablupp;
+----+
| id |
+----+
|  1 |
|  2 |
|  3 | 
+----+
3 rows in set (0.00 sec)
mysql> exit
Bye

Diese Datenbank mit der einen Tabelle soll jetzt gesichert werden, dazu nutze ich das Kommando mysqldump:

stard@vs2349:/tmp/backup$ mysqldump -uroot -p backuptest > backuptest.dump
Enter password:
stard@vs2349:/tmp/backup$ ls -l
insgesamt 4
-rw-r--r-- 1 stard stard 1759 14. Mär 16:48 backuptest.dump
stard@vs2349:/tmp/backup$

So einfach ist das, wenn man sich die Datei backuptest.dump jetzt mit einem Texteditor ansieht, findet man darin genau die SQL Befehle die man braucht, um die Datenbank im Notfall komplett zurückspielen:

stard@vs2349:/tmp/backup$ cat backuptest.dump
-- MySQL dump 10.11
--
-- Host: localhost    Database: backuptest
-- ------------------------------------------------------
-- Server version       5.0.51a-24+lenny1
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `blablupp`
--
DROP TABLE IF EXISTS `blablupp`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `blablupp` (
  `id` tinyint(4) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;
--
-- Dumping data for table `blablupp`
--
LOCK TABLES `blablupp` WRITE;
/*!40000 ALTER TABLE `blablupp` DISABLE KEYS */;
INSERT INTO `blablupp` VALUES (1),(2),(3);
/*!40000 ALTER TABLE `blablupp` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
-- Dump completed on 2010-03-14 15:48:09
stard@vs2349:/tmp/backup$

Das muß man im einzelnen jetzt nicht verstehen, die wichtigen Zeilen habe ich mal markiert und wie man sieht, sind das genau die Befehle, die ich benutzt habe, um die Datenbank zu erstellen und zu füllen. Wie das war's schon? Ja, das war's schon. Man kann so jede Datenbank einzeln in eine Textdatei sichern, diese irgendwo auf einen Backupspace schieben oder, wie in http://wiki.smfportal.de/Datensicherung#Sicherung_von_Dateien beschrieben, auf seinen Rechner zu Hause kopieren und schon ist die Sache gegessen :)

Der eigentliche Vorteil der Sicherung über die Shell ist aber, daß man das Ganze automatisiert zu einem Zeitpunkt X ablaufen lassen kann. Hier kommen die Cronjobs ins Spiel. Was Cronjobs genau sind, kann man unter http://de.wikipedia.org/wiki/Cron nachlesen, hier soll nur kurz erklärt werden, wie man diese für sein Datenbankbackup nutzt. Dazu lege ich eine Batchdatei an und schreibe meinen mysqldump-Befehl dort hinein:

stard@vs2349:/tmp/backup$ cat dobackup.sh
#!/bin/bash
echo "Sichere Datenbank backuptest"
/usr/bin/mysqldump -uroot -pxxxxxxxx backuptest > /tmp/backup/backuptest.dump
echo ".... fertig"
stard@vs2349:/tmp/backup$

Wie man sieht, nutze ich in der Datei vollständige Pfade zu den Dateien, das ist wichtig. Außerdem steht das Passwort hier im Klartext drin, es ist also auch wichtig, die Zugriffsrechte (Ausführrechte, kein Zugriff für die Gruppe und andere) zu setzen! Schon kann es losgehen mit der Sicherung:

stard@vs2349:/tmp/backup$ chmod 700 dobackup.sh
stard@vs2349:/tmp/backup$ ./dobackup.sh 
Sichere Datenbank backuptest
.... fertig
stard@vs2349:/tmp/backup$ ls -l
insgesamt 8
-rw-r--r-- 1 stard stard 1759 14. Mär 17:13 backuptest.dump
-rwx------ 1 stard stard  151 14. Mär 17:09 dobackup.sh
stard@vs2349:/tmp/backup$

Sieht gut aus, woll? Das ganze in die Crontab einzutragen ist auch ein Kinderspiel, der Befehl hierzu ist crontab -e. Mein Beispieleintrag sieht so aus:

stard@vs2349:/tmp/backup$ crontab -l
# m h  dom mon dow   command
00 02 * * * /tmp/backup/dobackup.sh &> /tmp/backup/backup.log
stard@vs2349:/tmp/backup$

Wichtig an dieser Stelle ist die Umleitung der Ausgabe in eine Log-Datei, ansonsten würde man bei jedem Backup eine Mail bekommen (an den User der den cronjob angelegt hat, also unter Umständen an ein totes Postfach). Ich habe als Zeitpunkt in diesem Beispiel täglich zwei Uhr morgens gewählt, das kann man natürlich anpassen, wie man lustig ist (der wikipedia Artikel von oben sollte das ganz gut erklären).

Das war's mit den Basics, ab jetzt wird auf meinem Server jeden morgen um zwei Uhr die Datenbank backuptest gesichert. Der nächste Schritt wäre das Script dahingehend zu erweitern, daß alle Datenbanken gesichert werden, dazu muß man diese eigentlich nur in die Datei dobackup.sh einfügen. Hier mal ein Beispiel wie ich das bei mir gemacht habe:

stard@vs2349:/backup/script$ more dbbackup.sh
##############################
#!/bin/sh
DATE=`date +%w`
DBUSER=root
DBPASS='XXXXXXX'
SCRIPT=/backup/script
TARGET=/backup/data
if [ $# -lt 1 ] ; then
       echo "Usage: $0 dbname|all"
       exit 1
fi
# get the database names
if [ $1 = "all" ] ; then
       DBNAMES=`mysql -u$DBUSER -p$DBPASS -e "SHOW DATABASES\G;"|grep 'Database:'|awk '{print $2}'`
else
       DBNAMES=$1
fi
# loop through the dbs
for DBNAME in $DBNAMES
do
       echo
       echo "---------------------------------- $DBNAME backup"
       echo
       /usr/bin/mysqldump --user=$DBUSER --password=$DBPASS $DBNAME > $TARGET/mysql_$DBNAME_$DATE.sql
       /bin/gzip -f $TARGET/mysql_$DBNAME_$DATE.sql
done
stard@vs2349:/backup/script$

Sicherung von Dateien

Der einfachste Weg die Dateien zu sichern ist das Kopieren der kompletten Dateien per FTP. Dazu verbindet man sich mittels FTP-Client mit dem Server, auf dem die Daten liegen (Hier im Beispiel FileZilla und klickt sich durch die Ordner, bis man die Dateien des Forums erreicht hat. Nun markiert man alle Dateien (z.B. mittels STRG+A auf der Tastatur und zieht dann alle markierten Dateien per Maus auf einen beliebigen Ordner auf der "lokalen Seite"..

Filezilla sicherung01.gif

Anschließend werden alle Daten in eine Warteschlange eingereiht und kopiert. Je nach Größe des Forums (Attachments) und Geschwindigkeit des Servers / der lokalen Internet-Leitung kann der Kopiervorgang eine ganze Weile dauern.

Daten wiederherstellen

Einleitung

Ganz generell: Ein Backup ist IMMER nur die halbe Miete! Ein ungetestetes Backup ist kein sicheres Backup, wenn man erst im Notfall feststellt, dass das Backupkonzept so nicht funktioniert, hat man ein echtes Problem. Wenn es nachher drauf ankommt habt ihr keine Zeit mehr zum üben, wer ein Backup einspielen muß steht in der Regel ziemlich unter (Zeit-)Druck!

Deswegen gilt:

Automatische Backups in regelmässigen Abständen überprüfen auf Aktualität und Dateigröße.
Ändert sich die Dateigröße plötzlich
rapide stimmt mit großer Wahrscheinlichkeit etwas nicht.
Testet in einer ruhigen Minute ob sich das Backup auch wieder einspielen läßt,
zum Beispiel in einem Testforum zu Hause oder
einem zweiten Forum auf dem gleichen Webspace.

Restore mit phpmyadmin / mysqldumper

- muß noch ergänzt werden -

Restore auf Kommandozeile

Wer sein Backup so eingerichtet hat wie in Datensicherung#Sicherung_mittels_Cronjob_.2FMySQL-Kommandozeile beschrieben, kennt sich mit den grundsätzlichen Funktionen von Linux und der Kommandozeile aus. Darauf wird hier an dieser Stelle also nicht weiter eingegangen. Das Wiederherstellen der Datenbanken ist tatsächlich noch viel einfacher als das Sichern und noch dazu deutlich schneller als über phpmyadmin/mysqldumper. Als Beispiel nehme ich wieder die Datenbank von oben, das macht das Ganze hoffentlich für jeden nachvollziehbar. Schauen wir uns das Backupfile nochmal genauer an:

Alles was mit "--" anfängt ist eine Kommentarzeile, alles was mit "/*" anfängt ist ein mysql internes Kommando, was uns an dieser Stelle nicht weiter interessiert. Mit "SET" werden nur Variablen gesetzt, gehe ich auch erstmal nicht drauf ein. Die wichtigen Befehle sind also

DROP TABLE IF EXISTS `blablupp`;
CREATE TABLE `blablupp` (
  `id` tinyint(4) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
LOCK TABLES `blablupp` WRITE;
INSERT INTO `blablupp` VALUES (1),(2),(3);
UNLOCK TABLES;

Zu deutsch: Lösche die Tabelle falls vorhanden, lege sie neu an und befülle diese dann wieder mit den Werten. Diese Befehle kann man von Hand aus der Datei kopieren (muß man manchmal auch wenn man nur einzelne Tabellen wieder herstellen möchte) oder einfach mit dem mysql Kommando source ausführen. Wichtig ist, daß man vorher die Datenbank auswählt. Wie man sieht steht der Datenbankname nicht im Script. Sollte die Datenbank komplett weg sein (wenn man sein Backup auf einem neuen Server aufspielt zum Beispiel) muß die Datenbank vorher angelegt werden.

Anmelden am mysql Server:

stard@vs2349:/tmp/backup$ mysql -uroot -p
Enter password:                          
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 26559                        
Server version: 5.0.51a-24+lenny1 (Debian)               
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

Löschen der Datenbank (nur als Beispiel, muß im Normalfall natürlich nicht gemacht werden):

mysql> drop database backuptest;
Query OK, 1 row affected (0.01 sec)

Neuanlegen einer leeren Datenbank:

mysql> create database backuptest;
Query OK, 1 row affected (0.00 sec)

Datenbank auswählen:

mysql> use backuptest;
Database changed      
mysql> show tables;   
Empty set (0.00 sec)  

Einlesen des Backupscripts:

mysql> source backuptest.dump
Query OK, 0 rows affected (0.00 sec)
.
.
.
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0
Query OK, 0 rows affected (0.00 sec)
.
.
.
Query OK, 0 rows affected (0.00 sec)

Anzeigen der Tabelle:

mysql> show tables;
+----------------------+
| Tables_in_backuptest |
+----------------------+
| blablupp             |
+----------------------+
1 row in set (0.00 sec)
mysql> select * from blablupp;
+----+
| id |
+----+
|  1 |
|  2 |
|  3 | 
+----+
3 rows in set (0.00 sec)
mysql> exit
Bye

Das war's. Einfach, woll?

Die im SMFPortal.de-Wiki bereitgestellten Informationen werden nur stichprobenhaft geprüft. Wir übernehmen keine Haftung für direkte oder indirekte Schäden, die durch Informationen, die im Wiki bereitgestellt werden, entstanden sind. Obwohl sich unser Wiki-Team bemüht, Fehler schnell und umfassend zu beheben, sind wir auf Deine Mithilfe angewiesen. Bitte melde fehlerhafte Informationen in den Artikeln über die entsprechende Diskussionsseite, damit wir diese korrigieren können, oder bearbeite den Artikel selbst (hierfür musst du im Wiki registriert und angemeldet sein).