Menu ▾ ▴

German Documentation

German Documentation (1)
Eike Starkman

Was ist es und was kann es?

Backuptools gibt es viele, was unterscheidet dieses von den andern bzw. wo sind die Vorteile dieses Tools?
Hauptsächlich wurde dieses Skript für folgendes Szenario entwickelt:
Eine Firma hat viele Kunden und betreut die Webseiten dieser Kunden. Alle Kunden sind bei unterschiedlichen Providern, mit unterschiedlichen Funktionalitäten. So gibt es bei einigen Server rsync, bei anderen nicht mal einen ssh Zugang. Fast alle Kunden benutzten ein CMS, wie z.B. typo3 oder Wordpress. Die Firma ist nun zu ständig von alle Kunden Backups zu erstellen und lokal zu sichern. Diese Aufgabe soll möglichst wenig Arbeit und Wartung in Anspruch nehmen, dabei aber sicher sein.

Daraus lassen sich folgende Features ableiten:

  1. Zentrale Konfiguration des Backups der verschiedenen Server
  2. Es müssen Backups von Dateien und Datenbanken erstelle werden
  3. Wenn sich Datenbank Zugänge ändern sollte das Skript automatisch davon wissen
  4. Inkrementelle Backups
  5. Backup Rotation
  6. Flexibel Schnittstelle zu den Servern (sftp/ssh/ftp)
  7. Keine Software Abhängigkeiten seitens der Server, also keine Clients
    Technik

Dieser Abschnitt beschreibt die darunterliegenden Techniken des Skript, wie Backups gemacht werden.

Datenbank

Die meisten Datenbanken sind nur über einen lokalen Port erreichbar. Das der Datenbankport von außen erreichbar ist ist eher die Ausnahme. Da möglichst viele Server abgedeckt werden sollen muss für beide Servertypen ein Möglichkeit gefunden werden. Dies geschieht mit SSH Tunnel. Das heißt der Datenbankport des zu sichernden Servers wird bei dem Backupserver lokal erreichbar gemacht. Das Skript sucht einen freien Port ab 4000, und erstellen einen Tunnel. Das setzt voraus, das auf dem Server SSH verfügbar ist. Der Transport des Datenbankdumps erfolgt über diesen Tunnel und wird bereits auf dem Server komprimiert. Daher benötigt die Übertragung keine hohe Bandbreite und dank SSH ist die Verbindung verschlüsselt. Zum sichern der Datenbank und zur Rotation wird eine geänderte Version von autobackupmysql eingesetzt.
Mehr Informationen:
http://en.wikipedia.org/wiki/Tunneling_protocol
http://sourceforge.net/projects/autobackupmysql/

Dateien

Das Sichern von Dateien muss über möglichst viele Protokolle wie SSH, SFTP und FTP möglich sein. Um ebenfalls unabhängig von auf dem Server installierter Software zu ein geschieht der Backups über FUSE. Dabei wird auf Backupserver eine Mountpunkt erstellt und der zu sichernde Server dort gemountet. Das Skript sichert diesen Ordner inkrementell. Ja nach Protokoll ist diese Verbindung ebenfalls verschlüsselt. Dies vorgehen hat allerdings den Nachteil eines etwas höheren Overheads, gegen über eines rsync basierten Backups, da nun bei der Suche nach Änderungen auf dem Server Daten übertragen werden müssen. Zum erstellen eines Inkrementellen Backus und passender Rotation wird rdiff verwendet. Das Skript ist aber so aufgebaut, das alle möglich Tool zu Einsatz kommen können. Für das System handelt es sich ja um das Backups eines normalen Ordners.
Mehr Informationen:
http://fuse.sourceforge.net/
http://en.wikipedia.org/wiki/Rsync
http://rdiff-backup.nongnu.org/
Installation

Zu Installation einfach das Skript an eine gewünschte Stelle kopieren und fertig. Benötigt werden: rdiff fuse je nach Server sshf oder curlftpfs

Konfiguration

Jegliche Konfiguration des Skriptes wir in dem Ordner conf. vorgenommen.
Alle Pfadangaben sind absolut.
Globale Konfiguration

Zunächst müssen in der gobla_config folgende (absoluten) Pfade angepasst werden:

1
2
3
4
5
#!/bin/bash
#Das Verzeichnis in dem die Backups gespeichert werden sollen
DATADIR='/home/backup/'
#Das Verzeichnis in dem die logs gespeichert werden sollen
LOGDIR='var/log/backup/'

Mit der Variable DRYRUN kann gesteuert werden ob das Skript tatsächlich Daten übertragen soll. Die ist nützlich für das testen der Server Konfiguration. Siehe 4.1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
#!/bin/bash
# Dies ist um die Konfiguration zu testen 1|0
# Wenn dies aktiviert ist werden nur die Zugänge überprüft
# es werden keinen Backups durchgeführt
DRYRUN=0

# Mail setup
# Was soll verschickt werden?
# - log    : jede Log-Datei
# - files  : Log-Dateien und sql dump (see docs)
# - stdout : normale Konsolen ausgabe.
# - quiet  : Nur Fehler werden geschickt.
MAILCONTENT="quiet"

# Maximale größe einer Mail. (4000 = ungefähr 5MB email)
MAXATTSIZE="4000"

# An welche Adresse soll geschickt werden? (user@domain.com)
MAILADDR="addres@server.com"

Templates (das Verzeichniss conf.d)

Das Verzeichnis conf.d beinhaltet ein Template zur Erstellung einer Serverkonfiguration. Zum anlegen eines neuen Servers, der gesichert werden soll, kann dieses Template kopiert und angepasst werden. Dabei gilt zu beachten, das der Dateiname mit „conf_“ anfangen muss, für www.server.com also z.B. „conf_server.com“. Die Datei sieht dann folgendermaßen aus:

  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
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
#!/bin/bash
## Jede Konfiguration muss mit "conf_" im Dateinamen anfangen,  z.B. conf_server1
# Der Name des zu sichernden Servers, dies ist wirklich nur ein Name
SITENAME="test.de"
# Was für ein Backups soll druchgeführt werden
#  Drei Möglichkeiten sind vorhanden: 'komplettes backup', 'nur Dateien' und 'nur      
Datenbank'
# full|file|database 
BACKUP="full"
# ### SUBPART CMS
# Mit CMS und CONFIG_FILE ist es möglich anzugeben, welches CMS aus dem Server 
# läuft und wo sich die Datei befindet mit den Datenbankverbindungsparametern
# Wenn CMS und  CONFIG_FILE definiert sind wird versucht die nötigen Daten vom remote
# Server zu bekommen
# Definiert welches CMS auf dem Server läuft
CMS="typo3"
# Die Datei in welcher sich die Datenbankverbindungsparametern befinden
CONFIG_FILE="public_html/typo3/typo3conf/localconf.php"
# ### SUBPART CMS END
# ### SUBPART DATABASE
# Hier kann die Methode mit der die Datenbank gesichert werden soll eingestellt werden:
# 1. "ssh" bedeutet, das die Datenbank über einen ssh tunnel gesichert wird. 
#    Dies funktioniert nur wenn ein ssh Zugang vorhanden ist.
# 2. "remote" bedeutet das die Datenbank von "aussen" erreichbar ist und das script
sich so direkt verbinden kann. 
#   Dies sollte nur gewählt werden wenn tatsächlich ein ssh Zugang vorhanden ist, da
diese Methode nicht so sicher ist.
db_backup="ssh"

# Datenbank-host.
db_host="host"
# Name der Datenbanken
# DB1 DB2 oder aber auch db="all" für alle Datenbanken
db="database"
# Datenbanknutzer
db_username="db_user"
# Datenbankpasswort
db_password="db_password"
# Datenbankport
db_port=""
# ### SUBPART DATABASE END
# Tabellen die ignoriert werden sollen
# Standard Tabllenen für Typo3 und Worpress sind in  ignore_typo3 
# und ignore_wordpress definiert . Benutzung "DB_IGNORE=ignore_typo3".
DB_IGNORE="ignore_typo3"

# Normalerweise sperrt mysqldump die Datenbank während des backups.
# Das kann dazu führen, das die Webseite währed des backups nicht erreicht werden kann
# Wenn "no" gewählt wird werden die Tabellen nicht gesperrt, dies kann aber zu
inkonsistenten dumps führen.
# Mehr Informationen: mysqldump --single-transaction --quick
LOCK_TABLES="yes"

# Optionen für mysqldumper
# Mehr Informationen: man mysqldump
# Wenn folgende Fehler auftreten:
# mysqldump: Error: 'Access denied for user 'user'@'host' to database   
'INFORMATION_SCHEMA'' when trying to dump tablespaces
# Dann  "--no-tablespaces" benutzen
# mysqldump: Got error: 1044: Access denied for user 'user'@'host' to database
'information_schema' when using LOCK TABLES
# Dann "--single-transaction" neutzen oder LOCK_TABLES="yes" setzen
DB_OPTIONS=""


# ### SUBPART SSH/FTP
# Welches Protokoll soll benutzt werden (ssh|ftp)
# SSH wird empfohlen, ftp nur benutzen wenn keine SSH Verbindung möglich ist.
M_PROTOCOLL="ssh"
# Soll Zertifikate basierte Authentifizierung per SSH benutzt werden?
# Es wird empoflen dies zu tun , da die der der sicherste Weg ist, anderfalls müsste
das Passwort
# für eine SSH-Verbindung Plaintext in die Konfiguration geschrieben werden 
# Bitte vor dem Backup überprüfen ob ein Zugang per Zertifikate möglich ist.
# Unter „man  ssh-copy-id“ nachsehen für Hilfe
# Nochmal wenn  "no", denn muss M_PASS definert werden.
M_CERT="yes"
# Benutzer
m_username="m_user"
# Passwort für ftp, oder ssh ohne Zertifikat
m_pass="m_password"
# FTP/SSH Server
m_host="m_host"
# Der zu sichernde Pfad auf dem Serve
M_PATH="public_html/"
# Mehr SSH OPTION (e.g. -pPORTNUMBER)
# Mehr unter „man ssh“
M_OPTIONS=""
# ### SUBPART SSH/FTP END
# ### SUBPART RDIFF-BACKUP START
# Wie viele Versionen sollen erstellt werden (Dateien)
# 20B = 20 Versions.
VERSIONS=20B
# Definiert Ordner oder Dateien die beim Backups ignoriert werden sollen
# e.g. "folder1 folder2 file.txt"
EXCLUDE=""
#Mehr Optionen für rdiff-backup unter man rdiff-backup
#
R_OPTIONS=""
# ### SUBPART RDIFF-BACKUP END

CMS

Wie im letzte Kapitel erwähnt ist es möglich das das Skript die Datenbankverbindungsparameter automatisch vom Server ausließt. Dies ist dadurch möglich, dass CMS wie Typo3 oder Wordpress diese Daten in einer Datei speichern, bei Typo3 ist es die localconf.php. Das Auslesen dieser Dateien ist sinnvoll, da so sichergestellt wird, das tatsächlich die Datenbank gesichert wird die das System benutzt. Sollte als einmal auf dem Server das Passwort oder die Datenbank geändert werden, müssen diese Änderungen nicht in der Konfiguration der Skriptes nachvollzogen werden und die Backups bleiben automatisch lauffähig.

Ignore Tables

Viele CMS beinhalten Tabellen die nicht gesichert werden müssen, z.B. Tabellen die nur für den Cach zuständig sind. Bei Typo3 betrifft das das Cachingframework und einige Tabellen für die Index-Suche. Sollte mal eine neue Tabelle dazukommen, muss dies nicht bei allen Konfiguration geändert werden sondern kann zentral in dem Ordner ignore_tables geschehen. Für Typo3 wäre das dann die Datei ignore_typo3 im Ordner ignore_tabels.

Excludes

Es ist möglich bestimmte Ordner vom backups auszuschließen. Die normale Syntax dafür ist

EXCLUDE="ordner1 ordner2"

Es ist aber ebenfalls möglich für global definierte Ordner auszuschließen. Die ist z.B. sinnvoll wenn viele Backups von Servern erstellt werden auf denen Typo3 installiert ist, da die Sourcen von Typo3 nicht mit gesichert werden müssen. Dazu existiert der Ordner exclude_folders. Die Verwendung von wildcarts ist ebenfalls erlaubt, so schließt „test**“ alle Ordner/Dateien die mit test beginnen aus.

Backup

Es gibt zwei verschieden Arten ein Backups zu starten:

  1. Automatisch:
    Mit Parameter „all“ werden alle alle Konfigurationen in conf.d durchgegangen und zu jedem Server wird ein Backup erstellt. Dies ist vor allem für den automatisch Aufruf per Cron: backup all. Dabei kann hinter all ein weiterer Parameter folgen, zur Auswahl stehen full|file|database. „backup all database“ würde in diesem Fall die Datenbanken aller server sichern. Wird nichts angegeben, wird die in der Konfiguration angegebene Aktion ausgeführt, siehe BACKUP=““.
  2. Manuell „conf_sitename“:
    Es ist aber auch möglich nur einen Server gezielt zu sichern. Dazu muss der Dateiname der Konfiguration angegeben werden: backup conf_sitename
    Auch hier können wieder die Parameter full|file|database angehangen werden. „backup conf_server file“ würde demnach nur Dateien vom Server sichern.

Ein kleiner Hinweis an dieser Stelle: Es ist möglich durch die Dateinamen der Konfigurationen selbige von automatischen Backups auszuschließen, aber manuell benutzbar zumachen. Wenn der Parameter „all“ angegeben ist werden alle Konfigurationen die mit conf_ beginnen berücksichtigt, alle andern nicht. Daher kann eine Konfiguration angelegt werden z.B. „test_beispiel.de“ die nicht automatisch gesichert wird, aber manuell durch „backup test_beispiel.de“ gesichert werden kann.

Es können mehrere Backups parallel laufen!

rdiff-backup

Wie bereits erwähnt wird zum eigentliche Backup rdiff-backup eingesetzt. Rdiff-back hat den Vorteil das Dateien nicht neu angelegt werden wenn Änderungen auftreten sondern nur diese Änderungen werden angelegt. Dadurch ist rdiff-backups sehr speicherplatzeffizient. Natürlich biete es ebenfalls alle andern Vorteile eines inkrementellen Backups. Ferner gibt es viele weitere Tools welche auf rdiff-backup aufbauen, wie z.B. rdiff-web. Dieses Tool liefert detaillierte Statistiken über alle durchgeführten Backups. Nach einem durchgeführten Backup befinden sich die Dateien in dem Ordner „seitenname/daten“ Mehr Informationen: http://rdiff-backup.nongnu.org/

Datenbank

Nach eine durchgeführten Backup befindet sich das aktuelle Datenbank Backup in dem Ordner „seitenname/latest“. Ältere Versionen werden entsprechend in die Ordern daily, monthly und weekly kopiert.

Szenarien

Server mit ssh und CMS

Schlüssel erstellen:
Um automatisierte Backups vom Backupserver auf den verschiedenen Kunden durchführen zu können ist es notwendig den Login-Prozess zu automatisieren, sprich sich ohne Passwort einloggen zu können.
Zu diesem Zweck erlaubt es SSH sich via Schlüssel zu authentifizieren. Dazu muss zunächst ein Schlüsselpaar erzeugt werden. Hierzu folgenden Befehl auf dem Backupserver eingeben:

sudo ssh-keygen -t rsa

Damit werden eigene Schlüsselpaare erzeugt. Die Passphrase sollte leer sein, da sonst später beim Cronjob diese abgefragt wird. Es entstehen Dateien mit den Schlüsselpaaren:
/root/.ssh/id_rsa und /root/.ssh/id_rsa.pub.

Die *.pub-Dateien können nun auf den Zielhost kopiert und dort an ~/.ssh/authorized_keys angehängt werden:

ssh-copy-id -i /root/.ssh/id_rsa.pub user@remote-system

Oder, wenn ssh-copy-id nicht vorhanden ist:

cat /root/.ssh/*.pub | ssh user@remote-system 'umask 077; cat >>.ssh/authorized_keys'

Jetzt sollte es möglich sein sich per

ssh user@remote-system

einzuloggen ohne ein Passwort einzugeben.

Konfig anlegen:
Am besten einfach das Template kopieren und dann umbenennen, hier nur die nötigsten Sachen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
#!/bin/bash
SITENAME="test.de"
BACKUP="full"
CMS="typo3"
CONFIG_FILE="public_html/typo3/typo3conf/localconf.php"
db_backup="ssh"
DB_IGNORE="ignore_typo3"
LOCK_TABLES="yes"
M_PROTOCOLL="ssh"
M_CERT="yes"
M_USER="m_user"
M_HOST="m_host"
M_PATH="public_html/"

Server mit ssh ohne CMS

Im Prinzip alles wie oben, mit dem Unterschied, das jetzt die Datenbankverbindungsparameter mit angegeben werden müssen.

1
2
3
4
5
6
7
#!/bin/bash
db_backup="ssh"
db_host="host"
db="database"
db_username="db_user"
db_password="db_password"
db_port=""

Server mit rssh oder nur sftp

Bei Servern dieser Art ist es nicht möglich eine Shell per ssh zu bekommen, noch sich per Zertifikat einzuloggen. Dadurch ist es nicht möglich einen ssh Tunnel aufzubauen, was dazu führt das Datenbankbackups nur möglich sind wenn die Datenbank von außen erreichbar ist (siehe Unten). Um dem Script dies mitzuteilen muss der Parameter CERT auf „no“ gesetzt werden. Außerdem muss das ssh Passwort in der Konfiguration angegeben werden. Achtung dies ist sehr unsicher, aber die einzige Möglichkeit aber Servern dieser Art.

1
2
3
4
5
6
#!/bin/bash
M_PROTOCOLL="ssh"
M_CERT="no"
M_USER="m_user"
M_PASS="m_password"
M_HOST="m_host"

Server ohne ssh aber ftp

Bei Server dieser Art ist kein Login per Schlüssel möglich und das Passwort muss in der Konfiguration gespeichert werden. Ferner muss PROTOCOLL auf ftp und der CERT auf „no“ gestellt werden.

1
2
3
4
5
6
7
#!/bin/bash
CERT="no"
M_PROTOCOLL="ftp"
M_USER="m_user"
M_PASS="m_password"
M_HOST="m_host"
M_PATH="public_html/"

Datenbank ist von außen erreichbar

Ist dies der Fall so kann die Datenbank ebenfalls gesichert werden. Und die Datenbankverbindungsparameter müssen mit angegeben werden. Ein automatische auslesen z.B. der localconf ist nicht möglich. Damit das Script weiß das die Datenbank von außen erreichbar ist muss db_backup auf „remote“ gestellt werden.

1
2
3
4
5
6
7
#!/bin/bash
db_backup="remote"
db_host="host"
db="database"
db_username="db_user"
db_password="db_password"
db_port=""

Datenbank ist nicht von außen erreichbar

Jetzt ist leider kein Datenbankbackup mehr möglich. Diese muss auf andere Weise erfolgen.

Related

Wiki: Home

Cerberus Logo