MariaDB
 sql >> डेटाबेस >  >> RDS >> MariaDB

अपने MySQL और MariaDB बैकअप को कैसे एन्क्रिप्ट करें

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

अपना बैकअप कैसे एन्क्रिप्ट करें?

स्थानीय फ़ाइल एन्क्रिप्ट करें

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

openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpassword

यह वर्तमान निर्देशिका में एक नई, एन्क्रिप्टेड फ़ाइल, 'backup_file.tar.gz.enc' बनाएगा। आप इसे बाद में चलाकर कभी भी डिक्रिप्ट कर सकते हैं:

openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpassword

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

फ्लाई पर बैकअप एन्क्रिप्ट करें

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

mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl  enc -aes-256-cbc -k mypass > backup.xb.enc

आप इस विधि का उपयोग एक्स्ट्राबैकअप या मारियाबैकअप के साथ भी कर सकते हैं। वास्तव में, यह MariaDB दस्तावेज़ीकरण का उदाहरण है:

mariabackup --user=root --backup --stream=xbstream  | openssl  enc -aes-256-cbc -k mypass > backup.xb.enc

यदि आप चाहें, तो आप प्रक्रिया के भाग के रूप में डेटा अपलोड करने का प्रयास भी कर सकते हैं:

mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl  enc -aes-256-cbc -k mysecretpassword | tee -a mysqldump.gz.enc | nc 10.0.0.102 9991

परिणामस्वरूप, आपको एक स्थानीय फ़ाइल 'mysqldump.gz.enc' दिखाई देगी और डेटा की प्रतिलिपि एक प्रोग्राम में भेज दी जाएगी जो इसके बारे में कुछ करेगा। हमने 'एनसी' का इस्तेमाल किया, जिसने डेटा को दूसरे होस्ट पर स्ट्रीम किया, जिस पर निम्नलिखित निष्पादित किया गया था:

nc -l 9991 > backup.gz.enc

इस उदाहरण में हमने mysqldump और nc का उपयोग किया है लेकिन आप xtrabackup या mariabackup और कुछ टूल का उपयोग कर सकते हैं जो स्ट्रीम को Amazon S3, Google क्लाउड स्टोरेज या किसी अन्य क्लाउड प्रदाता पर अपलोड करेगा। कोई भी प्रोग्राम या स्क्रिप्ट जो स्टड पर डेटा स्वीकार करता है, उसका उपयोग 'एनसी' के बजाय किया जा सकता है।

एम्बेडेड एन्क्रिप्शन का उपयोग करें

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

इससे पहले कि हम इसका उपयोग कर सकें, हमें एक कुंजी बनानी होगी जिसका उपयोग डेटा को एन्क्रिप्ट करने के लिए किया जाएगा। यह निम्न आदेश चलाकर किया जा सकता है:

[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1Fhunjb

Xtrabackup कुंजी को सादे पाठ प्रारूप में स्वीकार कर सकता है (--encrypt-key विकल्प का उपयोग करके) या इसे फ़ाइल से पढ़ सकता है (--encrypt-key-file विकल्प का उपयोग करके)। उत्तरार्द्ध पासवर्ड और कुंजियों को सादे पाठ के रूप में पारित करने के रूप में सुरक्षित है, जिसके परिणामस्वरूप उन्हें बैश इतिहास में संग्रहीत किया जाता है। आप इसे चल रही प्रक्रियाओं की सूची में भी स्पष्ट रूप से देख सकते हैं, जो काफी खराब है:

root      1130  0.0  0.6  65508  4988 ?        Ss   00:46   0:00 /usr/sbin/sshd -D
root     13826  0.0  0.8  93100  6648 ?        Ss   01:26   0:00  \_ sshd: [email protected]
root     25363  0.0  0.8  92796  6700 ?        Ss   08:54   0:00  \_ sshd: vagrant [priv]
vagrant  25393  0.0  0.6  93072  4936 ?        S    08:54   0:01  |   \_ sshd: [email protected]/1
vagrant  25394  0.0  0.4  21196  3488 pts/1    Ss   08:54   0:00  |       \_ -bash
root     25402  0.0  0.4  52700  3568 pts/1    S    08:54   0:00  |           \_ sudo su -
root     25403  0.0  0.4  52284  3264 pts/1    S    08:54   0:00  |               \_ su -
root     25404  0.0  0.4  21196  3536 pts/1    S    08:54   0:00  |                   \_ -su
root     26686  6.0  4.0 570008 30980 pts/1    Sl+  09:48   0:00  |                       \_ innobackupex --encrypt=AES256 --encrypt-key=TzIZ7g+WzLt0PXWf8WDPf/sjIt7UzCKw /backup/

आदर्श रूप से, आप किसी फ़ाइल में संग्रहीत कुंजी का उपयोग करेंगे, लेकिन फिर एक छोटा सा गोचा है जिसके बारे में आपको जानकारी होनी चाहिए।

[email protected]:~# openssl rand -base64 24 > encrypt.key
[email protected]:~# innobackupex --encrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/
.
.
.
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
encryption: unable to set libgcrypt cipher key - User defined source 1 : Invalid key length
encrypt: failed to create worker threads.
Error: failed to initialize datasink.

आपको आश्चर्य हो सकता है कि समस्या क्या है। जब हम hexedit जैसे हेक्साडेसिमल संपादक में एन्क्रिप्ट.की फ़ाइल खोलेंगे तो यह स्पष्ट हो जाएगा:

00000000   6D 6B 2B 4B  66 69 55 4E  5A 49 48 77  39 42 36 72  68 70 39 79  6A 56 44 72  47 61 79 45  6F 75 6D 70  0A                                     mk+KfiUNZIHw9B6rhp9yjVDrGayEoump.

अब आप '0A' का उपयोग करके एन्कोड किए गए अंतिम वर्ण को देख सकते हैं। यह मूल रूप से लाइन फीड कैरेक्टर है, लेकिन एन्क्रिप्शन कुंजी का मूल्यांकन करते समय इसे ध्यान में रखा जाता है। एक बार जब हम इसे हटा देते हैं, तो हम अंततः बैकअप चला सकते हैं।

[email protected]:~# innobackupex --encrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql --innodb_buffer_pool_size=185M --innodb_flush_log_at_trx_commit=2 --innodb_file_per_table=1 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_read_io_threads=4 --innodb_write_io_threads=4 --innodb_doublewrite=1 --innodb_log_file_size=64M --innodb_log_buffer_size=16M --innodb_log_files_in_group=2 --innodb_flush_method=O_DIRECT --server-id=1
xtrabackup: recognized client arguments: --datadir=/var/lib/mysql --innodb_buffer_pool_size=185M --innodb_flush_log_at_trx_commit=2 --innodb_file_per_table=1 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_read_io_threads=4 --innodb_write_io_threads=4 --innodb_doublewrite=1 --innodb_log_file_size=64M --innodb_log_buffer_size=16M --innodb_log_files_in_group=2 --innodb_flush_method=O_DIRECT --server-id=1 --databases-exclude=lost+found --ssl-mode=DISABLED
encryption: using gcrypt 1.6.5
181116 10:11:25 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".

181116 10:11:25  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/var/lib/mysql/mysql.sock' as 'backupuser'  (using password: YES).
181116 10:11:25  version_check Connected to MySQL server
181116 10:11:25  version_check Executing a version check against the server...
181116 10:11:25  version_check Done.
181116 10:11:25 Connecting to MySQL server host: localhost, user: backupuser, password: set, port: not set, socket: /var/lib/mysql/mysql.sock
Using server version 5.7.23-23-57
innobackupex version 2.4.12 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 170eb8c)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 67108864
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
181116 10:11:25 >> log scanned up to (2597648)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 19 for mysql/server_cost, old maximum was 0
181116 10:11:25 [01] Encrypting ./ibdata1 to /backup/2018-11-16_10-11-25/ibdata1.xbcrypt
181116 10:11:26 >> log scanned up to (2597648)
181116 10:11:27 >> log scanned up to (2597648)
181116 10:11:28 [01]        ...done
181116 10:11:28 [01] Encrypting ./mysql/server_cost.ibd to /backup/2018-11-16_10-11-25/mysql/server_cost.ibd.xbcrypt
181116 10:11:28 [01]        ...done
181116 10:11:28 [01] Encrypting ./mysql/help_category.ibd to /backup/2018-11-16_10-11-25/mysql/help_category.ibd.xbcrypt
181116 10:11:28 [01]        ...done
181116 10:11:28 [01] Encrypting ./mysql/slave_master_info.ibd to /backup/2018-11-16_10-11-25/mysql/slave_master_info.ibd.xbcrypt
181116 10:11:28 [01]        ...done

परिणामस्वरूप हम एन्क्रिप्टेड फ़ाइलों से भरी एक बैकअप निर्देशिका के साथ समाप्त होंगे:

[email protected]:~# ls -alh /backup/2018-11-16_10-11-25/
total 101M
drwxr-x---  5 root root 4.0K Nov 16 10:11 .
drwxr-xr-x 16 root root 4.0K Nov 16 10:11 ..
-rw-r-----  1 root root  580 Nov 16 10:11 backup-my.cnf.xbcrypt
-rw-r-----  1 root root  515 Nov 16 10:11 ib_buffer_pool.xbcrypt
-rw-r-----  1 root root 101M Nov 16 10:11 ibdata1.xbcrypt
drwxr-x---  2 root root 4.0K Nov 16 10:11 mysql
drwxr-x---  2 root root  12K Nov 16 10:11 performance_schema
drwxr-x---  2 root root  12K Nov 16 10:11 sys
-rw-r-----  1 root root  113 Nov 16 10:11 xtrabackup_checkpoints
-rw-r-----  1 root root  525 Nov 16 10:11 xtrabackup_info.xbcrypt
-rw-r-----  1 root root 2.7K Nov 16 10:11 xtrabackup_logfile.xbcrypt

Xtrabackup में कुछ अन्य चर हैं जिनका उपयोग एन्क्रिप्शन प्रदर्शन को ट्यून करने के लिए किया जा सकता है:

  • --encrypt-threads एन्क्रिप्शन प्रक्रिया को समानांतर करने की अनुमति देता है
  • --encrypt-chunk-size एन्क्रिप्शन प्रक्रिया के लिए एक कार्यशील बफर को परिभाषित करता है।

यदि आपको फ़ाइलों को डिक्रिप्ट करने की आवश्यकता है, तो आप उसके लिए --decrypt विकल्प के साथ innobackupex का उपयोग कर सकते हैं:

[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/

चूंकि xtrabackup एन्क्रिप्टेड फाइलों को साफ नहीं करता है, आप निम्न वन-लाइनर का उपयोग करके उन्हें हटाना चाह सकते हैं:

for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; done

ClusterControl में बैकअप एन्क्रिप्शन

ClusterControl के साथ एन्क्रिप्टेड बैकअप केवल एक क्लिक दूर हैं। सभी बैकअप विधियाँ (mysqldump, xtrabackup या mariabackup) एन्क्रिप्शन का समर्थन करती हैं। आप दोनों एक बैकअप एड हॉक बना सकते हैं या आप अपने बैकअप के लिए एक शेड्यूल तैयार कर सकते हैं।

हमारे उदाहरण में हमने एक पूर्ण एक्स्ट्राबैकअप चुना है, हम इसे कंट्रोलर इंस्टेंस पर स्टोर करेंगे।

अगले पृष्ठ पर हमने एन्क्रिप्शन को सक्षम किया। जैसा कि कहा गया है, ClusterControl स्वचालित रूप से हमारे लिए एक एन्क्रिप्शन कुंजी बनाएगा। यही वह है, जब आप "बैकअप बनाएं" बटन पर क्लिक करते हैं तो एक प्रक्रिया शुरू हो जाएगी।

बैकअप सूची में नया बैकअप दिखाई दे रहा है। इसे एन्क्रिप्टेड (लॉक आइकन) के रूप में चिह्नित किया गया है।

हम आशा करते हैं कि यह ब्लॉग पोस्ट आपको यह सुनिश्चित करने के बारे में कुछ अंतर्दृष्टि प्रदान करती है कि कैसे सुनिश्चित करें कि आपके बैकअप ठीक से एन्क्रिप्ट किए गए हैं।


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. ClusterControl के साथ डेटाबेस बैकअप कैसे शेड्यूल करें

  2. कैसे EXP () मारियाडीबी में काम करता है

  3. मारियाडीबी दिनांक और समय इकाइयाँ

  4. मारियाडीबी के लिए डेटाबेस प्रदर्शन ट्यूनिंग

  5. मारियाडीबी में एक सीमा के भीतर एक यादृच्छिक पूर्णांक कैसे उत्पन्न करें