अमेज़ॅन ने 2006 की शुरुआत में S3 जारी किया और क्लाउड में डेटा अपलोड करने के लिए PostgreSQL बैकअप स्क्रिप्ट को सक्षम करने वाला पहला टूल - s3cmd - एक साल बाद ही पैदा हुआ था। 2010 तक (मेरे Google खोज कौशल के अनुसार) इसके बारे में बीआई ब्लॉग खोलें। तब यह कहना सुरक्षित है कि कुछ PostgreSQL DBA 9 वर्षों से AWS S3 में डेटा का बैकअप ले रहे हैं। पर कैसे? और उस समय में क्या बदल गया है? जबकि s3cmd को अभी भी ज्ञात PostgreSQL बैकअप टूल के संदर्भ में कुछ लोगों द्वारा संदर्भित किया गया है, विधियों में वांछित पुनर्प्राप्ति उद्देश्यों RTO और RPO को प्राप्त करने के लिए फ़ाइल सिस्टम या PostgreSQL देशी बैकअप विकल्पों के साथ बेहतर एकीकरण की अनुमति देने वाले परिवर्तन देखे गए हैं।
अमेज़न S3 ही क्यों
जैसा कि पूरे Amazon S3 प्रलेखन में बताया गया है (S3 अक्सर पूछे जाने वाले प्रश्न एक बहुत अच्छा प्रारंभिक बिंदु है) S3 सेवा का उपयोग करने के फायदे हैं:
- 99.999999999 (ग्यारह नौ) टिकाऊपन
- असीमित डेटा संग्रहण
- कम लागत (बिटटोरेंट के साथ संयुक्त होने पर और भी कम)
- इनबाउंड नेटवर्क ट्रैफ़िक निःशुल्क
- केवल आउटबाउंड नेटवर्क ट्रैफ़िक बिल करने योग्य है
AWS S3 CLI Gotchas
AWS S3 CLI टूलकिट S3 स्टोरेज के अंदर और बाहर डेटा ट्रांसफर करने के लिए आवश्यक सभी टूल प्रदान करता है, तो क्यों न उन टूल्स का उपयोग किया जाए? इसका उत्तर Amazon S3 कार्यान्वयन विवरण में निहित है जिसमें ऑब्जेक्ट स्टोरेज से संबंधित सीमाओं और बाधाओं को संभालने के उपाय शामिल हैं:
- प्रति संग्रहित वस्तु के लिए अधिकतम 5TB आकार
- एक PUT वस्तु का अधिकतम 5GB आकार
- 100MB से बड़े ऑब्जेक्ट के लिए अनुशंसित मल्टीपार्ट अपलोड
- S3 प्रदर्शन चार्ट के अनुसार उपयुक्त भंडारण वर्ग चुनें
- S3 जीवनचक्र का लाभ उठाएं
- S3 डेटा संगतता मॉडल
उदाहरण के तौर पर aws s3 cp सहायता पृष्ठ देखें:
--expected-size (string) यह तर्क बाइट्स के संदर्भ में एक स्ट्रीम के अपेक्षित आकार को निर्दिष्ट करता है। ध्यान दें कि इस तर्क की आवश्यकता केवल तभी होती है जब कोई स्ट्रीम s3 पर अपलोड की जा रही हो और आकार 5GB से बड़ा हो। इन शर्तों के तहत इस तर्क को शामिल करने में विफलता के परिणामस्वरूप अपलोड में बहुत अधिक भाग होने के कारण एक विफल अपलोड हो सकता है।
उन नुकसानों से बचने के लिए S3 पारिस्थितिकी तंत्र के गहन ज्ञान की आवश्यकता होती है, जो कि उद्देश्य-निर्मित PostgreSQL और S3 बैकअप उपकरण प्राप्त करने का प्रयास कर रहे हैं।
Amazon S3 सपोर्ट के साथ PostgreSQL नेटिव बैकअप टूल्स
S3 एकीकरण कुछ जाने-माने बैकअप टूल द्वारा प्रदान किया जाता है, जो PostgreSQL नेटिव बैकअप सुविधाओं को लागू करते हैं।
बर्मनएस3
BarmanS3 को बर्मन हुक स्क्रिप्ट के रूप में लागू किया गया है। यह ऊपर सूचीबद्ध सिफारिशों और सीमाओं को संबोधित किए बिना, एडब्ल्यूएस सीएलआई पर निर्भर करता है। सरल सेटअप इसे छोटे प्रतिष्ठानों के लिए एक अच्छा उम्मीदवार बनाता है। विकास कुछ हद तक रुका हुआ है, लगभग एक साल पहले अंतिम अपडेट, इस उत्पाद को उन लोगों के लिए एक विकल्प बना रहा है जो पहले से ही अपने वातावरण में बर्मन का उपयोग कर रहे हैं।
S3 डंप
S3dumps एक सक्रिय परियोजना है, जिसे Amazon की Python लाइब्रेरी Boto3 का उपयोग करके कार्यान्वित किया गया है। स्थापना आसानी से पाइप के माध्यम से की जाती है। हालांकि Amazon S3 Python SDK पर भरोसा करते हुए, मल्टी.*पार्ट या स्टोरेज जैसे रेगेक्स कीवर्ड के लिए सोर्स कोड की खोज। *क्लास मल्टीपार्ट ट्रांसफर जैसी उन्नत S3 सुविधाओं में से कोई भी प्रकट नहीं करता है।
pgBackRest
pgBackRest S3 को एक रिपॉजिटरी विकल्प के रूप में लागू करता है। यह प्रसिद्ध पोस्टग्रेएसक्यूएल बैकअप टूल में से एक है, जो समानांतर बैकअप और पुनर्स्थापना, एन्क्रिप्शन और टेबलस्पेस समर्थन जैसे बैकअप विकल्पों का एक सुविधा संपन्न सेट प्रदान करता है। यह ज्यादातर सी कोड है, जो हम जिस गति और थ्रूपुट की तलाश कर रहे हैं, प्रदान करता है, हालांकि, जब एडब्ल्यूएस एस 3 एपीआई के साथ बातचीत करने की बात आती है तो यह एस 3 स्टोरेज सुविधाओं को लागू करने के लिए आवश्यक अतिरिक्त कार्य की कीमत पर आता है। हाल का संस्करण S3 बहु-भाग अपलोड लागू करता है।
वाल-जी
2 साल पहले घोषित वाल-जी को सक्रिय रूप से बनाए रखा जा रहा है। यह रॉक-सॉलिड पोस्टग्रेएसक्यूएल बैकअप टूल स्टोरेज क्लासेस को लागू करता है, लेकिन अपलोड को मल्टीपार्ट नहीं करता है (क्रिएटमल्टीपार्टअपलोड के लिए कोड खोजने पर कोई घटना नहीं हुई)।
PGHoard
pghoard लगभग 3 साल पहले रिलीज़ हुई थी। यह S3 मल्टीपार्ट ट्रांसफर के समर्थन के साथ एक प्रदर्शनकारी और सुविधा संपन्न पोस्टग्रेएसक्यूएल बैकअप टूल है। यह भंडारण वर्ग और वस्तु जीवनचक्र प्रबंधन जैसी अन्य S3 सुविधाओं की पेशकश नहीं करता है।
S3 एक स्थानीय फाइल सिस्टम के रूप में
एक स्थानीय फाइल सिस्टम के रूप में S3 भंडारण तक पहुंचने में सक्षम होने के नाते, यह एक अत्यधिक वांछित विशेषता है क्योंकि यह PostgreSQL के मूल बैकअप टूल का उपयोग करने की संभावना को खोलता है।
लिनक्स वातावरण के लिए, अमेज़ॅन दो विकल्प प्रदान करता है:एनएफएस और आईएससीएसआई। वे एडब्ल्यूएस स्टोरेज गेटवे का लाभ उठाते हैं।
NFS
स्थानीय रूप से माउंट किया गया NFS शेयर AWS संग्रहण गेटवे फ़ाइल सेवा द्वारा प्रदान किया जाता है। लिंक के अनुसार हमें एक फाइल गेटवे बनाने की जरूरत है।
होस्ट प्लेटफॉर्म चुनें स्क्रीन पर Amazon EC2 चुनें और लॉन्च इंस्टेंस बटन पर क्लिक करें उदाहरण बनाने के लिए EC2 विज़ार्ड प्रारंभ करने के लिए।
अब, Sysadmin की जिज्ञासा से बाहर, आइए विज़ार्ड द्वारा उपयोग किए गए AMI का निरीक्षण करें क्योंकि यह हमें AWS के कुछ आंतरिक टुकड़ों पर एक दिलचस्प परिप्रेक्ष्य देता है। ज्ञात छवि आईडी के साथ ami-0bab9d6dffb52fef5 आइए विवरण देखें:
जैसा कि ऊपर दिखाया गया है, AMI नाम aws-thinstaller है - तो क्या है एक "स्थापनाकर्ता"? इंटरनेट खोजों से पता चलता है कि थइंस्टालर माइक्रोसॉफ्ट उत्पादों के लिए एक आईबीएम लेनोवो सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन उपकरण है और इसे पहले इस 2008 ब्लॉग में संदर्भित किया गया है, और बाद में इस लेनोवो फोरम पोस्ट और सेवा के लिए इस स्कूल जिला अनुरोध में संदर्भित किया गया है। मेरे पास यह जानने का कोई तरीका नहीं था, क्योंकि मेरी Windows sysadmin नौकरी 3 साल पहले समाप्त हो गई थी। तो क्या यह एएमआई थइंस्टालर उत्पाद के साथ बनाया गया था मामलों को और अधिक भ्रमित करने के लिए, एएमआई ऑपरेटिंग सिस्टम को "अन्य लिनक्स" के रूप में सूचीबद्ध किया गया है जिसे एसएसएच-आईएनजी द्वारा सिस्टम में व्यवस्थापक के रूप में पुष्टि की जा सकती है।
एक विजार्ड गोचा:EC2 फ़ायरवॉल सेटअप निर्देशों के बावजूद स्टोरेज गेटवे से कनेक्ट करते समय मेरा ब्राउज़र टाइम आउट कर रहा था। पोर्ट 80 को अनुमति देना पोर्ट रिक्वायरमेंट्स में प्रलेखित है - हम तर्क दे सकते हैं कि विज़ार्ड को या तो सभी आवश्यक पोर्ट्स को सूचीबद्ध करना चाहिए, या दस्तावेज़ीकरण से लिंक करना चाहिए, हालांकि क्लाउड की भावना में, क्लाउडफॉर्मेशन जैसे टूल के साथ उत्तर "स्वचालित" है।
विज़ार्ड xबड़े आकार के इंस्टेंस के साथ शुरुआत करने का भी सुझाव देता है।
भंडारण गेटवे तैयार हो जाने पर, बनाएँ पर क्लिक करके NFS शेयर को कॉन्फ़िगर करें गेटवे मेनू में फ़ाइल साझा करें बटन:
एनएफएस शेयर तैयार होने के बाद, फाइल सिस्टम को माउंट करने के लिए निर्देशों का पालन करें:
उपरोक्त स्क्रीनशॉट में, ध्यान दें कि माउंट कमांड इंस्टेंस प्राइवेट आईपी को संदर्भित करता है पता। किसी सार्वजनिक होस्ट से माउंट करने के लिए बस इंस्टेंस सार्वजनिक पते का उपयोग करें जैसा कि ऊपर EC2 इंस्टेंस विवरण में दिखाया गया है।
यदि फ़ाइल शेयर बनाने के समय S3 बकेट मौजूद नहीं है तो विज़ार्ड ब्लॉक नहीं करेगा, हालांकि, S3 बकेट बनने के बाद हमें इंस्टेंस को पुनरारंभ करने की आवश्यकता है, अन्यथा, माउंट कमांड इसके साथ विफल:
[[email protected] ~]# mount -t nfs -o nolock,hard 34.207.216.29:/s9s-postgresql-backup /mnt
mount.nfs: mounting 34.207.216.29:/s9s-postgresql-backup failed, reason given by server: No such file or directoryसत्यापित करें कि शेयर उपलब्ध करा दिया गया है:
[[email protected] ~]# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
34.207.216.29:/s9s-postgresql-backup 8.0E 0 8.0E 0% /mntअब एक त्वरित परीक्षण करते हैं:
[email protected][local]:54311 postgres# \l+ test
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges | Size | Tablespace | Description
------+----------+----------+-------------+-------------+-------------------+---------+------------+-------------
test | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | 2763 MB | pg_default |
(1 row)
[[email protected] ~]# date ; time pg_dump -d test | gzip -c >/mnt/test.pg_dump.gz ; date
Sun 27 Oct 2019 06:06:24 PM PDT
real 0m29.807s
user 0m15.909s
sys 0m2.040s
Sun 27 Oct 2019 06:06:54 PM PDTध्यान दें कि S3 बकेट पर अंतिम संशोधित टाइमस्टैम्प लगभग एक मिनट बाद है, जैसा कि पहले उल्लेख किया गया है कि Amazon S3 डेटा संगतता मॉडल के साथ है।
यहां अधिक विस्तृत परीक्षण दिया गया है:
~ $ for q in {0..20} ; do touch /mnt/touched-at-$(date +%Y%m%d%H%M%S) ;
sleep 1 ; done
~ $ aws s3 ls s3://s9s-postgresql-backup | nl
1 2019-10-27 19:50:40 0 touched-at-20191027194957
2 2019-10-27 19:50:40 0 touched-at-20191027194958
3 2019-10-27 19:50:40 0 touched-at-20191027195000
4 2019-10-27 19:50:40 0 touched-at-20191027195001
5 2019-10-27 19:50:40 0 touched-at-20191027195002
6 2019-10-27 19:50:40 0 touched-at-20191027195004
7 2019-10-27 19:50:40 0 touched-at-20191027195005
8 2019-10-27 19:50:40 0 touched-at-20191027195007
9 2019-10-27 19:50:40 0 touched-at-20191027195008
10 2019-10-27 19:51:10 0 touched-at-20191027195009
11 2019-10-27 19:51:10 0 touched-at-20191027195011
12 2019-10-27 19:51:10 0 touched-at-20191027195012
13 2019-10-27 19:51:10 0 touched-at-20191027195013
14 2019-10-27 19:51:10 0 touched-at-20191027195014
15 2019-10-27 19:51:10 0 touched-at-20191027195016
16 2019-10-27 19:51:10 0 touched-at-20191027195017
17 2019-10-27 19:51:10 0 touched-at-20191027195018
18 2019-10-27 19:51:10 0 touched-at-20191027195020
19 2019-10-27 19:51:10 0 touched-at-20191027195021
20 2019-10-27 19:51:10 0 touched-at-20191027195022
21 2019-10-27 19:51:10 0 touched-at-20191027195024उल्लेखनीय एक और मुद्दा:विभिन्न विन्यासों के साथ खेलने के बाद, गेटवे और शेयरों को बनाने और नष्ट करने के बाद, किसी समय फ़ाइल गेटवे को सक्रिय करने का प्रयास करते समय, मुझे एक आंतरिक त्रुटि मिल रही थी:
कमांड लाइन कुछ और विवरण देती है, हालांकि किसी मुद्दे की ओर इशारा नहीं करती:
~$ curl -sv "http://107.22.30.30/?gatewayType=FILE_S3&activationRegion=us-east-1"
* Trying 107.22.30.30:80...
* TCP_NODELAY set
* Connected to 107.22.30.30 (107.22.30.30) port 80 (#0)
> GET /?gatewayType=FILE_S3&activationRegion=us-east-1 HTTP/1.1
> Host: 107.22.30.30
> User-Agent: curl/7.65.3
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< Date: Mon, 28 Oct 2019 06:33:30 GMT
< Content-type: text/html
< Content-length: 14
<
* Connection #0 to host 107.22.30.30 left intact
Internal Error~ $इस फ़ोरम पोस्ट ने बताया कि मेरे मुद्दे का मेरे द्वारा बनाए गए VPC समापन बिंदु से कुछ लेना-देना हो सकता है। मेरा समाधान विभिन्न iSCSI परीक्षण और त्रुटि रन के दौरान मेरे द्वारा सेटअप किए गए VPC समापन बिंदु को हटा रहा था।
जबकि S3 आराम से डेटा एन्क्रिप्ट करता है, NFS वायर ट्रैफ़िक सादा पाठ है। बुद्धि के लिए, यहाँ एक tcpdump पैकेट डंप है:
23:47:12.225273 IP 192.168.0.11.936 > 107.22.30.30.2049: Flags [P.], seq 2665:3377, ack 2929, win 501, options [nop,nop,TS val 1899459538 ecr 38013066], length 712: NFS request xid 3511704119 708 getattr fh 0,2/53
[email protected]@.......k....... ...c..............
q7s..D.......PZ7...........................4........omiday.can.local...................................................5.......]...........!....................C...
..............&...........]....................# inittab is no longer used.
#
# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.
#
# Ctrl-Alt-Delete is handled by /usr/lib/systemd/system/ctrl-alt-del.target
#
# systemd uses 'targets' instead of runlevels. By default, there are two main targets:
#
# multi-user.target: analogous to runlevel 3
# graphical.target: analogous to runlevel 5
#
# To view current default target, run:
# systemctl get-default
#
# To set a default target, run:
# systemctl set-default TARGET.target
..... .........0..
23:47:12.331592 IP 107.22.30.30.2049 > 192.168.0.11.936: Flags [P.], seq 2929:3109, ack 3377, win 514, options [nop,nop,TS val 38013174 ecr 1899459538], length 180: NFS reply xid 3511704119 reply ok 176 getattr NON 4 ids 0/33554432 sz -2138196387जब तक यह आईईई ड्राफ्ट स्वीकृत नहीं हो जाता, तब तक एडब्ल्यूएस के बाहर से कनेक्ट करने का एकमात्र सुरक्षित विकल्प वीपीएन टनल का उपयोग करना है। यह सेटअप को जटिल बनाता है, FUSE आधारित टूल की तुलना में ऑन-प्रिमाइसेस NFS विकल्प को कम आकर्षक बनाता है, जिसके बारे में मैं थोड़ी देर बाद चर्चा करने जा रहा हूँ।
iSCSI
यह विकल्प AWS संग्रहण गेटवे वॉल्यूम सेवा द्वारा प्रदान किया गया है। एक बार सेवा के विन्यस्त होने के बाद Linux iSCSI क्लाइंट सेटअप अनुभाग पर जाएं।
NFS पर iSCSI का उपयोग करने के लाभ में Amazon क्लाउड नेटिव बैकअप, क्लोनिंग और स्नैपशॉट सेवाओं का लाभ उठाने की क्षमता शामिल है। विवरण और चरण-दर-चरण निर्देशों के लिए, AWS बैकअप, वॉल्यूम क्लोनिंग और EBS स्नैपशॉट के लिंक का अनुसरण करें
जबकि बहुत सारे फायदे हैं, एक महत्वपूर्ण प्रतिबंध है जो संभवतः कई उपयोगकर्ताओं को फेंक देगा:गेटवे तक इसके सार्वजनिक आईपी पते के माध्यम से पहुंचना संभव नहीं है। इसलिए, NFS विकल्प की तरह, यह आवश्यकता सेटअप में जटिलता जोड़ती है।
स्पष्ट सीमा के बावजूद और यह आश्वस्त होने के बावजूद कि मैं इस सेटअप को पूरा नहीं कर पाऊंगा, मैं अभी भी यह जानना चाहता था कि यह कैसे किया जाता है। विज़ार्ड एडब्ल्यूएस मार्केटप्लेस कॉन्फ़िगरेशन स्क्रीन पर रीडायरेक्ट करता है।
ध्यान दें कि मार्केटप्लेस विजार्ड एक सेकेंडरी डिस्क बनाता है, हालांकि इसमें इतना बड़ा नहीं है आकार, और इसलिए हमें अभी भी दो आवश्यक वॉल्यूम जोड़ने की आवश्यकता है जैसा कि होस्ट सेटअप निर्देशों द्वारा इंगित किया गया है। यदि भंडारण आवश्यकताओं को पूरा नहीं किया जाता है तो विज़ार्ड स्थानीय डिस्क कॉन्फ़िगरेशन स्क्रीन पर ब्लॉक कर देगा:
यहां Amazon Marketplace कॉन्फ़िगरेशन स्क्रीन की एक झलक दी गई है:
SSH (उपयोगकर्ता sguser के रूप में लॉग इन) के माध्यम से एक टेक्स्ट इंटरफ़ेस सुलभ है। जो बुनियादी नेटवर्क समस्या निवारण उपकरण और अन्य कॉन्फ़िगरेशन विकल्प प्रदान करता है जिसे वेब GUI के माध्यम से नहीं किया जा सकता है:
~ $ ssh [email protected]
Warning: Permanently added 'ec2-3-231-96-109.compute-1.amazonaws.com,3.231.96.109' (ECDSA) to the list of known hosts.
'screen.xterm-256color': unknown terminal type.
AWS Storage Gateway Configuration
#######################################################################
## Currently connected network adapters:
##
## eth0: 172.31.1.185
#######################################################################
1: SOCKS Proxy Configuration
2: Test Network Connectivity
3: Gateway Console
4: View System Resource Check (0 Errors)
0: Stop AWS Storage Gateway
Press "x" to exit session
Enter command:और कुछ अन्य महत्वपूर्ण बिंदु:
- एनएफएस सेटअप के विपरीत, एस3 स्टोरेज तक कोई सीधी पहुंच नहीं है जैसा कि वॉल्यूम गेटवे एफएक्यू सेक्शन में बताया गया है।
- AWS दस्तावेज़ीकरण कनेक्शन के प्रदर्शन और सुरक्षा को बेहतर बनाने के लिए iSCSI सेटिंग्स को अनुकूलित करने पर जोर देता है।
FUSE
इस श्रेणी में, मैंने FUSE आधारित टूल सूचीबद्ध किए हैं जो PostgreSQL बैकअप टूल की तुलना में अधिक पूर्ण S3 संगतता प्रदान करते हैं, और Amazon स्टोरेज गेटवे के विपरीत, ऑन-प्रिमाइसेस होस्ट से डेटा ट्रांसफर की अनुमति देते हैं। अतिरिक्त कॉन्फ़िगरेशन के बिना Amazon S3 के लिए। ऐसा सेटअप स्थानीय फाइल सिस्टम के रूप में S3 स्टोरेज प्रदान कर सकता है जिसे PostgreSQL बैकअप टूल समानांतर pg_dump जैसी सुविधाओं का लाभ उठाने के लिए उपयोग कर सकता है।
s3fs-fuse
s3fs-fuse को C++ में लिखा गया है, जो कि Amazon S3 SDK टूलकिट द्वारा समर्थित भाषा है, और इसलिए यह मल्टीपार्ट अपलोड, कैशिंग, S3 स्टोरेज क्लास, सर्वर जैसी उन्नत S3 सुविधाओं को लागू करने के लिए उपयुक्त है। साइड एन्क्रिप्शन, और क्षेत्र चयन। यह अत्यधिक पॉज़िक्स संगत भी है।
एप्लिकेशन को मेरे फेडोरा 30 के साथ शामिल किया गया है जिससे इंस्टॉलेशन आसान हो गया है।
परीक्षण करने के लिए:
~/mnt/s9s $ time pg_dump -d test | gzip -c >test.pg_dump-$(date +%Y%m%d-%H%M%S).gz
real 0m35.761s
user 0m16.122s
sys 0m2.228s
~/mnt/s9s $ aws s3 ls s3://s9s-postgresql-backup
2019-10-28 03:16:03 79110010 test.pg_dump-20191028-031535.gzध्यान दें कि एनएफएस विकल्प के साथ अमेज़ॅन स्टोरेज गेटवे का उपयोग करने की तुलना में गति कुछ धीमी है। यह अत्यधिक POSIX संगत फाइल सिस्टम प्रदान करके निम्न प्रदर्शन की भरपाई करता है।
S3QL
S3QL स्टोरेज क्लास और सर्वर साइड एन्क्रिप्शन जैसी S3 सुविधाएँ प्रदान करता है। संपूर्ण S3QL दस्तावेज़ीकरण में कई विशेषताओं का वर्णन किया गया है, हालाँकि, यदि आप मल्टीपार्ट अपलोड की तलाश कर रहे हैं तो इसका कहीं उल्लेख नहीं है। ऐसा इसलिए है क्योंकि S3QL डी-डुप्लीकेशन सुविधा प्रदान करने के लिए अपने स्वयं के फ़ाइल विभाजन एल्गोरिथ्म को लागू करता है। सभी फाइलें 10 एमबी ब्लॉक में विभाजित हैं।
Red Hat आधारित सिस्टम पर संस्थापन सीधा है:yum के माध्यम से आवश्यक RPM निर्भरता स्थापित करें:
sqlite-devel-3.7.17-8.14.amzn1.x86_64
fuse-devel-2.9.4-1.18.amzn1.x86_64
fuse-2.9.4-1.18.amzn1.x86_64
system-rpm-config-9.0.3-42.28.amzn1.noarch
python36-devel-3.6.8-1.14.amzn1.x86_64
kernel-headers-4.14.146-93.123.amzn1.x86_64
glibc-headers-2.17-260.175.amzn1.x86_64
glibc-devel-2.17-260.175.amzn1.x86_64
gcc-4.8.5-1.22.amzn1.noarch
gcc48-4.8.5-28.142.amzn1.x86_64
mpfr-3.1.1-4.14.amzn1.x86_64
libmpc-1.0.1-3.3.amzn1.x86_64
libgomp-6.4.1-1.45.amzn1.x86_64
libgcc48-4.8.5-28.142.amzn1.x86_64
cpp48-4.8.5-28.142.amzn1.x86_64
python36-pip-9.0.3-1.26.amzn1.noarch
python36-libs-3.6.8-1.14.amzn1.x86_64
python36-3.6.8-1.14.amzn1.x86_64
python36-setuptools-36.2.7-1.33.amzn1.noarchफिर pip3 का उपयोग करके पायथन निर्भरता स्थापित करें:
pip-3.6 install setuptools cryptography defusedxml apsw dugong pytest requests llfuse==1.3.6इस टूल की एक उल्लेखनीय विशेषता S3QL फाइल सिस्टम है जिसे S3 बकेट के ऊपर बनाया गया है।
नासमझ
goofys एक विकल्प है जब प्रदर्शन POSIX अनुपालन को मात देता है। इसके लक्ष्य s3fs-fuse के विपरीत हैं। गति पर ध्यान भी वितरण मॉडल में परिलक्षित होता है। लिनक्स के लिए पूर्व-निर्मित बायनेरिज़ हैं। एक बार डाउनलोड हो जाने के बाद चलाएं:
~/temp/goofys $ ./goofys s9s-postgresql-backup ~/mnt/s9s/और बैकअप:
~/mnt/s9s $ time pg_dump -d test | gzip -c >test.pg_dump-$(date +%Y%m%d-%H%M%S).gz
real 0m27.427s
user 0m15.962s
sys 0m2.169s
~/mnt/s9s $ aws s3 ls s3://s9s-postgresql-backup
2019-10-28 04:29:05 79110010 test.pg_dump-20191028-042902.gzध्यान दें कि S3 पर ऑब्जेक्ट बनाने का समय फ़ाइल टाइमस्टैम्प से केवल 3 सेकंड दूर है।
ऑब्जेक्टएफएस
ऑब्जेक्टएफएस को लगभग 6 महीने पहले तक बनाए रखा गया प्रतीत होता है। मल्टीपार्ट अपलोड के लिए एक जांच से पता चलता है कि इसे लागू नहीं किया गया है, लेखक के शोध पत्र से हमें पता चलता है कि सिस्टम अभी भी विकास में है, और 2019 में पेपर जारी होने के बाद से मुझे लगा कि यह इसका उल्लेख करने योग्य होगा।
S3 क्लाइंट
जैसा कि पहले उल्लेख किया गया है, AWS S3 CLI का उपयोग करने के लिए, हमें सामान्य रूप से ऑब्जेक्ट स्टोरेज और विशेष रूप से Amazon S3 के लिए विशिष्ट कई पहलुओं को ध्यान में रखना होगा। यदि केवल आवश्यकता ही S3 स्टोरेज के अंदर और बाहर डेटा ट्रांसफर करने की क्षमता है, तो एक टूल जो Amazon S3 अनुशंसाओं का बारीकी से पालन करता है, वह काम कर सकता है।
s3cmd उन उपकरणों में से एक है जो समय की कसौटी पर खरे उतरे हैं। यह 2010 ओपन बीआई ब्लॉग इसके बारे में बात करता है, ऐसे समय में जब एस3 ब्लॉक पर नया बच्चा था।
उल्लेखनीय विशेषताएं:
- सर्वर-साइड एन्क्रिप्शन
- स्वचालित मल्टीपार्ट अपलोड
- बैंडविड्थ थ्रॉटलिंग
S3cmd पर जाएं:अधिक जानकारी के लिए अक्सर पूछे जाने वाले प्रश्न और ज्ञानकोष।
निष्कर्ष
अमेज़ॅन S3 के लिए PostgreSQL क्लस्टर का बैकअप लेने के लिए उपलब्ध विकल्प डेटा ट्रांसफर विधियों में भिन्न होते हैं और वे Amazon S3 रणनीतियों के साथ कैसे संरेखित होते हैं।
AWS स्टोरेज गेटवे इस सेवा का अधिकतम लाभ उठाने के लिए आवश्यक अतिरिक्त ज्ञान के साथ-साथ बढ़ी हुई जटिलता की कीमत पर, Amazon के S3 ऑब्जेक्ट स्टोरेज का पूरक है। उदाहरण के लिए, डिस्क की सही संख्या का चयन करने के लिए सावधानीपूर्वक योजना बनाने की आवश्यकता होती है, और परिचालन लागत को कम करने के लिए Amazon की S3 संबंधित लागतों की अच्छी समझ होना आवश्यक है।
केवल Amazon S3 ही नहीं, किसी भी क्लाउड स्टोरेज पर लागू होने पर, सार्वजनिक क्लाउड में डेटा को स्टोर करने के निर्णय के सुरक्षा निहितार्थ हैं। अमेज़ॅन S3 शून्य ज्ञान की कोई गारंटी नहीं है, या कोई ज्ञान प्रमाण नहीं है, आराम से डेटा और पारगमन में डेटा के लिए एन्क्रिप्शन प्रदान करता है। अपने डेटा पर पूर्ण नियंत्रण रखने की इच्छा रखने वाले संगठनों को क्लाइंट-साइड एन्क्रिप्शन को लागू करना चाहिए और एन्क्रिप्शन कुंजियों को अपने AWS इन्फ्रास्ट्रक्चर के बाहर संग्रहीत करना चाहिए।
S3 को स्थानीय फाइल सिस्टम में मैप करने के व्यावसायिक विकल्पों के लिए ObjectiveFS या NetApp के उत्पादों की जाँच करना उचित है।
अंत में, कई ओपन सोर्स एप्लिकेशन द्वारा प्रदान की गई नींव पर निर्माण करके, या शून्य से शुरू करके, अपने स्वयं के बैकअप टूल विकसित करने की मांग करने वाले संगठनों को सेफ प्रोजेक्ट द्वारा उपलब्ध कराए गए S3 संगतता परीक्षण का उपयोग करने पर विचार करना चाहिए।
