pgbackrest/pgbackrest

 (github.com/pgbackrest)
3 पॉइंट द्वारा GN⁺ 2 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • PostgreSQL के लिए एक backup·restore tool के रूप में डिज़ाइन किया गया था, जिसे बड़े पैमाने के environments तक scale किया जा सके, लेकिन अब यह maintenance समाप्त स्थिति में है
  • bug fix, PR review, issue response और नए feature development सभी बंद कर दिए गए हैं, और इसे अनियमित रूप से खींचते रहने के बजाय स्पष्ट रूप से रोकने का निर्णय लिया गया है
  • यह full·differential·incremental backup, block-level backup, interrupted jobs को 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 verification जैसे integrity assurance mechanisms व्यापक रूप से मौजूद थे, लेकिन आगे यदि कोई fork आता भी है तो उसे अलग से भरोसा बनाना होगा

maintenance समाप्ति और project status

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

project की मुख्य features

  • इसका लक्ष्य large-scale PostgreSQL environments तक scale होने वाला backup·restore था, और वर्तमान 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 बचाता है
  • interrupted backup को resume किया जा सकता है, और manifest के checksum से तुलना करके पहले से copied files की integrity फिर से verify की जाती है
  • delta restore में backup में मौजूद न होने वाली files को पहले हटाया जाता है, फिर बाकी files के checksum मिलाए जाते हैं; जो files match करती हैं उन्हें वैसे ही छोड़ा जाता है और केवल ज़रूरी files restore की जाती हैं

remote operation और repository design

  • अपनी protocol layer के जरिए local और remote दोनों environments में backup, restore, archive operations किए जा सकते हैं, और remote connections के लिए TLS/SSH का उपयोग होता है
  • यही protocol layer PostgreSQL query interface भी देती है, जिससे PostgreSQL में सीधे remote login किए बिना काम किया जा सकता है और security बेहतर होती है
  • multiple repositories support होने से, fast 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 segments repository तक पहुँचने का इंतज़ार किया जाता है
  • सभी operations में file और directory level पर fsync का उपयोग कर durability सुनिश्चित की जाती है
  • अगर PostgreSQL में page checksum enabled है, तो full backup में सभी files के page checksum verify किए जाते हैं, जबकि differential·incremental backup में केवल बदली हुई files verify की जाती हैं
  • page checksum verification fail होने पर भी backup रोका नहीं जाता, लेकिन कौन-से pages fail हुए इसकी 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 कई बार आता है तो duplication अपने-आप हटा दी जाती है, और content अलग होने पर error उत्पन्न होती है
  • asynchronous WAL push में दूसरा process transfer संभालता है और WAL segments को parallel compress करता है, इसलिए बहुत high-write databases में यह खास तौर पर महत्वपूर्ण है
  • asynchronous WAL get local में decompressed WAL queue बनाए रखता है ताकि replay से पहले तुरंत supply किया जा सके; high-latency connections या S3 जैसे storage में इसका फ़ायदा और बढ़ जाता है
  • WAL push और get दोनों PostgreSQL version और system identifier की तुलना कर यह verify करते हैं कि database और repository सही pair हैं, जिससे WAL archive location की गलत configuration की संभावना काफ़ी कम होती है

operational flexibility और compatibility

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

reference resources और sponsorship status

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 일 전
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 बनकर ही इसे आगे बढ़ाया जा सकेगा, यह साफ नहीं है