Databasus: PostgreSQL-Backups mit Point-in-Time-Recovery selbst betreiben

PostgreSQL-Sicherung mit PITR als Kernversprechen

Databasus ist ein freies, selbst gehostetes Werkzeug zur Sicherung von PostgreSQL, das im README mit Point-in-Time-Recovery bei niedrigem RPO und RTO wirbt. Die Repository-Metadaten vom 28. August 2026 weisen 8345 Sterne, 516 Forks und 5 offene Issues aus, die neueste Veröffentlichung trägt die Versionsnummer v3.55.2. Entwickelt ist das Werkzeug in Go, verteilt wird es als Docker-Image.

Interessant ist der Sprung über PostgreSQL hinaus: MySQL 5.7 bis 9, MariaDB 10 bis 12 und MongoDB ab 4.2 bis 8 werden ebenfalls unterstützt, aber nur logisch gesichert. Physische Sicherungen mit Inkrementen und WAL-Streaming bleiben der Domäne von PostgreSQL 14, 15, 16, 17 und 18 vorbehalten. Wer eine heterogene Umgebung mit mehreren Engines betreibt, bekommt also ein Werkzeug für alle, mit deutlich tieferer Funktionalität auf der PostgreSQL-Seite.

Physische und logische Sicherungstypen im Vergleich

Beim Sicherungstyp unterscheidet das README zwei Familien. Physische Sicherungen kopieren den gesamten Datenbankcluster auf Dateiebene über den nativen inkrementellen Mechanismus von PostgreSQL: eine vollständige, in sich geschlossene Kopie, dann Inkremente, die nur Änderungen seit der letzten Vollsicherung speichern, was Sicherungen klein und schnell hält. Ergänzt wird WAL-Streaming, das den Schreibstrom der Datenbank fortlaufend aufzeichnet und damit die Point-in-Time-Recovery ermöglicht, gedacht für Katastrophenfälle mit nahezu null Datenverlust.

Logische Sicherungen sind ein nativer Dump im binären Format der jeweiligen Engine, komprimiert und für paralleles Zurückspielen geeignet. Sie reichen für MySQL, MariaDB und MongoDB, aber sie erlauben naturgemäß keine Wiederherstellung auf einen beliebigen Zeitpunkt wie ein WAL-Stream. Die Wahl des Typs hängt also direkt an der Datenbank-Engine und an der Frage, wie viele Sekunden Datenverlust akzeptabel sind.

Restore-Verifikation: ein echter Restore statt Prüsumme

Ein eigenes Feature widmet sich der Frage, ob eine Sicherung im Ernstfall wirklich funktioniert. Databasus führt dazu eine echte Wiederherstellung aus: Es startet einen Datenbankcontainer, spielt die Sicherung dort zurück und gleicht die Größe der wiederhergestellten Datenbank mit der Sicherung ab. Der Bericht listet am Ende jede Tabelle mit ihrer Zeilenzahl auf. Ein Checksummenvergleich oder die bloße Intaktheit der Dateien auf dem Datenträger ersetzt das laut README bewusst nicht.

Auslöser für so eine Prüfung sind entweder jede abgeschlossene Sicherung oder ein eigener Zeitplan, von stündlich bis monatlich oder als cron-Ausdruck. Der Bericht lässt sich über jeden konfigurierten Meldeweg verschicken, alternativ nur bei Fehlern alarmieren. Für Betreiber ist das der direkteste Nachweis, dass eine Wiederherstellung messbar durchläuft, bevor sie im echten Störfall gebraucht wird.

Aufbewahrung nach GFS und Größenlimits

Die Aufbewahrungsregeln arbeiten mit vier Mechanismen, die sich kombinieren lassen. Nach Zeitraum bleiben Sicherungen für eine feste Dauer erhalten, etwa sieben Tage, drei Monate oder ein Jahr. Nach Anzahl hält das Werkzeug eine feste Zahl der jüngsten Sicherungen vor, zum Beispiel die letzten dreißig. Das GFS-Schema, Grandfather-Father-Son, legt stündliche, tägliche, wöchentliche, monatliche und jährliche Sicherungen unabhängig voneinander in Schichten ab, wie es Unternehmen für langfristige Historien verlangen.

Dazu kommen Größenlimits pro Sicherung und für den gesamten Speicherbedarf, mit denen sich der Platzverbrauch begrenzen lässt. Die Kompressionswerte nennt das README als Beispielspanne: 4 bis 8 Ersparnis bei ausgewogener Kompression mit rund 20 Prozent Aufwand bei der Wiederherstellung. Wer hohe Datenmengen an hässlichen Speicherkosten scheitern sieht, kann über diese Stellschrauben das Gleichgewicht zwischen Historientiefe und Speicherplatz selbst justieren.

Verschlüsselung, read-only-Zugriff und Teameinbindung

Sicherungsdateien werden laut README mit AES-256-GCM verschlüsselt und bleiben so in geteilten Speichern wie S3 oder Azure Blob Storage für Angreifer nutzlos, selbst wenn ihnen der Speicher entfällt. Für den Zugriff auf die gesicherte Datenbank verwendet Databasus standardmäßig einen Nur-Lese-Nutzer und speichert nichts, was Daten verändern könnte. Zugangsdaten werden verschlüsselt gehalten und dürfen laut Angabe weder in Logs noch in Fehlermeldungen auftauchen. Ein eingebautes SSH-Tunnel-Feature verbindet das Werkzeug über eine verschlüsselte Verbindung mit der Zielinstanz.

Für Teams gibt es Workspaces, in denen Datenbanken, Meldewege und Speicher nach Projekten gruppiert werden. Rollenbasierte Berechtigungen steuern, wer Datenbanken sehen oder verwalten darf, mit den Stufen Viewer, Member, Admin und Owner. Ein Audit-Protokoll zeichnet alle Aktivitäten auf und lässt sich über OpenTelemetry an ein externes System exportieren, parallel dazu schreibt das Werkzeug standardmäßig eine lokale Logdatei.

Speicherziele und Meldewege für den Operationbetrieb

Als Speicherziele nennt das README lokale Ablage auf dem eigenen Server sowie S3, Cloudflare R2, Google Drive, NAS, Dropbox, SFTP und Rclone. Die Daten bleiben dadurch auf der eigenen Infrastruktur, was das Projekt als Datenschutzargument führt. Die Kombination aus verschlüsselten Sicherungen und einem beliebigen Cloud-Speicher erlaubt es, Offsite-Kopien zu führen, ohne der Cloud-Plattform lesbare Datenbestände zu hinterlassen.

Auf der Meldeseite stehen Email, Telegram, Slack, Discord, Teams, Mattermost und generische Webhooks bereit, mit Echtzeit-Updates über Erfolg und Misserfolg. Für DevOps-Workflows bedeutet das, dass bestehende Alarmkanäle weitergenutzt werden können, statt einen eigenen Benachrichtigungspfad für Backups zu pflegen. Eine mobil angepasste Oberfläche mit dunklem und hellem Thema erlaubt den Blick auf den Sicherungsstatus von unterwegs.

Installation per Skript, Docker oder Helm

Vier Installationswege sind dokumentiert: ein automatisiertes Skript als empfohlener Weg nur für Linux, ein einfacher Docker-Run, ein Docker-Compose-Setup und Kubernetes mit Helm. Das Skript installiert bei Bedarf Docker samt Compose, richtet Databasus ein und konfiguriert den automatischen Neustart nach Systemboot; im README steht dafür der Befehl mit sudo curl -sSL auf das Skript install-databasus.sh im main-Zweig des Repositorys.

Der direkteste Weg ist ein einziger Docker-Befehl: docker run -d --name databasus -p 4005:4005 -v ./databasus-data:/databasus-data --restart unless-stopped databasus/databasus:latest. Alle Daten landen dabei im lokalen Verzeichnis ./databasus-data, der Port ist 4005. Wer von Docker Hub gedrosselt wird, greift auf das identische Image ghcr.io/databasus/databasus:latest von der GitHub-Registry zurück. Lizenziert ist das Projekt unter Apache 2.0.

Redaktionelles Fazit

Databasus richtet sich an Teams, die PostgreSQL-14- bis 18-Cluster mit PITR sichern wollen und dabei S3, R2, Google Drive oder SFTP als Ziele sowie Telegram, Slack oder Discord als Meldeweg nutzen. Da alle Daten auf der eigenen Infrastruktur bleiben, lohnt sich das Werkzeug besonders bei restriktiven Datenschutzvorgaben; vor dem produktiven Start sollte der Wiederherstellungsbericht mit Zeilenzahlen pro Tabelle gegen eine Testinstanz gefahren werden.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes