pgBackRest wird nicht mehr weiter gepflegt

 (github.com/pgbackrest)
3 Punkte von GN⁺ 14 일 전 | 2 Kommentare | Auf WhatsApp teilen
  • Als Backup- und Restore-Tool für PostgreSQL wurde es dafür entwickelt, bis in große Umgebungen zu skalieren, doch nun wird die Wartung eingestellt
  • Bugfixes, PR-Reviews, Issue-Bearbeitung und die Entwicklung neuer Funktionen wurden allesamt eingestellt; statt das Projekt unregelmäßig weiterzuschleppen, fiel die Entscheidung für einen klaren Stopp
  • Unterstützt vollständige, differenzielle und inkrementelle Backups sowie block-level backup, das Fortsetzen unterbrochener Aufgaben und delta restore, sodass nur geänderte Teile gespeichert und wiederhergestellt werden
  • Verfügt über eine protocol layer für lokale und entfernte Umgebungen sowie multiple repositories und erweitert den Einsatzbereich über TLS-/SSH-Verbindungen und S3-, Azure- und GCS-kompatible Object Stores
  • Es war ein Tool mit umfassenden Mechanismen zur Integritätssicherung wie Checksum, Warten auf WAL-Segmente, fsync und Prüfung von Page Checksums, doch selbst wenn künftig ein Fork erscheint, muss dafür neues Vertrauen erst separat aufgebaut werden

Ende der Wartung und Projektstatus

  • pgBackRest ist ein Backup- und Restore-Tool für PostgreSQL, wird derzeit jedoch nicht mehr weiter gepflegt
  • Es wurde bekannt gegeben, dass die Arbeiten am Projekt eingestellt wurden und künftig keine Zeit mehr in Bugfixes, PR-Reviews, Issue-Bearbeitung oder die Entwicklung neuer Funktionen investiert wird
  • Auch nach dem Wegfall bisheriger Sponsoring- und Beschäftigungsformen sollte die Wartung weitergeführt werden, doch es konnten nicht genügend berufliche Möglichkeiten und Sponsoring gesichert werden, um das Projekt aufrechtzuerhalten
  • Statt die Wartung unregelmäßig oder unvollständig fortzusetzen, wurde ein klarer Abschluss als die bessere Lösung angesehen
  • Künftig könnte zwar jemand einen Fork erstellen, doch dieser würde als neues Projekt gelten, und neue Maintainer müssten sich Vertrauen separat erst aufbauen

Zentrale Funktionen des Projekts

  • Ziel ist Backup und Restore, skalierbar bis in große PostgreSQL-Umgebungen; die aktuelle stabile Version ist v2.58.0
  • Das Design nutzt Parallelisierung und Komprimierungsverfahren wie lz4 und zstd, um die bei Backups oft zum Flaschenhals werdenden Komprimierungskosten zu senken
  • Unterstützt vollständige, differenzielle und inkrementelle Backups und speichert nicht nur auf Dateiebene, sondern per block-level backup auch nur geänderte Teile, um Speicherplatz zu sparen
  • Unterbrochene Backups können fortgesetzt werden, und durch den Vergleich mit den Checksummen im Manifest wird die Integrität bereits kopierter Dateien erneut geprüft
  • Bei delta restore werden zuerst Dateien entfernt, die nicht im Backup enthalten sind; anschließend werden die Checksummen der verbleibenden Dateien verglichen, sodass passende Dateien unverändert bleiben und nur benötigte Dateien wiederhergestellt werden

Remote-Betrieb und Repository-Design

  • Über eine eigene protocol layer können Backup-, Restore- und Archivierungsaufgaben sowohl lokal als auch remote ausgeführt werden; für Remote-Verbindungen werden TLS/SSH verwendet
  • Dieselbe protocol layer stellt auch eine PostgreSQL-Abfrageschnittstelle bereit, sodass Arbeiten möglich sind, ohne direkt remote auf PostgreSQL zuzugreifen, was die Sicherheit erhöht
  • Unterstützt multiple repositories, sodass sich ein lokales Repository für schnelle Wiederherstellung und ein entferntes Repository für Langzeitaufbewahrung und Redundanz gemeinsam betreiben lassen
  • Repositories können auch in S3-, Azure- und GCS-kompatiblen Object Stores liegen, wodurch sich Kapazität und Aufbewahrungsdauer deutlich erweitern lassen
  • Das Repository selbst kann verschlüsselt werden, sodass Backup-Daten unabhängig vom Speicherort geschützt bleiben

Mechanismen zur Sicherung von Integrität und Konsistenz

  • Für alle Dateien eines Backups wird eine checksum berechnet und bei Restore oder Verify erneut geprüft
  • Nach Abschluss des Kopiervorgangs wird gewartet, bis alle für einen konsistenten Backup-Zustand erforderlichen WAL-Segmente im Repository angekommen sind
  • In allen Vorgängen werden fsync auf Datei- und Verzeichnisebene verwendet, um Dauerhaftigkeit sicherzustellen
  • Wenn in PostgreSQL Page Checksums aktiviert sind, werden bei vollständigen Backups die Page Checksums aller Dateien geprüft und bei differenziellen bzw. inkrementellen Backups nur die geänderten Dateien
  • Selbst wenn die Prüfung von Page Checksums fehlschlägt, wird das Backup nicht abgebrochen; stattdessen wird vermerkt, welche Seiten betroffen sind, damit page-level corruption früh erkannt werden kann, bevor ein gültiges Backup abläuft

WAL-Verarbeitung und Optimierung der Restore-Performance

  • Es gibt eigene Befehle für WAL push/get; beide unterstützen Parallelisierung und asynchrone Ausführung und sind darauf ausgelegt, die PostgreSQL-Antwortzeit so kurz wie möglich zu halten
  • WAL push entfernt Duplikate automatisch, wenn dasselbe WAL-Segment mehrfach eingeht, und erzeugt einen Fehler, wenn sich die Inhalte unterscheiden
  • Asynchrones WAL push überträgt die Übertragung an andere Prozesse, die WAL-Segmente parallel komprimieren; das ist besonders wichtig für Datenbanken mit sehr hohem Schreibvolumen
  • Asynchrones WAL get hält lokal eine dekomprimierte WAL queue vor, damit diese vor dem Replay sofort bereitgestellt werden kann; das bringt besonders bei Verbindungen mit hoher Latenz oder bei Speichern wie S3 Vorteile
  • Sowohl WAL push als auch get vergleichen PostgreSQL-Version und System Identifier, um zu prüfen, ob Datenbank und Repository zusammenpassen, wodurch sich Fehlkonfigurationen des WAL-Archivpfads stark reduzieren lassen

Betriebliche Flexibilität und Kompatibilität

  • Richtlinien für Backup-Aufbewahrung und archive expiration lassen sich getrennt nach vollständigen, differenziellen und WAL-Backups konfigurieren und decken so den gewünschten Zeitraum ab
  • Backups können im nativen PostgreSQL-Cluster-Format gespeichert werden; wenn die Komprimierung deaktiviert und Hardlinks aktiviert sind, lässt sich der PostgreSQL-Cluster auch direkt auf einem Repository-Snapshot starten
  • Dieser Ansatz ist vorteilhaft bei terabyte-scale database-Umgebungen, in denen ein traditionelles Restore viel Zeit benötigt
  • tablespace wird vollständig unterstützt; beim Restore kann jeder Tablespace an einen anderen Ort verschoben oder gesammelt auf ein Ziel remappt werden
  • Auch Datei- und Verzeichnis-Links werden unterstützt, sodass beim Restore die ursprüngliche Position beibehalten, ein teilweises oder vollständiges Remapping durchgeführt oder eine Wiederherstellung als normale Dateien bzw. Verzeichnisse erfolgen kann
  • Unterstützt 10 PostgreSQL-Versionen und umfasst die aktuell unterstützten 5 Versionen sowie die zuletzt EOL gegangenen 5 Versionen, um ausreichend Zeit für Upgrades zu schaffen

Referenzressourcen und Sponsoring-Status

Verwandte Beiträge

2 Kommentare

 
xguru 7 일 전

Dazu gab es ein Update.

  • Nach der Ankündigung, die Wartung von pgBackRest einzustellen, wurde das Postfach überflutet
  • Es gab viele unterstützende Nachrichten
  • Durch einen Zusammenschluss mehrerer Sponsoren erhält pgBackRest nun finanzielle Unterstützung, sodass das Projekt fortgeführt werden kann
  • Zusätzlich wird ein weiterer Maintainer an Bord geholt, um die Arbeitslast zu verteilen und die Kontinuität des Projekts zu sichern
  • Die aktuelle Version von pgBackRest funktioniert derzeit normal, und da es keine schwerwiegenden Bugs oder Sicherheitsprobleme gibt, besteht kein unmittelbarer Bedarf, das Projekt zu forken
  • Es wird aktiv daran gearbeitet, pgBackRest wieder zu beleben
 
GN⁺ 14 일 전
Hacker-News-Kommentare
  • Wenn man sich den LinkedIn-Beitrag des Autors ansieht, wird klar, wie viel Zeit und Herzblut er 13 Jahre lang in pgBackRest gesteckt hat, und dass er nun beschlossen hat, die Wartung einzustellen
    Es gab zwar Unterstützung durch ein Unternehmen, aber er hat auch Nächte und Wochenenden geopfert. Nach dem Verkauf von Crunchy Data hat er die Pflege zunächst fortgesetzt und gleichzeitig nach einer Möglichkeit gesucht, diese Arbeit beruflich weiterzuführen, doch das hat nicht geklappt
    Um seinen Lebensunterhalt zu sichern, müsse er sich nach breiteren Möglichkeiten umsehen, und dann könne er die Zeit für Wartung, Bugfixes, PR-Reviews und Issue-Bearbeitung nicht mehr aufbringen; deshalb wolle er das Repository archivieren
  • Ich habe pgBackRest in privaten Projekten genutzt, sogar so intensiv, dass ich einen PostgreSQL-Backup-Leitfaden für lokale Volumes und Cloud-Speicher geschrieben habe, und finde es schade, dass es so endet
    Der Leitfaden ist https://github.com/freakynit/postgre-backup-and-restore-guide, und ich bin wirklich dankbar für all die Zeit und Mühe, die hineingeflossen sind
    • Ich denke, dass Entwickler heute wegen der AI-Erwartungen unter noch härteren Deadlines leiden und dadurch weniger Zeit haben
      Dazu kommt, dass viele Leute Geld in Tokens verbrannt haben, sodass oft sowohl freies Kapital als auch freie Zeit knapper geworden sind
    • Ich hoffe, dass Projekte wie dieses nicht weiter verschwinden, weil sie keine Finanzierung bekommen, und finde die realen Schwierigkeiten von OSS einfach viel zu groß
  • Hier ist nicht das Open-Source-Modell selbst gescheitert; der Autor findet schlicht keine weitere finanzielle Unterstützung und ändert deshalb seinen Kurs, was völlig nachvollziehbar ist
    Wenn das hier ein Tool auf Produktniveau war, das über ein Hobbyprojekt hinaus in kommerziellen Umgebungen echten Wert geliefert hat, dann gibt es sicher auch eine Chance für ein gewinnorientiertes Unternehmen, diese Lücke zu füllen
    Nutzer müssen dann aber zu Kunden werden und tatsächlich bezahlen; es ist nicht nachhaltig, weiterhin Bugreports und Beschwerden an kostenlose Maintainer zu schicken
    Es braucht neue Lösungen für die finanzielle Nachhaltigkeit von FOSS, und Spenden allein scheinen nicht auszureichen
    • Ich habe gelernt, dass man in jedem Ökosystem, wenn einem etwas wichtig ist, es selbst unterstützen muss, damit es überlebt
      Das gilt gleichermaßen für den Laden um die Ecke wie für ein Open-Source-Projekt
    • Ich frage mich, ob der Autor geprüft hat, daraus ein Bezahlprodukt zu machen
      Allerdings könnten je nach Beitragsleistenden Urheberrechte betroffen sein, sodass man je nach ACL und Rechtsraum Rechte klären und sich möglicherweise auch über Gewinnverteilung einigen müsste
  • Ich finde, die Leute sollten den Teil mit der Crunchy-Data-Übernahme stärker beachten
    Solange es Unternehmensförderung gab, lief alles, aber nachdem die Firma verkauft wurde und der neue Eigentümer die Prioritäten verschob, wurde ein Infrastruktur-Tool mit 3.8k Stars sofort instabil. Die Nutzer wussten also gar nicht, dass die Finanzierung ihres Backup-Tools von der M&A-Strategie anderer abhing
    Deshalb bewege ich mich selbst schrittweise eher in Richtung Dateien, die mit SQLite und git nachverfolgt werden
    Auch Managed-Postgres-Stacks bauen am Ende auf mehreren Tools auf, die von Leuten gepflegt werden, deren Finanzierungslage man nicht kennt
    • Ganz verschwunden ist es nicht, und zumindest brechen Backups nicht sofort einfach weg
      Der übergeordnete Punkt, dass die Finanzierungsstruktur fragil ist, bleibt aber trotzdem richtig
    • Allerdings ist auch SQLite nicht vollständig vor demselben Risiko geschützt; mich würde interessieren, warum es als sicherer angesehen wird
  • Der Quellcode ist ja noch da, also sollte man nicht nur bedauern, sondern kann selbst forken und die Pflege übernehmen oder jemanden dafür bezahlen
    Bei der Gelegenheit sollte man sich auch die Projekte anschauen, von denen man ungern abhängt, und am besten sofort Unterstützung einrichten
    • Ich halte diese Haltung für richtig
      Alle sagen, sie seien traurig, aber wenn man wirklich traurig ist, sollte man sich zuerst fragen, ob man traurig genug zum Spenden ist
  • Soweit ich das Ökosystem richtig überblicke, war pgBackRest die beste Lösung im Bereich PostgreSQL-Backups
    Besonders selten war, dass nicht nur Backups, sondern auch Wiederherstellung und Verifikation ernst genommen wurden; ich habe im Job schon einmal große Probleme erlebt, weil genau das vernachlässigt wurde
    Mehr dazu steht hier: https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
    Deshalb fühlt sich das wie ein ziemlich großer Verlust an
  • Ziemlich überraschend, ich hatte das praktisch für das Standard-Tool für PG-Backup/Recovery gehalten
    Mich würde interessieren, wie es im Vergleich zu WAL-G oder Barman abschneidet
    https://github.com/wal-g/wal-g
    https://github.com/EnterpriseDB/barman
    • Ich kann keinen exakten Vergleich liefern, aber wir nutzen Barman schon lange und sind sehr zufrieden
      Wir erstellen jede Nacht mit Barman eine wiederhergestellte Nightly-DB und verwenden sie auch für User-Training und Tests, sodass wir fortlaufend prüfen, ob die Backups tatsächlich beschädigt sind; seit Jahren gab es kein Problem
    • Ich bin einer der wal-g-Maintainer und halte es funktional für absolut konkurrenzfähig
      Nach einigen Jahren Inaktivität bin ich wieder in den Bereich Managed Postgres zurückgekehrt und hoffe, dass zusätzlich zu den Delta-Backups über den eigenen Blockvergleich von wal-g auch pg17 incremental backup unterstützt wird
      Und den Daemon-Modus sollte man wirklich nutzen
      Es ist schade, wenn ein Konkurrenztool verschwindet, aber in diesem Bereich gibt es noch viel Verbesserungspotenzial, und wenn Postgres auf einem System ohne Overcommit laufen möchte, hat C gegenüber Golang auch seine Vorteile
    • Wir haben früher WAL-E und heute zufrieden den Nachfolger WAL-G genutzt
      Als wir das vor etwa 9 Jahren evaluiert haben, fanden wir es wegen der Streaming-PITR-Eigenschaften attraktiver als pgBackRest
    • Ich verstehe, warum man es für das Standardtool hielt, aber ich muss auch an eine Situation wie https://xkcd.com/2347/ denken
  • Ich habe pgBackRest auf einer 2-TB-Produktions-DB zufrieden genutzt und wollte es ausgerechnet diese Woche auch an eine 8-TB-DB hängen
    Jetzt frage ich mich, ob die nächstliegende Alternative wal-g, barman oder databasus ist
    Ich sage zwar gern, dass ich nur so tue, als wäre ich DBA, aber in Wirklichkeit ist die Auswahl ziemlich wichtig
    • Ich habe Barman bei 30TB+-Datenbanken eingesetzt und hatte nichts zu beanstanden
      Zur Einordnung: Ich bin DBRE
    • Wenn du Multi-Terabyte-Produktiv-Postgres sicherst, dann ist das nicht bloß so tun als ob DBA, dann machst du das schon ziemlich ernsthaft
    • Wenn du Backups in Cloud-Speicher ablegst, dann ist Barman mit Hook-Skripten wahrscheinlich die naheliegendste Alternative
      Die passende Doku ist https://docs.pgbarman.org/release/3.18.0/user_guide/hook_scripts.html#hook-scripts-using-barman-cloud-scripts-as-hooks-in-barman
      https://github.com/aiven-open/pghoard sieht ebenfalls gut aus, ich habe es aber noch nicht selbst verifiziert
    • Mich würde auch interessieren, ob jemand schon einmal einen Standby auf ZFS oder einem anderen snapshotfähigen Dateisystem betrieben und darüber Backups gemacht hat
    • Ich hatte pgBackRest noch nie verwendet und habe vor genau 2 Stunden erst angefangen, es in einem Projekt einzusetzen; als ich das README fertig gelesen hatte, war die Meldung schon aktualisiert
  • pgBackRest gehört unter den PostgreSQL-Backup-Technologien zu den vielseitigsten, und meiner Erfahrung nach kommen andere Produkte da nicht ganz mit
    Deshalb ist das umso bedauerlicher, und es dürfte nicht leicht werden, bei diesem großartigen Tool Funktionsgleichheit zu erreichen
    Hoffentlich ist das eine Entscheidung, die sich noch rückgängig machen lässt; andernfalls wäre es vielleicht gut, wenn das PostgreSQL-Projekt es als contrib übernehmen würde
  • Es ist weiterhin nutzbar, also kann man es erst einmal einfach weiterverwenden
    Ich denke, der Autor würde wahrscheinlich auch lieber sehen, dass die Leute es weiter nutzen, bis es wirklich nicht mehr funktioniert, statt es sofort aufzugeben
    • Und bis dahin wäre es schön, wenn sich jemand als neuer Maintainer findet
      Ich weiß nur nicht, ob dafür ein Fork nötig ist oder ob jemand als Mitwirkender in das bestehende Repository aufgenommen werden könnte, um es weiterzuführen