कन्टेनरको वा त्यसभित्रका फाइलको ब्याकअप? पुनःस्थापनाको स्वरूप हेरेर निर्णय गर्नुहोस्
इमेज र फाइल-स्तरीय ब्याकअपले फरक-फरक कुरा पुनःस्थापना गर्छन् र फरक-फरक कुञ्जीमा निर्भर हुन्छन्। भण्डारण गरिएको वस्तुलाई तपाईंलाई साँच्चै चाहिने पुनःस्थापनासँग मिलाउनुहोस्।
तपाईं एन्क्रिप्ट गरिएको कन्टेनरको ब्याकअप एउटै वस्तुका रूपमा लिन सक्नुहुन्छ, वा त्यसलाई माउन्ट गरेर भित्रका फाइलको ब्याकअप लिन सक्नुहुन्छ। दुवै VPNबाट सजिलै जान्छन्, र समानता त्यहीँ सकिन्छ। तिनीहरू फरक-फरक कुरा पुनःस्थापना गर्छन्, फरक-फरक कुञ्जीमा निर्भर हुन्छन्, फरक ठाउँ लिन्छन्, र कसैलाई डेटा फर्काउनु पर्दा फरक तरिकाले असफल हुन्छन्। पहिले पुनःस्थापनाको वस्तु छान्नुहोस्, त्यसपछि ढुवानी, त्यसपछि भण्डारण गरिएको प्रतिको इन्क्रिप्शन। तलको जाँचसूची त्यही क्रममा चल्छ, किनकि लगभग हरेक ब्याकअप विवाद वास्तवमा यी तीनमध्ये कुन पहिले तय भयो भन्नेमा मतभेद हो।
दुई वस्तु, दुई पुनःस्थापना स्वरूप
इमेज-स्तरीय ब्याकअपले कन्टेनर पुनःस्थापना गर्छ: इन्क्रिप्ट गरिएको भोल्युम फर्केर आउँछ र त्यसलाई खोल्न अझै त्यसको पुनःस्थापना सामग्री चाहिन्छ। फाइल-स्तरीय ब्याकअपले फाइल र डाइरेक्टरी-रूख पुनःस्थापना गर्छ, र तिनलाई जोगाउने जुनसुकै इन्क्रिप्शन ब्याकअप भण्डारको गुण हो, मूल कन्टेनरको होइन। टाढाको फोल्डरमा साधारण प्रत तेस्रो अवस्था हो, र त्यसले त्यो फोल्डरसँग संयोगवश भएको सुरक्षा उत्तराधिकारमा पाउँछ।
| Object | What a restore gives you | Where the encryption question lands |
|---|---|---|
| Encrypted container image | The volume, still locked | The container format and its recovery key material |
| Mounted files into a backup tool | Selected files and metadata | The backup repositorys own keys and design |
| Plain copy to a remote folder | Whatever the copy process kept | Whatever protects that storage afterwards |
बीचको पङ्क्ति त्यही हो जो मानिसहरू गलत पढ्छन्। यो पूर्ण रूपमा राम्रो डिजाइन हुन सक्छ: ब्याकअप प्रोग्रामले स्थानीय रूपमा स्पष्ट पाठ पढ्छ र इन्क्रिप्ट गरिएको, प्रमाणित भण्डार लेख्छ। तब सुरक्षा त्यो प्रोग्राम र त्यसका प्रमाणहरूमा टिक्छ, मूल कन्टेनरको पासवर्डमा होइन, र दुवैलाई एउटै नियन्त्रण भनेर वर्णन गर्नु हुँदैन।
जाँच 1: पुनःस्थापनाले के पुनर्निर्माण गर्नुपर्छ?
प्रश्न ब्याकअपको होइन, पुनःस्थापनाको रूपमा सोध्नुहोस्। आवश्यकता “यो सेवा अर्को होस्टमा फर्काउने” हो भने, इमेज र त्यसको पुनःस्थापना सामग्री सुसंगत उत्तर हो। आवश्यकता “मार्चको वित्तीय स्प्रेडसिट फर्काउने” हो भने, एउटा फाइल निकाल्न धेरै गिगाबाइटको इमेज पुनःस्थापना गर्नु महँगो उत्तर हो। दुवै वैध पुनःस्थापना हुन्, र ती परस्पर बदल्न मिल्ने बजेट होइनन्। एउटाको मात्र नाम लिने योजना अन्ततः अर्कोले परीक्षण गरिनेछ।
पुनःस्थापनाको लक्ष्य योजनामा लेख्नुहोस्: पूरै भोल्युम, डाइरेक्टरी-रूख वा व्यक्तिगत फाइल। त्यसपछि तिनीसँगै कुन मेटाडेटा जानुपर्छ भनी टिप्नुहोस्, किनकि स्वामित्व, अनुमति, विस्तारित विशेषता र समय-छाप फाइल-स्तरीय पुनःस्थापनाको भाग हुन् र परीक्षणमा पर्याप्त देखिएका प्रत-आधारित कार्यप्रवाहमा ती प्रायः हराउँछन्।
पुनःस्थापना कसले गर्ने पनि निर्णय गर्नुहोस्। जुनसुकै अपरेटरले माउन्ट गर्न सक्ने फाइल-स्तरीय भण्डार र कुञ्जीधारकको उपस्थिति चाहिने इमेज फरक पहुँच-ढाँचा हुन्, र कुनै पनि स्वतः राम्रो होइन। महत्त्वपूर्ण कुरा निर्णय जानाजान र लिखित हुनु हो।
जाँच 2: भण्डारण गरिएको प्रतिको सुरक्षा केले गर्छ?
VPN ले ढुवानीको एउटा खण्ड सुरक्षित गर्छ। स्थानान्तरण सकिएपछि भण्डारण गरिएको प्रतिबारे यसले केही भन्दैन, र “त्यो सुरुङबाट गयो” भन्नु ब्याकअप अपरेटरले तपाईंको डेटा पढ्न सक्ने क्षमताबारेको भनाइ होइन। टाढाको पक्ष अरू कसैले चलाउँछ भने प्रश्न यो हो कि तिनले के पढ्न सक्छन्, लिङ्क इन्क्रिप्ट थियो कि थिएन होइन।
इमेजका लागि यसको अर्थ कन्टेनरको कुञ्जी सामग्रीलाई इमेजबाट अलग रूपमा सुरक्षित गर्नु हो। हेडर गुमाउनु भोल्युम गुमाउनु हो, त्यसैले इमेज नभएको ठाउँमा हेडरको ब्याकअप लिनुहोस्:
cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20फाइल-स्तरीय भण्डारका लागि, उपकरणले सामग्री र मेटाडेटा होस्ट छोड्नुअघि इन्क्रिप्ट र प्रमाणित गर्छ कि भनी जाँच्नुहोस्, र कुञ्जी कसको हातमा छ भनी पत्ता लगाउनुहोस्। Resticको डिजाइन कागजात स्पष्ट भन्छ कि यसले विश्वसनीय स्रोत-होस्ट मान्छ र इन्क्रिप्शनले भण्डारमा पहुँच भएको व्यक्तिलाई ब्याकअप मेट्नबाट रोक्दैन। दुवै चेतावनी महत्त्वपूर्ण छन्: भण्डार गोप्य हुन सक्छ र तैपनि नष्ट हुन सक्छ।
जाँच 3: प्रत सुसंगत छ?
परिवर्तनशील फाइलसिस्टम कैद गर्ने ब्याकअप प्रत हो, पुनःस्थापना-बिन्दु होइन। इमेजका लागि भोल्युम उपकरणको समर्थित विधिबाट स्थिर स्न्यापसट लिनुहोस्, जसको सामान्य अर्थ स्न्यापसट कार्य वा अनमाउन्ट हो, ठूलो फाइल बदलिँदै गर्दा पढ्नु होइन:
lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonlyमाउन्ट गरिएका फाइलका लागि सक्रिय डेटाबेस र अन्य समन्वित डेटाका लागि अनुप्रयोगको समर्थित सुसंगतता-प्रक्रिया प्रयोग गर्नुहोस्। फाइलसिस्टम-स्तरीय प्रत र अनुप्रयोग-सुसंगत पुनःस्थापना-बिन्दु फरक वर्णन हुन्, र फरक पुनःस्थापित प्रतिबाट अनुप्रयोग सुरु गर्न खोज्दा मात्र देखिन्छ।
पुनःस्थापना सामग्री स्वतन्त्र सुरक्षित मार्गमा राख्नुहोस्। मूल मेसिन गुमाउँदा त्यसको ब्याकअप खोल्ने एकमात्र प्रमाण पनि कहिल्यै गुम्नु हुँदैन, र कुञ्जी-फाइल ब्याकअप लिइँदै गरेको भोल्युममै बस्छ भने ठ्याक्कै त्यही हुन्छ। त्यो अलगाव जानाजान जाँच्नुहोस्: मूल कहिल्यै नदेखेको होस्टमा, योजनाले उपलब्ध भनेको कुरा मात्र प्रयोग गरेर पुनःस्थापना गर्नुहोस्।
जाँच 4: यो वस्तुका लागि परिवर्तन-पहिचान लागू हुन्छ?
इन्क्रिप्ट गरिएको कन्टेनर अधिकांश स्थानान्तरण उपकरणलाई एउटा ठूलो अपारदर्शी फाइलजस्तो देखिन्छ, त्यसैले स्पष्ट पाठको सानो सम्पादनले उपकरण र ढाँचाअनुसार ठूलो पुनःपठन वा पूरै पुनःअपलोड गराउन सक्छ। restic ले अभिलेख गरेअनुसार परिवर्तनशील आकारको खण्डीकरण र प्रतिलिपि हटाउनेले त्यो घटाउन सक्छन्, तर त्यो त्यो उपकरणको गुण हो, सामान्य रूपमा इन्क्रिप्ट गरिएका कन्टेनरको होइन।
अनुमान नगरी नाप्नुहोस्। सानो, हानिरहित परिवर्तनपछि पहिलो चलाइलाई दोस्रोसँग तुलना गर्नुहोस्, र स्थानान्तरित बाइट तथा बितेको समय दुवै टिप्नुहोस्। प्रयोग गर्दा ज्ञात-राम्रो ब्याकअप राख्नुहोस्, ताकि एउटा परीक्षणले तपाईंको एकमात्र पुनःस्थापना-बिन्दु सकिदिँदैन।
त्यसपछि जाँचसूची एकमात्र अर्थपूर्ण परीक्षणले पूरा गर्नुहोस्: मूल मेसिनबिना पुनःस्थापना। पुनःस्थापित कन्टेनर खोल्नुहोस्, वा छानिएका फाइल तिनका मेटाडेटासहित पुनःस्थापना गर्नुहोस्, र अनुप्रयोग वा प्रयोगकर्ताले नतिजा प्रयोग गर्न सक्छ भनी पुष्टि गर्नुहोस्। त्यो परीक्षणको उत्तर दिन नसक्ने छिटो, राम्ररी इन्क्रिप्ट गरिएको स्थानान्तरण तपाईंको डेटाको प्रत हो, त्यसको ब्याकअप होइन।