लिनक्स के लिए एन्क्रिप्टेड बैकअप और फ्रीबीएसडी दोनों के लिए पठनीय


8

मेरे पास एक लिनक्स और एक FreeBSD कंप्यूटर है, दोनों एन्क्रिप्टेड (LUKS और geli क्रमशः)। मैं सोच रहा हूं कि बैकअप कैसे बनाया जाए जो एन्क्रिप्टेड भी होगा और दोनों के लिए पठनीय होगा (ताकि यदि कंप्यूटर में से एक विफल हो जाए तो मैं दूसरे का उपयोग करके डेटा को जल्दी से पुनर्प्राप्त कर सकूं)।

दुर्भाग्यवश ऐसा लगता है कि बॉट एलयूकेएस और गेल ईआईआई संबंधित प्रणालियों के लिए कर्नेल मॉड्यूल हैं जिन्हें कभी भी संबंधित अन्य के साथ पोर्ट नहीं किया गया है। BSD / Linux संगत फाइल सिस्टम पर कई खतरों को देखते हुए ऐसा लगता है कि यह अनएन्क्रिप्टेड बैकअप बनाना काफी मुश्किल है जो दोनों के लिए पठनीय होगा (ext2 जाहिर तौर पर एक फाइलसिस्टम के लिए एकमात्र विकल्प है जो इसे अनुमति देगा)।

इसलिए मेरे विचार लिनक्स के केवीएम में एक वर्चुअल फ्रीबीएसडी को सेटअप करना था जो एक जीएलई एन्क्रिप्टेड बाहरी डिस्क को पढ़ने और लिखने में सक्षम होगा और डेटा को लिनक्स के एलयूकेएस-एनक्रिप्टेड सिस्टम (और अन्य तरीके से) एक अनएन्क्रिप्टेड वर्चुअल ext2 वॉल्यूम में स्थानांतरित करेगा। चारों ओर)। यह, हालांकि, बहुत जटिल लगता है और वास्तव में ऐसा करने का सही तरीका नहीं लगता है।

क्या कोई बेहतर / आसान / अधिक बेहतर तरीके हैं? या जिस तरह से ऊपर समझाया गया है वर्तमान में सबसे अच्छा संभव विकल्प है?

धन्यवाद; मैं मामले पर किसी भी विचार की सराहना करता हूं।


2
मुझे लगता है कि मैं इस सूची en.wikipedia.org/wiki/… को देख रहा हूं, जो दोनों पर समर्थित है, eCryptFS en.wikipedia.org/wiki/ECryptfs है, हालांकि यह ब्लॉक स्तर एन्क्रिप्शन नहीं है। यह एक फाइल सिस्टम लेयर है।
18

1
मैं जल्द ही अपने पसंदीदा ओएस के साथ एक और बॉक्स सेट करूंगा ताकि बैकअप की सेवा और स्टोर कर सकूं।
урослав Рахматуллин

अपने विचारों के लिए आप दोनों का बहुत-बहुत धन्यवाद। मुझे आशा है कि भविष्य में कुछ समय LUKS को FreeBSD या geli to Linux में पोर्ट कर देगा (मुझे दुर्भाग्य से दोनों के लिए आवश्यक प्रोग्रामिंग कौशल / अनुभव और उन्हें प्राप्त करने के लिए समय का
अभाव है

जवाबों:


3

आइए कुछ मान्यताओं को स्थापित करें। यदि वे सही नहीं हैं तो टिप्पणी करें।

  1. आप अलग-अलग ऑपरेटिंग सिस्टम और संभवतः अलग-अलग प्लेटफ़ॉर्म के साथ मशीनें चलाते हैं।
  2. आप इसे 2 मशीनों के साथ मामले के लिए वर्णन करते हैं, और लिनक्स और फ्रीबीएसडी
  3. आपकी मशीनें एन्क्रिप्टेड फ़ाइल सिस्टम का उपयोग करती हैं
  4. आप अपने डेटा का बैकअप बनाना चाहते हैं, और चाहते हैं कि उन बैकअप को भी एन्क्रिप्ट किया जाए
  5. आप संग्रह में योगदान करने वाले किसी भी प्लेटफ़ॉर्म से उन एन्क्रिप्टेड बैकअप में डेटा का उपयोग करने में सक्षम होना चाहते हैं

(टिप्पणी एन्क्रिप्शन के रूपों के बीच एक अंतर बनाने के लिए जोड़ा गया)

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

हालांकि, एक तरफ के रूप में - एन्क्रिप्टेड बैकअप पर हमेशा चिंता होती है: - आपको वास्तव में कुंजी के साथ सावधान रहने की जरूरत है - आंशिक भ्रष्टाचार आमतौर पर पूरे बैकअप को मारता है

मेरा सुझाव: का उपयोग करें

एक या एक से अधिक कंटेनरों में बैकअप बनाने के लिए दोनों मशीनें पहुंच सकती हैं।

अपने लैन के अंदर यह सब रखने के लिए, आप कर सकते हैं:

  1. एन्क्रिप्टेड बैकअप "पैकेज" को स्टोर करने के लिए, दोनों मेजबानों पर "बैकअप" फाइल सिस्टम बनाएं। इसे एन्क्रिप्टेड फाइलसिस्टम की आवश्यकता नहीं है, क्योंकि बैकअप "पैकेज" (उस पर संग्रहीत ब्रैप "चंक्स" कहता है) को एन्क्रिप्ट किया जाएगा
  2. NFS के साथ इन फाइल सिस्टम को निर्यात करें, और इसे क्रमशः अन्य होस्ट पर माउंट करें
  3. जब आप बैकअप बनाते हैं, तो उन्हें स्थानीय फाइल सिस्टम में डंप करें, और दूसरे होस्ट पर एनएफएस-माउंटेड डायरेक्टरी को मिरर करें। यह आपकी बैकअप फ़ाइलों के दो उदाहरण होने का अच्छा दुष्प्रभाव है।

अब आपके पास अपने सर्वर पर निम्नलिखित फाइल सिस्टम होंगे:

tux पर, आपकी लिनक्स मशीन:

/dev/foo            /           # encrypted filesystem
/dev/bar            /tuxdump    # unencrypted filesystem, local backup
beastie:/daemondump /daemondump # NFS backup destination

जानवर पर, आप FreeBSD मशीन:

/dev/flurb          /           # encrypted filesystem
/dev/baz            /daemondump # unencrypted filesystem, local backup
tux:/tuxdump        /tuxdump    # NFS backup destination

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


बिल्कुल नहीं। मुझे इसे ब्लॉक-बाय-ब्लॉक करने की आवश्यकता नहीं है और मुझे नेटवर्क पर होने की आवश्यकता नहीं है (हालाँकि आपके द्वारा सुझाए गए उपकरण बहुत दिलचस्प लगते हैं)। समस्या यह है (जैसा कि यह सही ढंग से Zoredache और срослав Рахматуллин द्वारा समझा गया था) कि अगर दोनों में से किसी भी कारण से सिस्टम टूट जाता है तो मुझे बैकअप लेने के लिए किसी तरह की आवश्यकता होती है। इसलिए बैकअप को एक एन्क्रिप्टेड फाइलसिस्टम (एक अन्य डिस्क पर) दोनों प्रणालियों के लिए सुलभ होना चाहिए। यह देशी एन्क्रिप्शन सिस्टम और लिनक्स और फ्रीबस के मूल फाइल सिस्टम दोनों के लिए एक समस्या है असंगत है। पहले जवाब नहीं देने के लिए खेद है।
0range

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

मैंने कभी भी नकल के बारे में नहीं सुना है, लेकिन यह बिल्कुल वैसा ही है जैसा मैं देख रहा हूँ! क्या आप जानते हैं कि यह कितना पुराना है? क्या यह स्थिर है? जब परियोजना शुरू हुई है तो मुझे कोई तारीख नहीं मिल रही है।
cnst

दोहरेपन [ duplicity.nongnu.org] 2002 के बाद से आसपास किया गया है, मैं इसे का उपयोग कर रहा सीए के बाद से 2004.
फ्लोरेंज केली

@ 0 व्यवस्था - "एन्क्रिप्शन" भेद को थोड़ा साफ कर दिया। मैं जो प्रस्ताव कर रहा हूं वह ब्लॉक-बाय-ब्लॉक नहीं है, यह फाइल-आधारित है। अनियंत्रित फाइल सिस्टम का उपयोग करने का सुझाव दें, क्योंकि उन्हें दोनों प्रणालियों द्वारा पढ़ा जा सकता है। उन पर एन्क्रिप्टेड बैकअप स्टोर करें, वे भी, दोनों प्लेटफ़ॉर्म पर संबंधित देशी टूल द्वारा पढ़े जा सकते हैं। यह आपकी आवश्यकताओं, एन्क्रिप्शन और पठनीयता, दोनों प्लेटफार्मों पर बॉक्स को टिक करना चाहिए।
फ्लोरेंज केली

2

द्वैधता - इस कार्य के लिए महान उपकरण, एन्क्रिप्शन के लिए GPG का उपयोग करता है। मैं इसे कुछ समय के लिए उपयोग कर रहा हूं और मैं वास्तव में सलाह देता हूं।

विकल्प के रूप में आप कोशिश कर सकते हैं:

  • ओबनम - एक नई परियोजना है, लेकिन इसमें कुछ अच्छी विशेषताएं हैं (यह ssh / scp के माध्यम से उपयोग करने पर थोड़ा धीमा है)
  • burp - पासवर्ड के साथ एन्क्रिप्शन

फ्लोरेंसे केली के जवाब के ऊपर मेरी टिप्पणी देखें। (और उन उपकरणों का सुझाव देने के लिए धन्यवाद)
0range

क्षमा करें, मैं केवल यहाँ टिप्पणी जोड़ सकता हूँ। ये उपकरण ब्लॉक-बाय-ब्लॉक नहीं हैं, लेकिन एफएस (आप एफएस का बैकअप ले सकते हैं और खिड़कियों पर भी इसे पुनर्स्थापित कर सकते हैं)। जीपीजी एन्क्रिप्शन के लिए एक मानक है - यह दोनों पर भी काम करता है। ये प्रोग्राम केवल नेटवर्क नहीं हैं, आप dir से dir का बैकअप ले सकते हैं। तो, डुप्लिकेट के साथ आप दोनों मशीनों का बैकअप ले सकते हैं और एन्क्रिप्टेड बैकअप को हर उस जगह पर पुनर्स्थापित कर सकते हैं जहाँ आपके पास डुप्लिकेट और GPG कुंजी है।
spinus

2

TrueCrypt को लिनक्स और फ्रीबीएसडी दोनों के तहत काम करना चाहिए। हालांकि मैं नियमित रूप से केवल विंडोज के तहत ट्रूक्रिप्ट का उपयोग करता हूं और खुद को फ्रीबीएसडी ट्रूक्रिप्ट को आजमाया नहीं है। YMMV।


1

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.