Zabbix Backup erstellen

Backup des Zabbix-Servers erstellen

Um einen kontinuierlichen Betrieb des Monitorings sicherzustellen, ist das regelmäßige Erstellen eines Backups unerlässlich. Welche Dateien und Daten Sie sichern müssen, hängt stark von Ihrem Setup ab.
Wenn Sie fertige DEB- oder RPM-Pakete zur Installation verwendet haben, reicht ein Backup der Konfigurationsdateien und der Datenbank. Wenn Sie Zabbix selbst kompiliert haben, sollten Sie neben den Binaries auch alle zum Kompilieren verwendeten Dateien sichern. Bei einem kompletten Datenverlust müssen Sie dann nicht alle Schritte des Kompilierens noch einmal durchführen. Es ist daher ratsam, alle Binaries und die Konfigurationsdatei zu sichern.

Vergessen Sie nicht Ihre eigenen Erweiterungen und Alarmierungsskripte zu sichern. Damit Sie nach einem Serverausfall alle nötigen Dateien möglichst schnell wiederherstellen können, ist es ebenfalls ratsam, auch die Konfiguration der Datenbank und des Webservers sowie die Dateien des Webfrontends zu sichern. Im nachfolgenden Beispiel wird ein Backup aller wichtigen Dateien erstellt, wenn Sie den Zabbix-Server per Paketmanager installiert haben. Das Skript benachrichtigt Zabbix per Zabbix-Sender über den Erfolg oder Misserfolg des Backups.

#!/bin/bash
 
SRC="/etc/ /usr/lib/zabbix/ /var/www/ /usr/share/zabbix*"
DEST=/var/backups/zabbix.tar.gz
LOG=/tmp/zabbix-backup.log
ZBX_HOSTNAME=zabbix-server
ZABBIX_SERVER=localhost
 
if tar czf $DEST $SRC >$LOG 2>&1
then
 zabbix_sender -z $ZABBIX_SERVER -s $ZBX_HOSTNAME -k zabbix.backup -o "Finished OK"
else
 zabbix_sender -z $ZABBIX_SERVER -s $ZBX_HOSTNAME -k zabbix.backup -o "FAILED"
fi

Richten Sie ein Item vom Typ "Zabbix-Trapper" mit dem Item-Key zabbix.backup ein, damit der Zabbix-Server über den Status des Backups informiert ist.

Der Zabbix-Server empfängt per Zabbix-Sender den Backup-Status.
Welche Dateien Sie sichern müssen, hängt stark von Ihrer Installation und der verwendeten Distribution ab. Schauen Sie genau nach, wo sich die Binaries des Zabbix-Servers, die Konfiguration und die PHP-Dateien des Webfrontends befinden.

Die MySQL-Datenbank sichern

Ohne ein Backup der Datenbank ist das Backup der Zabbix-Dateien wertlos. Die gesamte Konfiguration von Items, Triggern, Graphen etc. ist in der Datenbank gespeichert.

Es gibt zahlreiche Möglichkeiten, eine Datenbank zu sichern. Welche davon die geeignete ist, hängt von der Größe der Datenbank und des maximal vertretbaren Datenverlustes ab.

MySQL-Dump

Im Falle von MySQL ist der klassische MySQL-Dump aber immer eine zuverlässige Backup-Methode. Die über den Dump exportierten Daten stellen eine konsistente Kopie der Datenbank da. Mit einem Dump können Sie eine MySQL-Datenbank in kurzer Zeit komplett rekonstruieren.

Beachten Sie aber, dass während des Dumps die Datenbank einen Read-Lock setzt, das heißt, alle Clients können nur lesend zugreifen. Im Falle des Zabbix-Servers bedeutet das, dass keine neuen Messwerte gespeichert werden können. In der Regel führt das zu zahlreichen Fehlalarmen. Der Zabbix-Server ist während des Dumps faktisch unbrauchbar und sollte besser ausgeschaltet werden. Nachfolgend sehen Sie ein Beispiel für ein Datenbank-Backup per MySQL-Dump:

#!/bin/sh
PASS=your_mysql_root_password
/etc/init.d/zabbix-server stop
mysqldump -u root -p${PASS} --all-databases|gzip -c>/var/backups/mysql.dump.gz
/etc/init.d/zabbix-server start

Percona XtraBackup

Für produktive Umgebungen ist das Open-Source-Programm XtraBackup eine bessere Alternative zu MySQL-Dump. Die Vorteile von XtraBackup sind u.a.:

  • Die Datenbank wird während des Backups nicht für Schreibzugriff gesperrt.
  • XtraBackup verbraucht wenig Ressourcen und beeinträchtigt die Performance der Datenbank nur sehr gering.
  • Funktionen wie Kompression und Versionierung der Backups sowie inkrementelle Backups sind in XtraBackup enthalten.

Im Gegensatz zu MySQL-Dump produziert XtraBackup keine Datenbankexporte in Form einer SQL-Datei. Das Backup wird in Form von binären Tabellendateien erstellt. XtraBackup legt eine komplette Kopie das MySQL-Datenverzeichnisses an. Damit ist auch schon erklärt, warum es kein Werkzeug zum Zurückspielen der Backups gibt. Man braucht keines. Das Backup kann mit gestopptem MySQL-Server per symbolischen Link oder durch Kopieren nach /var/lib/mysql verschoben werden, und schon kann MySQL mit diesen Tabellendaten starten.

Nutzer von Debian und Ubuntu installieren XtraBackup ganz einfach über den Paketmanager per apt-get install percona-xtrabackup. Benutzer von Red Hat und CentOS finden auf der Percona-Webseite ein Repository und eine Anleitung, wie dieses in den Paketmanager eingebunden wird.

Ein einfacher Aufruf des Kommandos innobackupex /var/backups würde ausreichen, und Sie erhalten eine konsistente Kopie des MySQL-Datenverzeichnisses. Dieses Backup ist aber noch nicht „lauffähig“, und MySQL könnte nicht mit diesen Daten starten. Der Grund dafür ist, dass einige Transaktionen nur im Transaktionslog ib_log gespeichert sind und noch nicht in die Tabellendateien geschrieben wurden. Mit dem Kommando innobackupex --apply-log finalisieren Sie das Backup. Alle Transaktionen werden in die Tabellendateien geschrieben. Nun ist es möglich, den MySQL-Server mit den Backup-Dateien zu starten.

XtraBackup verfügt über die Möglichkeit, das Backup On-the-fly zu komprimieren. Dabei wird QuickLZ als Kompression verwendet. Diese eingebaute Kompression hat den Nachteil, dass das zuvor beschriebene „Einspielen“ der Transaktionslogs in die Tabellendateien nicht durchgeführt werden kann. Verzichten Sie lieber auf die On-the-fly-Variante und komprimieren Sie das Backup, nachdem das Transaktionslog angewendet wurde.
Sie können jedes Komprimierungsprogramm wie Gzip oder Zip verwenden. QuickLZ bietet gegenüber den beiden letztgenannten folgende Vorteile:

  • Es ist ressourcenschonender.
  • Dateien in Ordnern können ohne Zuhilfenahme von Tar rekursiv gepackt werden.
  • Beim rekursiven Packen liegt jede einzelne Datei in einer komprimierten Version vor. Es entsteht nicht eine große Datei wie bei Tar-Gz oder Zip. Dies erleichtert das partielle Entpacken.

Auf der Webseite von von QuickLZ können Sie fertige Binärpakete oder den Quellcode des Kommandozeilentools qpress herunterladen.

Das Skript percona-backup-wrapper.sh kann Ihnen als Beispiel dienen, XtraBackup regelmäßig auszuführen und Erfolg und Fehler zu protokollieren.

Konfiguration des Wrapper-Skriptes für Percona XtraBackup
Möglicherweise wird XtraBackup mit folgendem Fehler abbrechen:
InnoDB: Error: log file ./ib_logfile0 is of different size 5242880 bytes
InnoDB: than specified in the .cnf file 50331648 bytes!
innobackupex: Error: The xtrabackup child process has died at /usr/bin/innobackupex line 2672.

In diesem Fall müssen Sie in der Datei /etc/my.cnf bzw. /etc/mysql/my.cnf den Wert innodb_log_file_size = 5242880 eintragen und MySQL bzw. MariaDB neu starten.

Backup regelmäßig ausführen

Speichern Sie die einzelnen Schritte des Backups in eine Datei, zum Beispiel /root/backup.sh, oder /root/percona-backup-wrapper.sh. Machen Sie diese mit

chmod +x /root/<BACKUP-SCRIPT>

ausführbar und richten Sie zum Beispiel in der Datei /etc/cron.d/backup einen Cronjob ein, der das Backup täglich ausführt.

# Daily Backup
0 2 * * *  root  /root/<BACKUP-SCRIPT>

Nun wird das Backup täglich um 2.00 Uhr ausgeführt.

Weiterführende Hinweise

Wenn Ihre Zabbix-Datenbank sehr groß ist und Sie den Zabbix-Server während des Backups nicht ausschalten wollen, dann sollten Sie über eine der folgenden Backup-Methoden nachdenken:

  • Master-Slave-Replikation der Datenbank und dann einen Dump über den Slave erstellen
  • Backup per Filesystem-Snapshot, zum Beispiel mit LVM
  • inkrementelles Backup über Binary-Logs der Datenbank