क्या एन्क्रिप्टेड ऑडिट बैकअप सत्यापन रिकवरी साबित कर सकता है?

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

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

सफल रिस्टोर और वैध ऑडिट चेन अलग सवालों के जवाब देते हैं

बहाल की गई डायरेक्टरी स्टोरेज से जुड़ा सवाल पूछती है: क्या यह मशीन सेव किए गए बाइट पढ़ सकती है? सत्यापित हैश चेन सबूत से जुड़ा सवाल पूछती है: क्या ये बाइट अब भी ऑडिट रिकॉर्ड का एक सतत, बिना छेड़छाड़ वाला क्रम बताते हैं? आपको दोनों जवाब चाहिए और कोई भी दूसरे का विकल्प नहीं है।

टीमें अक्सर तीन जांचों को «रिस्टोर» शब्द में मिला देती हैं। ड्रिल रिकॉर्ड में इन्हें अलग रखें।

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

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

जब कोई पूछे, «क्या हम इस पर भरोसा कर सकते हैं?», तो यह अंतर अहम हो जाता है। ईमानदार जवाब में दावे का नाम होना चाहिए: «हमने पुष्टि की कि यह कॉपी बिना बदलाव के ट्रांसफर हुई, एन्क्रिप्टेड रिकॉर्ड एक सतत चेन के रूप में सत्यापित हुए और यह इस टाइमस्टैंप तक पहुंचती है।» यह सिर्फ इतना कहने से कहीं मजबूत है कि बैकअप सफलतापूर्वक रिस्टोर हो गया।

NIST SP 800-34, Federal Information Systems के लिए Contingency Planning Guide, रिकवरी टेस्टिंग और एक्सरसाइज को काम करने योग्य आकस्मिक क्षमता बनाए रखने का हिस्सा मानता है, बैकअप कॉन्फ़िगर होते ही पूरे हो जाने वाला कागजी काम नहीं। छोटी इंजीनियरिंग टीम के लिए सीख सीधी है: बैकअप रन साबित करता है कि जॉब चला, एक्सरसाइज साबित करती है कि लोग और टूल तय नतीजा बहाल कर सकते हैं। एन्क्रिप्टेड ऑडिट ट्रेल आपको ऐसा नतीजा देता है जिसे पहले सीक्रेट स्टोर खोले बिना जांचा जा सकता है।

क्लीन मशीन में आपकी सामान्य सुविधाएं नहीं होनी चाहिए

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

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

वॉल्ट रिकवरी को इस ड्रिल से बाहर रखें। ऑडिट सत्यापन चलाने के लिए एन्क्रिप्टेड वॉल्ट इंपोर्ट न करें, उसे अनलॉक न करें और कोई कार्रवाई मंजूर न करें। वेरिफायर को सिफरटेक्स्ट और क्रिप्टोग्राफिक चेन देखनी चाहिए, बाहरी कार्रवाइयों को दोहराना नहीं। यदि कोई कहे कि ऑडिट कॉपी सुरक्षित है या नहीं देखने के लिए सीक्रेट चाहिए, तो रुकें और पहचानें कि किस कंपोनेंट को ऑडिट वेरिफायर समझ लिया गया है।

मशीन को सीमित उद्देश्य के लिए तैयार करें:

1. कमांड-लाइन वेरिफायर की दर्ज रिलीज, या बैकअप बनाने में इस्तेमाल की गई उसी रिलीज फैमिली को इंस्टॉल करें।
2. लोकल स्टोरेज पर एक खाली ड्रिल डायरेक्टरी बनाएं जिसमें सिफरटेक्स्ट कॉपी और छोटे सबूत रिकॉर्ड के लिए पर्याप्त जगह हो।
3. दर्ज रिकवरी पाथ से बैकअप और उसकी इन्वेंट्री या चेकसम मैनिफेस्ट ट्रांसफर करें।
4. जहां ऑपरेटिंग सिस्टम और मीडिया अनुमति दें, सत्यापन के दौरान स्रोत मीडिया और बहाल कॉपी को रीड-ओनली रखें।

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

चेन से पूछने से पहले कॉपी जांचें

चेन सत्यापन से पहले फ़ाइल-स्तर की जांच चलाएं। इससे खराब ट्रांसफर और संरचनात्मक रूप से खराब ऑडिट इतिहास अलग होते हैं, और जब खराब केबल, अधूरा डाउनलोड या गलत डायरेक्टरी ही पूरी समस्या हो तो समय बचता है।

Mac या किसी दूसरे सिस्टम पर जिसमें shasum हो, बैकअप के समय बनाई गई इन्वेंट्री ऐसी दिख सकती है:

shasum -a 256 audit-export/* | sort > audit-export.sha256

रिकवरी साइट पर सिफरटेक्स्ट एक्सपोर्ट और audit-export.sha256, दोनों को ड्रिल डायरेक्टरी में कॉपी करें, फिर चलाएं:

shasum -a 256 -c audit-export.sha256

सूची में हर फ़ाइल के लिए OK आना चाहिए। गायब फ़ाइल, मेल न खाता फ़ाइलनाम या चेकसम मिसमैच ट्रांसपोर्ट अथवा इन्वेंट्री की विफलता है। ऑडिट वेरिफायर चलाने से पहले इसे इसी रूप में दर्ज करें। बहाल फ़ाइलों से मैनिफेस्ट दोबारा न बनाएं, क्योंकि इससे बदले हुए बाइट को सिर्फ नई रसीद मिलती है।

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

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

वॉल्ट अनलॉक किए बिना सिफरटेक्स्ट सत्यापित करें

फ़ाइल-स्तर की जांच पास होने के बाद कॉपी किए गए ऑडिट डेटा पर ऑडिट चेन वेरिफायर चलाएं। अहम बात यह है कि सत्यापन सिफरटेक्स्ट पर काम करे और उसे वॉल्ट सीक्रेट की जरूरत न हो। Sallyport कमांड-लाइन टूल में सत्यापन कमांड है:

sp audit verify

इसे कॉपी किए गए ऑडिट डेटा के दर्ज रिकवरी कॉन्टेक्स्ट से चलाएं, प्रोडक्शन खाते से नहीं। कमांड एन्क्रिप्टेड, हैश-चेन ऑडिट लॉग को ऑफलाइन जांचता है। इससे अप्रूवल कार्ड ट्रिगर नहीं होना चाहिए, Touch ID नहीं मांगना चाहिए, API कॉल नहीं करनी चाहिए, SSH कनेक्शन नहीं खोलना चाहिए और वॉल्ट अनलॉक करने की जरूरत नहीं होनी चाहिए। इनमें से कोई भी घटना बताती है कि ड्रिल किसी दूसरी सिस्टम सीमा में चली गई है।

नतीजे को «पास» लिखे स्क्रीनशॉट तक सीमित न करें। कमांड, वेरिफायर वर्जन, ऑडिट एक्सपोर्ट आइडेंटिफ़ायर या बैकअप टाइमस्टैंप, कॉपी के लिए इस्तेमाल हुआ लोकल पाथ, ड्रिल की तारीख और ऑपरेटर का नाम कैप्चर करें। इससे कोई दूसरा रिस्पॉन्डर हफ्तों बाद गलत डायरेक्टरी पर चलाए गए कमांड और साफ सत्यापन में अंतर कर सकता है।

उपयोगी पास मानदंड के तीन भाग हैं: चेकसम मैनिफेस्ट पास हो, चेन वेरिफायर सफलता बताए और बहाल सामग्री उस बैकअप रन के अपेक्षित सबसे नए रिकॉर्ड बाउंड्री तक पहुंचे। तीसरे भाग को अपनी इन्वेंट्री के वास्तविक टाइमस्टैंप या सीक्वेंस बाउंड्री के साथ लिखें। «काफी नया» एक राय है, «18:00 UTC के तय बैकअप तक कवर करता है» जांचा जा सकने वाला कथन है।

Sallyport एन्क्रिप्टेड स्रोत लॉग को राइट-ब्लाइंड रखता है और उससे Sessions जर्नल और Activity जर्नल, दोनों बनाता है। इस डिजाइन में ऑफलाइन चेन सत्यापन सबूत की जांच है। मानव-पठनीय जर्नल कामकाज के लिए उपयोगी दृश्य हैं, लेकिन रिकवरी के दौरान वॉल्ट अनलॉक करने का कारण नहीं।

टूटी चेन को ठीक करने से पहले सुरक्षित रखें

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

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

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

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

सबूत डायरेक्टरी में विफल बैकअप को «ठीक» न करें। सेवा बहाल करने के लिए आपको पुरानी रखी हुई कॉपी या दूसरी मंज़िल से डेटा लाना पड़ सकता है, लेकिन उसे अलग स्रोत के रूप में लेबल करें। जांच में लोगों को पता होना चाहिए कि कौन सा आर्टिफैक्ट विफल हुआ और कौन सा बाद में सत्यापित हुआ।

ड्रिल शुरू होने से पहले रिकवरी का दायरा लिखें

रिकवरी मशीन को छूने से पहले तय करें कि ऑडिट बैकअप से क्या रिकवर होना चाहिए। जवाब में आम तौर पर समय सीमा, संबंधित एजेंट सेशन और बाहरी कॉल से बने रिकॉर्ड तथा उन्हें बनाने वाली रिलीज पहचानने के लिए पर्याप्त प्रोवेनेंस शामिल होते हैं। इसमें सहायक बैकअप इन्वेंट्री और अलग चेकसम मैनिफेस्ट भी हो सकते हैं।

इसमें अपने आप ऐप से जुड़ी हर फ़ाइल शामिल नहीं हो जाती। वॉल्ट में क्रेडेंशियल होते हैं और ऑडिट ट्रेल में एजेंट रन और अलग-अलग कार्रवाइयों के बारे में गेटवे का रिकॉर्ड होता है। ये अलग रिकवरी लक्ष्य हैं और इनके एक्सेस नियम अलग हैं। ऑडिट ड्रिल में वॉल्ट लाने से चेन नतीजा बेहतर हुए बिना सीक्रेट का एक्सपोज़र बढ़ता है।

ऐसा छोटा स्कोप स्टेटमेंट लिखें जिसे ऑपरेटर जांच सके। उदाहरण:

रिकवरी लक्ष्य: [organization timestamp] दिनांक के तय बैकअप का एन्क्रिप्टेड ऑडिट डेटा
अपेक्षित बाउंड्री: सबसे नया रिकॉर्ड किया गया ऑडिट एंट्री [organization timestamp] पर या उसके बाद का हो
जरूरी जांचें: ट्रांसफर मैनिफेस्ट पास हो; ऑफलाइन चेन सत्यापन पास हो
इस ड्रिल से बाहर: वॉल्ट इंपोर्ट, वॉल्ट अनलॉक, लाइव API कॉल, SSH कार्रवाई
रखा जाने वाला सबूत: स्रोत आइडेंटिफ़ायर, वेरिफायर वर्जन, कमांड आउटपुट, ऑपरेटर रिकॉर्ड

ब्रैकेट वाले फ़ील्ड जानबूझकर रखे गए हैं। ड्रिल से पहले उन्हें बैकअप इन्वेंट्री से भरें। जो डेटा पहुंचा है उसे देखने के बाद बाउंड्री चुनकर एक्सरसाइज को पास न कराएं।

यहीं रिटेंशन नीति और वास्तविकता मिलती हैं। यदि टीम कहती है कि वह किसी खास इंसिडेंट विंडो को फिर से बना सकती है, तो उसके स्कोप स्टेटमेंट में सामान्य डिलीशन, विफल जॉब और स्टोरेज रोटेशन के बाद भी वह विंडो कवर होनी चाहिए। पिछले हफ्ते की सत्यापित कॉपी, कल की घटना की जांच की जरूरत पूरी नहीं करती।

सत्यापन में अप्रूवल मॉडल मौजूद नहीं होना चाहिए

कार्रवाई अप्रूवल और ऑडिट सत्यापन के काम उलटे हैं। अप्रूवल तय करता है कि लाइव एजेंट प्रक्रिया क्रेडेंशियल का उपयोग करके बाहरी असर डाल सकती है या नहीं। सत्यापन पूछता है कि संग्रहीत ऑडिट सिफरटेक्स्ट अब भी अखंड इतिहास रखता है या नहीं। रिकवरी ड्रिल में दूसरा काम करने के लिए पहला चलाने की जरूरत नहीं होनी चाहिए।

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

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

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

ड्रिल रिकॉर्ड अगले ऑपरेटर को आसानी से असरदार बनाए

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

इन तथ्यों को साफ भाषा में कैप्चर करें:

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

टीम को कोई उपाय मिल जाने भर से ड्रिल को सफल न मानें। वास्तविक घटना में सबूत बहाल करने के लिए उपाय जरूरी हो सकता है, लेकिन वह दर्ज प्रक्रिया में कमी बताता है। जब तक सामान्य प्रक्रिया नई मशीन पर काम न करे, मूल टेस्ट को विफल ही दर्ज करें।

बैकअप स्क्रिप्ट, ऑडिट स्टोरेज, रिटेंशन या रिकॉर्ड बनाने वाली ऐप रिलीज में अहम बदलाव के बाद यह एक्सरसाइज चलाएं। इसे ऐसे शेड्यूल पर चलाएं जो घटना के बाद भरोसेमंद सबूत पाने की आपकी जरूरत से मेल खाता हो। सही अंतराल आपकी जिम्मेदारियों और बैकअप कैडेंस पर निर्भर करता है, इसलिए किसी दूसरी टीम का अंक उधार लेने के बजाय इसे लिखें।

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