Restic: अनएन्क्रिप्टेड बैकअप

मैंने इस सुविधा अनुरोध को अब कई बार सुना है, और मेरे मन में था कि इसमें कोई समस्या थी। चूंकि मुझे यह नहीं मिल रहा है, इसलिए इस सुविधा अनुरोध को यहां ट्रैक किया गया है। संक्षिप्त संस्करण है: हम अंत में एन्क्रिप्शन को अक्षम करने के लिए एक विकल्प जोड़ सकते हैं, लेकिन यह इस समय रोडमैप पर नहीं है।

लंबा संस्करण है:

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

जब मैं उन्हें ढूंढूंगा तो मैं और अंक जोड़ सकता हूं।

अनएन्क्रिप्टेड बैकअप (स्थानीय रूप से) चाहने का एक वैकल्पिक कारण यह है कि एक केंद्रीय भंडार कई उपयोगकर्ताओं द्वारा साझा किया जा सकता है - यानी मेरे होम सर्वर पर मैं HTTPS के माध्यम से बैकअप भेजना चाहता हूं, लेकिन उन सभी को एक सामान्य भंडार में काट दिया जाए, भले ही उन्हें अलग-अलग उपयोगकर्ताओं के लिए तार्किक रूप से अलग होने के रूप में प्रस्तुत किया गया हो।

एक मौका है कि हमलावर एक क्लाइंट को बिना एन्क्रिप्शन के डेटा को (मूल रूप से) एन्क्रिप्टेड रिपॉजिटरी में सहेजने के लिए धोखा देने का एक तरीका ढूंढते हैं।

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

@wrouesnel आप पहले से ही ऐसा कर सकते हैं, होस्टनाम से अलग! (मैं दूसरे दिन भी यही सोच रहा था) :)

@alexeymuranov आप कैसे निर्धारित करते हैं कि उपयोगकर्ता द्वारा दर्ज किया गया पासवर्ड एन्क्रिप्टेड निर्देशिका के लिए एन्क्रिप्शन पासवर्ड है, या अनएन्क्रिप्टेड निर्देशिका की प्रामाणिकता की पुष्टि के लिए मैक पासवर्ड है? अधिक --switches ? यह बहुत जल्दी गन्दा हो जाता है।

मैं स्थानीय बैकअप बनाने के लिए यह विकल्प रखना चाहता हूं। उदाहरण के लिए, हर दिन मैं अपने सर्वर पर अपनी ~/संगीत निर्देशिका का बैकअप चलाता हूं, लेकिन मुझे इसे एन्क्रिप्ट करने की आवश्यकता नहीं है। बैकअप हार्डवेयर विफलता या हानि से बचाने के लिए नहीं है (मेरे पास इसके लिए अन्य बैकअप हैं), लेकिन केवल दुर्घटनाओं और बिटरोट से बचाने के लिए। और सर्वर बल्कि कम शक्ति वाला है, इसलिए एन्क्रिप्शन ओवरहेड एक मुद्दा है।

@alphapapa इसके लिए rsync ।
संपादित करें: और फ़ाइल अनुमतियाँ/विशेषताएँ। BTW, "हार्डवेयर विफलता" और "बिट्रोट" में क्या अंतर है?

@cfcs , rsync डुप्लीकेट नहीं है।

उसके लिए rsync है।

@cfcs जैसा कि हम सभी जानते हैं, दर्पण बैकअप नहीं है। ;) ओबनम का उपयोग करते हुए, मैं रेस्टिक के समान बैकअप की एक श्रृंखला रखता हूं: keep = 7d,8w,12m,3y जब से मैंने अपनी GPG कुंजी लगभग खो दी है (क्योंकि इसे मेरी सूचना के बिना रहस्यमय तरीके से 0 बाइट्स में छोटा कर दिया गया था, और काटे गए फ़ाइल का बैकअप लिया गया था) बार-बार), और मुझे इसे सीडी-आर पर एक साल पुराने बैकअप से खोदना पड़ा, मैं पुराने बैकअप डेटा को आसपास रखने के महत्व को पहचानता हूं।

BTW, "हार्डवेयर विफलता" और "बिट्रोट" में क्या अंतर है?

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

और जैसा कि एलेक्सी बताते हैं, rsync डिडुप्लिकेट नहीं करता है, न ही यह पुराने बैकअप डेटा की छंटाई के लिए प्रदान करता है, न ही डेटा अखंडता जांच, आदि। rsync एक अच्छा उपकरण है, और मैं इसे नियमित रूप से उपयोग करता हूं, लेकिन बैकअप बनाने के लिए नहीं।

एन्क्रिप्शन अब महंगा नहीं है, कम से कम यदि आपके पास एईएस-एनआई (हार्डवेयर त्वरित एन्क्रिप्शन) है, जो आजकल काफी आम है (कम से कम लैपटॉप और सर्वर में)

जब तक आपका सॉफ़्टवेयर चलते-फिरते न लिखा हो। गो का क्रायप्रो केवल इंटेल को छोड़कर किसी भी चीज़ के लिए सॉफ़्टवेयर है - इसलिए एक आर्म डिवाइस के साथ आप उसी फ़ाइल सेट के लिए "अनुमानित बैकअप समय - 14 दिन" के साथ फंस गए हैं जो मेरे NAS पर आधिकारिक ओपनएसएल आधारित बैकअप समाधान के साथ 30 मिनट से भी कम समय में पूरा हो जाता है। .

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

फिर भी एन्क्रिप्शन बहुत उपयोगी है, जब मैं एक अविश्वसनीय लक्ष्य का समर्थन कर रहा हूँ।

लोगों को बैकअप के साथ पासवर्ड सहित टेक्स्ट फ़ाइल को सुरक्षित करने के लिए प्रेरित किया जा सकता है...

मैं एक लुक्स/डीएम-क्रिप्ट एन्क्रिप्टेड बैकअप लक्ष्य का भी उपयोग करता हूं। यह एक बाहरी यूएसबी डिस्क है जिसे मैं /बैकअप/ पर माउंट करता हूं
आप बस उस स्थान (/बैकअप/रेस्टिक_पासवर्ड) पर एक पासवर्ड फ़ाइल बना सकते हैं और --password-file का उपयोग करके इसे रेस्टिक को फीड कर सकते हैं। भंडार /बैकअप/रेस्टिक_रेपो/ के अंतर्गत आता है
पासवर्ड फ़ाइल को अपरिवर्तनीय बनाना महत्वपूर्ण है, या यदि आप दुर्घटना से खो जाते हैं तो आप खराब हो जाते हैं: chattr +i /Backup/restic_password
इसके अलावा, मैं सिर्फ "रेस्टिक" को पासवर्ड के रूप में उपयोग करता हूं, बस मामले में।

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

अनएन्क्रिप्टेड बैकअप की अनुमति देने से ZFS या BtrFS या NTFS या जो भी फाइल सिस्टम बैकअप को संपीड़ित कर सकता है।

(यदि वांछित हो तो निचली परत पर dmcrypt के माध्यम से एन्क्रिप्शन किया जा सकता है)

अनएन्क्रिप्टेड बैकअप की अनुमति देने से ZFS या BtrFS या NTFS या जो भी फाइल सिस्टम बैकअप को संपीड़ित कर सकता है।

यहाँ भी, कोई संपीड़न और अनिवार्य एन्क्रिप्शन मेरे बैकअप सर्वर पर बहुत अधिक स्थान नहीं लेता है। मेरा उपयोग मामला (कुछ छवियां, बहुत सी छोटी xml/txt/csv फ़ाइलें) बिना किसी एन्क्रिप्शन (इसलिए ZFS अपना काम कर सकती हैं) या संपीड़न (~ zstd के साथ 2.3 संपीड़न अनुपात, 5) से बहुत लाभ होगा।

यदि आप ZFS का उपयोग कर रहे हैं, तो क्यों न केवल zfs send स्नैपशॉट का उपयोग करें?

ZFS स्नैपशॉट कई मामलों में बैकअप के लिए पर्याप्त नहीं हैं। यदि आपने किसी फ़ाइल में भ्रष्टाचार का पता नहीं लगाया है, या यदि आप वर्षों के लायक बचत करना चाहते हैं, तो ZFS स्नैपशॉट इतना अधिक मदद नहीं करते हैं। जैसे, मान लें कि आप FreeNAS का उपयोग कर रहे हैं और एक वर्ष का साप्ताहिक बैकअप बनाए रखना चाहते हैं। FreeNAS में निर्मित शेड्यूलिंग और स्नैपशॉट प्रबंधन _really_ इसे सही ढंग से बंद करने के लिए पर्याप्त नहीं है। यह "उद्यम" नहीं है।

यदि आपके पास अधिक विस्तृत शेड्यूलिंग सिस्टम है तो यह शायद बहुत बेहतर काम करेगा। इससे पहले कि आप इसे शिप कर सकें, एक स्नैपशॉट मौजूद होने की आवश्यकता वाले zfs भेजने की समस्या भी है; आपको एक स्नैपशॉट शेड्यूल भी प्रबंधित करना होगा और सुनिश्चित करना होगा कि आपका स्नैपशॉट और शेड्यूल्ड भेजना सिंक्रनाइज़ (मैन्युअल रूप से) है ताकि आप अपने आरटीओ/आरपीओ को हिट कर सकें।

और हाँ.. मैं FreeNAS पर एंटरप्राइज़ सुविधाओं की बात कर रहा हूँ। लेकिन यही चिंता...

एन्क्रिप्शन अब महंगा नहीं है, कम से कम यदि आपके पास एईएस-एनआई है तो नहीं

एईएस-एनआई आवश्यकता में बहुत सारे पुराने सर्वर शामिल नहीं हैं (जो कुछ मामलों में बैकअप के लिए _विशेष रूप से महत्वपूर्ण_ हैं!)।

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

एन्क्रिप्शन के बिना +1

यह उपयोगी होगा

एन्क्रिप्शन के बिना +1

यह उपयोगी होगा

दर्शकों के इनबॉक्स में बाढ़ से बचने के लिए कृपया '+1'-आईएनजी के बजाय मूल मुद्दे पर थम्स अप सुविधा का उपयोग करें। आपको धन्यवाद!

इस सुविधा की स्थिति क्या है?

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

कृपया इसे लागू करें।

@mrkafk रेस्टिक एन्क्रिप्शन के साथ आपके लिए वास्तविक समस्या क्या है? यहां तक ​​​​कि अगर आपको इसकी आवश्यकता नहीं है, तो आपको इसकी समस्या होने के लिए बहुत विशिष्ट कारणों की आवश्यकता होगी, क्योंकि आपके सीपीयू में हार्डवेयर एन्क्रिप्शन के लिए सबसे अधिक समर्थन है।

मैंने अपनी वास्तविक समस्या का वर्णन किया है: विशिष्ट संदर्भ को देखते हुए मुझे इसकी आवश्यकता नहीं है, जबकि मैं कम से कम समझता हूं कि यह btrfs फाइल सिस्टम में संपीड़न लाभ को समाप्त करता है। मेरे पास बैकअप के लिए बहुत सारी फाइलें हैं, इसलिए मैं पहली बार में सक्षम संपीड़न के साथ btrfs का उपयोग कर रहा हूं क्योंकि RAID-1 के साथ hw अतिरेक के लिए मुझे बहुत सारे डिस्क स्थान की आवश्यकता होती है (क्या यह उसके लिए नहीं था, मैं बहुत अधिक उपयोग करूंगा ext4)। साथ ही, कितनी मात्रा में नकली पासवर्ड के साथ एन्क्रिप्ट करना और एन्क्रिप्शन करना अनावश्यक रूप से लगता है ... मूर्खतापूर्ण।

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

यदि एन्क्रिप्शन कुंजी एन्क्रिप्टेड नहीं है तो उसे खोना असंभव है। यह बैकअप के लिए विशेष रूप से प्रासंगिक है।

मेबस

यदि एन्क्रिप्शन कुंजी एन्क्रिप्टेड नहीं है तो उसे खोना असंभव है। यह बैकअप के लिए विशेष रूप से प्रासंगिक है।

इस पर चर्चा की गई है कि दुनिया कल पहले ही खत्म हो जाएगी :) https://github.com/restic/restic/issues/1786