pgBackRest अब मेंटेन नहीं किया जा रहा है

• PostgreSQL के लिए एक बैकअप·रिकवरी टूल के रूप में इसे बड़े पैमाने के environments तक scale होने के लिए डिज़ाइन किया गया था, लेकिन अब इसका maintenance बंद कर दिया गया है
• bug fix, PR review, issue response और नए feature development सभी बंद कर दिए गए हैं, और इसे अनियमित रूप से खींचते रहने के बजाय स्पष्ट रूप से रोकने का फैसला किया गया
• यह full·differential·incremental backup और block-level backup, बाधित काम को resume करना, तथा delta restore को support करता है, जिससे केवल बदले हुए हिस्सों को store और restore किया जा सकता है
• local·remote environments को कवर करने वाली protocol layer और multiple repositories के साथ, TLS·SSH connections तथा S3·Azure·GCS compatible object store के जरिए इसका operational scope बढ़ाया गया
• checksum, WAL segment wait, fsync, page checksum validation जैसे integrity assurance mechanisms से लैस यह एक मजबूत टूल था, लेकिन आगे अगर कोई fork आता भी है तो उसे अलग से भरोसा बनाना होगा

---

maintenance समाप्ति और प्रोजेक्ट की स्थिति

• pgBackRest PostgreSQL के लिए एक बैकअप·रिकवरी टूल है, लेकिन अब इसका maintenance नहीं किया जा रहा है
• प्रोजेक्ट पर काम रोक दिया गया है, और आगे bug fix, PR review, issue response तथा नए feature development पर समय नहीं देने की बात कही गई है
• पहले की sponsorship और employment arrangements खत्म हो जाने के बाद भी maintenance जारी रखने की कोशिश की गई, लेकिन प्रोजेक्ट को जारी रखने लायक job opportunities और sponsorship नहीं मिल सकी
• maintenance को अनियमित या अधूरा जारी रखने के बजाय, इसे स्पष्ट रूप से समाप्त करना बेहतर माना गया
• भविष्य में कोई इसे fork कर सकता है, लेकिन उस स्थिति में उसे नया प्रोजेक्ट माना जाएगा और नए maintainer को अलग से भरोसा बनाना होगा

प्रोजेक्ट की मुख्य विशेषताएँ

• इसका लक्ष्य बड़े PostgreSQL environments तक scale होने वाली backup·recovery क्षमता देना है, और वर्तमान stable version v2.58.0 है
• parallel processing और lz4, zstd जैसे compression methods का उपयोग करके backup के दौरान bottleneck बनने वाली compression cost को कम करने के लिए इसे डिज़ाइन किया गया है
• यह full, differential, incremental backup को support करता है, और file-level के साथ-साथ block-level backup के जरिए केवल बदले हुए हिस्सों को copy करके storage space बचाता है
• बाधित backup को resume किया जा सकता है, और manifest के checksum से तुलना करके पहले से copy की गई files की integrity फिर से verify की जाती है
• delta restore में backup में न मौजूद files को पहले हटाया जाता है और बाकी files के checksum मिलाए जाते हैं, ताकि matching files को वैसे ही रखा जाए और केवल ज़रूरी files ही restore हों

remote operation और repository design

• अपनी protocol layer के जरिए local और remote दोनों environments में backup, restore और archive operations किए जा सकते हैं, और remote connection के लिए TLS/SSH का उपयोग होता है
• यही protocol layer PostgreSQL query interface भी देती है, जिससे PostgreSQL में सीधे remote login किए बिना काम किया जा सकता है और security बढ़ती है
• multiple repositories support होने से तेज़ recovery के लिए local repository और long-term retention तथा redundancy के लिए remote repository साथ में रखे जा सकते हैं
• repositories को S3, Azure, GCS compatible object store पर भी रखा जा सकता है, जिससे capacity और retention period काफी बढ़ाए जा सकते हैं
• repository को स्वयं encrypt किया जा सकता है, इसलिए backup data जहाँ भी store हो, उसे सुरक्षित रखा जा सकता है

integrity और consistency सुनिश्चित करने का तरीका

• backup की सभी files के लिए checksum calculate किया जाता है, और restore या verify के समय फिर से जांच की जाती है
• file copy पूरी होने के बाद backup को consistent state में लाने के लिए ज़रूरी सभी WAL segment repository तक पहुँचने का इंतज़ार किया जाता है
• सभी operations में file और directory level पर fsync का उपयोग करके durability सुनिश्चित की जाती है
• अगर PostgreSQL में page checksum enabled है, तो full backup में सभी files के page checksum validate किए जाते हैं, जबकि differential·incremental backup में केवल बदली हुई files को validate किया जाता है
• page checksum validation fail होने पर भी backup बंद नहीं होता, लेकिन किस page में failure हुआ उसकी warning छोड़ी जाती है, ताकि valid backup expire होने से पहले page-level corruption जल्दी पकड़ी जा सके

WAL handling और recovery performance optimization

• WAL push/get के लिए dedicated commands दिए गए हैं, और दोनों में parallel processing तथा asynchronous execution support है, ताकि PostgreSQL response time को यथासंभव तेज़ रखा जा सके
• WAL push में यदि वही WAL segment कई बार आता है तो उसे अपने आप deduplicate किया जाता है, और content अलग होने पर error दी जाती है
• asynchronous WAL push में दूसरा process transfer संभालता है और WAL segment को parallel compress करता है, इसलिए बहुत high write volume वाले database में यह खास तौर पर महत्वपूर्ण है
• asynchronous WAL get local में decompressed WAL queue बनाए रखता है, ताकि replay से पहले उन्हें तुरंत उपलब्ध कराया जा सके; high-latency connections या S3 जैसे storage में इसका फायदा खास तौर पर बड़ा है
• WAL push और get दोनों PostgreSQL version और system identifier की तुलना करके यह verify करते हैं कि database और repository सही pair हैं, जिससे WAL archive location गलत configure होने की संभावना काफी कम हो जाती है

operational flexibility और compatibility

• backup retention और archive expiration policies को full, differential और WAL unit में अलग-अलग configure किया जा सकता है, जिससे मनचाही अवधि को cover किया जा सकता है
• backup को PostgreSQL cluster format में जैसा है वैसा store किया जा सकता है, और compression बंद करके hard link enable करने पर repository snapshot पर PostgreSQL cluster को सीधे start भी किया जा सकता है
• यह तरीका पारंपरिक restore में अधिक समय लेने वाले terabyte-scale database के लिए फायदेमंद है
• tablespace का पूरा support है, और restore के समय हर tablespace को अलग location पर ले जाया जा सकता है या एक location पर bulk remap किया जा सकता है
• file और directory links भी support हैं, इसलिए restore के समय original location बनाए रखना, कुछ या सभी remap करना, या उन्हें सामान्य file·directory के रूप में restore करना संभव है
• PostgreSQL के 10 versions support किए जाते हैं, जिनमें वर्तमान में supported 5 versions और EOL हो चुके हाल के 5 versions शामिल हैं, ताकि upgrade के लिए पर्याप्त समय मिल सके

संदर्भ संसाधन और sponsorship स्थिति

• User guides
• Command reference
• Configuration reference
• वर्तमान sponsor Supabase है
• पिछले sponsors में Crunchy Data, Resonate शामिल थे

[xguru]

इस संबंध में अपडेट किया गया है.

• pgBackRest के maintenance बंद करने की घोषणा के बाद mailbox भर गया
• समर्थन और हौसला बढ़ाने वाले कई संदेश आए
• कई sponsors के गठबंधन से pgBackRest को funding मिलने लगी, इसलिए प्रोजेक्ट को जारी रखा जा सकेगा
• इसके अलावा एक और maintainer को शामिल किया गया है, जिससे काम का बोझ बांटा जा सके और प्रोजेक्ट की निरंतरता बनाए रखी जा सकेगी
• मौजूदा pgBackRest version सामान्य रूप से काम कर रहा है, और कोई गंभीर bug या security issue नहीं है, इसलिए अभी तुरंत प्रोजेक्ट को fork करने की जरूरत नहीं है
• pgBackRest को फिर से सक्रिय करने के लिए सक्रिय रूप से प्रयास किए जा रहे हैं

[GN⁺]

Hacker News की रायें

• लेखक ने LinkedIn पर लिखी पोस्ट में बताया कि उन्होंने 13 साल तक pgBackRest पर बहुत समय और लगाव लगाया, और अब maintenance बंद करने का फैसला किया है
  कंपनी sponsorship भी थी, लेकिन रातों और weekends तक इसमें लगाते रहे, और Crunchy Data के बिकने के बाद भी इसे maintain करते हुए इस काम को आगे जारी रखने वाली भूमिका खोजी, लेकिन बात नहीं बनी
  आजीविका के लिए अब उन्हें बड़े अवसर देखने होंगे, और तब maintenance, bug fixes, PR review, और issue response के लिए ज़रूरी समय वे नहीं दे पाएँगे, इसलिए repository को archive करने का उनका इरादा है
• मैंने अपने personal project में pgBackRest इस्तेमाल किया है, यहाँ तक कि local volume और cloud storage के लिए PostgreSQL backup guide भी बनाई थी, इसलिए इसका इस तरह खत्म होना दुखद लग रहा है
  guide यहाँ है: https://github.com/freakynit/postgre-backup-and-restore-guide, और अब तक लगाए गए समय और मेहनत के लिए सच में आभार
  • आजकल AI expectations की वजह से developers और सख्त deadlines में फँसे हैं और उनके पास समय भी कम बचता है
    ऊपर से बहुत से लोगों ने tokens पर पैसा जला दिया है, इसलिए उनके पास extra funds और समय दोनों कम हो गए हैं
  • काश ऐसे projects funding support की कमी से गायब न हों, और OSS की व्यावहारिक कठिनाइयाँ बहुत बड़ी लगती हैं
• यहाँ open source model खुद fail नहीं हुआ है; बस लेखक को अब financial support नहीं मिल रही, इसलिए वे दिशा बदल रहे हैं, और यह पूरी तरह वाजिब है
  अगर यह hobby project से आगे बढ़कर commercial environment में वास्तविक value देने वाला product-grade tool था, तो इस खाली जगह को भरने के लिए किसी for-profit company के आने का मौका भी ज़रूर है
  लेकिन users को customer बनकर वास्तव में पैसा देना होगा; मुफ्त maintainers को लगातार bug reports और शिकायतें भेजते रहना sustainable नहीं है
  FOSS की financial sustainability के लिए नए हल चाहिए, सिर्फ donations काफी नहीं लगते
  • मैंने सीखा है कि किसी भी ecosystem में अगर मैं चाहता हूँ कि कुछ जिंदा रहे, तो मुझे खुद support करना चाहिए
    चाहे local shop हो या open source project, बात एक जैसी है
  • सोचता हूँ कि क्या लेखक ने इसे paid product बनाने का विकल्प देखा था
    हालाँकि अलग-अलग contributors के copyrights जुड़े हो सकते हैं, इसलिए ACL है या नहीं और jurisdiction क्या है, उसके हिसाब से rights clear करने पड़ सकते हैं, और revenue sharing जैसे समझौते भी करने पड़ सकते हैं
• लोगों को ज़्यादा ध्यान Crunchy Data acquisition वाली बात पर देना चाहिए
  corporate sponsorship के समय सब चल रहा था, लेकिन कंपनी बिकते ही और नए मालिक की priorities बदलते ही 3.8k-star infra tool तुरंत अस्थिर हो गया, और users को पता भी नहीं था कि मेरे backup tool की funding किसी और की M&A strategy पर टिकी थी
  इसी वजह से मैं भी धीरे-धीरे SQLite और git से track होने वाली files की तरफ जा रहा हूँ
  managed Postgres stacks भी आखिरकार कई ऐसे tools के ऊपर खड़े हैं जिन्हें ऐसे लोग maintain कर रहे हैं जिनकी funding स्थिति हमें पता नहीं होती
  • यह पूरी तरह गायब नहीं हुआ है, और कम से कम अभी के लिए backup रुक जाने जैसी स्थिति नहीं है
    लेकिन funding structure के नाज़ुक होने वाली बड़ी बात अब भी सही है
  • लेकिन SQLite भी इस तरह के risk से पूरी तरह मुक्त नहीं है; तो फिर उसे ज़्यादा सुरक्षित क्यों माना जा रहा है, यह जानने की जिज्ञासा है
• source अभी भी मौजूद है, इसलिए सिर्फ अफसोस करने के बजाय खुद fork करके maintain करना, या किसी को पैसे देकर यह काम करवाना भी एक विकल्प है
  और इसी बहाने उन dependency projects को भी देख लेना चाहिए जिन्हें आप खोना नहीं चाहते, और अभी से sponsorship सेट कर देनी चाहिए
  • मुझे लगता है यह सही रवैया है
    सब कहते हैं कि वे दुखी हैं, लेकिन अगर सच में दुख है तो पहले यह पूछना चाहिए कि क्या वे donate करने जितने दुखी हैं
• जहाँ तक मैंने ecosystem को सही से देखा है, pgBackRest PostgreSQL backup क्षेत्र का सबसे बेहतरीन समाधान था
  खासकर यह बात दुर्लभ थी कि यह सिर्फ backup ही नहीं बल्कि restore और verification को भी गंभीरता से लेता था, और इसे हल्के में लेने की वजह से मुझे नौकरी में बड़ा नुकसान झेलना पड़ा था
  पूरी कहानी यहाँ है: https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
  इसलिए यह काफ़ी बड़ा नुकसान लगता है
• यह काफ़ी चौंकाने वाला है, और मैं इसे लगभग मुख्य PG backup/restore tool मानकर चल रहा था
  WAL-G और Barman के मुकाबले यह कैसा है, यह जानना चाहता हूँ
  https://github.com/wal-g/wal-g
  https://github.com/EnterpriseDB/barman
  • मैं सटीक तुलना नहीं कर सकता, लेकिन हम लंबे समय से Barman इस्तेमाल कर रहे हैं और बहुत संतुष्ट हैं
    हर रात हम Barman से restore किया हुआ nightly DB बनाते हैं और उसे user training/testing में भी चलाते हैं, ताकि backup वास्तव में टूटा हुआ तो नहीं है यह लगातार verify होता रहे, और कई सालों से कोई समस्या नहीं आई
  • मैं wal-g maintainers में से एक हूँ, और features के हिसाब से यह पूरी तरह तुलनीय स्तर पर है
    कुछ साल inactive रहने के बाद मैं फिर managed Postgres की तरफ लौटा हूँ, और आशा है कि wal-g, अपने block-comparison based delta backup के अलावा, pg17 incremental backup को भी support करे
    और daemon mode का इस्तेमाल करना वाकई अच्छा रहता है
    competing tool का गायब होना दुखद है, लेकिन इस क्षेत्र में अभी भी बहुत सुधार की गुंजाइश है, और जब Postgres बिना overcommit वाले system पर चलना चाहता है, तब C, Golang से कुछ मामलों में बेहतर हो सकता है
  • हम पहले WAL-E, और अब उसके successor WAL-G को संतोषजनक रूप से इस्तेमाल करते आए हैं
    लगभग 9 साल पहले जब हमने समीक्षा की थी, तब streaming PITR characteristics की वजह से यह pgBackRest से ज़्यादा आकर्षक लगा था
  • यह समझ में आता है कि इसे representative tool माना गया, लेकिन https://xkcd.com/2347/ जैसी स्थिति भी याद आती है
• मैं 2TB production DB पर pgBackRest आराम से इस्तेमाल कर रहा हूँ, और संयोग से इसी हफ्ते इसे 8TB DB पर भी लगाने की सोच रहा था
  तो अब सबसे नज़दीकी विकल्प wal-g है, barman है, या databasus, यह जानना चाहता हूँ
  मैं मज़ाक में कहता हूँ कि बस DBA होने का नाटक कर रहा हूँ, लेकिन असल में यह चुनाव काफ़ी अहम है
  • मैंने 30TB+ class DB पर Barman इस्तेमाल किया है और कोई खास शिकायत नहीं रही
    संदर्भ के लिए, मैं DBRE हूँ
  • अगर आप multi-terabyte production Postgres का backup ले रहे हैं, तो वह DBA होने का नाटक नहीं, बल्कि आप सच में काम कर रहे हैं
  • अगर setup में cloud storage पर backup रखा जाता है, तो hook scripts लगे हुए Barman सबसे नज़दीकी विकल्प जैसा लगता है
    संबंधित docs: 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 भी अच्छा लगता है, लेकिन मैंने अभी खुद verify नहीं किया है
  • क्या किसी ने standby को ZFS या किसी और snapshot-capable filesystem पर रखकर backup लिया है, यह भी जानने की जिज्ञासा है
  • मैंने कभी pgBackRest इस्तेमाल भी नहीं किया था, लेकिन ठीक 2 घंटे पहले एक project में इसे जोड़ना शुरू किया, और README पूरा पढ़ने तक वह पहले ही update हो चुका था
• pgBackRest PostgreSQL backup तकनीकों में सबसे versatile tools में से एक है, और मेरे अनुभव में दूसरे products अभी इस स्तर तक नहीं पहुँचे
  इसलिए यह और भी अफसोसजनक है, और इस शानदार tool के साथ feature parity हासिल करना आसान नहीं होगा
  अगर संभव हो तो अच्छा होगा कि यह फैसला reversible हो, और नहीं तो PostgreSQL project इसे contrib के रूप में absorb कर ले
• अभी भी इसे इस्तेमाल करते रहना संभव है, इसलिए फिलहाल बस इस्तेमाल करते रहो
  शायद लेखक भी यही चाहेंगे कि लोग इसे तुरंत छोड़ने के बजाय तब तक इस्तेमाल करते रहें जब तक यह सच में काम करना बंद न कर दे
  • और तब तक उम्मीद है कि कोई नया maintainer आगे आए
    fork की ज़रूरत होगी या मौजूदा repository में contributor बनकर ही इसे आगे बढ़ाया जा सकेगा, यह साफ नहीं है