यह लेख एनएएस के निर्माण के बारे में एक श्रृंखला का हिस्सा है, और एक विशिष्ट प्रकार की प्रणाली के लिए लिखा गया है।

बैकअप दूसरा मुख्य कार्य है जिसे मैं NAS का उपयोग करके, रिपॉजिटरी प्रबंधन प्रणाली के बाद हल करना चाहता था।

उसके फैसले को घसीटा गया ...

इस विषय के बारे में बहुत सारे लेख और यहां तक ​​कि कई किताबें पहले ही लिखी जा चुकी हैं और इस बारे में विवादों में कई प्रतियाँ टूट चुकी हैं।

नीचे सामग्री के इस ढेर का पता लगाने का प्रयास किया गया है, इसे अपने सिर में रखें और अपेक्षाकृत सक्षम रूप से एक छोटी प्रणाली का निर्माण करें।

बैकअप सिस्टम (SRK) द्वारा निर्धारित किया जाता है:

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

नियमित बैकअप प्रक्रिया को निम्नलिखित मुख्य भागों में विभाजित किया गया है:

• नकल की आवधिक शुरुआत।
• मांग पर वसूली शुरू।
• कॉपी प्रक्रिया का परीक्षण।

NAS मंच के साथ प्रणाली के इंटरफ़ेस बिंदु:

• tank0/apps/backup - tank0/apps/backup भंडारण।
• tank1/apps/backup - tank1/apps/backup भंडारण।
• https://backup.NAS.cloudns.cc - वेब-आधारित सिस्टम इंटरफ़ेस।

बैकअप रिपॉजिटरी अलग फाइल सिस्टम हैं ।
यह आवश्यक है क्योंकि उनके विकल्प बहुत भिन्न हो सकते हैं, दोनों सामान्य फाइल सिस्टम से, और आपस में।

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

बैकअप सिद्धांत

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

ये सिद्धांत नीतियों और नियमों पर आधारित हैं।

यहाँ कुछ बुनियादी हैं:

• 3-2-1 । दो संग्रहण स्वरूपों में, कम से कम तीन बैकअप बनाएं, जिनमें से कम से कम एक को भौतिक रूप से अलग स्थान पर संग्रहीत किया जाना चाहिए। सिद्धांत का पालन करना वांछनीय है। मेरे मामले में, यह सिद्धांत आंशिक रूप से लागू किया गया है। सबसे पहले, तीन अलग-अलग मशीनें हैं जिन पर डेटा को आंशिक रूप से दोहराया गया है: एनएएस, काम और लैपटॉप। दूसरे, बादल की प्रतिकृति की योजना बनाई गई है।
• जाँच करें कि क्या कॉपी किया गया है । अन्यथा, ऐसा हो सकता है कि एक महत्वपूर्ण क्षण में, डेटा को पुनर्स्थापित नहीं किया जा सकता है। रिकवरी प्रक्रिया के माध्यम से बेहतर जांच करें।
• कार्य के लिए सही उपकरणों का उपयोग करें । यह संभावना है कि आभासी मशीनों के एक बेड़े की नकल करने के साथ, मशीन पर एक एजेंट के साथ फ़ाइलों की नकल करने के लिए एक प्रणाली खराब करेगी। विशेषीकृत सॉफ्टवेयर मशीन संसाधनों पर तेजी से और कम खर्चीली नकल करेगा। यह महत्वपूर्ण है कि उपकरण विश्वसनीय और सरल है। IBS ऐसा कुछ नहीं है जिसे आप आमतौर पर साथ खोदना चाहते हैं।
• अतिरिक्त के स्पष्ट अपवाद के साथ, सब कुछ कॉपी करना बेहतर है । या "खत्म नहीं होने से आगे निकल जाना बेहतर है।" यह अतिरिक्त फेंकना संभव होगा, लेकिन यदि रिवर्स पॉलिसी का उपयोग किया जाता है, तो एक मूल्यवान फ़ाइल को पुनर्स्थापित करना असंभव हो सकता है जिसे आप स्पष्ट रूप से निर्दिष्ट करना भूल गए थे।
• डेटा को जल्दी से चुनना और पुनर्स्थापित करना संभव होना चाहिए । यह सलाह दी जाती है, "एक क्लिक", और एक घंटे प्रतीक्षा न करें। औपचारिक रूप से, आपके पास बहुत कम आरटीओ, और पर्याप्त आरपीओ होना चाहिए। यह बेहद सुविधाजनक है अगर IBS आपको गलती से हटाए गए, और कई संस्करणों से चुनने की अनुमति देता है, और न केवल नवीनतम (उदाहरण के लिए, यदि यह क्षतिग्रस्त है, क्योंकि तार्किक त्रुटियों को बाहर नहीं किया गया है)।

लेख के अंत में उन स्रोतों के लिंक हैं जिन्हें आप इन बिंदुओं के साथ खुद को पूरी तरह से परिचित करने के लिए अध्ययन कर सकते हैं, साथ ही दूसरों के साथ भी पढ़ सकते हैं।

बैकअप नीति

जाहिर है, किसी भी बैकअप का लक्ष्य आपातकालीन स्थितियों में अनियोजित डेटा विनाश की लागत को कम करना है।

यह काम करने वाली मशीनों से लेकर थर्ड-पार्टी स्टोरेज तक के मूल्यवान डेटा की नकल करके हासिल किया जाता है।

बैकअप कार्य

निम्नलिखित कार्य बैकअप उद्देश्यों के लिए परिभाषित किए गए हैं:

• लक्ष्य डेटा हाइलाइट करें।
• बाद में पुनर्प्राप्ति के लिए निर्दिष्ट डेटा सहेजना।
• सहेजे गए डेटा की रिकवरी।
• परिवर्तन और विनाश के लिए संग्रहीत डेटा की स्थिरता सुनिश्चित करना।
• संग्रहीत डेटा तक पहुंच का अंतर।
• सिस्टम नियंत्रण और बैकअप प्रक्रिया प्रदान करना।

सिस्टम की आवश्यकताएं

सूची में आगे, दोनों कार्यात्मक और गैर-कार्यात्मक आवश्यकताएं मिश्रित हैं:

• बैकअप प्रदर्शन किया जाना चाहिए:
  
  • समय पर।
  • अनुरोध करने पर।
  • यदि आप पिछले को छोड़ देते हैं।
• डेटा बैकअप को 1 महीने की गहराई तक प्रति दिन कम से कम 1 बार प्रदान किया जाना चाहिए। स्नैपशॉट लेने की प्रथा, साथ ही साथ एक कामकाजी मशीन पर सिस्टम के पिछले संस्करण का उपयोग करने से पता चलता है कि यह मेरे लिए पर्याप्त है।
• डेटा रिकवरी का समय 1 जीबी प्रति 2 मिनट से अधिक नहीं होना चाहिए (नेटवर्क बैंडविड्थ की सीमा 81 एस। प्रति 1 जीबी है)। कारकों को सीमित करने के रूप में लैन बैंडविड्थ और डिस्क की गति को ध्यान में रखते हुए लिया गया।
• सभी चैनलों को एन्क्रिप्ट किया जाना चाहिए। संवेदनशील डेटा, जैसे कि ऑनलाइन सेवाओं में प्राधिकरण डेटा, को बचाया जा सकता है।
• सर्वर पर डिक्रिप्शन की संभावना के बिना, उपयोगकर्ता की मशीन पर एक गुप्त कुंजी के साथ उपयोगकर्ता बैकअप को एन्क्रिप्ट करना संभव होना चाहिए। यह महत्वपूर्ण है क्योंकि उपयोगकर्ताओं को सर्वर पर भरोसा करने की आवश्यकता नहीं है।
• अपूर्ण नकल में अधिक समय नहीं लेना चाहिए, उदाहरण के लिए, 30 मिनट से अधिक। इंटरनेट का उपयोग लैपटॉप से ​​डेटा कॉपी करने के लिए किया जाता है।
• क्लाउड की प्रतियों की नकल करने की क्षमता होनी चाहिए (बैकअप के एन्क्रिप्शन के साथ किसी विशेष क्लाउड स्टोरेज के लिए लचीले ढंग से प्रतिकृति को कॉन्फ़िगर करने की क्षमता)। यह "3-2-1 सिद्धांत" के परिणामों में से एक भी है।
• वेब-इंटरफ़ेस में एकीकरण के साथ एक सरल केंद्रीकृत प्रबंधन होना चाहिए।
• सर्वर पर न्यूनतम सुधार और जटिल सेटिंग्स।

आरक्षित संसाधन संरचना

मेरे मामले में, यह काफी विशिष्ट है:

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

खतरा रचना

यह वह जगह है, जहां क्या और किस तरह से संरक्षित किया जाना चाहिए।

मोबाइल कंप्यूटर के सभी मुख्य खतरे स्थिर करने के लिए खतरों को दोहराते हैं।
टैबलेट कंप्यूटर व्यावहारिक रूप से मोबाइल से भिन्न नहीं है, इस दृष्टिकोण से।

अतिरिक्त नीति शर्तें

उन्हें खाते में लेना उचित है:

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

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

बैकअप नियम

एक नीति के विकास के बाद, सीधे एक विनियमन के विकास के साथ आगे बढ़ना संभव है।
सामान्य मामले में, कई नियम हो सकते हैं: सामान्य, IBS प्रशासकों के लिए, उपयोगकर्ताओं के लिए, भंडारण के लिए जिम्मेदार लोगों के लिए, लक्ष्य प्रणालियों के प्रशासकों के लिए, आदि ...
लेकिन एक छोटी प्रणाली के मामले में, यह आमतौर पर एक व्यक्ति है, और इसलिए केवल एक ही विनियमन है।

नियमों का उद्देश्य

• डेटा बैकअप प्रक्रियाओं को परिभाषित करना।
• डेटा रिकवरी प्रक्रियाओं को परिभाषित करना।
• एक प्रणाली स्वास्थ्य जांच प्रक्रिया को परिभाषित करना।
• बैकअप भंडारण की स्थिति और मीडिया आवश्यकताओं।
• सुव्यवस्थित करने का काम।

विनियमन का उदाहरण

स्पॉइलर के तहत, आप देख सकते हैं कि एक बड़े संगठन में नियम क्या दिखते हैं, खुले स्रोतों से लिए गए रोज़रेस्ट्र विनियमन का उदाहरण।

यहां आपको एक छोटा उदाहरण के साथ एक और उदाहरण मिलेगा।

आरक्षण प्रक्रिया

बैकअप डेटा की संरचना:

• काम मशीनों:
  
  • व्यक्तिगत उपयोगकर्ता निर्देशिका ( /home/* )। .
  • .
  • , ( /opt ).
  • ( /etc ).
  • .
  • .
  • .
  • .
• :
  
  • .
• NAS:
  
  • Docker .
  • .
  • .
  • .
  • .
  • Docker .
  • .
  • .
• :
  
  • .

:

• .
• , .
• /etc/apt/apt.conf.d , , .
• Mikrotik .
• NAS .

:

• 1 . .
  3 .
• 1 .
  .
• 1 .
  .
• .
  .
• .
  6 , .

• , .
• , .

:

• live .
• .
• , .

, Debian ( Squeeze 2011 ), Slackware ReiserFS .

:

• , .
• .
• , .
• .

Mikrotik , RouterOS .

• .
  logcheck, .
• .

, .

• .
• 1 .
  .
• . .
• .

, .

:

• Veeam , , . , Acronis, , .
• .
• .

.
, .

UrBackup .
, .

.

UrBackup

, :

 # zfs create -o com.sun:auto-snapshot=false -p tank0/apps/backup # zfs set compression=on tank0/apps/backup 

, , UrBackup ZFS .

, :

 # zfs set dedup=on tank0/apps/backup 

UrBackup :

 # mkdir /tank0/docker/services/urbackup # cd /tank0/docker/services/urbackup # vim docker-compose.yml # docker-compose up -d 

docker-compose .
Web- .

 version: '2' networks: docker0: external: name: docker0 services: urbackup: uroni/urbackup-server image: restart: always expose: - 55414 ports: # - 55413:55413 - 55415:55415 - 35623:35623/udp volumes: - /tank0/apps/backup/urbackup/database:/var/urbackup - /tank0/apps/backup/urbackup/backups:/backups - /tank0/apps/backup/urbackup/log:/var/log - /etc/localtime:/etc/localtime:ro networks: - docker0 environment: - VIRTUAL_HOST=backup.* - VIRTUAL_PORT=55414 - VIRTUAL_PROTO=http - CERT_NAME=NAS.cloudns.cc - TZ=Europe/Moscow 

Docker uroni/urbackup-server , tristanteu/urbackup-docker .
.

, :

1. . UrBackup LDAP .
2. LDAP. LDAP . " ". , .
3. .
4. , . . . , NAS, .
5. -.

:

:

LDAP , : , .

:

 ou=users,dc=nas,dc=nas?memberOf,objectClass?sub?(&(memberOf=cn=users_backup,ou=groups,dc=nas,dc=nas)(uid={USERNAME})) 

- , .

, , .
, :

-:

, , .

, UrBackup:

• TCP 55415 — .
• TCP 55414 — Web- HTTP.
• TCP 55413 — Web- FastCGI, Web-. क्योंकि NAS HTTP/HTTPS, .
• TCP 35621 — .
• UDP 35622 — . . .
• TCP 35623 — .
• UDP 35623 — .

, 55415 , 35621, 35622, 35623 .

, .

:

• , shell .
• GUI , .
• Docker- .

UrBackup , .. , :

.

shell :

 TF=`mktemp` && wget "https://NAS.system.cloudns.cc/x?a=download_client&lang=ru&clientid=1&authkey=KEY&os=linux" -O $TF && sh $TF; rm $TF 

:

 ~# urbackupclientctl status { "capability_bits": 65548, "finished_processes": [], "internet_connected": true, "internet_status": "connected", "last_backup_time": 0, "running_processes": [], "servers": [], "time_since_last_lan_connection": 152446032 } 

NAS , :

• : /etc;/home;/var;/root;/tank0/apps;/tank0/docker .
• : /tank0/apps/backup;/tank1/apps/backup;/tank0/apps/cloud/nextcloud/html/data .

, , , , , .

, , , " ", , :

:

 ~# service urbackupclientbackend status ● urbackupclientbackend.service - UrBackup Client backend Loaded: loaded (/lib/systemd/system/urbackupclientbackend.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-09-30 21:55:53 MSK; 37min ago Main PID: 1694 (urbackupclientb) Tasks: 14 (limit: 4915) Memory: 13.4G CGroup: /system.slice/urbackupclientbackend.service └─1694 /usr/local/sbin/urbackupclientbackend --config /etc/default/urbackupclient --no-consoletime  30 22:33:48 host urbackupclientbackend[1694]: Hashing file "/home/artiom/Docs/Books/   .djvu"  30 22:33:48 host urbackupclientbackend[1694]: Hashing file "/home/artiom/Docs/Books/  .doc"  30 22:33:48 host urbackupclientbackend[1694]: Hashing file "/home/artiom/Docs/Books/-.fb2" 

, UrBackup , . .
— -, .

 ~# service urbackupclientbackend status ● urbackupclientbackend.service - UrBackup Client backend Loaded: loaded (/lib/systemd/system/urbackupclientbackend.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-09-30 20:36:54 MSK; 9s ago Main PID: 27034 (urbackupclientb) Tasks: 10 (limit: 4915) Memory: 6.1M CGroup: /system.slice/urbackupclientbackend.service └─27034 /usr/local/sbin/urbackupclientbackend --config /etc/default/urbackupclient --no-consoletime  30 20:36:54 host urbackupclientbackend[27034]: urbackupserver: Server started up successfully!  30 20:36:54 host urbackupclientbackend[27034]: FileSrv: Server started up successfully  30 20:36:54 host urbackupclientbackend[27034]: Started UrBackupClient Backend...  30 20:36:55 host urbackupclientbackend[27034]: Looking for old Sessions... 2 sessions  30 20:36:56 host urbackupclientbackend[27034]: Trying to connect to internet server "NAS.system.cloudns.cc" at port 55415  30 20:36:56 host urbackupclientbackend[27034]: Successfully connected.  30 20:36:56 host urbackupclientbackend[27034]: ERROR: Internet server auth failed. Error: Auth failed (Authkey/password wrong)  30 20:36:56 host urbackupclientbackend[27034]: InternetClient: Had an auth error  30 20:36:56 host urbackupclientbackend[27034]: ERROR: Internet server auth failed. Error: Auth failed (Authkey/password wrong)  30 20:36:56 host urbackupclientbackend[27034]: InternetClient: Had an auth error 

:

 ERROR: Internet mode not enabled. Please set "internet_mode_enabled" to "true". 

.

:

 ~# service urbackupclientbackend stop ~# rm -rf /usr/local/var/urbackup/ 

/etc/default/urbackupclient , .

, /usr/local/var/urbackup/data/settings.cfg .

, , :

 internet_server=NAS.system.cloudns.cc internet_server_port=55415 internet_authkey=44R3MUIdB computername=zenbook internet_mode_enabled=true 

, , -.
, , , .

Debian, , /etc/apt/apt.conf.d/80full-backup :

 DPkg::Post-Invoke {"test -x /usr/local/bin/urbackupclientctl && /usr/local/bin/urbackupclientctl start -f || true"; }; 

NAS, . , mtbackup SSH, NAS.
Python , , , UrBakup, .

:

• .
• .

, : . , .

, :

• .
• , .
• .
• , , .
• .
• .
• , .

, - , .

.
, , .
- , , Storj .

साहित्य

, , :

• debian-russian . , " rsync?".
• " " .
• " 3-2-1" Veeam .
• .
• , , , .
• Veeam .
• " " , , .
• " : " .
• , .
• .

, :

• W. Curtis Preston — "Backup & Recovery" — 2000 .
• .. — .
• . — Backup "" — 2014 .
• Steven Nelson — Pro Data Backup and Recovery — 2011 .
• Dorian Cougias — The Backup Book: Disaster Recovery from Desktop to Data Center, 3 edition — 2003 .
• (2017 ) .

.

, RTO, RPA, RPO. , , , .

- NAS , , , .