कसरी GitLab ले तपाईंलाई ठूला नेक्स्टक्लाउड भण्डारणहरू ब्याकअप गर्न मद्दत गर्दछ

हे हाबर!

आज म बिभिन्न कन्फिगरेसनहरूमा नेक्स्टक्लाउड भण्डारणहरूबाट ठूलो डाटाको ब्याकअप स्वचालित गर्ने हाम्रो अनुभवको बारेमा कुरा गर्न चाहन्छु। म Molniya AK मा सेवा स्टेशनको रूपमा काम गर्छु, जहाँ हामी IT प्रणालीहरूको कन्फिगरेसन व्यवस्थापन गर्छौं; Nextcloud डेटा भण्डारणको लागि प्रयोग गरिन्छ। रिडन्डन्सी सहित, वितरित संरचना सहित।

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

प्रागितिहास

नेक्स्टक्लाउड प्रशासित गर्दा, प्रभावकारी ब्याकअप व्यवस्थित गर्ने समस्या उत्पन्न हुन्छ, जुन ईन्क्रिप्टेड हुनुपर्छ, किनकि डाटा मूल्यवान छ।

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

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

पहिले, इनपुट डेटा हेरौं। हामीलाई चाहिन्छ:

• एक नोड वा धेरैको सर्तमा स्केलेबिलिटी। ठूला स्थापनाहरूको लागि हामी भण्डारणको रूपमा minio प्रयोग गर्छौं।
• ब्याकअप प्रदर्शन गर्ने समस्याहरूको बारेमा पत्ता लगाउनुहोस्।
• तपाईंले आफ्ना ग्राहकहरू र/वा हामीसँग ब्याकअप राख्नुपर्छ।
• समस्याहरू छिटो र सजिलैसँग समाधान गर्नुहोस्।
• ग्राहकहरू र स्थापनाहरू एकअर्काबाट धेरै फरक छन् - एकरूपता प्राप्त गर्न सकिँदैन।
• रिकभरी गति दुई परिदृश्यहरूमा न्यूनतम हुनुपर्छ: पूर्ण रिकभरी (विपत्ति), एउटा फोल्डर गल्तीले मेटियो।
• डुप्लिकेशन प्रकार्य आवश्यक छ।

ब्याकअप प्रबन्ध गर्ने समस्या समाधान गर्न, हामीले GitLab स्थापना गर्यौं। ट्याकल द्वारा थप विवरण।

निस्सन्देह, हामी यस्तो समस्या समाधान गर्ने पहिलो होइनौं, तर यो हामीलाई लाग्छ कि हाम्रो व्यावहारिक, मेहनतले कमाएको अनुभव रोचक हुन सक्छ र हामी यसलाई साझा गर्न तयार छौं।

हाम्रो कम्पनीको खुला स्रोत नीति भएकोले, हामी खुला स्रोत समाधान खोजिरहेका थियौं। बारीमा, हामी हाम्रा विकासहरू साझा गर्छौं र तिनीहरूलाई पोस्ट गर्छौं। उदाहरण को लागी, GitHub मा छ Nextcloud को लागि हाम्रो प्लगइन, जुन हामीले ग्राहकहरूलाई प्रदान गर्छौं, आकस्मिक वा जानाजानी मेटिएको अवस्थामा डाटा सुरक्षा बढाउँदै।

ब्याकअप उपकरणहरू

हामीले ब्याकअप निर्माण उपकरण छनोट गरेर समाधान विधिहरूको खोजी सुरु गर्यौं।

नियमित tar + gzip ले राम्रोसँग काम गर्दैन - डाटा नक्कल गरिएको छ। एक वृद्धिमा प्रायः धेरै थोरै वास्तविक परिवर्तनहरू हुन्छन्, र एकल फाइल भित्रको धेरै डेटा दोहोर्याइएको छ।
त्यहाँ अर्को समस्या छ - वितरित डाटा भण्डारणको अनावश्यकता। हामी minio प्रयोग गर्छौं र यसको डाटा मूल रूपमा अनावश्यक छ। वा तपाईंले minio मार्फत ब्याकअप गर्नुपर्‍यो - यसलाई लोड गर्नुहोस् र फाइल प्रणालीको बीचमा सबै स्पेसरहरू प्रयोग गर्नुहोस्, र, कम महत्त्वपूर्ण छैन, त्यहाँ केही बाल्टिनहरू र मेटा-जानकारीहरू बिर्सने जोखिम छ। वा डुप्लिकेशन प्रयोग गर्नुहोस्।

नक्कलको साथ ब्याकअप उपकरणहरू खुला स्रोतमा उपलब्ध छन् (हब्रेमा त्यहाँ थिए लेख यस विषयको बारेमा) र हाम्रा फाइनलहरू थिए बोर्ग и विश्राम। हाम्रो दुई एप्लिकेसनहरूको तुलना तल छ, तर अहिलेको लागि हामी तपाईंलाई बताउनेछौं कि हामीले कसरी सम्पूर्ण योजना व्यवस्थित गर्यौं।

ब्याकअपहरू प्रबन्ध गर्दै

बोर्ग र रेस्टिक राम्रो छन्, तर कुनै पनि उत्पादनमा केन्द्रीकृत नियन्त्रण संयन्त्र छैन। व्यवस्थापन र नियन्त्रणको उद्देश्यको लागि, हामीले एउटा उपकरण रोज्यौं जुन हामीले पहिले नै लागू गरिसकेका छौं, जस बिना हामी स्वचालन सहित हाम्रो कामको कल्पना गर्न सक्दैनौं - यो प्रसिद्ध CI/CD - GitLab हो।

विचार निम्नानुसार छ: नेक्स्टक्लाउड डाटा भण्डारण गर्ने प्रत्येक नोडमा gitlab-runner स्थापना गरिएको छ। धावकले ब्याकअप प्रक्रियाको अनुगमन गर्ने तालिकामा स्क्रिप्ट चलाउँछ, र यसले बोर्ग वा रेस्टिक सुरु गर्छ।

हामीले के पायौं? कार्यान्वयनबाट प्रतिक्रिया, परिवर्तनहरूमा सुविधाजनक नियन्त्रण, त्रुटिको अवस्थामा विवरणहरू।

यहाँ यहाँ GitHub मा हामीले विभिन्न कार्यहरूको लागि स्क्रिप्टको उदाहरणहरू पोस्ट गर्यौं, र हामीले यसलाई नेक्स्टक्लाउड मात्र होइन, अन्य धेरै सेवाहरूको ब्याकअपमा पनि संलग्न गर्यौं। त्यहाँ एक शेड्यूलर पनि छ यदि तपाईं यसलाई म्यानुअल रूपमा कन्फिगर गर्न चाहनुहुन्न (र हामी चाहँदैनौं) र .gitlab-ci.yml

Gitlab API मा CI/CD टाइमआउट परिवर्तन गर्ने कुनै तरिका छैन, तर यो सानो छ। यसलाई बढाउन आवश्यक छ, भन्नुहोस् 1d.

GitLab, सौभाग्य देखि, एक प्रतिबद्धता अनुसार मात्र सुरु गर्न सक्दैन, तर केवल एक तालिका अनुसार, यो वास्तवमा हामीलाई आवश्यक छ।

अब रैपर स्क्रिप्टको बारेमा।

हामीले यस लिपिको लागि निम्न सर्तहरू सेट गर्छौं:

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

पूर्ण लग GitLab मा कलाकृतिको रूपमा बचत गरिएको छ; यदि कुनै त्रुटि छैन भने, लग मेटाइन्छ। हामी ब्याशमा स्क्रिप्ट लेख्छौं।

खुला स्रोतको सन्दर्भमा कुनै पनि सुझाव र टिप्पणीहरू विचार गर्न हामी खुसी हुनेछौं - स्वागत छ।

यो कसरी काम गर्छ

ब्यास एक्जिक्युटरको साथ एक धावक ब्याकअप नोडमा सुरु गरिएको छ। अनुसूचक अनुसार, काम CI/CD एक विशेष शलजम मा सुरु गरिएको छ। धावकले त्यस्ता कार्यहरूको लागि विश्वव्यापी र्यापर स्क्रिप्ट सुरू गर्दछ, यसले ब्याकअप भण्डार, माउन्ट पोइन्टहरू र हामीले चाहेको सबै कुराको वैधता जाँच गर्दछ, त्यसपछि ब्याकअप गर्दछ र पुरानोलाई सफा गर्दछ। समाप्त ब्याकअप आफै S3 मा पठाइन्छ।

हामी यो योजना अनुसार काम गर्छौं - यो एक बाह्य AWS प्रदायक वा रूसी समकक्ष हो (यो छिटो छ र डेटा रूसी संघ छोड्दैन)। वा हामी यी उद्देश्यहरूका लागि ग्राहकको लागि उसको साइटमा छुट्टै minio क्लस्टर स्थापना गर्छौं। हामी सामान्यतया यो सुरक्षा कारणहरूका लागि गर्छौं, जब ग्राहकले डेटालाई उनीहरूको सर्किट छोड्न चाहँदैन।

हामीले ssh मार्फत ब्याकअप पठाउने सुविधा प्रयोग गरेका छैनौं। यसले सुरक्षा थप्दैन, र S3 प्रदायकको नेटवर्क क्षमताहरू हाम्रो एक ssh मेसिन भन्दा धेरै उच्च छन्।

तपाईको स्थानीय मेसिनलाई ह्याकरबाट जोगाउनको लागि, उसले S3 मा डाटा मेटाउन सक्ने हुनाले, तपाईले संस्करण सक्षम गर्नुपर्छ।
ब्याकअपले सधैं ब्याकअपलाई इन्क्रिप्ट गर्छ।

Borg सँग एन्क्रिप्टेड मोड छ none, तर हामी दृढताका साथ यसलाई सक्रिय गर्न सिफारिस गर्दैनौं। यस मोडमा, त्यहाँ कुनै इन्क्रिप्शन मात्र हुनेछैन, तर के लेखिएको छ त्यसको चेकसम गणना गरिएको छैन, जसको अर्थ अखण्डता मात्र अनुक्रमणिका प्रयोग गरेर अप्रत्यक्ष रूपमा जाँच गर्न सकिन्छ।

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

रुसी भाषामा पढ्नुहोस्

मुख्य कार्यहरू

• prepare प्रशिक्षण
• testcheck तयारी जाँच
• maincommand कोर टोली
• forcepostscript एक प्रकार्य जुन अन्तमा वा त्रुटि द्वारा निष्पादित हुन्छ। हामी यसलाई विभाजन अनमाउन्ट गर्न प्रयोग गर्छौं।

सेवा कार्यहरू

• cleanup हामी त्रुटिहरू रेकर्ड गर्छौं वा लग फाइल मेटाउँछौं।
• checklog त्रुटिको साथ लाइनको घटनाको लागि लगलाई पार्स गर्नुहोस्।
• ret बाहिर निस्कने ह्यान्डलर।
• checktimeout टाइमआउटको लागि जाँच गर्नुहोस्।

वातावरण

• VERBOSE=1 हामी तुरुन्तै स्क्रिनमा त्रुटिहरू प्रदर्शन गर्छौं (stdout)।
• SAVELOGSONSUCCES=1 सफलतामा लग बचत गर्नुहोस्।
• INIT_REPO_IF_NOT_EXIST=1 यदि यो अवस्थित छैन भने भण्डार सिर्जना गर्नुहोस्। पूर्वनिर्धारित रूपमा असक्षम।
• TIMEOUT मुख्य सञ्चालनको लागि अधिकतम समय। तपाइँ यसलाई अन्त्यमा 'm', 'h' वा 'd' को रूपमा सेट गर्न सक्नुहुन्छ।

पुरानो प्रतिलिपिहरूको लागि भण्डारण मोड। पूर्वनिर्धारित:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

लिपि भित्र चर

• ERROR_STRING - त्रुटिको लागि लग इन जाँचको लागि स्ट्रिङ।
• EXTRACT_ERROR_STRING - त्रुटि देखाउने स्ट्रिङको लागि अभिव्यक्ति।
• KILL_TIMEOUT_SIGNAL - समय समाप्त भएमा मार्ने संकेत।
• TAIL - स्क्रिनमा त्रुटिहरूसँग कति स्ट्रिङहरू।
• COLORMSG - सन्देशको रंग (पूर्वनिर्धारित पहेंलो)।

त्यो स्क्रिप्ट, जसलाई वर्डप्रेस भनिन्छ, सशर्त नाम छ, यसको चाल यो हो कि यसले mysql डाटाबेसलाई पनि ब्याकअप गर्दछ। यसको मतलब यो एकल-नोड Nexcloud स्थापनाहरूको लागि प्रयोग गर्न सकिन्छ, जहाँ तपाइँ डाटाबेस जगेडा पनि गर्न सक्नुहुन्छ। सुविधा भनेको सबै कुरा एकै ठाउँमा हुनु मात्र होइन, तर डाटाबेसका सामग्रीहरू पनि फाइलहरूको सामग्रीसँग नजिक छन्, किनकि समय भिन्नता न्यून छ।

रेस्टिक बनाम बोर्ग

त्यहाँ Borg र Restic बीच तुलना पनि छन् यहाँ Habré मा, र हामीसँग अर्को मात्र बनाउने काम थिएन, तर हाम्रो आफ्नै। यो हाम्रो लागि महत्त्वपूर्ण थियो कि यसले हाम्रो डेटामा हाम्रो विवरणहरू कसरी हेर्छ। हामी तिनीहरूलाई ल्याउँछौं।

हाम्रो चयन मापदण्ड, पहिले नै उल्लेख गरिएका (डिडुप्लिकेशन, छिटो रिकभरी, आदि) को अतिरिक्त:

• अधूरा कामको प्रतिरोध। हत्याको लागि जाँच गर्नुहोस् -9।
• डिस्क मा आकार।
• स्रोतहरूको लागि आवश्यकता (CPU, मेमोरी)।
• भण्डार गरिएका ब्लबहरूको आकार।
• S3 मा काम गर्नुहुन्छ
• अखण्डता जाँच।

परीक्षणको लागि, हामीले वास्तविक डेटा र 1,6 TB को कुल आकारको साथ एक ग्राहक लियौं।
सर्तहरू।

बोर्गलाई S3 सँग सीधै कसरी काम गर्ने थाहा छैन, र हामीले डिस्कलाई फ्यूजको रूपमा माउन्ट गर्यौं, मार्फत मूर्खहरू। रेस्टिकले यसलाई S3 मा पठायो।

Goofys धेरै छिटो र राम्रोसँग काम गर्दछ, र त्यहाँ छन् डिस्क क्यास मोड्युलजसले कामलाई थप गति दिन्छ। यो बिटा चरणमा छ, र, स्पष्ट रूपमा, हामीले परीक्षण (अन्य) को समयमा डेटा हानि संग क्र्यास गर्यौं। तर सुविधा यो हो कि ब्याकअप प्रक्रिया आफैंमा धेरै पढ्न आवश्यक पर्दैन, तर प्राय: लेख्न, त्यसैले हामी केवल अखण्डता जाँचको समयमा क्यास प्रयोग गर्छौं।

नेटवर्क को प्रभाव कम गर्न को लागी, हामीले एक स्थानीय प्रदायक - Yandex Cloud प्रयोग गर्यौं।

तुलनात्मक परीक्षण परिणामहरू।

• Kill -9 अर्को पुन: सुरु संग दुबै सफल थिए।
• डिस्क मा आकार। बोर्गले कम्प्रेस गर्न सक्छ, त्यसैले परिणामहरू अपेक्षित छन्।

ब्याकअप गर्ने
आकार

बोर्ग
562Gb

विश्राम
628Gb

• CPU द्वारा
  बोर्ग आफैंले पूर्वनिर्धारित कम्प्रेसनको साथ थोरै उपभोग गर्दछ, तर यसलाई मुर्ख प्रक्रियाको साथ मूल्याङ्कन गरिनु पर्छ। कुलमा, तिनीहरू तुलनात्मक छन् र समान परीक्षण भर्चुअल मेसिनमा लगभग 1,2 कोरहरू प्रयोग गर्छन्।
• मेमोरी। Restic लगभग 0,5GB छ, Borg लगभग 200MB छ। तर यो प्रणाली फाइल क्यास तुलनामा सबै नगण्य छ। त्यसैले यो अधिक मेमोरी आवंटित गर्न सल्लाह दिइन्छ।
• ब्लब साइजमा भिन्नता उल्लेखनीय थियो।

ब्याकअप गर्ने
आकार

बोर्ग
लगभग 500MB

विश्राम
लगभग 5MB

• Restic को S3 को साथ अनुभव उत्कृष्ट छ। Goofys मार्फत बोर्गसँग काम गर्दा कुनै प्रश्न उठ्दैन, तर यो नोट गरिएको छ कि ब्याकअप पूर्ण भएपछि क्यास रिसेट गर्नको लागि umount गर्न सल्लाह दिइन्छ। S3 को विशेषता यो हो कि अन्डर-पम्प गरिएको खण्डहरू कहिल्यै बाल्टिनमा पठाइने छैन, जसको मतलब अपूर्ण रूपमा भरिएको डाटाले ठूलो क्षति पुर्‍याउँछ।
• अखण्डता जाँचले दुबै अवस्थामा राम्रोसँग काम गर्छ, तर गति महत्त्वपूर्ण रूपमा फरक हुन्छ।
  रेस्टिक 3,5 घण्टा.
  Borg, 100GB SSD फाइल क्यास संग - 5 घण्टायदि डाटा स्थानीय डिस्कमा छ भने लगभग समान गतिको परिणाम।
  बोर्गले क्यास बिना S3 बाट सीधा पढ्छ 33 घण्टा। भयंकर लामो।

मुख्य कुरा यो हो कि बोर्गले कम्प्रेस गर्न सक्छ र ठूला ब्लबहरू छन् - जसले S3 मा भण्डारण र GET/PUT सञ्चालनहरू सस्तो बनाउँछ। तर यो थप जटिल र ढिलो प्रमाणीकरणको लागतमा आउँछ। रिकभरी गतिको लागि, हामीले कुनै फरक देखेनौं। रेस्टिकले पछिको ब्याकअपहरू (पहिलो पछि) थोरै लामो लिन्छ, तर महत्त्वपूर्ण रूपमा होइन।

छनोटमा अन्तिम तर कम से कम समुदायको आकार थियो।

र हामीले बोर्ग रोज्यौं।

सङ्कुचन बारे केही शब्दहरू

बोर्गसँग यसको शस्त्रागारमा उत्कृष्ट नयाँ कम्प्रेसन एल्गोरिथ्म छ - zstd। कम्प्रेसन गुणस्तर gzip भन्दा खराब छैन, तर धेरै छिटो। र पूर्वनिर्धारित lz4 को गति मा तुलनात्मक।

उदाहरणका लागि, MySQL डाटाबेस डम्प समान गतिमा lz4 भन्दा दुई गुणा राम्रो कम्प्रेस गरिएको छ। यद्यपि, वास्तविक डेटाको अनुभवले नेक्स्टक्लाउड नोडको कम्प्रेसन अनुपातमा धेरै थोरै भिन्नता रहेको देखाउँछ।

बोर्गसँग बरु बोनस कम्प्रेसन मोड छ - यदि फाइलमा उच्च एन्ट्रोपी छ भने, त्यसपछि कम्प्रेसन लागू हुँदैन, जसले गति बढाउँछ। सिर्जना गर्दा विकल्प द्वारा सक्षम
-C auto,zstd
zstd एल्गोरिथ्मको लागि
त्यसैले यो विकल्पको साथ, पूर्वनिर्धारित कम्प्रेसनको तुलनामा, हामीले पायौं
क्रमशः ५६० जीबी र ५६२ जीबी। माथिको उदाहरणबाट डाटा, मलाई सम्झाउन दिनुहोस्, सङ्कुचन बिना परिणाम 560Gb हो। 562GB भिन्नताको नतिजाले हामीलाई केही हदसम्म चकित तुल्यायो, तर हामीले सोच्यौं कि हामीले यसलाई सबै पछि छान्नेछौं। auto,zstd.

ब्याकअप प्रमाणिकरण विधि

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

एउटै योजना प्रयोग गरेर, हामी एन्टिभाइरस (तथ्य पछि) संग फाइलहरू जाँच गर्छौं। आखिर, प्रयोगकर्ताहरूले नेक्स्टक्लाउडमा विभिन्न चीजहरू अपलोड गर्छन् र सबैसँग एन्टिभाइरस हुँदैन। खन्याउने समयमा निरीक्षण सञ्चालन गर्न धेरै समय लाग्छ र व्यापारमा हस्तक्षेप गर्दछ।

स्केलेबिलिटी विभिन्न ट्यागहरूसँग विभिन्न नोडहरूमा धावकहरू चलाएर प्राप्त गरिन्छ।
हाम्रो निगरानीले एक विन्डोमा GitLab API मार्फत ब्याकअप स्थितिहरू सङ्कलन गर्दछ; आवश्यक भएमा, समस्याहरू सजिलै देख्न सकिन्छ र सजिलै स्थानीयकरण गरिन्छ।

निष्कर्षमा

नतिजाको रूपमा, हामीलाई निश्चित रूपमा थाहा छ कि हामी ब्याकअपहरू बनाउँछौं, हाम्रा ब्याकअपहरू मान्य छन्, तिनीहरूसँग उत्पन्न हुने समस्याहरूले थोरै समय लिन्छ र कर्तव्य प्रशासकको स्तरमा समाधान गरिन्छ। tar.gz वा Bacula को तुलनामा ब्याकअपहरूले साँच्चै थोरै ठाउँ लिन्छन्।

स्रोत: www.habr.com