MySQL और MariaDB डेटाबेस के लिए क्लाउड बैकअप विकल्प

आपके डेटा का बैकअप लेने का मुख्य उद्देश्य, निश्चित रूप से, हार्डवेयर विफलता के मामले में अपने संग्रह को वापस रोल करने और एक्सेस करने की क्षमता है। आज व्यापार करने के लिए, आपको यह जानने की निश्चितता की आवश्यकता है कि आपदा की स्थिति में, आपका डेटा सुरक्षित और सुलभ होगा। यदि आपका डेटासेंटर आग की लपटों में गिर जाता है, तो आपको अपने बैकअप को ऑफसाइट स्टोर करने की आवश्यकता होगी।

छोटे और मध्यम आकार के व्यवसायों के लिए डेटा सुरक्षा एक चुनौती बनी हुई है। छोटे से मध्यम आकार के व्यवसाय डायरेक्ट-अटैच्ड स्टोरेज का उपयोग करके अपनी कंपनी के डेटा को संग्रहित करना पसंद करते हैं, अधिकांश फर्मों के पास ऑफसाइट बैकअप कॉपी करने की योजना है। स्थानीय भंडारण दृष्टिकोण आधुनिक कंपनी के सामने आने वाली सबसे गंभीर दुविधाओं में से एक को जन्म दे सकता है - आपदा के मामले में डेटा की हानि।

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

• क्या बैकअप किया गया डेटा बाहरी डेटा केंद्र में आराम से सुरक्षित है?
• क्या सार्वजनिक इंटरनेट नेटवर्क के माध्यम से बाहरी डेटा केंद्र में या उससे स्थानांतरण सुरक्षित है?
• क्या आरटीओ (रिकवरी टाइम ऑब्जेक्टिव) पर कोई प्रभाव पड़ता है?
• क्या बैकअप और पुनर्प्राप्ति प्रक्रिया हमारे आईटी कर्मचारियों के लिए काफी आसान है?
• क्या मौजूदा प्रक्रियाओं में किसी बदलाव की आवश्यकता है?
• क्या तृतीय पक्ष बैकअप टूल की आवश्यकता है?
• आवश्यक सॉफ़्टवेयर या डेटा स्थानांतरण के संदर्भ में अतिरिक्त लागतें क्या हैं?
• भंडारण लागत क्या हैं?

क्लाउड का बैकअप लेते समय बैकअप सुविधाएं

यदि आपका MySQL सर्वर या बैकअप गंतव्य सार्वजनिक क्लाउड, होस्टिंग प्रदाता या किसी अविश्वसनीय WAN नेटवर्क के माध्यम से कनेक्टेड इन्फ्रास्ट्रक्चर में स्थित है, तो आपको अपनी बैकअप नीति में अतिरिक्त कार्यों के बारे में सोचने की आवश्यकता है। MySQL के लिए डेटाबेस बैकअप करने के कुछ अलग तरीके हैं, और बैकअप के प्रकार के आधार पर, पुनर्प्राप्ति समय, आकार और बुनियादी ढांचे के विकल्प अलग-अलग होंगे। चूंकि कई क्लाउड स्टोरेज समाधान केवल अलग-अलग एपीआई फ्रंट एंड के साथ स्टोरेज हैं, इसलिए किसी भी बैकअप समाधान को थोड़ी सी स्क्रिप्टिंग के साथ किया जा सकता है। तो प्रक्रिया को सुचारू और सुरक्षित बनाने के लिए हमारे पास क्या विकल्प हैं?

एन्क्रिप्शन

बैकअप डेटा की सुरक्षा बढ़ाने के लिए एन्क्रिप्शन को लागू करना हमेशा एक अच्छा विचार है। एन्क्रिप्शन को लागू करने के लिए एक सरल उपयोग मामला वह है जहाँ आप बैकअप को सार्वजनिक क्लाउड में स्थित ऑफ़साइट बैकअप संग्रहण में धकेलना चाहते हैं।

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

दूसरी ओर, यदि आप एन्क्रिप्शन के लिए निजी कुंजी का उपयोग कर रहे हैं, तो कुंजी को सुरक्षित स्थान पर रखना सुनिश्चित करें। यदि निजी कुंजी गुम है, तो बैकअप बेकार और अप्राप्य होगा। यदि कुंजी चोरी हो जाती है, तो सभी बनाए गए बैकअप जो समान कुंजी का उपयोग करते हैं, उनसे समझौता किया जाएगा क्योंकि वे अब सुरक्षित नहीं हैं। आप निजी या सार्वजनिक कुंजी बनाने के लिए लोकप्रिय GnuPG या OpenSSL का उपयोग कर सकते हैं।
GnuPG का उपयोग करके mysqldump एन्क्रिप्शन करने के लिए, एक निजी कुंजी उत्पन्न करें और तदनुसार विज़ार्ड का पालन करें:

$ gpg --gen-key

हमेशा की तरह एक सादा mysqldump बैकअप बनाएं:

$ mysqldump --routines --events --triggers --single-transaction db1 | gzip > db1.tar.gz

डंप फ़ाइल को एन्क्रिप्ट करें और पुराने सादे बैकअप को हटा दें:

$ gpg --encrypt -r ‘[email protected]’ db1.tar.gz
$ rm -f db1.tar.gz

GnuPG स्वचालित रूप से एन्क्रिप्टेड फ़ाइल पर .gpg एक्सटेंशन जोड़ देगा। डिक्रिप्ट करने के लिए,
बस gpg कमांड को --decrypt ध्वज के साथ चलाएँ:

$ gpg --output db1.tar.gz --decrypt db1.tar.gz.gpg

OpenSSL का उपयोग करके एक एन्क्रिप्टेड mysqldump बनाने के लिए, एक निजी कुंजी और एक सार्वजनिक कुंजी उत्पन्न करनी होगी:
OpenSSL req -x509 -nodes -newkey rsa:2048 -keyout dump.priv.pem -out dump.pub.pem

इस निजी कुंजी (dump.priv.pem) को भविष्य में डिक्रिप्शन के लिए सुरक्षित स्थान पर रखा जाना चाहिए। mysqldump के लिए, सामग्री को ओपनएसएल में पाइप करके एक एन्क्रिप्टेड बैकअप बनाया जा सकता है, उदाहरण के लिए

mysqldump --routines --events --triggers --single-transaction database | openssl smime -encrypt -binary -text -aes256
-out database.sql.enc -outform DER dump.pub.pem

डिक्रिप्ट करने के लिए, बस -डिक्रिप्ट ध्वज के साथ निजी कुंजी (dump.priv.pem) का उपयोग करें:
openssl smime -decrypt -in database.sql.enc -binary -inform

DEM -inkey dump.priv.pem -out database.sql

Percona XtraBackup का उपयोग स्थानीय या स्ट्रीमिंग बैकअप को एन्क्रिप्ट या डिक्रिप्ट करने के लिए xbstream विकल्प के साथ बैकअप में सुरक्षा की एक और परत जोड़ने के लिए किया जा सकता है। एन्क्रिप्शन libgcrypt लाइब्रेरी के साथ किया जाता है। एन्क्रिप्शन कुंजी को निर्दिष्ट करने के लिए --encrypt-key विकल्प और --encryptkey-file विकल्प दोनों का उपयोग किया जा सकता है। एन्क्रिप्शन कुंजियाँ

$ openssl rand -base64 24
$ bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1

यह मान तब एन्क्रिप्शन कुंजी के रूप में उपयोग किया जा सकता है। --encrypt-कुंजी का उपयोग करके innobackupex कमांड का उदाहरण:

$ innobackupex --encrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1” /storage/backups/encrypted

उपरोक्त ओपनएसएसएल कमांड के आउटपुट को एक फाइल पर रीडायरेक्ट किया जा सकता है और इसे एक की फाइल के रूप में माना जा सकता है:

openssl rand -base64 24 > /etc/keys/pxb.key

इसके बजाय --encrypt-key-file विकल्प के साथ इसका प्रयोग करें:

innobackupex --encrypt=AES256 --encrypt-key-file=/etc/keys/pxb.key /storage/backups/encrypted

डिक्रिप्ट करने के लिए, उपयुक्त --encrypt-key या --encrypt-key-file के साथ --decrypt विकल्प का उपयोग करें:

$ innobackupex --decrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1”
/storage/backups/encrypted/2018-11-18_11-10-09/

MySQL और MariaDB एन्क्रिप्शन के बारे में अधिक जानकारी के लिए, कृपया हमारी दूसरी ब्लॉग पोस्ट देखें।

संपीड़न

डेटाबेस क्लाउड बैकअप दुनिया के भीतर, संपीड़न आपके सबसे अच्छे दोस्तों में से एक है। यह न केवल भंडारण स्थान को बचा सकता है, बल्कि यह डेटा को डाउनलोड/अपलोड करने के लिए आवश्यक समय को भी काफी कम कर सकता है।
वहां बहुत सारे संपीड़न उपकरण उपलब्ध हैं, जैसे कि gzip, bzip2, zip, rar, और 7z।
आम तौर पर, mysqldump में सबसे अच्छी संपीड़न दर हो सकती है क्योंकि यह एक फ्लैट टेक्स्ट फ़ाइल है। संपीड़न उपकरण और अनुपात के आधार पर, एक संपीड़ित mysqldump मूल बैकअप आकार से 6 गुना छोटा हो सकता है। बैकअप को कंप्रेस करने के लिए, आप mysqldump आउटपुट को कंप्रेशन टूल में पाइप कर सकते हैं और इसे डेस्टिनेशन फाइल पर रीडायरेक्ट कर सकते हैं। आप टिप्पणियों, लॉक टेबल स्टेटमेंट (यदि InnoDB) जैसी कई चीजों को छोड़ सकते हैं, GTID पर्ज और ट्रिगर्स को छोड़ सकते हैं:

mysqldump --single-transaction --skip-comments --skip-triggers --skip-lock-tables --set-gtid-purged OFF --all-databases | gzip > /storage/backups/all-databases.sql.gz

Percona Xtrabackup के साथ, आप स्ट्रीमिंग मोड (innobackupex) का उपयोग कर सकते हैं, जो बैकअप निर्देशिका में फ़ाइलों की प्रतिलिपि बनाने के बजाय STDOUT को विशेष टार या xbstream प्रारूप में बैकअप भेजता है। कंप्रेस्ड बैकअप होने से आप डेटासेट के आधार पर मूल बैकअप आकार का 50% तक बचा सकते हैं। बैकअप कमांड में --compress विकल्प जोड़ें। स्ट्रीमिंग बैकअप में xbstream का उपयोग करके, आप --compress-threads विकल्प का उपयोग करके संपीड़न प्रक्रिया को तेज कर सकते हैं। यह विकल्प समानांतर डेटा संपीड़न के लिए xtrabackup द्वारा बनाए गए थ्रेड्स की संख्या निर्दिष्ट करता है। इस विकल्प के लिए डिफ़ॉल्ट मान 1 है। इस सुविधा का उपयोग करने के लिए, विकल्प को स्थानीय बैकअप में जोड़ें। संपीड़न के साथ एक उदाहरण बैकअप:

innobackupex --stream=xbstream --compress --compress-threads=4 > /storage/backups/backup.xbstream

तैयारी के चरण के दौरान लॉग लगाने से पहले, संपीड़ित फ़ाइलों को
xbstream का उपयोग करके विघटित करना होगा:
फिर, चलने से पहले .qp के साथ समाप्त होने वाली प्रत्येक फ़ाइल को निकालने के लिए qpress का उपयोग करें
चलाने से पहले -- MySQL डेटा तैयार करने के लिए अप्लाई-लॉग कमांड।

$ xbstream -x < /storage/backups/backup.xbstream

नेटवर्क थ्रूपुट सीमित करें

क्लाउड बैकअप के लिए एक बढ़िया विकल्प बैकअप करते समय नेटवर्क स्ट्रीमिंग बैंडविड्थ (एमबी/एस) को सीमित करना है। आप इसे pv टूल से हासिल कर सकते हैं। pv उपयोगिता डेटा संशोधक विकल्प -L RATE, --rate-limit RATE के साथ आती है जो स्थानांतरण को अधिकतम RATE बाइट्स प्रति सेकंड तक सीमित करती है। नीचे दिया गया उदाहरण इसे 2MB/s तक सीमित कर देगा।

$ pv -q -L 2m

नीचे के उदाहरण में, आप समानांतर gzip, एन्क्रिप्शन के साथ xtrabackup देख सकते हैं

 /usr/bin/innobackupex --defaults-file=/etc/mysql/my.cnf --galera-info --parallel 4 --stream=xbstream --no-timestamp . | pv -q -L 2m | pigz -9 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-008688-19992-72450efc3b6e9e4f.tmp > /home/ubuntu/backups/BACKUP-3445/backup-full-2018-11-28_213540.xbstream.gz.aes256 ) 2>&1.

बैकअप को क्लाउड में स्थानांतरित करें

अब जब आपका बैकअप संपीड़ित और एन्क्रिप्ट किया गया है, तो यह स्थानांतरण के लिए तैयार है।

Google क्लाउड

gsutil कमांड लाइन टूल का उपयोग Google क्लाउड स्टोरेज पर आपके स्टोरेज बकेट को प्रबंधित करने, मॉनिटर करने और उपयोग करने के लिए किया जाता है। यदि आपने पहले से ही gcloud उपयोग स्थापित किया है, तो आपके पास पहले से ही gsutil स्थापित है। अन्यथा, यहां से अपने Linux वितरण के लिए निर्देशों का पालन करें।

gcloud CLI स्थापित करने के लिए आप नीचे दी गई प्रक्रिया का पालन कर सकते हैं:

curl https://sdk.cloud.google.com | bash

अपना खोल पुनः प्रारंभ करें:

exec -l $SHELL

gcloud वातावरण को प्रारंभ करने के लिए gcloud init चलाएँ:

gcloud init

gsutil कमांड लाइन टूल को स्थापित और प्रमाणित करके, अपने वर्तमान प्रोजेक्ट में mysql-backups-storage नामक एक क्षेत्रीय स्टोरेज बकेट बनाएं।

gsutil mb -c regional -l europe-west1 gs://severalnines-storage/
Creating gs://mysql-backups-storage/

अमेज़न S3

यदि आप अपने डेटाबेस को होस्ट करने के लिए RDS का उपयोग नहीं कर रहे हैं, तो यह बहुत संभव है कि आप अपने स्वयं के बैकअप कर रहे हों। अमेज़ॅन का AWS प्लेटफ़ॉर्म, S3 (अमेज़ॅन सिंपल स्टोरेज सर्विस) एक डेटा स्टोरेज सेवा है जिसका उपयोग डेटाबेस बैकअप या अन्य व्यावसायिक महत्वपूर्ण फ़ाइलों को संग्रहीत करने के लिए किया जा सकता है। या तो यह Amazon EC2 इंस्टेंस है या आपका ऑन-प्रिमाइसेस वातावरण आप अपने डेटा को सुरक्षित करने के लिए सेवा का उपयोग कर सकते हैं।

जबकि बैकअप वेब इंटरफ़ेस के माध्यम से अपलोड किए जा सकते हैं, समर्पित s3 कमांड लाइन इंटरफ़ेस का उपयोग कमांड लाइन से और बैकअप ऑटोमेशन स्क्रिप्ट के माध्यम से करने के लिए किया जा सकता है। यदि बैकअप को बहुत लंबे समय तक रखा जाना है, और पुनर्प्राप्ति समय चिंता का विषय नहीं है, तो बैकअप को अमेज़ॅन ग्लेशियर सेवा में स्थानांतरित किया जा सकता है, जो बहुत सस्ता दीर्घकालिक भंडारण प्रदान करता है। फ़ाइलें (अमेज़ॅन ऑब्जेक्ट्स) तार्किक रूप से बकेट नामक एक विशाल फ्लैट कंटेनर में संग्रहीत की जाती हैं। S3 अपने आंतरिक के लिए एक REST इंटरफ़ेस प्रस्तुत करता है। आप इस API का उपयोग बकेट और ऑब्जेक्ट पर CRUD संचालन करने के साथ-साथ दोनों पर अनुमतियाँ और कॉन्फ़िगरेशन बदलने के लिए कर सकते हैं।

लिनक्स, विंडोज और मैकओएस पर एडब्ल्यूएस सीएलआई के लिए प्राथमिक वितरण विधि पाइप है, जो पायथन के लिए एक पैकेज मैनेजर है। निर्देश यहां पाया जा सकता है।

aws s3 cp severalnines.sql s3://severalnine-sbucket/mysql_backups

डिफ़ॉल्ट रूप से S3 ग्यारह 9s ऑब्जेक्ट स्थायित्व प्रदान करता है। इसका मतलब है कि यदि आप इसमें 1.000.000.000 (1 बिलियन) ऑब्जेक्ट स्टोर करते हैं, तो आप औसतन हर 10 साल में 1 ऑब्जेक्ट खोने की उम्मीद कर सकते हैं। S3 जिस तरह से 9s की प्रभावशाली संख्या प्राप्त करता है, वह वस्तु को स्वचालित रूप से कई उपलब्धता क्षेत्रों में दोहराता है, जिसके बारे में हम एक अन्य पोस्ट में बात करेंगे। Amazon के दुनिया भर में क्षेत्रीय डेटा केंद्र हैं।

Microsoft Azure संग्रहण

Microsoft के सार्वजनिक क्लाउड प्लेटफ़ॉर्म, Azure के पास अपने नियंत्रण रेखा इंटरफ़ेस के साथ भंडारण विकल्प हैं। यहां पर सूचनाएं प्राप्त की जा सकती हैं। ओपन-सोर्स, क्रॉस-प्लेटफ़ॉर्म Azure CLI, Azure प्लेटफ़ॉर्म के साथ काम करने के लिए कमांड का एक सेट प्रदान करता है। यह रिच डेटा एक्सेस सहित, Azure पोर्टल में देखी जाने वाली अधिकांश कार्यक्षमता देता है।

Azure CLI की स्थापना काफी सरल है, आप यहां निर्देश पा सकते हैं। नीचे आप अपने बैकअप को Microsoft संग्रहण में स्थानांतरित करने का तरीका जान सकते हैं।

az storage blob upload --container-name severalnines --file severalnines.sql --name severalnines_backup

MySQL और MariaDB बैकअप के लिए हाइब्रिड स्टोरेज

बढ़ते सार्वजनिक और निजी क्लाउड स्टोरेज उद्योग के साथ, हमारे पास हाइब्रिड स्टोरेज नामक एक नई श्रेणी है। यह तकनीक फ़ाइलों को स्थानीय रूप से संग्रहीत करने की अनुमति देती है, जिसमें परिवर्तन स्वचालित रूप से क्लाउड में रिमोट से सिंक हो जाते हैं। इस तरह का दृष्टिकोण तेजी से पुनर्स्थापना (निचला आरटीओ) के साथ-साथ व्यापार निरंतरता उद्देश्यों के लिए स्थानीय रूप से संग्रहीत हालिया बैकअप की आवश्यकता से आ रहा है।
कुशल संसाधन उपयोग का महत्वपूर्ण पहलू अलग बैकअप प्रतिधारण है। डेटा जो स्थानीय रूप से संग्रहीत किया जाता है, अनावश्यक डिस्क ड्राइव पर कम अवधि के लिए रखा जाएगा जबकि क्लाउड बैकअप संग्रहण लंबे समय तक आयोजित किया जाएगा। कई बार लंबे समय तक बैकअप बनाए रखने की आवश्यकता विभिन्न उद्योगों के लिए कानूनी दायित्वों से आती है (जैसे दूरसंचार को कनेक्शन मेटाडेटा स्टोर करना पड़ता है)। क्लाउड प्रदाता जैसे Google क्लाउड सर्विसेज, Microsoft Azure और Amazon S3 प्रत्येक वस्तुतः असीमित भंडारण की पेशकश करते हैं, जिससे स्थानीय स्थान की जरूरत कम हो जाती है। यह आपको अपनी बैकअप फ़ाइलों को लंबे समय तक बनाए रखने की अनुमति देता है, जब तक आप चाहें और स्थानीय डिस्क स्थान के बारे में चिंता न करें।

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

• नेटवर्क थ्रॉटलिंग
• बिल्ड इन की मैनेजमेंट के साथ एन्क्रिप्शन
• संपीड़न
• स्थानीय बैकअप के लिए अवधारण अवधि
• क्लाउड बैकअप के लिए अवधारण अवधि

निष्कर्ष

क्लाउड ने डेटा बैकअप उद्योग को बदल दिया है। अपने किफायती मूल्य बिंदु के कारण, छोटे व्यवसायों के पास एक ऑफ़साइट समाधान होता है जो उनके सभी डेटा का बैकअप लेता है।

आपकी कंपनी स्टोरेज की बढ़ती जरूरतों के लिए क्लाउड स्केलेबिलिटी और पे-एज-यू-गो प्राइसिंग का लाभ उठा सकती है। आप तत्काल बहाली के लिए डेटासेंटर में स्थानीय प्रतियां और AWS, Google और Azure से क्लाउड स्टोरेज सेवाओं के लिए एक सहज गेटवे दोनों प्रदान करने के लिए एक बैकअप रणनीति तैयार कर सकते हैं।

उन्नत टीएलएस और एईएस 256-बिट एन्क्रिप्शन और संपीड़न सुविधाएं सुरक्षित बैकअप का समर्थन करती हैं जो क्लाउड में काफी कम जगह लेती हैं।