# Time Machine रिस्टोर ऑडिट ट्रेल को कैसे दो हिस्सों में बांटता है

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

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

## रिस्टोर से दो ईमानदार निरंतरताएं बन सकती हैं

रिस्टोर किया गया Mac तब फोर्क बनाता है, जब रिस्टोर में ऑडिट स्टोर की पुरानी कॉपी शामिल हो और ऐप बाद में उस रिस्टोर की गई स्थिति से नई घटनाएं लिखे। ऐसे लॉग पर विचार करें, जिसके रिकॉर्ड क्रम में अपने हैश से जुड़े हैं। रिकॉर्ड 500 पर स्टोर का हेड हैश H500 है। Time Machine इस स्थिति को कैप्चर करता है। Mac काम करता रहता है और रिकॉर्ड 501 से 580 तक लिखता है, जिनमें हर रिकॉर्ड अपने पिछले रिकॉर्ड से जुड़ा है।

बाद में कोई Mac को उस बैकअप पर रिस्टोर करता है जो रिकॉर्ड 500 पर समाप्त हुआ था। रिस्टोर किया गया ऐप H500 को अपना वर्तमान हेड मानता है और नया रिकॉर्ड 501 लिखता है। यह नया रिकॉर्ड H500 से ठीक तरह जुड़ता है। बस इसकी सामग्री, हैश और शायद टाइमस्टैम्प, रिस्टोर से पहले मूल Mac द्वारा लिखे गए रिकॉर्ड 501 से अलग होते हैं।

नतीजे में एक साझा शुरुआती भाग और दो आगे की लाइनें होती हैं:

```text
records 1 through 500
             |
             +-- lineage-original: 501 through 580
             |
             +-- lineage-restored: 501 through 544
```

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

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

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

## किसी शाखा के भीतर वैधता, पूरी टाइमलाइन नहीं होती

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

दावों को अलग रखने के लिए इन चार शब्दों को अलग समझना उपयोगी है:

- अखंडता का मतलब है कि एकत्र किए गए एक क्रम के रिकॉर्ड उम्मीद के मुताबिक जुड़े हुए हैं।
- निरंतरता का मतलब है कि आपके पास मौजूद सामग्री में क्रम के भीतर कोई अनसमझा अंतर नहीं है।
- पूर्णता का मतलब है कि संबंधित दायरे में हुई हर घटना आपके पास है।
- विशिष्टता का मतलब है कि उसी बिंदु से कोई दूसरी निरंतरता मौजूद नहीं है।

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

समय इस भ्रम को और बढ़ाता है। वॉल-क्लॉक टाइमस्टैम्प ओवरलैप कर सकते हैं। मूल Mac 14:03 पर किसी कार्रवाई का रिकॉर्ड बना सकता है, फिर रिस्टोर किया गया Mac नेटवर्क से अपनी घड़ी सेट करके 14:02 पर किसी दूसरी कार्रवाई का रिकॉर्ड बना सकता है, जबकि वह पुराने क्रम हेड से आगे बढ़ रहा हो। टाइमस्टैम्प से क्रम लगाने पर शाखाओं की घटनाएं आकर्षक, मगर झूठे क्रम में मिल सकती हैं।

क्रम संख्याओं को भी संदर्भ चाहिए। दोनों आगे की लाइनों में रिकॉर्ड 501 हो सकता है। कच्चे साक्ष्य में किसी एक रिकॉर्ड का नाम 501A न करें और यह भी तय न करें कि अधिक क्रम संख्या वाला रिकॉर्ड जीतता है। मूल फ़ील्ड को वैसा ही रखें और अपनी कार्यशील नोट्स में लीनिएज की जानकारी जोड़ें।

NIST Special Publication 800-92, Guide to Computer Security Log Management, समय के तालमेल और संरक्षित लॉग प्रबंधन को संचालन संबंधी आवश्यकताएं मानता है। यह मार्गदर्शन अब भी सही है, लेकिन सिंक्रनाइज़ घड़ियां रिस्टोर की गई स्थिति की समस्या हल नहीं करतीं। घड़ी का अनुशासन स्रोतों की तुलना में मदद करता है। वह वेरिफ़ायर को नहीं बता सकता कि बाद के दो रिकॉर्ड में से कौन पुराने रिकॉर्ड का एकमात्र उत्तराधिकारी था।

## फोर्क बिंदु को वही नाम दें जो वह है

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

हर लीनिएज को स्थायी केस पहचानकर्ता दें। नामों को स्रोत बताना चाहिए, विश्वसनीयता नहीं। उदाहरण के लिए, रिस्टोर से पहले के डिवाइस इमेज या एक्सपोर्ट से मिले क्रम के लिए lineage-original और बाद में रिकवर किए गए Mac द्वारा लिखे गए क्रम के लिए lineage-restored इस्तेमाल करें। यदि स्रोत स्पष्ट न हो, तो जब तक साक्ष्य अधिक विशिष्ट नाम का समर्थन न करे, lineage-A और lineage-B इस्तेमाल करें।

एक छोटा संरक्षण नोट भी हफ्तों की उलझन रोक सकता है:

```yaml
case: IR-2026-041
fork_record: 000500
shared_head_hash: H500-value-recorded-verbatim
lineage-original:
  source: external-export-collected-from-operator
  first-divergent-record: 000501
  collection-copy-sha256: recorded-separately
lineage-restored:
  source: restored-mac-audit-store
  first-divergent-record: 000501
  collection-copy-sha256: recorded-separately
```

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

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

## रिस्टोर की गई शाखा आगे बढ़ने से पहले मशीन सुरक्षित करें

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

पहले सामान्य उपयोग रोकें और Mac की दिखाई देने वाली स्थिति दर्ज करें। यदि वह पहले से चल रहा है, तो स्क्रीन की तस्वीर लें, दिखाया गया समय और नेटवर्क स्थिति नोट करें, और यह भी लिखें कि मशीन पर भौतिक नियंत्रण किसका था। फिर अपनी घटना प्रक्रिया के अनुरूप उसे नेटवर्क से अलग करें। केवल साफ संग्रह पसंद होने के कारण रीबूट न करें। रीबूट अस्थायी संदर्भ बदल सकता है और और अधिक लिखने को शुरू कर सकता है।

फिर अलग-अलग स्रोतों को अलग सुरक्षित करें। इसमें रिस्टोर किया गया वॉल्यूम, संबंधित Time Machine बैकअप सेट, रिस्टोर से पहले का कोई एक्सपोर्ट और ऑडिट की गई कार्रवाई पाने वाली सेवाओं के पास मौजूद कॉपियां शामिल हैं। एकत्र की गई हर फ़ाइल या इमेज का क्रिप्टोग्राफ़िक हैश निकालें और जहां टूलिंग अनुमति दे, मूल को केवल पढ़ने योग्य रखें। काम कॉपियों पर करें।

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

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

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

## घटनाओं को क्रम देने से पहले साक्ष्य मानचित्र बनाएं

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

मानचित्र अक्सर दिखा देता है कि माना गया फोर्क केवल अधूरा एक्सपोर्ट है। उदाहरण के लिए, कोई ऑपरेटर एक मशीन से रिकॉर्ड 1 से 580 तक एक्सपोर्ट करे, जबकि रिस्टोर Mac में रिकॉर्ड 1 से 544 तक हों। यदि दोनों क्रम 500 तक एक जैसे रिकॉर्ड साझा करते हैं और 501 पर अलग होते हैं, तो यह वास्तविक फोर्क का समर्थन करता है। यदि एक्सपोर्ट केवल रिकॉर्ड 545 से 580 छोड़ देता है और बाकी रिस्टोर क्रम से मेल खाता है, तो आपके पास छोटी कॉपी वाला एक लीनिएज है।

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

शुरू से ही लीनिएज कॉलम वाली कार्यशील तालिका बनाएं। वह इतनी सरल हो सकती है:

| इवेंट संदर्भ | लीनिएज | रिकॉर्ड किया समय | सहायक स्रोत | भरोसे का नोट |
| --- | --- | --- | --- | --- |
| 000500 | साझा | 13:42 | दोनों नेटिव स्टोर | सामान्य फोर्क बिंदु |
| 000501-O | मूल | 13:45 | रिस्टोर-पूर्व एक्सपोर्ट | पहला मूल उत्तराधिकारी |
| 000501-R | रिस्टोर किया गया | 13:38 | रिस्टोर वॉल्यूम | पहला रिस्टोर उत्तराधिकारी |

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

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

## हर लीनिएज सत्यापित करें, उन्हें जुड़ा हुआ मानकर नहीं

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

Sallyport के वेरिफ़ायर का समर्थन करने वाले ऑडिट डेटा के लिए संबंधित कमांड है:

```text
sp audit verify
```

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

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

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

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

## शाखाएं ओवरलैप करें तो टाइमस्टैम्प को गवाह चाहिए

लीनिएज अलग करने के बाद टाइमस्टैम्प का सही उपयोग फिर संभव होता है। वे घटनाओं को बाहरी स्रोतों के संबंध में रखने में मदद करते हैं। वे यह तय नहीं करते कि कौन सी स्थानीय निरंतरता आधिकारिक है।

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

मान लीजिए मूल निरंतरता 15:10 पर HTTP कॉल रिकॉर्ड करती है। रिस्टोर की गई निरंतरता 14:58 पर अलग कॉल रिकॉर्ड करती है, हालांकि रिस्टोर वास्तविक समय में बाद में हुआ था। यह अंतर रिस्टोर की घड़ी, पुराने घड़ी मान वाले स्नैपशॉट या स्टार्टअप के बाद समय सुधरने को दिखा सकता है। सही रिपोर्ट 14:58 या 15:10 को सार्वभौमिक क्रम नहीं चुनती। वह बताती है कि किस डिवाइस ने कौन सा समय रिकॉर्ड किया और कौन सा स्वतंत्र रिकॉर्ड उनके बीच रिस्टोर को रखता है।

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

जब आपको घटना का एक ही विवरण चाहिए, तो आंशिक क्रम अपनाएं। वे घटनाएं बताएं जिनका क्रम साक्ष्य स्पष्ट करता है, जैसे अपने संग्रह से पहले बना मूल एक्सपोर्ट। जहां क्रम अज्ञात रहे, वहां अंतराल बताएं। जांचकर्ताओं को यह जवाब कभी-कभी पसंद नहीं आता, क्योंकि नेतृत्व एक टाइमलाइन चाहता है। झूठा पूर्ण क्रम स्पष्ट अनिश्चितता से बदतर है, खासकर जब अनुशासनात्मक या कानूनी निर्णय उसी पर निर्भर हों।

## रिस्टोर किया इतिहास छिपाने का प्रमाण नहीं है

टीमें अक्सर रिकवरी के बाद के अंतर को इस प्रमाण की तरह लेती हैं कि किसी ने गतिविधि मिटाने का इरादा रखा था। यह निष्कर्ष लोकप्रिय है, क्योंकि यह सरल कहानी में फिट बैठता है: बैकअप मतलब रोलबैक, रोलबैक मतलब सबूत मिटाना। तकनीकी साक्ष्य अकेले इतने बड़े इरादे का समर्थन शायद ही करते हैं।

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

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

व्यावहारिक समीक्षा क्रम तर्क को अनुशासित रखता है:

1. साझा शुरुआती भाग और पहला अलग रिकॉर्ड स्थापित करें।
2. नेटिव सामग्री सुरक्षित रखें और संग्रह डाइजेस्ट निकालें।
3. हर लीनिएज को अलग सत्यापित करें।
4. बैकअप और बाहरी रिकॉर्ड से रिस्टोर सीमा की पुष्टि करें।
5. तकनीकी निष्कर्षों को इरादे के निष्कर्षों से अलग रखें।

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

## रिकवरी ऐसी बनाएं कि फोर्क का दिखने वाला सबूत रहे

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

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

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

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

## मुश्किल हिस्सों को छिपाए बिना दो इतिहास रिपोर्ट करें

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

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

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