pgBackRest wird nicht länger gewartet

 (github.com/pgbackrest)
3 Punkte von GN⁺ 2 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Als Backup- und Restore-Tool für PostgreSQL konzipiert und auf den Einsatz bis in große Umgebungen skalierbar, wird es nun nicht weiter gewartet
  • Bugfixes, PR-Reviews, Issue-Bearbeitung und die Entwicklung neuer Funktionen wurden vollständig eingestellt; statt das Projekt unregelmäßig weiterzuschleppen, wurde ein klarer Stopp gewählt
  • Unterstützt vollständige, differenzielle und inkrementelle Backups sowie block-level backup, das Fortsetzen unterbrochener Vorgänge und delta restore, sodass nur geänderte Teile gespeichert bzw. 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 mit S3-, Azure- und GCS-kompatiblen Object Stores
  • Es war ein Tool mit umfassenden Mechanismen zur Sicherung der Integrität wie checksum, Warten auf WAL-Segmente, fsync und page-checksum-Validierung, doch selbst bei einem künftigen Fork müsste das Vertrauen separat neu aufgebaut werden

Ende der Wartung und Projektstatus

  • pgBackRest ist ein Backup- und Restore-Tool für PostgreSQL, wird derzeit aber nicht länger gewartet
  • Die Arbeit am Projekt wurde eingestellt; künftig wird keine Zeit mehr für Bugfixes, PR-Reviews, Issue-Bearbeitung oder die Entwicklung neuer Funktionen aufgewendet
  • Auch nachdem frühere Förderung und Beschäftigung in diesem Zusammenhang weggefallen waren, sollte die Wartung zunächst fortgesetzt werden, doch es ließen sich weder genügend berufliche Möglichkeiten noch Sponsoring sichern, um das Projekt weiterzuführen
  • Statt die Wartung unregelmäßig oder unvollständig fortzusetzen, wurde ein klarer Abschluss als die bessere Option angesehen
  • Künftig könnte jemand das Projekt forken, doch in diesem Fall würde es als neues Projekt gelten, und neue Maintainer müssten sich das Vertrauen gesondert erarbeiten

Kernfunktionen des Projekts

  • Das Ziel ist eine Backup- und Restore-Lösung, die bis in große PostgreSQL-Umgebungen skaliert; die aktuelle stabile Version ist v2.58.0
  • Entworfen, um mithilfe von Parallelisierung und Kompressionsverfahren wie lz4 und zstd die bei Backups oft zum Flaschenhals werdenden Kompressionskosten zu senken
  • Unterstützt vollständige, differenzielle und inkrementelle Backups und spart nicht nur auf Dateiebene, sondern auch mit block-level backup Speicherplatz, indem nur geänderte Teile kopiert werden
  • Unterbrochene Backups können fortgesetzt werden; dabei wird die Integrität bereits kopierter Dateien erneut geprüft, indem sie mit den Checksummen im Manifest verglichen werden
  • Bei delta restore werden zunächst Dateien entfernt, die im Backup nicht vorhanden 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 Aufgaben ohne direkte Remote-Verbindung zu PostgreSQL ausgeführt werden können, 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 parallel nutzen lassen
  • Repositories können auch in S3-, Azure- und GCS-kompatiblen Object Stores liegen, was Kapazität und Aufbewahrungsdauer deutlich erweitert
  • Das Repository selbst kann verschlüsselt werden, sodass Backup-Daten unabhängig vom Speicherort geschützt bleiben

Methoden 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 dem Kopieren der Dateien wird gewartet, bis alle für einen konsistenten Backup-Zustand erforderlichen WAL-Segmente im Repository eingetroffen sind
  • Bei allen Vorgängen wird fsync auf Datei- und Verzeichnisebene genutzt, um Dauerhaftigkeit sicherzustellen
  • Wenn in PostgreSQL page checksum aktiviert ist, werden bei vollständigen Backups die Seitenprüfsummen aller Dateien validiert, bei differenziellen und inkrementellen Backups nur die der geänderten Dateien
  • Selbst wenn die Validierung der Seitenprüfsummen fehlschlägt, wird das Backup nicht abgebrochen; stattdessen wird vermerkt, welche Seiten fehlgeschlagen sind, damit page-level corruption früh erkannt werden kann, bevor ein gültiges Backup abläuft

WAL-Verarbeitung und Optimierung der Restore-Performance

  • Bietet eigene Befehle für WAL push/get; beide unterstützen Parallelisierung und asynchrone Ausführung, um die Reaktionszeit von PostgreSQL so schnell wie möglich zu halten
  • WAL push entfernt Duplikate automatisch, wenn dasselbe WAL-Segment mehrfach eingeht, und erzeugt einen Fehler, wenn sich der Inhalt unterscheidet
  • Beim asynchronen WAL push übernimmt ein anderer Prozess die Übertragung und komprimiert WAL-Segmente parallel, was besonders bei Datenbanken mit sehr hoher Schreiblast wichtig ist
  • Asynchrones WAL get hält lokal eine dekomprimierte WAL queue vor, damit sie vor dem Replay sofort bereitsteht; das ist besonders vorteilhaft bei Verbindungen mit hoher Latenz oder bei Speichern wie S3
  • Sowohl WAL push als auch get vergleichen PostgreSQL-Version und system identifier, um sicherzustellen, dass Datenbank und Repository zusammenpassen, und reduzieren so das Risiko einer falsch konfigurierten WAL-Archivierung erheblich

Betriebliche Flexibilität und Kompatibilität

  • Richtlinien für backup retention und archive expiration lassen sich getrennt nach Full, Differential und WAL konfigurieren, sodass sich gewünschte Zeiträume flexibel abdecken lassen
  • Backups können im nativen PostgreSQL-Cluster-Format gespeichert werden; wenn Komprimierung deaktiviert und hard link aktiviert ist, kann ein PostgreSQL-Cluster sogar direkt auf einem Repository-Snapshot gestartet werden
  • Diese Vorgehensweise ist besonders vorteilhaft bei terabyte-scale database-Umgebungen, in denen traditionelle Restores viel Zeit benötigen
  • tablespace wird vollständig unterstützt; beim Restore kann jeder tablespace an einen anderen Ort verschoben oder gesammelt auf einen Zielort remappt werden
  • Auch Datei- und Verzeichnis-Links werden unterstützt; beim Restore sind das Beibehalten des ursprünglichen Orts, teilweises oder vollständiges Remapping sowie die Wiederherstellung als normale Datei bzw. normales Verzeichnis möglich
  • Unterstützt 10 PostgreSQL-Versionen, darunter die derzeit unterstützten fünf sowie die letzten fünf EOL-Versionen, um für Upgrades ausreichend Zeit zu lassen

Referenzressourcen und Sponsoring-Status

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 일 전
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