फ़ाइल चेकसम के साथ ऑफ़लाइन डायरी बैकअप की जाँच कैसे करें
यह जाँचने के लिए कि डिजिटल डायरी की एक ऑफ़लाइन प्रति अपने मूल स्रोत से बाइट-दर-बाइट मेल खाती है, अभीष्ट स्रोत से एक SHA-256 चेकसम मेनिफ़ेस्ट और फ़ाइल इन्वेंट्री तैयार करें, फिर उस सुरक्षित बेसलाइन के विरुद्ध बैकअप को सत्यापित करें। एक मेल खाता चेकसम सूचीबद्ध फ़ाइलों के बाइट्स के बारे में पुष्टि करता है; यह यह नहीं दर्शाता कि सूची पूरी है, मूल फ़ाइलें सही या पढ़ने योग्य थीं, या कोई अविश्वसनीय बेसलाइन प्रामाणिक है।
चेकसम जाँच आपको क्या बताती है
चेकसम किसी फ़ाइल की सामग्री से गणना किया गया एक मान होता है। यदि सामग्री में कोई बदलाव होता है, तो गणना किए गए मान में भी अंतर आने की अपेक्षा होती है। इसलिए किसी बैकअप की संदर्भ मान से तुलना करने से कॉपी करने या संग्रहण के दौरान होने वाले परिवर्तनों की पहचान करने में मदद मिल सकती है। डिजिटल प्रिजर्वेशन गठबंधन (Digital Preservation Coalition) चेकसम को सफल स्थानांतरण और निरंतर फ़ाइल स्थिरता (फिक्सिटी) की जाँच करने के एक तरीके के रूप में वर्णित करता है, और एक ऐसे संदर्भ के साथ तुलना पर ज़ोर देता है जिसका सही होना ज्ञात हो ([Fixity and checksums](https://www.dpconline.org/handbook/technical-solutions-and-tools/fixity-and-checksums))।
संदर्भ मायने रखता है: यदि आप बेसलाइन और तुलना दोनों की गणना उसी क्षतिग्रस्त प्रति से करते हैं, तो मिलान यह स्थापित नहीं करता कि पहले की फ़ाइल में क्या था। कोई मिलान यह भी साबित नहीं करता कि डायरी की प्रविष्टि ठीक से खुलती है, स्रोत पूर्ण था, या फ़ाइलें किसने बनाई थीं। इसे जानबूझकर चुनी गई फ़ाइलों के एक सेट के लिए केवल बाइट तुलना मानें।
स्रोत सेट चुनें और रिकॉर्ड करें
एक स्थिर निर्यातित डायरी फ़ोल्डर की पहचान करें जिसका बैकअप लिया जाना चाहिए, और उसका हैश निकालने से पहले सभी संपादन पूरे कर लें। यह उदाहरण सामान्य फ़ाइलों को शामिल करता है, जिसमें छिपी हुई फ़ाइलें भी शामिल हैं; यह सिम्बोलिक लिंक का अनुसरण नहीं करता है या किसी सक्रिय एप्लिकेशन डेटाबेस को लगातार कैप्चर नहीं करता है। आवश्यकता पड़ने पर लिंक की गई सामग्री को चयनित फ़ोल्डर में निर्यात करें और एप्लिकेशन के निर्यात निर्देशों की जाँच करें। जनरेट की गई इन्वेंट्री और मेनिफ़ेस्ट को उस फ़ोल्डर से बाहर स्टोर करें।
इन उदाहरणों के लिए Bash और GNU findutils/coreutils की आवश्यकता होती है, जैसा कि Ubuntu Linux पर होता है; ये असंशोधित macOS या Windows टर्मिनल के लिए कमांड नहीं हैं। उदाहरण में काल्पनिक स्थानीय पथों और नए आउटपुट फ़ाइल नामों का उपयोग किया गया है। रिकॉर्ड के लिए किसी मौजूदा पैरेंट डायरेक्टरी का उपयोग करें; ऐसे फ़ाइल नाम चुनें जो अप्रयुक्त हों ताकि पहले की बेसलाइन ओवरराइट न हों। उन्हें अपने कंप्यूटर के पथों से बदलें; निजी डायरी और जनरेट किए गए रिकॉर्ड को स्थानीय ही रखें। उबंटू मैनुअल पूर्व आउटपुट को सत्यापित करने के लिए `sha256sum` जनरेशन और इसके `--check` विकल्प का दस्तावेज़ीकरण करता है ([sha256sum manual](https://manpages.ubuntu.com/manpages/noble/man1/sha256sum.1.html))।
```bash ( set -euo pipefail set -C cd "/home/example/Diary" find . -type f -print0 | LC_ALL=C sort -z > "/home/example/diary-inventory.nul" xargs -0 -r sha256sum < "/home/example/diary-inventory.nul" > "/home/example/diary-source.sha256" test -s "/home/example/diary-source.sha256" ) ```
सबशेल डायरेक्टरी बदलने में विफलता या पाइपलाइन की खराबी पर रुक जाता है, मौजूदा रिकॉर्ड फ़ाइलों को ओवरराइट करने से मना कर देता है, और खाली चेकसम मेनिफ़ेस्ट को अस्वीकार कर देता है। यदि यह कोई त्रुटि रिपोर्ट करता है, तो आंशिक आउटपुट को बेसलाइन के रूप में उपयोग न करें। इन्वेंट्री NUL सेपरेटर का उपयोग करती है ताकि लाइन ब्रेक वाले फ़ाइल नाम अलग-अलग बने रहें। दोनों रिकॉर्ड चयनित फ़ोल्डर के बाहर रहते हैं। स्रोत सेट पर भरोसा करने से पहले डायरी निर्यात के साथ उसकी समीक्षा करें; मेनिफ़ेस्ट उस अटैचमेंट को उजागर नहीं कर सकता जिसे उसके निर्माण से पहले ही छोड़ दिया गया था।
बेसलाइन को सुरक्षित रखें और फ़ाइलों को कॉपी करें
मेनिफ़ेस्ट और इन्वेंट्री को कार्यरत स्रोत और ऑफ़लाइन बैकअप दोनों से अलग किसी स्थान पर संग्रहीत करें। उन्हें आकस्मिक संपादन से बचाएं, और यदि व्यावहारिक हो तो एक दूसरी सुरक्षित प्रति भी रखें। चेकसम तुलना का एक संदर्भ जाँच के रूप में केवल तभी मूल्य होता है जब आपके पास बेसलाइन पर भरोसा करने और उसे संरक्षित करने का कारण हो। संरक्षण मार्गदर्शन भी फिक्सिटी जानकारी को ऑडिटिंग के लिए रिकॉर्ड और उपयोग की जाने वाली चीज़ मानता है; NARA अपने डिजिटल संरक्षण कार्यक्रम में फिक्सिटी रिकॉर्ड करने, फ़ाइल कार्रवाइयों पर नज़र रखने और मेनिफ़ेस्ट व लॉग बनाने का विवरण देता है ([National Archives digital preservation](https://www.archives.gov/preservation/digital-preservation/about))।
अपनी सामान्य फ़ाइल-कॉपी विधि का उपयोग करके चयनित डायरी फ़ोल्डर को बैकअप ड्राइव में कॉपी करें। जब बैकअप की जाँच न की जा रही हो, तो उसे डिस्कनेक्ट रखें। यहाँ दिए गए कमांड कॉपी की प्रक्रिया नहीं करते हैं; वे पहले से कॉपी की गई फ़ाइलों की जाँच करते हैं। जाँच करने से पहले बैकअप को संपादित करने, उसका नाम बदलने या पुनर्गठित करने से बचें, क्योंकि पथ में परिवर्तन मेनिफ़ेस्ट को अपेक्षित फ़ाइलों को ढूँढने से रोक सकता है।
कॉपी किए गए बाइट्स को सत्यापित करें
ऑफ़लाइन ड्राइव को माउंट करें और कॉपी किए गए डायरी फ़ोल्डर में जाएँ। स्रोत पर रिकॉर्ड किए गए समान SHA-256 एल्गोरिदम और सापेक्ष पथों का उपयोग करके बेसलाइन मेनिफ़ेस्ट के विरुद्ध जाँच चलाएँ:
```bash ( set -euo pipefail cd "/media/example/DiaryBackup/Diary" sha256sum --check --strict "/home/example/diary-source.sha256" ) ```
मेनिफ़ेस्ट `./` से शुरू होने वाले सापेक्ष पथों को संग्रहीत करता है, इसलिए सत्यापन कॉपी किए गए डायरी फ़ोल्डर से चलता है। `OK` उस फ़ाइल के लिए मिलान की रिपोर्ट करता है। अनुपलब्ध या मेल न खाने वाली फ़ाइलें, विकृत चेकसम लाइनें और कमांड त्रुटियाँ जाँच की मांग करती हैं; उन्हें `--ignore-missing` के साथ न छिपाएँ या यह न मान लें कि कुछ दृश्यमान `OK` लाइनों का अर्थ है कि पूरी जाँच सफल रही। [Ubuntu manual](https://manpages.ubuntu.com/manpages/noble/man1/sha256sum.1.html) इन विकल्पों का दस्तावेज़ीकरण करता है।
यह जाँच बैकअप पर मौजूद उन अतिरिक्त फ़ाइलों की रिपोर्ट नहीं करती है जो मेनिफ़ेस्ट में नहीं थीं। यदि आपको अतिरिक्त या अप्रत्याशित डायरेक्टरी सामग्री का पता लगाने की आवश्यकता है, तो एक अलग चरण के रूप में बैकअप की फ़ाइल इन्वेंट्री की तुलना सहेजी गई स्रोत इन्वेंट्री से करें। इन्वेंट्री समानता अभी भी यह साबित नहीं कर सकती कि आपके मूल चयन में हर वह डायरी आइटम शामिल था जिसे आप सहेजना चाहते थे।
साक्ष्य को बदले बिना विसंगतियों की जाँच करें
यदि कोई फ़ाइल मेल नहीं खाती है, तो उसका पथ रिकॉर्ड करें और दोनों प्रतियों को अपरिवर्तित रखें। अभीष्ट मेनिफ़ेस्ट और वर्किंग फ़ोल्डर की पुष्टि करें, फिर स्रोत और बैकअप की अलग-अलग तुलना करें। जाँचें कि क्या संपादन, नाम बदलना या अधूरा कॉपी होना इस विसंगति की व्याख्या करता है। जाँच करते समय बेमेल प्रति को संरक्षित रखें; इसे स्वचालित रूप से अधिलेखित करने से साक्ष्य मिट जाएँगे।
डिजिटल संरक्षण मार्गदर्शन उस प्रति को बदलने के लिए एक ज्ञात-सही प्रति का उपयोग करने का वर्णन करता है जिसकी फिक्सिटी खो गई है, जो एक अन्य भरोसेमंद प्रति उपलब्ध होने पर निर्भर करता है ([Digital Preservation Coalition](https://www.dpconline.org/handbook/technical-solutions-and-tools/fixity-and-checksums))। एक व्यक्तिगत डायरी के लिए, यह एक ऐसा निर्णय है जो उपलब्ध साक्ष्यों की तुलना करने के बाद ही लिया जाना चाहिए। चेकसम अंतरों का पता लगाते हैं; वे फ़ाइलों की मरम्मत नहीं करते हैं या सही संस्करण का चयन नहीं करते हैं।
सीमाएं और एक व्यावहारिक रिकॉर्ड
स्रोत फ़ोल्डर, बेसलाइन तिथि, एल्गोरिदम, मेनिफ़ेस्ट स्थान और प्रत्येक जाँच परिणाम का एक संक्षिप्त स्थानीय रिकॉर्ड रखें। बाद की जाँचों के लिए, जाँचे जा रहे बैकअप से फिर से बेसलाइन बनाने के बजाय स्थापित बेसलाइन को ही बनाए रखें। किसी जानबूझकर किए गए संपादन या रूपांतरण के बाद, नए संस्करण का अलग से दस्तावेज़ीकरण करें। कभी-कभार फ़ाइलें खोलने और पुनर्स्थापना (रिस्टोर) की जाँच जारी रखें: केवल बाइट फिक्सिटी यह नहीं बता सकती कि आपकी डायरी उपयोग करने योग्य बनी हुई है या नहीं।
