PostgreSQL के लिए ओपन सोर्स बैकअप प्रबंधन की वर्तमान स्थिति

PostgreSQL क्लस्टर का बैकअप लेने को संबोधित करने के कई तरीके हैं। ऐसे कई लेख और ब्लॉग हैं जो विभिन्न तकनीकों को प्रस्तुत करते हैं जिसके द्वारा हम अपने कीमती डेटा को PostgreSQL में सहेज सकते हैं। तार्किक बैकअप समाधान हैं, ओएस स्तर पर भौतिक बैकअप, फाइल सिस्टम स्तर पर, आदि। यहां इस ब्लॉग में हम सैद्धांतिक भाग को कवर नहीं करेंगे जो कि विभिन्न ब्लॉगों और लेखों के साथ-साथ आधिकारिक दस्तावेज़ीकरण द्वारा पर्याप्त रूप से कवर किया गया है।

यह ब्लॉग उपलब्ध विभिन्न उपकरणों और समाधानों की स्थिति पर ध्यान केंद्रित कर रहा है और वास्तविक जीवन के अनुभवों के आधार पर पूरी तरह से तुलना प्रस्तुत करने का प्रयास कर रहा है। यह लेख किसी भी तरह से किसी विशिष्ट उत्पाद को बढ़ावा देने की कोशिश नहीं करता है, मुझे वास्तव में इस ब्लॉग में वर्णित सभी उपकरण, समाधान और प्रौद्योगिकियां पसंद हैं। यहां उद्देश्य उनकी ताकत, उनकी कमजोरियों को नोट करना और अंतिम उपयोगकर्ता का मार्गदर्शन करना है कि कौन सा उपकरण उसके पर्यावरण, बुनियादी ढांचे और विशिष्ट आवश्यकताओं के लिए सबसे उपयुक्त होगा। यहां विभिन्न स्तरों पर PostgreSQL के लिए बैकअप टूल का वर्णन करने वाला एक अच्छा लेख है।

मैं इस ब्लॉग में विभिन्न उपकरणों का उपयोग करने का तरीका नहीं बताऊंगा, क्योंकि यह जानकारी उपरोक्त ब्लॉग में और आधिकारिक दस्तावेज़ों के साथ-साथ नेट पर अन्य संसाधनों में भी प्रलेखित है। लेकिन मैं पेशेवरों और विपक्षों का वर्णन करूंगा जैसा कि मैंने उन्हें अभ्यास में अनुभव किया था। इस ब्लॉग में, हम विशेष रूप से क्लासिक PITR- आधारित भौतिक PostgreSQL बैकअप पर निर्भर हैं:

• pg_basebackup या pg_start_backup()/pg_stop_backup
• भौतिक प्रति
• WALs का संग्रह या स्ट्रीमिंग प्रतिकृति

कई बेहतरीन उत्पाद और समाधान हैं, कुछ खुले स्रोत हैं और उपयोग करने के लिए स्वतंत्र हैं जबकि अन्य वाणिज्यिक हैं। मेरी जानकारी के अनुसार, वे हैं:

• pgbarman by 2ndquadrant (मुक्त)
• पीजीबैकरेस्ट (फ्री)
• Pg_probackup by Postgres Professional (मुफ़्त)
• ईडीबी द्वारा बार्ट (वाणिज्यिक)

मुझे बार्ट को आज़माने का मौका नहीं मिला क्योंकि यह लिनक्स के फ्लेवर पर चलता है जिसका मैं उपयोग नहीं करता। इस ब्लॉग में, मैं प्रत्येक समाधान के संबंधित लेखकों/समुदाय/अनुरक्षकों के साथ बातचीत करते समय अपने विचारों और छापों को शामिल करूंगा क्योंकि यह एक बहुत ही महत्वपूर्ण पहलू है जिसे आमतौर पर शुरुआत में कम करके आंका जाता है। प्रत्येक टूल में विभिन्न शब्दों को बेहतर ढंग से समझने के लिए थोड़ी सी शब्दावली:

pgbarman

पगबर्मन या जस्ट बर्मन उन उपकरणों में सबसे पुराना है। नवीनतम रिलीज़ 2.6 है (रिलीज़ जब मैं इस ब्लॉग पर काम कर रहा था! जो बहुत अच्छी खबर है)।

Pgbarman दो तरीकों से बेस बैकअप का समर्थन करता है:

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

और वाल हस्तांतरण के माध्यम से:

• वाल संग्रह
  • rsync के माध्यम से
  • बर्मन-वाल-आर्काइव / पुट-वाल के माध्यम से
• WAL प्रतिकृति स्लॉट के साथ स्ट्रीमिंग प्रतिकृति के माध्यम से
  • अतुल्यकालिक
  • तुल्यकालिक

यह हमें 8 आउट ऑफ द बॉक्स कॉम्बिनेशन देता है जिसके द्वारा हम बर्मन का उपयोग कर सकते हैं। प्रत्येक के अपने फायदे और नुकसान हैं।

pg_basebackup (बैकअप_मेथोड =पोस्टग्रेज) के माध्यम से बेस बैकअप

पेशेवरों:

• नवीनतम/आधुनिक तरीका
• सिद्ध कोर पोस्टग्रेएसक्यूएल तकनीक पर निर्भर करता है
• आधिकारिक डॉक्स द्वारा अनुशंसित

विपक्ष:

• कोई वृद्धिशील बैकअप नहीं
• कोई समानांतर बैकअप नहीं
• कोई नेटवर्क संपीड़न नहीं
• कोई डेटा डुप्लीकेशन नहीं
• कोई नेटवर्क बैंडविड्थ सीमा नहीं

rsync (बैकअप_मेथोड =rsync) के माध्यम से बेस बैकअप

पेशेवरों:

• पुराना और सिद्ध
• वृद्धिशील बैकअप
• डेटा डुप्लीकेशन
• नेटवर्क संपीड़न
• समानांतर बैकअप
• नेटवर्क बैंडविड्थ सीमा

विपक्ष:

• अनुशंसित (लेखकों द्वारा) तरीके से नहीं

WAL संग्रह के माध्यम से WAL स्थानांतरण (rsync के माध्यम से)

पेशेवरों:

• सेटअप में आसान

विपक्ष:

• कोई RPO=0 (शून्य डेटा हानि)
• लंबी और लगातार नेटवर्क विफलताओं से उबरने का कोई तरीका नहीं

WAL संग्रह के माध्यम से WAL स्थानांतरण (बर्मन-वाल-संग्रह / पुट-वाल के माध्यम से)

पेशेवरों:

• नवीनतम और अनुशंसित तरीका (2.6 में पेश किया गया)
• rsync से अधिक विश्वसनीय/सुरक्षित

विपक्ष:

• कोई RPO=0 (शून्य डेटा हानि)
• अभी भी लंबे और लगातार नेटवर्क विफलताओं से उबरने का कोई तरीका नहीं है

WAL स्ट्रीमिंग के माध्यम से प्रतिकृति स्लॉट के साथ WAL स्थानांतरण (pg_receivewal के माध्यम से)

पेशेवरों:

• अधिक आधुनिक (और अनुशंसित)
• RPO=0 (शून्य डेटा हानि) सिंक्रोनस मोड में

विपक्ष:

• हमेशा प्रतिकृति स्लॉट के साथ जुड़ा हुआ है। नेटवर्क विफल होने की स्थिति में बढ़ सकता है

इसलिए, जबकि pg_basebackup (पोस्टग्रेज मेथड) pgbarman के भविष्य की तरह लगता है, वास्तव में, सभी फैंसी फीचर्स rsync मेथड के साथ आते हैं। तो आइए हम बर्मन की सभी विशेषताओं को अधिक विस्तार से सूचीबद्ध करें:

• दूरस्थ संचालन (बैकअप/पुनर्स्थापना)
• वृद्धिशील बैकअप। बर्मन की महान विशेषताओं में से एक, वृद्धिशील बैकअप कैटलॉग में अंतिम बैकअप की तुलना में डेटाबेस फ़ाइलों की फ़ाइल स्तर की तुलना पर आधारित हैं। बर्मन में "डिफरेंशियल" शब्द एक अलग अवधारणा को संदर्भित करता है:बर्मन शब्दावली के अनुसार, एक डिफरेंशियल बैकअप अंतिम बैकअप है + अंतिम बैकअप से व्यक्तिगत परिवर्तन। बर्मन डॉक्स का कहना है कि वे WALs के माध्यम से डिफरेंशियल बैकअप प्रदान करते हैं। बर्मन वृद्धिशील बैकअप फ़ाइल-स्तर पर काम करते हैं, जिसका अर्थ है कि यदि कोई फ़ाइल बदली जाती है तो पूरी फ़ाइल स्थानांतरित हो जाती है। यह pgbackrest जैसा है और pg_probackup या BART जैसे कुछ अन्य प्रस्तावों के विपरीत है जो ब्लॉक-स्तरीय अंतर/वृद्धिशील बैकअप का समर्थन करते हैं। बर्मन वृद्धिशील बैकअप इसके द्वारा निर्दिष्ट किए जाते हैं:reuse_backup =लिंक या कॉपी। "प्रतिलिपि" को परिभाषित करके हम बैकअप के कम समय को प्राप्त करते हैं क्योंकि केवल बदली गई फ़ाइलों को स्थानांतरित और बैकअप किया जाता है लेकिन फिर भी स्थान में कोई कमी नहीं होती है क्योंकि पिछले बैकअप से अपरिवर्तित फ़ाइलों की प्रतिलिपि बनाई जाती है। "लिंक" को परिभाषित करके फिर अपरिवर्तित फ़ाइलें पिछले बैकअप से हार्ड लिंक्ड (कॉपी नहीं) की जाती हैं। इस तरह हम समय में कमी और स्थान में कमी दोनों को प्राप्त करते हैं। मैं किसी भी तरह से इसमें अधिक भ्रम नहीं लाना चाहता, लेकिन वास्तव में, बर्मन वृद्धिशील बैकअप सीधे pgbackrest वृद्धिशील बैकअप के साथ तुलनीय हैं, क्योंकि बर्मन एक वृद्धिशील बैकअप को एक पूर्ण बैकअप के रूप में प्रभावी ढंग से (लिंक या कॉपी के माध्यम से) मानता है। तो दोनों प्रणालियों में, एक वृद्धिशील बैकअप उन फाइलों से संबंधित है जो पिछले बैकअप के बाद से बदली गई थीं। हालांकि, डिफरेंशियल बैकअप के संबंध में, उपरोक्त प्रत्येक सिस्टम में इसका एक अलग अर्थ है, जैसा कि हम नीचे देखेंगे।
• स्टैंडबाय से बैकअप। बर्मन आधार बैकअप संचालन के थोक को स्टैंडबाय से करने का विकल्प देता है और इस प्रकार प्राथमिक को अतिरिक्त आईओ लोड से मुक्त करता है। हालांकि, ध्यान दें कि अभी भी वाल प्राथमिक से आना चाहिए। इससे कोई फर्क नहीं पड़ता कि आप आर्काइव_कमांड या वाल स्ट्रीमिंग का उपयोग प्रतिकृति स्लॉट के माध्यम से करते हैं, आप अभी तक (इस लेखन के अनुसार बर्मन संस्करण 2.6 पर होने के साथ) इस कार्य को स्टैंडबाय पर लोड नहीं कर सकते हैं।
• बैकअप और पुनर्प्राप्ति के लिए समानांतर कार्य
• इनमें से किसी एक पर आधारित अवधारण सेटिंग का एक समृद्ध और व्यापक सेट:
  • अतिरेक (रखने के लिए बैकअप की संख्या)
  • पुनर्प्राप्ति विंडो (बैकअप को अतीत में कैसे रखा जाना चाहिए)
  एक उपयोगकर्ता के नजरिए से मेरी राय में, उपरोक्त बहुत अच्छा है। उपयोगकर्ता पुन:उपयोग_बैकअप =लिंक और एक पुनर्प्राप्ति विंडो को परिभाषित कर सकता है और बरमन (इसकी क्रॉन जॉब) को बाकी के साथ सौदा करने देता है। चिंता करने या शेड्यूल करने या प्रबंधित करने के लिए कोई भिन्न/incr/पूर्ण आदि बैकअप नहीं। सिस्टम (बर्मन) पारदर्शी तरीके से सही काम करता है।
• अपनी खुद की प्री/पोस्ट इवेंट हुक स्क्रिप्ट की प्रोग्रामिंग करना।
• टेबलस्पेस रीमैपिंग

वे बर्मन की सबसे अच्छी ताकत हैं। और वास्तव में यह बैकअप और रिकवरी टूल से पूछे जाने वाले औसत DBA से लगभग अधिक है। हालांकि, कुछ बिंदु हैं जो बेहतर हो सकते हैं:

• मेलिंग सूची इतनी सक्रिय नहीं है और अनुरक्षक शायद ही कभी प्रश्न लिखते या उत्तर देते हैं
• असफल/बाधित बैकअप को फिर से शुरू करने के लिए कोई सुविधा नहीं
• प्रतिकृति स्लॉट या संग्रह के लिए rsync/barman-wal-archive का उपयोग विफल नेटवर्क या बैकअप साइट की अन्य विफलताओं के मामले में क्षमा नहीं कर रहा है। किसी भी मामले में, यदि नेटवर्क आउटेज काफी लंबा है और डीबी में कई वाल फाइलों के लायक परिवर्तन होते हैं तो प्राथमिक "डिवाइस पर कोई जगह नहीं छोड़ी" से पीड़ित होगा और अंततः क्रैश हो जाएगा। (अच्छी बात नहीँ हे)। यहाँ जो आशाजनक है वह यह है कि बर्मन अब WALs को स्थानांतरित करने के लिए एक वैकल्पिक (rsync) तरीका प्रदान करता है ताकि उदा। भविष्य में pg_wal अंतरिक्ष थकावट को लागू किया जा सकता है, जो बैकअप रेज़्यूमे के साथ कम से कम मेरे लिए वास्तव में बर्मन को परिपूर्ण बना देगा।

पीजीबैकरेस्ट

Pgbackrest ओपन सोर्स बैकअप टूल के बीच वर्तमान चलन है, मुख्यतः क्योंकि इसकी दक्षता बहुत बड़ी मात्रा में डेटा से निपटने के लिए है और इसके निर्माता चेकसम के माध्यम से बैकअप के सत्यापन में अत्यधिक देखभाल करते हैं। इस लेखन के रूप में यह संस्करण v2.09 पर है, और दस्तावेज़ यहां पाए जाते हैं। उपयोगकर्ता मार्गदर्शिका थोड़ी पुरानी हो सकती है लेकिन शेष दस्तावेज़ बहुत अद्यतित और सटीक हैं। Pgbackrest अपने स्वयं के संग्रह_कमांड और अपने स्वयं के फ़ाइल स्थानांतरण तंत्र का उपयोग करके WAL संग्रह पर निर्भर करता है जो rsync से बेहतर और सुरक्षित है। तो pgbackrest बहुत आगे है क्योंकि यह बर्मन द्वारा प्रदान किए जाने वाले विकल्पों का बड़ा सेट नहीं देता है। चूंकि इसमें कोई सिंक्रोनस मोड शामिल नहीं है, स्वाभाविक रूप से pgbackrest RPO=0 (शून्य डेटा हानि) की गारंटी नहीं देता है। आइए हम pgbackrest की अवधारणाओं का वर्णन करें:

• एक बैकअप हो सकता है:
  • पूर्ण। एक पूर्ण बैकअप संपूर्ण डेटाबेस क्लस्टर की प्रतिलिपि बनाता है।
  • डिफरेंशियल (डिफरेंशियल)। एक अंतर बैकअप केवल उन फ़ाइलों की प्रतिलिपि बनाता है जो पिछले पूर्ण बैकअप के बाद से बदली गई थीं। एक सफल पुनर्स्थापना के लिए, अंतर बैकअप और पिछला पूर्ण बैकअप दोनों मान्य होना चाहिए।
  • वृद्धिशील (incr)। एक वृद्धिशील बैकअप केवल उन फ़ाइलों की प्रतिलिपि बनाता है जो पिछले बैकअप के बाद से बदली गई थीं (जो एक पूर्ण बैकअप, एक अंतर या एक वृद्धिशील भी हो सकती है)। डिफरेंशियल बैकअप के समान, एक सफल पुनर्स्थापना करने के लिए, पिछले सभी आवश्यक बैकअप (इस बैकअप सहित, नवीनतम अंतर और पिछला पूर्ण) मान्य होना चाहिए।
• एक छंद एक PostgreSQL क्लस्टर के सभी आवश्यक मापदंडों की परिभाषा है। एक PostgreSQL सर्वर सामान्य का अपना श्लोक होता है, जबकि बैकअप सर्वर में प्रत्येक PostgreSQL क्लस्टर के लिए एक श्लोक होगा जिसका वे बैकअप लेते हैं।
• एक विन्यास वह जगह है जहां छंद के बारे में जानकारी रखी जाती है (आमतौर पर /etc/pgbackrest.conf)
• एक रिपॉजिटरी वह जगह है जहां pgbackrest WALs और बैकअप रखता है

उपयोगकर्ता को दस्तावेज़ीकरण का पालन करने के लिए प्रोत्साहित किया जाता है जैसा कि दस्तावेज़ीकरण स्वयं सुझाव देता है, ऊपर से नीचे तक। pgbackrest की सबसे महत्वपूर्ण विशेषताएं हैं:

• समानांतर बैकअप और पुनर्स्थापित करें
• PostgreSQL सर्वर के लिए सीधे SQL एक्सेस की आवश्यकता नहीं है
• स्थानीय/दूरस्थ संचालन
• अवधारण के आधार पर:
  • पूर्ण बैकअप प्रतिधारण (रखने के लिए पूर्ण बैकअप की संख्या)
  • डिफ बैकअप रिटेंशन (रखने के लिए अलग-अलग बैकअप की संख्या)
  वृद्धिशील बैकअप की अपनी अवधारण नहीं होती है और जैसे ही पूर्व बैकअप समाप्त हो जाता है, समाप्त हो जाते हैं। तो उपयोगकर्ता पूर्ण बैकअप लेने के लिए एक शेड्यूल और उनके बीच भिन्न बैकअप के रोलिंग सेट को परिभाषित कर सकता है।
• स्टैंडबाय से बैकअप। कुछ फ़ाइलों को अभी भी प्राथमिक से आने की आवश्यकता है लेकिन थोक प्रतिलिपि स्टैंडबाय पर होती है। फिर भी वाल प्राथमिक से उत्पन्न होने चाहिए।
• बैकअप अखंडता। जब बैकअप की अखंडता की बात आती है तो pgbackrest के पीछे के लोग बेहद सावधान रहते हैं। प्रत्येक फ़ाइल को बैकअप समय पर चेकसम किया जाता है और यह सुनिश्चित करने के लिए पुनर्स्थापना के बाद भी जाँच की जाती है कि कोई समस्याग्रस्त हार्डवेयर या सॉफ़्टवेयर बग के परिणामस्वरूप दोषपूर्ण पुनर्स्थापना नहीं हो सकती है। साथ ही यदि PostgreSQL क्लस्टर पर पृष्ठ स्तरीय चेकसम सक्षम हैं तो उनकी गणना भी प्रत्येक फ़ाइल के लिए की जाती है। इसके अलावा, प्रत्येक WAL फ़ाइल के लिए चेकसम की गणना की जाती है।
• यदि संपीड़न अक्षम है और हार्ड लिंक सक्षम हैं तो क्लस्टर को सीधे कैटलॉग से लाना संभव है। यह बहु टीबी बड़े डेटाबेस के लिए अत्यंत महत्वपूर्ण है।
• असफल/बाधित बैक का रिज्यूमे। अविश्वसनीय नेटवर्क के मामले में बहुत आसान है।
• डेल्टा रिस्टोर:पूरे क्लस्टर को साफ किए बिना बड़े डेटाबेस के लिए अल्ट्रा फास्ट रिस्टोर।
• अतुल्यकालिक और समानांतर वाल बैकअप सर्वर पर धक्का। यह pgbackrest के सबसे मजबूत बिंदुओं में से एक है। PostgreSQL आर्काइव केवल आर्काइव-पुश के माध्यम से स्पूल में कॉपी करता है और ट्रांसफर और प्रोसेसिंग का भारी काम एक अलग pgbackrest प्रक्रिया में होता है। यह कम PostgreSQL प्रतिक्रिया समय सुनिश्चित करते हुए बड़े पैमाने पर WAL स्थानान्तरण की अनुमति देता है।
• टेबलस्पेस रीमैपिंग
• अमेज़न S3 सपोर्ट
• अधिकतम WAL कतार आकार के लिए समर्थन। जब बैकअप साइट डाउन हो या नेटवर्क विफल हो रहा हो, तो इस विकल्प का उपयोग करने का मज़ाक उड़ाया जाएगा जैसे कि संग्रह सफल रहा, PostgreSQL को WAL को pg_wal को भरने से रोकने की अनुमति देता है, और इस प्रकार pgsql सर्वर को संभावित PANIC से बचाता है।

इसलिए जब डेटा सत्यापन और प्रदर्शन की बात आती है तो फीचर-वार pgbackrest बहुत जोर देता है, इसमें कोई आश्चर्य की बात नहीं है कि इसका उपयोग सबसे बड़े और व्यस्त पोस्टग्रेएसक्यूएल इंस्टॉलेशन द्वारा किया जाता है। हालांकि, एक चीज है जिसे सुधारा जा सकता है:

• जहां तक ​​प्रतिधारण का संबंध है, एक अधिक "उदार" विकल्प रखना वास्तव में आसान होगा, अर्थात कुछ अवधारण अवधि निर्दिष्ट करने के लिए घोषणात्मक तरीका प्रदान करें और फिर pgbackrest को आवश्यकतानुसार पूर्ण/diff/incr बैकअप से निपटने दें।

pg_probackup

Pg_proback बैकअप के लिए एक और आशाजनक उपकरण है। यह मूल रूप से pg_arman पर आधारित है। इसका जोर बैकअप के प्रदर्शन पर है। यह कैटलॉग और उदाहरणों पर आधारित है, जो बाकी टूल के समान है, इसलिए हमारे पास है। इसकी मुख्य विशेषताओं में शामिल हैं:

• समृद्ध बैकअप-स्तरीय समर्थन निम्न से लेकर:
  • पूर्ण बैकअप
  • तीन प्रकार की वृद्धि:
    • पेज बैकअप। WAL स्कैनिंग के माध्यम से स्तर परिवर्तन पाए गए। पिछले बैकअप के बाद से अबाधित WAL अनुक्रम तक पूर्ण पहुंच की आवश्यकता है।
    • डेल्टा बैकअप। केवल बदले गए पृष्ठों को बैकअप में कॉपी किया जाता है। वाल संग्रह से स्वतंत्र, सर्वर पर कुछ भार डालता है।
    • पीट्रैक बैकअप। विशेष pgsql कोर पैचिंग की आवश्यकता है। जैसे ही पृष्ठ संशोधित होते हैं, तुरंत बिटमैप बनाए रखने का काम करता है। सर्वर पर न्यूनतम लोड के साथ वास्तव में तेज़ बैकअप।
• बैकअप को भी इसमें विभाजित किया जा सकता है:
  • स्वायत्त बैकअप। बैकअप के बाहर वाल पर उनकी कोई आवश्यकता नहीं है। कोई PITR नहीं।
  • बैकअप संग्रहित करें. वे निरंतर संग्रह पर भरोसा करते हैं, और PITR का समर्थन करते हैं।
• मल्टीथ्रेडेड मॉडल (बर्मन, पीजीबैकरेस्ट और निश्चित रूप से खुद पोस्टग्रेएसक्यूएल के विपरीत जो एक मल्टीप्रोसेस मॉडल का पालन करते हैं)
• डेटा स्थिरता और बिना बहाल किए मांग पर सत्यापन
• प्राथमिक तक पहुंच के बिना स्टैंडबाय से बैकअप लें।
• एक अभिव्यंजक अवधारण नीति विनिर्देश जहां अतिरेक का उपयोग विंडो के साथ AND फैशन में किया जा सकता है। मर्जिंग बैकअप (मर्ज के माध्यम से) पिछले वृद्धिशील बैकअप को स्थान खाली करने के तरीके के रूप में पूर्ण रूप से परिवर्तित करके और सुचारू बैकअप रोटेशन के लिए एक विधि प्रदान करके समर्थित है।

तो, pg_probackup प्रदर्शन पर जोर देने के साथ महान सुविधाओं का एक सेट प्रदान करता है जो बड़े प्रतिष्ठानों को लाभान्वित करेगा। हालांकि, अभी भी कुछ चीजें गायब हैं, अर्थात्:

• कोई आधिकारिक रिलीज़ दूरस्थ बैकअप का समर्थन नहीं करता है। इसका अर्थ है कि pg_probackup उसी होस्ट पर चलना चाहिए जिस पर pgsql क्लस्टर है। (एक देव शाखा है जो एक दूरस्थ साइट से बैकअप के साथ-साथ एक दूरस्थ बैकअप सर्वर पर संग्रह से संबंधित है)
• असफल बैकअप रिज्यूमे के लिए कोई समर्थन नहीं।

हम उपरोक्त पैराग्राफ को नीचे की तरह एक फीचर मैट्रिक्स के साथ सारांशित कर सकते हैं।

(ऊपर जैसा ही)

(धागे के माध्यम से)

ClusterControl

ClusterControl या तो तत्काल बैकअप उत्पन्न करने या किसी एक को शेड्यूल करने और कार्य को सरल और तेज़ तरीके से स्वचालित करने के लिए कार्यक्षमता प्रदान करता है।

हम दो बैकअप विधियों, pgdump (तार्किक) और pg_basebackup (बाइनरी) के बीच चयन कर सकते हैं। हम यह भी निर्दिष्ट कर सकते हैं कि बैकअप (डेटाबेस सर्वर पर, ClusterControl सर्वर पर या क्लाउड में), संपीड़न स्तर और एन्क्रिप्शन को कहाँ संग्रहीत किया जाए।

साथ ही, क्लस्टरकंट्रोल के साथ हम जेनरेट किए गए बैकअप को सत्यापित करने के लिए पॉइंट-इन-टाइम रिकवरी फीचर और बैकअप सत्यापन का उपयोग कर सकते हैं।