Datenbanken-Backup: Unterschied zwischen den Versionen

Aus mxlinuxusers.de
Markierung: Durch einen Tor-Ausgangsknoten
KKeine Bearbeitungszusammenfassung
Markierung: Durch einen Tor-Ausgangsknoten
 
Zeile 1: Zeile 1:
 
__TOC__
 
__TOC__
Ein Backup von Datenbanken sollte nicht bei laufender Datenbank erfolgen (Gefahr von Inkonsistenz bei der Wiederherstellung), es sollte also wenigstens der schreibende Zugriff gesperrt werden, wenn möglich ist es jedoch besser, die Datenbank für den Zeitraum des Backups / der Wiederherstellung ganz zu sperren. Allerdings ist es beim physischen Backup möglich, durch das Zurückspielen der Logdateien wieder einen konsistenten Zustand zu erreichen, was allerdings meist einen grösseren Zeitverbrauch und eine höhere Datenbanklast verursacht.
+
Ein Backup von Datenbanken sollte nicht bei laufender Datenbank erfolgen (Gefahr von Inkonsistenz bei der Wiederherstellung), es muss also wenigstens der schreibende Zugriff gesperrt werden. Wenn möglich ist es jedoch besser, die Datenbank für den Zeitraum des Backups/der Wiederherstellung ganz zu sperren. Allerdings ist es beim physischen Backup möglich, durch das Zurückspielen der Logdateien wieder einen konsistenten Zustand zu erreichen, was allerdings meist einen grösseren Zeitverbrauch und eine höhere Datenbanklast verursacht.
   
Man sollte sich auch davon überzeugen, ob Konfigurationsdateien mit gesichert wurden, was oftmals nicht der Fall ist. Für diese Konfigurationsdateien kann man dann auf herkömmliche [[Backup|Backupwerkzeuge]] zurückgreifen oder eventuell sogar Versionierungstools wie git, Subversion o.ä. einsetzen. Auf jeden Fall sollte man auch die Wiederherstellung wenigstens einmal durchspielen, um zu sehen, ob auch tatsächlich alles wie gewünscht funktioniert. Das beste Backup nützt nichts, wenn man es im Ernstfall nicht wieder herstellen kann, aber das gilt generell für alle Arten von Backups.
+
Man sollte sich auch davon überzeugen, ob vorhandene Konfigurationsdateien mit gesichert wurden, was manchmal vergessen wird. Für diese Konfigurationsdateien kann man dann auf herkömmliche [[Backup|Backupwerkzeuge]] zurückgreifen oder eventuell sogar Versionierungstools wie git, Subversion o.ä. benutzen. Auf jeden Fall sollte man auch die Wiederherstellung wenigstens einmal durchspielen, um zu sehen, ob auch tatsächlich alles wie gewünscht funktioniert. Das beste Backup nützt nichts, wenn man es im Ernstfall nicht wieder herstellen kann, aber das gilt generell für alle Arten von Backups.
   
 
Beim Backup von Datenbanken unterscheidet man (wie allgemein beim Backup) zwei mögliche Verfahren, das logische Backup und das physische Backup. Beide Verfahren können natürlich auch kombiniert werden.
 
Beim Backup von Datenbanken unterscheidet man (wie allgemein beim Backup) zwei mögliche Verfahren, das logische Backup und das physische Backup. Beide Verfahren können natürlich auch kombiniert werden.
Zeile 8: Zeile 8:
 
das logische Backup kümmert sich um die Struktur der Daten/Tabellen, d.h. deren Inhalt wird sozusagen "im Klartext" gesichert.
 
das logische Backup kümmert sich um die Struktur der Daten/Tabellen, d.h. deren Inhalt wird sozusagen "im Klartext" gesichert.
 
=== Vorteile ===
 
=== Vorteile ===
Die Backup-Datei besteht aus SQL-Anweisungen, z.B. CREATE TABLE..., INSERT INTO... ist also weitgehend kompatibel und lässt die Wiederherstellung auch auf anderen Maschinen und sogar anderen Datenbanken (MySQL nach PostgreSQL) zu. Weiterhin sind auch nur Teilbackups möglich, also die Sicherung nur einer Tabelle bzw. nur ausgewählte Tabellen.
+
Die Backup-Datei besteht aus SQL-Anweisungen, z.B. CREATE TABLE..., INSERT INTO... ist also weitgehend kompatibel und lässt die Wiederherstellung auch auf anderen Maschinen und sogar anderen Datenbanken (MySQL nach PostgreSQL) zu. Weiterhin sind auch nur Teilbackups möglich, also die Sicherung nur einer Tabelle bzw. nur ausgewählter Tabellen.
 
Bei grossen Datenbanken kann es im Laufe der Zeit zu ungenutzten Speicherbereichen (Garbage) kommen. Dieser Garbage verschwindet beim Zurückspielen von logischen Backups.
 
Bei grossen Datenbanken kann es im Laufe der Zeit zu ungenutzten Speicherbereichen (Garbage) kommen. Dieser Garbage verschwindet beim Zurückspielen von logischen Backups.
 
=== eventuelle Nachteile ===
 
=== eventuelle Nachteile ===
Zeile 17: Zeile 17:
 
Speicherung auf Dateiebene (blockweises kopieren der Daten auf das Sicherungsmedium), dadurch werden auch Logdateien gesichert und es ist nicht unbedingt eine direkte Verbindung zur Datenbank notwendig.
 
Speicherung auf Dateiebene (blockweises kopieren der Daten auf das Sicherungsmedium), dadurch werden auch Logdateien gesichert und es ist nicht unbedingt eine direkte Verbindung zur Datenbank notwendig.
 
=== eventuelle Nachteile ===
 
=== eventuelle Nachteile ===
kopierte Dateien müssten mittels geeigneter Verfahren (Prüfsummen) auf Korrektheit geprüft werden, da schon geringe Datenübertragungs- oder Speicherfehler meist zur Unbrauchbarkeit führen. Ein physisches Backup ist für die Wiederherstellung auf jeden Fall an die gleiche Datenbank gebunden.
+
kopierte Dateien müssten mittels geeigneter Verfahren (Prüfsummen) auf Korrektheit geprüft werden, da schon geringe Datenübertragungs- oder Speicherfehler meist zur Unbrauchbarkeit führen. Ein physisches Backup ist für die Wiederherstellung auf jeden Fall an die gleiche Datenbank gebunden, unter Umständen sogar an die gleiche Version der Datenbank.
 
== Tools zum Backup von Datenbanken ==
 
== Tools zum Backup von Datenbanken ==
 
* [[automysqlbackup]]: erstellt täglich, wöchentlich und monatlich Backups für alle MySQL-Datenbanken. Im Normalfall werden diese Backups in den Ordnern /var/lib/automysqlbackup/daily/, /var/lib/automysqlbackup/weekly/ und /var/lib/automysqlbackup/monthly/ gesichert, der Zielort ist jedoch in der Konfigurationsdatei beliebig einstellbar.
 
* [[automysqlbackup]]: erstellt täglich, wöchentlich und monatlich Backups für alle MySQL-Datenbanken. Im Normalfall werden diese Backups in den Ordnern /var/lib/automysqlbackup/daily/, /var/lib/automysqlbackup/weekly/ und /var/lib/automysqlbackup/monthly/ gesichert, der Zielort ist jedoch in der Konfigurationsdatei beliebig einstellbar.

Aktuelle Version vom 22. Juni 2022, 16:58 Uhr

Ein Backup von Datenbanken sollte nicht bei laufender Datenbank erfolgen (Gefahr von Inkonsistenz bei der Wiederherstellung), es muss also wenigstens der schreibende Zugriff gesperrt werden. Wenn möglich ist es jedoch besser, die Datenbank für den Zeitraum des Backups/der Wiederherstellung ganz zu sperren. Allerdings ist es beim physischen Backup möglich, durch das Zurückspielen der Logdateien wieder einen konsistenten Zustand zu erreichen, was allerdings meist einen grösseren Zeitverbrauch und eine höhere Datenbanklast verursacht.

Man sollte sich auch davon überzeugen, ob vorhandene Konfigurationsdateien mit gesichert wurden, was manchmal vergessen wird. Für diese Konfigurationsdateien kann man dann auf herkömmliche Backupwerkzeuge zurückgreifen oder eventuell sogar Versionierungstools wie git, Subversion o.ä. benutzen. Auf jeden Fall sollte man auch die Wiederherstellung wenigstens einmal durchspielen, um zu sehen, ob auch tatsächlich alles wie gewünscht funktioniert. Das beste Backup nützt nichts, wenn man es im Ernstfall nicht wieder herstellen kann, aber das gilt generell für alle Arten von Backups.

Beim Backup von Datenbanken unterscheidet man (wie allgemein beim Backup) zwei mögliche Verfahren, das logische Backup und das physische Backup. Beide Verfahren können natürlich auch kombiniert werden.

Logisches Backup[Bearbeiten | Quelltext bearbeiten]

das logische Backup kümmert sich um die Struktur der Daten/Tabellen, d.h. deren Inhalt wird sozusagen "im Klartext" gesichert.

Vorteile[Bearbeiten | Quelltext bearbeiten]

Die Backup-Datei besteht aus SQL-Anweisungen, z.B. CREATE TABLE..., INSERT INTO... ist also weitgehend kompatibel und lässt die Wiederherstellung auch auf anderen Maschinen und sogar anderen Datenbanken (MySQL nach PostgreSQL) zu. Weiterhin sind auch nur Teilbackups möglich, also die Sicherung nur einer Tabelle bzw. nur ausgewählter Tabellen. Bei grossen Datenbanken kann es im Laufe der Zeit zu ungenutzten Speicherbereichen (Garbage) kommen. Dieser Garbage verschwindet beim Zurückspielen von logischen Backups.

eventuelle Nachteile[Bearbeiten | Quelltext bearbeiten]

dauert meist länger und die Backup-Dateien sind grösser. Logdateien sind im Backup nicht enthalten. Vorhandene Inexdateien werden nicht gesichert, sondern beim Zurückspielen neu erzeugt, dadurch erhöhter Zeitverbrauch. Auch globale Einstellungen wie z.B. Userrechte werden meist nicht gesichert.

physisches Backup[Bearbeiten | Quelltext bearbeiten]

physisches Backup sichert einfach alle Dateien der Datenbank, muss also nichts über die Struktur der Datenbank wissen, sonden nur, welche Dateien zu sichern sind.

Vorteile[Bearbeiten | Quelltext bearbeiten]

Speicherung auf Dateiebene (blockweises kopieren der Daten auf das Sicherungsmedium), dadurch werden auch Logdateien gesichert und es ist nicht unbedingt eine direkte Verbindung zur Datenbank notwendig.

eventuelle Nachteile[Bearbeiten | Quelltext bearbeiten]

kopierte Dateien müssten mittels geeigneter Verfahren (Prüfsummen) auf Korrektheit geprüft werden, da schon geringe Datenübertragungs- oder Speicherfehler meist zur Unbrauchbarkeit führen. Ein physisches Backup ist für die Wiederherstellung auf jeden Fall an die gleiche Datenbank gebunden, unter Umständen sogar an die gleiche Version der Datenbank.

Tools zum Backup von Datenbanken[Bearbeiten | Quelltext bearbeiten]

  • automysqlbackup: erstellt täglich, wöchentlich und monatlich Backups für alle MySQL-Datenbanken. Im Normalfall werden diese Backups in den Ordnern /var/lib/automysqlbackup/daily/, /var/lib/automysqlbackup/weekly/ und /var/lib/automysqlbackup/monthly/ gesichert, der Zielort ist jedoch in der Konfigurationsdatei beliebig einstellbar.
  • autopostgresqlbackup: wie der Name schon andeutet ist dies ein Port (eine Variante) von automysqlbackup, nur eben mit tegelmäßigen Backups von PostgreSQL-Datenbanken
  • barman: (Backup and Recovery Manager) ist ein Administrations-Tool für Disaster recovery von PostgreSQL-Servern, geschrieben in Python. Es ermöglicht Remote-Backups von mehreren Servern in geschäftskritischen Umgebungen durchzuführen, um Risiken zu reduzieren und Datenbank-Administratoren während der Wiederherstellungsphase zu unterstützen.
  • mariadb-backup: Backup-Tool für MariaDB Server, das physikalische Backups von InnoDB, MyRocks, Aria and MyISAM Tabellen erzeugt.
  • mydumper: Sehr schnelles MySQL Backup Tool, platzsparend durch Kompression des Backups. Daemon-Modus für zeitgesteuerte Schnappschüsse und kontinuierliche Binärprotokolle
  • mylvmbackup: schnelle Erstellung von Sicherungen der Datendateien des MySQL-Servers. Um ein Backup durchzuführen, erhält mylvmbackup eine Lesesperre für alle Tabellen und flusht allen Server-Cache auf Platte, erstellt einen LVM-Snapshot des Volumes, das das MySQL-Datenverzeichnis enthält, und entsperrt die Tabellen wieder. Der Snapshot-Prozess nimmt nur wenig Zeit in Anspruch. Wenn er abgeschlossen ist, kann der Server mit dem normalen Betrieb fortfahren, während das eigentliche Datei-Backup fortgesetzt wird.
  • pg-backup-ctl: ein Backup- und Recover-Tool, das die Erstellung eines vollständigen Transaktionsprotokoll-Archivierungs-Backups von PostgreSQL Clustern erleichtert.
  • pgbackrest: ein einfaches, zuverlässiges Sicherungs- und Wiederherstellungssystem für PostgreSQL, das sich auch für sehr grosse Datenbanken eignet

es existieren auch allgemeine Backup-Tools, die ebenfalls Backups von Datenbanken herstellen können:

s. dazu Backup

Weblinks[Bearbeiten | Quelltext bearbeiten]

  • Synology MariaDB MySQL Backup Das Tutorial erläutert die Einrichtung von automysqlbackup auf einer Synology Diskstation, lässt sich jedoch relativ problemlos allgemein umsetzen
  • Mariabackup (ausführliche engl. Beschreibung dazu)