सक्रिय पुनर्संचयित: आपत्ती पुनर्प्राप्ती जलद होऊ शकते? खूप वेगवान?

महत्त्वाच्या डेटाचा बॅकअप घेणे ही चांगली गोष्ट आहे. पण जर काम लगेच चालू ठेवायचे असेल आणि प्रत्येक मिनिट मोजला जाईल तर काय? आम्ही Acronis येथे शक्य तितक्या लवकर प्रणाली सुरू करण्याच्या समस्येचे निराकरण करणे किती शक्य आहे हे तपासण्याचे ठरविले. आणि सक्रिय पुनर्संचयित मालिकेतील ही पहिली पोस्ट आहे, ज्यामध्ये मी तुम्हाला सांगेन की आम्ही इनोपोलिस युनिव्हर्सिटीसह प्रकल्प कसा सुरू केला, आम्हाला कोणते उपाय सापडले आणि आज आम्ही काय काम करत आहोत. तपशील कट अंतर्गत आहेत.

नमस्कार! माझे नाव दौलेट तुंबायेव आहे, आणि आज मी आपत्ती पुनर्प्राप्ती वेगवान करणारी प्रणाली विकसित करण्याचा माझा अनुभव तुमच्यासोबत शेअर करू इच्छितो. प्रकल्पाच्या संपूर्ण विकासाच्या मार्गाबद्दल बोलण्यासाठी, थोडे दूरपासून सुरुवात करूया. मी सध्या Acronis येथे काम करतो, परंतु मी Innopolis विद्यापीठाचा पदवीधर देखील आहे, जिथे मी सॉफ्टवेअर डेव्हलपमेंट मॅनेजमेंट (MSIT-SE म्हणून ओळखले जाते) मध्ये मास्टर प्रोग्राम पूर्ण केला आहे. Innopolis एक तरुण विद्यापीठ आहे, आणि अभ्यासक्रम आणखी लहान आहे. परंतु हे कार्नेगी मेलॉन विद्यापीठाच्या अभ्यासक्रमावर तयार केले गेले आहे, ज्याच्या कार्यामध्ये औद्योगिक प्रकल्पांसारख्या विषयाचा समावेश आहे.

औद्योगिक प्रकल्पाचा उद्देश विद्यार्थ्याला खऱ्या विकासात बुडवणे आणि प्राप्त केलेले ज्ञान व्यवहारात एकत्रित करणे हा आहे. हे करण्यासाठी, विद्यापीठ Yandex, Acronis, MTC आणि इतर डझनभर कंपन्यांना सहकार्य करते (एकूण, 2018 पर्यंत, विद्यापीठाचे 144 भागीदार होते). सहकार्यादरम्यान, कंपन्या विद्यापीठाला त्यांचे कार्य क्षेत्र ऑफर करतात आणि विद्यार्थी त्यांच्या आवडी आणि प्रशिक्षणाच्या पातळीच्या जवळ असलेल्या प्रकल्पांपैकी एक निवडतात. अक्षरशः दोन वर्षांपूर्वी मी अजूनही “बॅरिकेड्सच्या पलीकडे” होतो आणि दुसर्‍या Acronis प्रकल्पावर विद्यार्थी म्हणून काम केले. पण यावेळी मी कंपनीच्या बाजूच्या विद्यार्थ्यांसाठी तांत्रिक सल्लागार बनलो आणि Innopolis ला Active Restore प्रकल्पाचा प्रस्ताव दिला. अ‍ॅक्टिव्ह रिस्टोरची कल्पना अक्रोनिस येथील कर्नल टीमने तयार केली होती, परंतु इनोपोलिस युनिव्हर्सिटीसह सोल्यूशनचा विकास सुरू झाला.

सक्रिय पुनर्संचयित - ते का आवश्यक आहे?

पारंपारिकपणे, आपत्ती पुनर्प्राप्ती मानक योजनेनुसार कार्य करते. तुमच्या संगणकातील समस्यांनंतर, तुम्ही काही बॅकअप सिस्टमच्या वेब इंटरफेसवर जा, उदाहरणार्थ, Acronis True Image, आणि मोठ्या “Restore” बटणावर क्लिक करा. पुढे तुम्हाला N मिनिटे थांबावे लागेल आणि त्यानंतरच तुम्ही काम करणे सुरू ठेवू शकता.

समस्या अशी आहे की हा क्रमांक N, ज्याला RTO (पुनर्प्राप्ती वेळेचे उद्दिष्ट) देखील म्हटले जाते, परवानगीयोग्य पुनर्प्राप्ती वेळ, खूप प्रभावी असू शकतो, जो कनेक्शनच्या गतीवर (पुनर्प्राप्ती क्लाउडवरून असल्यास), तुमच्या मशीनच्या हार्ड ड्राइव्हच्या आकारावर अवलंबून असते. , आणि इतर अनेक घटक. ते कमी करणे शक्य आहे का? होय, आपण हे करू शकता, कारण काम पुन्हा सुरू करण्यासाठी आपल्याला नेहमी संपूर्ण संगणक डिस्कची आवश्यकता नसते. तेच फोटो आणि व्हिडिओ कोणत्याही प्रकारे डिव्हाइसच्या कार्यक्षमतेवर परिणाम करत नाहीत आणि नंतर पार्श्वभूमीमध्ये खेचले जाऊ शकतात.

ड्रायव्हर पाहिजे...

ऑपरेटिंग सिस्टीम पूर्णपणे तयार असलेल्या डिस्कसह प्रारंभ करण्याची अपेक्षा करते. म्हणून, विंडोज डिस्कची अखंडता तपासण्यासाठी अनेक तपासण्या करते. OS ला अपेक्षित असलेल्या काही फायली गहाळ किंवा खराब झाल्यास सिस्टम सामान्य स्टार्टअपला अनुमती देणार नाही. या समस्येचे निराकरण करण्यासाठी, आम्ही तयार केलेल्या तथाकथित पुनर्निर्देशक फायली डिस्कवर ठेवण्याचा निर्णय घेण्यात आला, ज्या गहाळ किंवा खराब झालेल्या फायली पुनर्स्थित करतात, परंतु प्रत्यक्षात डमी आहेत. असे रीडायरेक्टर्स तयार होण्यास वेळ लागत नाही, कारण त्यांच्याकडे कोणतीही सामग्री नाही.

पुढील जीर्णोद्धार खालीलप्रमाणे होते. पार्श्वभूमी प्रक्रियेद्वारे, ऑपरेटिंग सिस्टमच्या ऑपरेशनच्या समांतर, "डमी" डेटाने भरलेले असतात. पार्श्वभूमी पुनर्प्राप्ती प्रक्रिया डिस्क लोड लक्षात घेते आणि सेट केलेल्या मर्यादेपेक्षा जास्त नाही. तथापि, वापरकर्त्यास किंवा ऑपरेटिंग सिस्टीमला अचानक एखादी फाईल आवश्यक असू शकते जी अद्याप अस्तित्वात नाही. इथेच दुसरा रिकव्हरी मोड येतो. विनंती केलेल्या फाईलची प्राथमिकता जास्तीत जास्त वाढवली जाते आणि पुनर्प्राप्ती प्रक्रिया तातडीने फाइल डिस्कवर लोड करते. थोड्या विलंबाने जरी ऑपरेटिंग सिस्टमला आवश्यक फाइल प्राप्त होते.

एक आदर्श चित्र असे दिसते. तथापि, वास्तविक जगात, मोठ्या संख्येने तोटे आणि संभाव्य डेडलॉक आहेत. इनोपोलिस मास्टरच्या विद्यार्थ्यांसह, आम्ही या पुनर्प्राप्ती परिस्थितीचा शोध घेण्याचे, आरटीओमधील नफ्याचे मूल्यांकन करण्याचे आणि असा दृष्टिकोन व्यवहार्य आहे की नाही हे समजून घेण्याचे ठरवले? शेवटी, त्यावेळी बाजारात असे कोणतेही उपाय नव्हते.

आणि जर मी इनोपोलिसमधील मुलांसाठी सेवा घटक तयार करण्याचे ठरवले, तर ऍक्रोनिसमध्ये काम सुरू झाले. फाइल सिस्टम ड्रायव्हरद्वारे मिनी-फिल्टर. हे विंडोज कर्नल टीमने केले. योजना अशी होती:

• OS स्टार्टअपच्या सुरुवातीच्या टप्प्यावर ड्रायव्हर लाँच करा,
• कामाच्या दरम्यान, जेव्हा वापरकर्ता क्षेत्र पूर्णपणे तयार होईल, सेवा डाउनलोड करा
• सेवा ड्रायव्हरच्या विनंतीवर प्रक्रिया करते आणि त्याच्या पुढील कामाचे समन्वय साधते.

ड्रायव्हर अभियांत्रिकीची सूक्ष्मता

जर माझे सहकारी दुसर्‍या पोस्टमध्ये सेवेबद्दल बोलतील, तर या मजकूरात आम्ही ड्रायव्हरच्या विकासाची गुंतागुंत प्रकट करू. आधीपासून विकसित मिनी-फिल्टर ड्रायव्हरमध्ये दोन ऑपरेटिंग मोड आहेत - जेव्हा सिस्टम सामान्य मोडमध्ये सुरू होते आणि जेव्हा सिस्टमला नुकतेच अपयश आले आणि पुनर्संचयित केले जाते. वापरकर्ता लायब्ररी आणि ऍप्लिकेशन लोड करण्यापूर्वी आणि म्हणून आमची सेवा, ड्रायव्हर समान वागतो. सध्या यंत्रणा कोणत्या अवस्थेत आहे हे त्याला माहीत नाही. परिणामी, प्रत्येक तयार करणे, वाचणे आणि लिहिणे लॉग केले जाते आणि सर्व मेटाडेटा रेकॉर्ड केला जातो. आणि जेव्हा सेवा ऑनलाइन असते तेव्हा ड्रायव्हर ही माहिती सेवेला पुरवतो.

सामान्य प्रारंभाच्या बाबतीत, सेवा ड्रायव्हरला "आराम" सिग्नल पाठवते जेणेकरून ते "विश्रांती" होते आणि सर्व डेटा काळजीपूर्वक लॉग करणे थांबवते. या प्रकरणात, ड्रायव्हर फक्त डिस्कवरील बदल लॉगिंगवर स्विच करतो आणि त्यांना सेवेला अहवाल देतो, जे इतर Acronis साधनांचा वापर करून, वापरकर्त्याद्वारे निर्दिष्ट केलेल्या मीडियावर सर्वात अद्ययावत स्थितीत डिस्क बॅकअप राखते. हे क्लाउड, रिमोट, हळूहळू किंवा रात्रीचे बॅकअप असू शकते.

पुनर्प्राप्ती मोड सक्षम असल्यास, सेवा ड्रायव्हरला सांगते की तिला "रिकव्हरी" मोडमध्ये कार्य करण्याची आवश्यकता आहे. सिस्टीम नुकतीच क्रॅशमधून सावरली आहे, आणि ती डिस्कवर फाइल उघडण्याची विनंती करताच, मिनी-फिल्टरने या ऑपरेशनमध्ये अडथळा आणला पाहिजे, ही विनंती स्वतःच केली पाहिजे, अशी फाइल डिस्कवर अस्तित्वात आहे की नाही हे तपासा. ते उघडले जाऊ शकते.

फाइल गहाळ असल्यास, मिनी-फिल्टर ही माहिती सेवेवर प्रसारित करते, ज्यामुळे फाइल पुनर्प्राप्तीची प्राथमिकता वाढते (या सर्व वेळी, पुनर्प्राप्ती पार्श्वभूमीवर चालू असते). असे दिसून आले की ही फाईल फक्त रांगेच्या सुरूवातीस उडी मारते. यानंतर, सेवा स्वतः (किंवा इतर ऍक्रोनिस म्हणजे) ही फाईल पुनर्संचयित करते आणि ड्रायव्हरला सांगते की सर्व काही ठीक आहे, आता ऑपरेटिंग सिस्टम त्यात प्रवेश करू शकते आणि ड्राइव्हर सिस्टमपासून डिस्कवर मूळ विनंती “रिलीझ” करतो.

पुनर्प्राप्ती अशक्य असल्यास, सेवा ड्राइव्हरला सूचित करते की फाइल बॅकअपमध्ये नाही. आमचा मिनी-फिल्टर ड्रायव्हर सिस्टीम विनंती पुढे पाठवतो आणि मूळ विनंतीकर्त्याला (ओएस स्वतः किंवा अनुप्रयोग) "फाइल सापडली नाही" त्रुटी प्राप्त होते. तथापि, फाइल खरोखर डिस्कवर आणि बॅकअपमध्ये नसल्यास हे अगदी सामान्य आहे.

अर्थात, ऑपरेटिंग सिस्टम खूपच हळू काम करेल, कारण कोणतीही फाईल किंवा लायब्ररी वाचणे अनेक टप्प्यांत होते, शक्यतो रिमोट संसाधनांमध्ये प्रवेशासह. परंतु पुनर्प्राप्ती होत असताना वापरकर्ता शक्य तितक्या लवकर कामावर परत येऊ शकतो.

कमी, आणखी कमी हवे...

प्रोटोटाइपने त्याची कार्यक्षमता सिद्ध केली आहे. परंतु आम्हाला पुढे जाण्याची आवश्यकता देखील आढळली कारण काही प्रकरणांमध्ये अजूनही गतिरोध आहेत. उदाहरणार्थ, ऑपरेटिंग सिस्टीम अनेक थ्रेड्समध्ये विविध लायब्ररींना विनंती करू शकते, ज्यामुळे आमची सेवा स्वतःकडे परत जाते.

मी सध्या ज्या समस्येवर काम करत आहे ती सक्रिय पुनर्संचयित करण्याची गती वाढवत आहे आणि सिस्टम सुरक्षिततेची पातळी वाढवत आहे. समजा सिस्टीमला संपूर्ण फाईलची गरज नाही, परंतु त्याचा फक्त एक भाग आहे. या उद्देशासाठी, दुसरा ड्रायव्हर विकसित केला गेला - डिस्क फिल्टर ड्रायव्हर. हे यापुढे फाइल स्तरावर कार्य करते, परंतु ब्लॉक स्तरावर. ऑपरेशनचे तत्त्व समान आहे: सामान्य ऑपरेशन मोडमध्ये, ड्रायव्हर फक्त डिस्कवर बदललेले ब्लॉक्स लॉग करतो आणि पुनर्प्राप्ती मोडमध्ये, तो स्वतः ब्लॉक वाचण्याचा प्रयत्न करतो आणि अयशस्वी झाल्यास, सेवेला प्राधान्य वाढवण्याची विनंती करतो. तथापि, सिस्टमचे इतर सर्व भाग समान राहतात. उदाहरणार्थ, ओएस-स्तरीय सेवेला दुसर्‍या ड्रायव्हरशी संप्रेषण करण्यास सांगितले जात असल्याची शंका देखील येत नाही, कारण मुख्य कार्य म्हणजे ओएसला ऑपरेशनसाठी आवश्यक असलेला डेटा प्रदान करणे. या क्षेत्रामध्ये लक्षणीय सुधारणा आवश्यक आहेत, फक्त कारण सेवेला अद्याप ब्लॉक स्तरावर कसे विचार करावे हे माहित नाही.

पुढची पायरी म्हणजे मी ड्रायव्हरला सखोल आणि आधी लॉन्च करण्याचा निर्णय घेतला, सेवेऐवजी UEFI ड्रायव्हर्स आणि नेटिव्ह विंडोज ऍप्लिकेशन्सच्या पातळीवर उतरत. या हेतूने ते विकसित केले गेले UEFI बूट ड्राइव्हर (किंवा DXE ड्राइव्हर), जो OS सुरू होण्यापूर्वीच सुरू होतो आणि मरतो. परंतु आम्ही पुढील पोस्टमध्ये UEFI ड्रायव्हर्सचा “इतिहास”, असेंब्ली आणि इन्स्टॉलेशनचे तपशील तसेच विंडोज नेटिव्ह ऍप्लिकेशन्सचे तपशील पाहू. म्हणून आमच्या ब्लॉगची सदस्यता घ्या आणि त्यादरम्यान मी कामाच्या पुढील टप्प्याबद्दल एक कथा तयार करेन. तुमच्या टिप्पण्या आणि सल्ला पाहून मला आनंद होईल.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

तुम्हाला कधी अशी परिस्थिती आली आहे की ज्यामध्ये पुनर्प्राप्तीसाठी खूप वेळ लागला:

• 65.1%होय २०७

• 23.2%क्रमांक २४४

• 11.6%याचा विचार केला नाही 5

43 वापरकर्त्यांनी मतदान केले. 3 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com