Backups, nicht Burnout: Was wir in Postgresus 2.0 ausgeliefert haben (und was wir gestrichen haben)

\ Es sind 6 Monate seit der ersten Veröffentlichung von Postgresus vergangen. In dieser Zeit erhielt das Projekt 247 Commits, neue Funktionen sowie ~2,8k Sterne auf GitHub und ~42k Downloads von Docker Hub. Die Projektgemeinschaft ist ebenfalls gewachsen, es gibt jetzt 13 Mitwirkende und 90 Personen in der Telegram-Gruppe.

In diesem Artikel werde ich behandeln:

• was sich im Projekt in sechs Monaten geändert hat;
• welche neuen Funktionen erschienen sind
• welche Pläne als nächstes anstehen.

\

Was ist Postgresus?

Für diejenigen, die zum ersten Mal von dem Projekt hören: Postgresus ist ein Open-Source-PostgreSQL-Backup-Tool mit Benutzeroberfläche. Es führt geplante Backups mehrerer Datenbanken durch, speichert sie lokal oder auf externen Speichern und benachrichtigt Sie, wenn Backups abgeschlossen sind oder fehlschlagen.

Das Projekt wird mit einem einzigen Befehl in Docker bereitgestellt. Es kann über Shell-Skript, Docker-Befehl, docker-compose.yml und jetzt auch über Helm für Kubernetes installiert werden. Mehr über Installationsmethoden.

Neben der Hauptfunktion "Backups erstellen" kann das Projekt:

• Backups lokal, in S3, CloudFlare R2, Google Drive, Azure Blob Storage und NAS speichern. Mehr Details hier.
• Statusbenachrichtigungen an Slack, Discord, Telegram, MS Teams, per E-Mail und an einen konfigurierbaren Webhook senden. Mehr Details hier.
• Datenbanken nach Arbeitsbereichen trennen, anderen Benutzern Zugriff gewähren und Audit-Logs speichern. Mehr Details hier.
• Backups und Anmeldedaten verschlüsseln. Mehr Details hier.
• Mit selbst gehosteten Datenbanken und Cloud-verwalteten Datenbanken arbeiten.

Website - https://postgresus.com/

GitHub - https://github.com/RostislavDugin/postgresus (würde mich über einen Stern freuen ⭐️)

Die Projektoberfläche sieht so aus:

Übersichtsvideo: https://www.youtube.com/watch?v=1qsAnijJfJE

Für diejenigen, die an der Entwicklung teilnehmen möchten, gibt es eine separate Seite in der Dokumentation. Wenn jemand dem Projekt helfen möchte, aber nicht programmieren will — erzählen Sie einfach Ihren Kollegen und Freunden von dem Projekt! Das ist auch eine große Hilfe und ein Beitrag zum Projekt.

Ich weiß, wie man entwickelt, aber selbst ein Open-Source-Projekt zu bewerben ist ziemlich schwierig. Das Projekt gewinnt Anerkennung dank derer, die Videorezensionen erstellen und in sozialen Medien über das Projekt sprechen. Vielen Dank!

Neue Funktionen in Version 2.0

In diesen sechs Monaten hat sich viel verändert. Das Projekt wurde in vier Richtungen verbessert:

• erweiterte Grundfunktionalität;
• verbesserte UX;
• neue Funktionen für Teams (DBAs, DevOps, Teams, Unternehmen);
• verbesserte Sicherheit und Verschlüsselung, um Unternehmensanforderungen zu erfüllen.

Gehen wir jede einzelne durch.

1) Datenbank-Zustandsprüfung

Neben Backups überwacht Postgresus jetzt den Datenbankzustand: Es zeigt die Betriebszeit an und warnt Sie, wenn eine Datenbank nicht verfügbar war.

Die Zustandsprüfung kann deaktiviert und konfiguriert werden.

Wenn die Datenbank nicht verfügbar ist — sendet das System eine Benachrichtigung darüber.

2) Neue Quellen zum Speichern von Backups und Senden von Benachrichtigungen

Ursprünglich konnte Postgresus Backups nur lokal und in S3 speichern. Google Drive, CloudFlare R2, Azure Blob Storage und NAS wurden hinzugefügt. Pläne beinhalten das Hinzufügen von FTP und möglicherweise SFTP und NFS.

Für Benachrichtigungen hatte das Projekt ursprünglich Telegram und E-Mail (SMTP). Jetzt werden auch Slack, Discord, MS Teams und Webhooks unterstützt. Darüber hinaus können Webhooks jetzt flexibel konfiguriert werden, um eine Verbindung zu verschiedenen Plattformen herzustellen:

3) Arbeitsbereich- und Benutzerverwaltung

Zuvor hatte das System nur einen Benutzer (Administrator), und Datenbanken waren global für das gesamte System. Jetzt unterstützt Postgresus das Erstellen von Arbeitsbereichen, um Datenbanken zu trennen und Benutzer zu Arbeitsbereichen hinzuzufügen. Mit Rollentrennung:

• nur Ansicht (kann Backup-Verlauf anzeigen, Backup-Dateien herunterladen);
• bearbeiten (kann zusätzlich zum Lesen Datenbanken hinzufügen\löschen\ändern).

Folglich können Sie jetzt Datenbanken trennen:

• Datenbanken des Kunden X;
• Datenbanken des Startups Y;
• Datenbanken des Teams Z;

DBA-Teams und große Outsourcing-Unternehmen begannen, Postgresus zu nutzen, daher wurde dies zu einer wichtigen Funktion. Es macht das Projekt nicht nur für einzelne Entwickler, DevOps oder DBAs nützlich, sondern für ganze Teams und Unternehmen.

Audit-Logs erschienen ebenfalls:

Wenn jemand beschließt, alle Datenbanken zu löschen oder aus irgendeinem Grund alle Backups aller Datenbanken herunterlädt — wird dies sichtbar sein 🙃

4) Verschlüsselung und Schutz

In der ersten Version hatte ich ehrlich gesagt keine Zeit für Sicherheit. Ich speicherte alle Backup-Dateien lokal, niemand hatte Zugriff darauf, und meine Projekte waren nicht gerade streng geheim.

Aber als Postgresus Open Source wurde, lernte ich schnell, dass Teams oft Backups in gemeinsam genutzten S3-Buckets speichern und nicht wollen, dass andere sie lesen. Datenbankpasswörter sollten auch nicht in der eigenen DB von Postgresus gespeichert werden, da viele Personen Zugriff auf seine Server haben. ~~Und es gibt ein gewisses Misstrauen untereinander.~~ Geheimnisse einfach nicht über API preiszugeben, reicht nicht mehr aus.

Daher wurde die Verschlüsselung und Sicherheit des gesamten Projekts zur Hauptpriorität für Postgresus. Der Schutz funktioniert jetzt auf drei Ebenen, und es gibt eine eigene Dokumentationsseite dafür.

1) Verschlüsselung aller Passwörter und Geheimnisse

Alle Datenbankpasswörter, Slack-Tokens und S3-Anmeldedaten werden verschlüsselt in der Datenbank von Postgresus gespeichert. Sie werden nur bei Bedarf entschlüsselt. Der geheime Schlüssel wird in einer separaten Datei von der DB gespeichert, sodass selbst wenn jemand die DB von Postgresus hackt (die ohnehin nicht extern zugänglich ist) — sie immer noch nichts lesen könnten. Die Verschlüsselung verwendet AES-256-GCM.

2) Verschlüsselung von Backup-Dateien

Backup-Dateien werden jetzt auch verschlüsselt (optional, aber Verschlüsselung ist standardmäßig aktiviert). Wenn Sie eine Datei verloren haben oder in öffentlichem S3 gespeichert haben — ist es nicht mehr so beängstigend.

Die Verschlüsselung verwendet sowohl Salt als auch einen eindeutigen Initialisierungsvektor. Dies verhindert, dass Angreifer Muster finden, um den Verschlüsselungsschlüssel zu erraten, selbst wenn sie alle Ihre Backup-Dateien stehlen.

Die Verschlüsselung erfolgt im Streaming-Modus, AES-256-GCM wird auch hier verwendet.

3) Verwendung eines schreibgeschützten Benutzers für Backups

Trotz der ersten beiden Punkte gibt es keine 100%ige Schutzmethode. Es besteht immer noch eine winzige Chance, dass:

• Ihr Server vollständig gehackt wird, sie den geheimen Schlüssel und die legitime IP-Adresse für den Zugriff auf die Datenbank erhalten;
• ein Hacker irgendwie Passwörter in der internen DB von Postgresus entschlüsselt und Ihr Datenbankpasswort herausfindet;
• oder, schlimmer noch, es wird kein Hacker sein, sondern jemand von innen;
• und sie werden Ihre Datenbank beschädigen, nachdem sie zuvor Backups gelöscht haben.

Daher sollte Postgresus Benutzern helfen, Schäden zu minimieren. Die Wahrscheinlichkeit eines solchen Hacks mag nahe Null sein, aber das ist ein schwacher Trost, wenn Sie derjenige sind, dem es passiert.

Wenn Sie jetzt einen Datenbankbenutzer mit Schreibberechtigungen zu Postgresus hinzufügen, bietet das System an, automatisch einen schreibgeschützten Benutzer zu erstellen und Backups darüber auszuführen. Menschen erstellen viel eher eine schreibgeschützte Rolle, wenn es nur einen Klick erfordert, anstatt sie manuell in der Datenbank einzurichten.

So bietet Postgresus an:

Sehr beharrlich bietet es an:

Mit diesem Ansatz, selbst wenn Ihr Postgresus-Server gehackt wird, alles entschlüsselt wird und Angreifer Zugriff auf Ihre DB erhalten — sie werden zumindest nicht in der Lage sein, die Datenbank zu beschädigen. Zu wissen, dass nicht alles verloren ist, ist ein ziemlich guter Trost.

5) Komprimierung standardmäßig, die optimalste

Die erste Version von Postgresus bot alle Komprimierungsalgorithmen an, die PostgreSQL unterstützt: gzip, lz4 und zstd, mit Komprimierungsstufen von 1 bis 9. Ehrlich gesagt, habe ich nicht wirklich verstanden, warum jemand all diese Optionen benötigen würde. Ich habe einfach gzip mit Stufe 5 als vernünftigen Mittelweg gewählt.

Aber als das Projekt Open Source wurde, musste ich das tatsächlich recherchieren. Also habe ich 21 Backups in allen möglichen Kombinationen durchgeführt und den besten Kompromiss zwischen Geschwindigkeit und Größe gefunden.

Jetzt ist standardmäßig für alle Backups zstd mit Komprimierungsstufe 5 eingestellt, wenn die PostgreSQL-Version 16 oder höher ist. Wenn niedriger — immer noch gzip (übrigens, nochmals Dank an die Mitwirkenden für die PG 12-Unterstützung). Hier ist zstd 5 im Vergleich zu gzip 5 (es ist unten):

Im Durchschnitt werden Backups etwa 8-mal im Verhältnis zur tatsächlichen Datenbankgröße komprimiert.

6) Kubernetes Helm-Unterstützung

Dies ist schnell erklärt — wir haben native k8s-Unterstützung mit Helm-Installation hinzugefügt. Teams, die k8s in der Cloud betreiben, können Postgresus jetzt einfacher bereitstellen. Drei Mitwirkende haben bei dieser Funktion geholfen.

7) Dunkles Thema

Ich bin eigentlich kein Fan von dunklen Themen. Aber es gab viele Anfragen, also habe ich eines hinzugefügt (~~Danke Claude für die Hilfe und das Designer-Auge~~). Überraschenderweise stellte es sich besser heraus als das helle Thema und wurde zum Standard. Ich habe sogar die Website von hell auf dunkel umgestaltet — es sah so gut aus.

Vorher:

Nachher:

8) Verzicht auf inkrementelle Backups und PITR (Point In Time Recovery)

Zunächst etwas Kontext:

• Logisches Backup — ist, wenn PostgreSQL selbst seine Daten exportiert (in eine Datei oder Gruppe von Dateien).
• Physisches Backup — ist, wenn wir uns mit der Festplatte von PostgreSQL verbinden und eine Kopie seiner Dateien erstellen.
• Inkrementelles Backup mit PITR-Unterstützung — ist ein physisches Backup + Änderungsprotokoll (WAL), kopiert von der Festplatte oder über das Replikationsprotokoll.

Ich glaubte, Postgresus sollte irgendwann inkrementelle Backups unterstützen. Schließlich ist das, was ernsthafte Tools tun! Selbst ChatGPT sagt, dass ernsthafte Tools mit Präzision bis zur Sekunde und Transaktion wiederherstellen können.

Also begann ich daran zu arbeiten. Aber dann traf mich die Realität:

• Es ist sehr schwer, es in Bezug auf UX und DevEx bequem zu machen. Denn Sie müssen entweder physisch eine Verbindung zur Festplatte mit der DB herstellen oder die Replikation einrichten.

Für die Wiederherstellung — gibt es keine Option, keine Verbindung zur Festplatte mit der Datenbank herzustellen. Um von einem inkrementellen Backup wiederherzustellen, stellt das Backup-Tool einfach den pgdata -Ordner wieder her (genauer gesagt, einen Teil davon).

Wenn die Datenbank wirklich groß ist, zum Beispiel mehrere TB und mehr — ist eine Feinabstimmung in Konfigurationen erforderlich. Hier ist die Benutzeroberfläche eher ein Hindernis als eine Hilfe.

• Die meisten Clouds (AWS, Google, Selectel) funktionieren nicht mit externen inkrementellen Backups, wenn sie Festplattenzugriff erfordern. Theoretisch, mit einigen Umgehungslösungen, über Replikation — werden sie es tun. Aber die Wiederherstellung aus einem solchen Backup in eine verwaltete Cloud wird trotzdem nicht funktionieren.
• Alle Clouds bieten inkrementelle Backups out of the box. Im Allgemeinen ist dies einer der Gründe, warum sie kostenpflichtig sind. Und selbst sie erlauben normalerweise keine Wiederherstellung Sekunde für Sekunde oder zu einem bestimmten Transaktionsmoment. Und wenn Sie nicht in der Cloud sind — ist es noch unwahrscheinlicher, dass Ihr Projekt kritisch genug ist, um eine solche Präzision zu erfordern.

Wenn Postgresus also ein Backup einer verwalteten DB erstellt — reicht es aus, dies ungefähr einmal pro Woche zu tun. Nur für den Fall eines unvorhergesehenen Notfalls oder wenn die Cloud nicht erlaubt, Backups lange genug zu speichern. Andernfalls verlassen Sie sich auf die eigenen inkrementellen Backups der Cloud.

• Für die meisten Projekte sind inkrementelle Backups nicht wirklich notwendig. Für kleine Datenbanken ist eine Granularität zwischen Backups von einer Stunde ausreichend, wenn häufig benötigt. Für große — mindestens einmal täglich. Dies reicht für 99% der Projekte aus, um verlorene Daten zu finden oder vollständig wiederherzustellen. Diese Bedürfnisse werden vollständig durch logische Backups abgedeckt.

Aber wenn Sie eine Bank oder ein Entwickler einer verwalteten DB sind, benötigen Sie wirklich die feinste Backup-Konfiguration für Ihre Dutzende und Hunderte von Terabytes an Daten. Hier wird Postgresus niemals physische Backups von WAL-G oder pgBackRest in Bezug auf Konsolenkomfort und Effizienz für DBs mit einem Volumen in TB und mehr übertreffen. Aber meiner Meinung nach sind dies bereits spezialisierte Tools für solche Aufgaben, erstellt von Genies und Maintainern von PostgreSQL selbst.

Meiner Meinung nach werden inkrementelle Backups wirklich in zwei Fällen benötigt:

• In der Vergangenheit, als es nicht eine solche Auswahl an Cloud-verwalteten Datenbanken gab und große Projekte erforderten, alles selbst zu hosten. Jetzt haben dieselben Banken, Marktplätze und Telekommunikationsunternehmen interne Clouds mit PITR out of the box.
• Sie sind eine verwaltete Cloud. Aber hier ist die Aufgabe radikal komplexer als nur Backups zu erstellen und von ihnen wiederherzustellen.

In Anbetracht all dessen habe ich eine bewusste Entscheidung getroffen, die Entwicklung inkrementeller Backups einzustellen. Stattdessen konzentriere ich mich darauf, logische Backups so bequem, zuverlässig und praktisch für den täglichen Gebrauch durch Entwickler, DevOps, DBAs und Unternehmen zu machen.

9) Viele kleine Verbesserungen

Die obigen Punkte sind bei weitem nicht alles. 80% der Arbeit ist normalerweise nicht sichtbar. Aus dem Stegreif hier eine kurze Liste:

• Pufferung und RAM-Optimierung. Postgresus versucht nicht mehr, alles zu puffern, was pg_dump sendet, während es darauf wartet, dass S3 aufholt (das Herunterladen aus der Datenbank ist normalerweise schneller als das Hochladen in die Cloud). Die RAM-Nutzung ist jetzt auf 32 MB pro parallelem Backup begrenzt.
• Verschiedene Stabilitätsverbesserungen und kleinere Fehlerbehebungen.
• Hinzufügen von SMTP ohne Benutzernamen und ohne Passwort. Ich wusste nicht einmal, dass das passiert…
• Hinzufügen von Themen für das Senden von Benachrichtigungen an Telegram-Gruppen.
• Dokumentation erschien!
• PostgreSQL 12-Unterstützung.

Und vieles mehr.

Was hat nicht funktioniert?

Natürlich klappt nicht alles und einige Dinge müssen aufgegeben werden. Ich baue Postgresus in meiner Freizeit auf, die kaum existiert. Also kann ich mich nicht zu dünn ausbreiten oder die UX mit unnötigen Funktionen verkomplizieren. Zu viele Funktionen sind auch schlecht.

1) Vollständige Datenbankressourcenüberwachung

Ich wollte Postgresus auch zu einem PostgreSQL-Überwachungstool machen. Einschließlich Systemressourcen des Servers, auf dem PostgreSQL läuft:

• CPU
• RAM
• ROM
• IO-Geschwindigkeit und -Last

Ich habe sogar die Basis für das Sammeln von Metriken (beliebige) und eine Vorlage für Grafiken erstellt:

Es stellt sich heraus, dass PostgreSQL nur RAM-Nutzung und IO-Metriken out of the box offenlegt.

Die Überwachung anderer Ressourcen erfordert Erweiterungen. Aber nicht jede Datenbank kann die Erweiterungen installieren, die ich benötige, also konnte ich nur teilweise Metriken sammeln. Dann entdeckte ich, dass Cloud-Datenbanken oft überhaupt nicht erlauben, Erweiterungen zu installieren.

Dann erkannte ich, dass Metriken in VictoriaMetrics oder zumindest TimescaleDB gespeichert werden sollten, nicht in Postgresus' eigenem PostgreSQL, was den Image-Build komplizieren würde.

Am Ende würde diese nicht wesentliche Funktion hinzufügen:

• erhebliche Codekomplexität, was eine schwierigere Wartung bedeutet;
• mehr Image-Build-Anforderungen (zusätzliche Komponenten);
• komplizierte UX (wie ich sagte, zu viele Funktionen sind schlecht);
• ~~unklare Positionierung: sind wir ein Backup-Tool, ein Überwachungstool oder versuchen wir, alles zu tun?~~

Also habe ich die Ressourcenüberwachung aufgegeben und mich darauf konzentriert, Postgresus zum besten Backup-Tool zu machen, das es sein kann.

2) SQL-Konsole

Ich wollte auch eine SQL-Konsole hinzufügen. Da Postgresus bereits mit der DB verbunden ist, warum nicht direkt von dort Abfragen ausführen? Es wäre bequem — keine Notwendigkeit, jedes Mal PgAdmin, DataGrip oder DBeaver zu öffnen.

Ich habe nie Zeit gefunden, daran zu arbeiten, nur geplant. Ein Mitwirkender begann mit der Funktion und erstellte einen PR. Aber wie erwartet bei komplexen Funktionen kamen viele Anforderungen und Randfälle auf:

• Notwendigkeit, SQL-Syntax-Unterstützung hinzuzufügen;
• Autovervollständigung und Hinweise hinzufügen;
• Lazy Loading implementieren, damit nicht einmal 100MB an Zeilen zum Browser kommen;
• mindestens mehrere Exporte nach CSV und XLSX hinzufügen.

Das ist im Grunde ein eigenes vollständiges Projekt, nicht nur ein Tab.

Wir haben beschlossen, die Funktion aufzugeben und den Aufwand zu sparen. Dies stellte sich als der richtige Anruf heraus, da wir schreibgeschützte Rollen hinzugefügt haben, die INSERT, UPDATE und DELETE sowieso nicht erlauben.

Fazit

Das ist die Reise, die Postgresus in sechs Monaten gemacht hat. Es entwickelte sich von einem Nischenprojekt zu einem Tool auf Unternehmensebene, das sowohl einzelnen Entwicklern als auch ganzen DBA-Teams hilft (ich war übrigens überrascht, dies nur ~2 Monate nach der ersten Veröffentlichung zu erfahren). Ich bin wirklich froh, dass Tausende von Projekten und Benutzern auf Postgresus vertrauen.

Das Projekt hört hier nicht auf. Mein Ziel ist es jetzt, Postgresus zum bequemsten PostgreSQL-Backup-Tool der Welt zu machen. Es gibt einen großen Rückstand an Funktionen und Verbesserungen, die nach und nach kommen.

Meine Hauptprioritäten bleiben:

• Projektsicherheit — dies ist kritisch, ohne sie macht alles andere keinen Sinn;
• bequeme UX in Bezug auf die Nutzung des Projekts selbst und kein Übermaß an Funktionen (wir erledigen eine Aufgabe, aber sehr gut);
• bequeme UX in Bezug auf die Bereitstellung: so dass alles mit einem Befehl bereitgestellt wird und nichts out of the box konfiguriert werden muss;
• Projektoffenheit — vollständig Open Source und kostenlos für jede Person oder jedes Unternehmen.

Wenn Ihnen das Projekt gefällt oder Sie es nützlich finden — würde ich mich über einen Stern auf GitHub oder das Teilen mit Freunden freuen ❤️

\