Kontinuierliche, inkrementelle PostgreSQL Backups (auch für Windows)

Was ein gutes Backup-Konzept auszeichnet kann man natürlich nicht pauschal sagen. Fast immer gehören aber kontinuierliche Backups dazu. Schließlich will niemand die Kunden-Bestellungen eines halben Tages verlieren, wenn sich mittags die Server verabschieden. Damit die Backup-Speicher nicht unter der dadurch anfallenden Datenmenge zusammenbrechen, sollten die Backups möglichst auch noch inkrementell sein.

Für diese Wünsche bringt PostgreSQL alle notwendigen Funktionen mit. Alles einzurichten kann aber etwas kompliziert sein. Unter Windows kommen außerdem noch ein paar Fallstricke dazu. Wir zeigen Ihnen daher in diesem kurzen Tutorial die wichtigsten Schritte hin zum Backup und testen anschließend natürlich auch das Recovery.

 

Die Grundlagen

Das Backup-Konzept das wir umsetzen werden, wird als „Continuous Archiving“ bezeichnet. Der Name trifft ziemlich genau, was dabei passiert: PostgreSQL merkt sich ständig in Log-Dateien Änderungen an seinem Datenbestand. Wir schnappen uns diese Logs und kopieren sie regelmäßig in ein Archiv. Wenn dann ein Recovery notwendig wird können wir diese Logs, ausgehend von einem initialen vollständigen Backup, einfach wieder abspielen. Anschließend ist die Datenbank dann wieder auf dem Stand der aktuellsten Log-Datei, was idealerweise kurz vor dem Ausfall ist.

Bei den Logs handelt es sich genau gesagt um „Write Ahead Logs“ (WAL). Änderungen werden von Postgres immer erst in die Logs und dann in den Datenbestand geschrieben. Damit ist sichergestellt, dass die Logs die Datenbank jederzeit wieder in einen konsistenten Zustand bringen können.

Kombiniert wird das Archivieren der WALs mit einem initialen, vollständigen Backup der Data-Files. Dabei handelt es sich im Prinzip einfach um den Inhalt von Postgres‘ data-Ordner. Ein Backup besteht damit immer aus einem vollständigen Data-Files-Backup und den danach angefallenen WALs.

Ein netter Nebeneffekt dieses Backup-Konzepts ist, dass auch Point-In-Time-Recovery möglich ist. Es kann also nicht nur im Fehlerfall der letzte Datenstand wiederhergestellt werden, sondern auch jederzeit der Stand zu einem beliebigen im Backup enthaltenen Zeitpunkt. Praktisch wenn ein Benutzer aus versehen wichtige Daten gelöscht hat.

 

WAL-Archivierung einrichten

Wir beginnen mit dem Archivieren der WALs vor dem initialen Data-Files-Backup. Damit ist sichergestellt, dass die WALs mindestens bis zum vollen Backup zurückreichen. Nur so können sie später auch garantiert wieder abgespielt werden.

Wichtig für die WAL-Archivierung ist das „archive command“. Dieser Befehl wird von Postgres immer dann ausgeführt, wenn eine WAL-Datei gesichert werden soll.

  1.  PostgreSQL beenden
  2. data/postgresql.conf öffnen und einige Werte anpassen
    • wal_level = archive
    • archive_mode = on
    • „archive_command“ setzen
      • unter Windows z.B. archive_command = ‚copy „%p“ „C:\\server\\archivedir\\%f“‚
      • unter Linux z.B. archive_command = ‚test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f‘
    • Falls auf der Datenbank nicht viele Änderungen anfallen, werden WALs nur selten archiviert. Daher kann es evtl. sinnvoll sein ein regelmäßiges Archivieren zu erzwingen:
      archive_timeout = <Sekunden>
      Dabei sollte der Wert nicht zu klein gewählt werden. Archivierte WALs haben eine feste Größe, normalerweise 16 MB, und würden sonst schnell den Speicherplatz aufbrauchen.
  3. PostgreSQL wieder starten. Je nach Datenaufkommen und archive_timeout-Wert sollten jetzt regelmäßig neue Dateien im vom Archive-Command festgelegten Ordnert auftauchen. Dabei handelt es sich um die archivierten WALs.

 

 Initiales Data-Files-Backup

  1. Sicherstellen das WAL-Archivierung läuft
  2. Mit DB verbinden (z.B. mit pgAdmin)
  3. Backup starten mit
    SELECT pg_start_backup(‚label‘, true);
    ‚label‘ ist dabei eine frei wählbare Bezeichnung. Eine gute Wahl ist beispielsweise der Pfad in dem das Backup später gespeichert wird.
  4. Warten bis der Befehl durchgeführt wurde
  5. Den data-Ordner von PostgreSQL in das Backup kopieren. Dabei ist vom einfachen Kopier-Befehl bis zum Verpacken in ein komprimiertes Archiv alles möglich.
    Unter Windows wird es an dieser Stelle aber schwierig: Postgres hat auf einige Dateien Sperren, diese können daher nicht kopiert werden. Die Datenbank zu stoppen, würde aber gleichzeitig das gestartete Backup beenden.
    Als Lösung kann, genau wie z.B. von regulären Backup-Tools, der Volume Shadow Service von Windows verwendet werden. Am einfachsten geht das mit HoboCopy:
    HoboCopy „c:\Program Files\PostgreSQL\9.3\data“ c:\server\basebackup\data /r
  6. Falls Tablespaces in anderen Ordner als data liegen, müssen diese ebenfalls in das Backup kopiert werden.
  7. Backup beenden mit
    SELECT pg_stop_backup();
  8. Fertig

 

Recovery

Wenn das Backup eingerichtet ist, sollte natürlich auch das Wiederherstellen der Daten getestet werden. Das läuft erfreulich einfach ab: Wir kopieren das Data-Files-Backup zurück und sagen Postgres wo es die archivierten WALs findet. Der Rest passiert automatisch.

  1. PostgreSQL stoppen (falls es noch läuft)
  2. Falls Zugriff auf die defekte Datenbank besteht, den data-Ordner sicherheitshalber kopieren
  3. Leere Datenbank bereitstellen
    • Entweder eine neue PostgreSQL-Installation aufspielen oder
    • aus dem data-Ordner der defekten Installation alle Dateien und Ordner löschen
  4. Inhalt des Data-Files-Backup in den data-Ordner der Datenbank kopieren
  5. Alle Dateien aus pg_xlog löschen
  6. Fall in Schritt 2 Dateien aus dem alten pg_xlog-Ordner gerettet werden können diese in den neuen kopieren
  7. Eine neue Datei bin/recovery.conf erstellen. Eine Vorlage dazu befindet sich im Ordner share.
  8. In recovery.conf ein „restore command“ eintragen, das angibt wo die archivierten WALs liegen
    • unter Windows z.B. restore_command = ‚copy „C:\\server\\archivedir\\%f“ „%p“‚
    • unter Linux z.B: restore_command = ‚cp /mnt/server/archivedir/%f %p‘
  9. PostgreSQL starten
  10. Warten bis recovery.conf in recovery.done umbenannt wurde. Das wars.

 

Ein komplettes Backup-Konzept

Auch wenn das in diesem kurzen Tutorial eingerichtete PostgreSQL Backup schon viel wert ist: Zu einem richtigen Backup-Konzept gehört natürlich noch viel mehr. Momentan würden die archivierten WALs irgendwann auch das größte NAS füllen und schon ein fehlendes oder beschädigtes Log alles zum Einsturz bringen. Und wenn dann nach einem Jahr ein Recovery ansteht, wäre die Datenbank tagelang mit dem Zurückspielen der Logs beschäftigt.

Gerne erarbeiten wir daher mit Ihnen ein passendes Backup-Konzept und setzen dies auch für Sie um. Und das nicht nur für PostgreSQL. Nehmen Sie einfach Kontakt mit uns auf!

Kontakt

Veröffentlicht in Allgemein Getagged mit: , , , , , , , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

* Copy This Password *

* Type Or Paste Password Here *