ADMIN 03/14 stellt Erste-Hilfe-Tipps zu Windows-Rettung, Backup und Recovery bei Datenbanken vor und verrät wie man Linux-Systeme vollständig sichert und ... (mehr)

Backup everything?

Unabhängig von der gewählten Backup-Variante sollte man sich vergewissern, was alles notwendig ist, um nach einem Crash mit möglichst geringem Datenverlust in möglichst kurzer Zeit wieder in Produktion gehen zu können. In Standard-Backups von Datenbanken muss nicht zwingend alles Notwendige für eine komplette Wiederherstellung enthalten sein!

Bei PostgreSQL landen beispielsweise Konfigurationsdateien wie »postgresql.conf« (Hauptkonfiguration), »pg_hba.conf« und »pg_ident.conf« (Client-Authentifizierung), die relevant für das Datenbanksystem sind, weder in logischen noch automatisch in physischen Backups. Bei physischen Backups hängt es davon ab, ob die Dateien im Basis-Verzeichnis liegen, was wiederum abhängig davon ist, wie PostgreSQL installiert wurde.

Betreibt man sowohl Produktions- als auch Entwicklungsumgebungen im gleichen Cluster, liegt es durchaus nahe, den klassischen Ansatz zu verfolgen und Backups via »pg_dump« zu ziehen, um nur den Produktionsstand zu sichern und um das Backup nicht unnötig zu vergrößern.

Unvollständige Sicherung

Im Falle eines Crashs kann dann jedoch leicht Wichtiges vergessen oder nicht bedacht werden. Etwa, dass »pg_dump« keine globalen Objekte sichert (Rollen/User, Dictionaries und so weiter). Generell werden in so einem Backup nur datenbankbezogene Elemente gespeichert, aber einige im Backup enthaltene Teile könnten auf globale Elemente zugreifen wollen, die im Recovery fehlen (Shared Objects, Extensions und so weiter).

Um solche Fälle auszuschließen, sollte man im Vorhinein einige Vorkehrungen treffen. Mit pg_dumpall [16] und der Option »--globals-only« lassen sich Rollen und User sichern. Die resultierende Datei muss eigens gespeichert werden. Generell muss man sich auf die Gegebenheiten des verwendeten Datenbanksystems einstellen, Oracle unterscheidet sich diesbezüglich sehr von PostgreSQL und MySQL.

Man sollte sichergehen, dass sämtliche in den Konfigurationsdateien definierte Pfade im Recovery-System vorhanden sind und/oder entsprechende Anpassungen treffen. Denn es kann schnell zu schwerwiegenden Problemen führen, wenn etwa Tablespaces nicht verwendet oder angelegt werden können.

Auch nicht gesetzte Kernel-Parameter sind oft der Grund dafür, warum sich eine Datenbank nach dem Recovery nicht starten lässt. Möglicherweise steht dadurch dann zum Beispiel zu wenig Shared Memory zur Verfügung. Umständlich kann es auch werden, wenn die Datenbank in einem falschen oder unpassenden Locale/Encoding aufgesetzt wurde.

Konfigurationsdateien, die nicht in den Backups enthalten sind, können mittels Tools wie »svn« , »git« und »etckeeper« [17] versioniert werden. Dadurch lassen sich zwei Fliegen mit einer Klappe schlagen, denn die Dateien werden nicht nur gesichert, sondern die Anpassungen können durch die Versionierung zeitlich verfolgt werden.

Ein wichtiger Punkt ist auch, vergleichbare (oder im besten Fall: die gleiche) Hardware für das wiederhergestellte System zu verwenden. Die für das neue Datenbanksystem verwendete Software-Version sollte außerdem nicht allzusehr von der des Originals abweichen. Vor allem bei physischen Backups können unterschiedliche Datenbankversionen schnell zu Inkompatibilitäten führen. Verwendet man logische Backups, sollte sich zwar zwischen Minor-Upgrades nichts Grundlegendes ändern, aber vor einem Umstieg auf die nächste Major-Version, sollte man (gerade im Falle von Disaster Recovery) kein Risiko eingehen. Zumindest muss der Umstieg zuvor ausführlich getestet worden ein.

Recovern üben

Um wirklich auf Nummer sicher zu gehen, sollte (zumindest einmal) ein komplettes Disaster Recovery mit dem Aufsetzen der Datenbank übungshalber geplant, durchgespielt und dokumentiert werden. Schließlich ist nichts unangenehmer, als erst im Ernstfall festzustellen, dass doch nicht alles Notwendige bedacht wurde und man nun entweder vor einem inkonsistenten oder neuen Datenbank-Setup steht oder es gar nicht erst zum Laufen bekommt. Regelmäßige Übungen und Testläufe helfen hier sehr!

Mit Letzteren testet man gleichzeitig Backups: Fehlen Inhalte? Sind womöglich Blöcke defekt? Oracle bietet in diesem Kontext zur Überprüfung von Backups auf defekte Blöcke oder fehlende Dateien etliche Optionen via Oracle RMAN [18].

Nach einer erfolgreichen Inbetriebnahme des Datenbanksystems samt Wiederherstellung der Daten steht immer noch die Frage im Raum, ob alles wieder normal läuft und voll funktionsfähig ist. Gerade das ist meist gar nicht so einfach zu beantworten …

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019