क्या 'dd' का उपयोग छोटे HDD पर क्लोन करने के लिए किया जा सकता है, यह जानते हुए कि विभाजन को संपादन की आवश्यकता होगी?

14

मैंने ddडिस्क डिस्क को इस तरह से उपयोग किया है:

 dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync

और यह हमेशा ठीक काम किया है। 'Dd' पर कोई भी और सभी डॉक्स आपको यह याद दिलाने के लिए पेन लेते हैं कि लक्ष्य डिस्क का आकार एक जैसा होना चाहिए या स्रोत से बड़ा होना चाहिए। क्या यह बिल्कुल सच है?

अब, मैं काफी समझता हूं कि अगर मैं एक छोटी सी डिस्क पर क्लोन करता हूं तो मैं ऐसे किसी भी विभाजन की उम्मीद नहीं कर सकता जो आंशिक रूप से 'सीमा से बाहर' हो।

हालाँकि, यह अच्छी तरह से जानते हुए कि मुझे अपने विभाजन को बाद में लक्ष्य पर संपादित करने की आवश्यकता है, 'सीमा से बाहर' हटाना, क्या मैं अभी भी 'dd' का उपयोग स्रोत की एक सीमा बल की प्रतिलिपि बनाने के लिए कर सकता हूँ? लक्ष्य का भौतिक आकार? या 'dd' मलबे के एक धूम्रपान ढेर पर लक्ष्य को कम कर देगा, जब यह अपनी स्थिति ;-) तक सीमित हो जाएगा;

BTW, इस पर शोध करते हुए, मैंने bs=हर चीज के लिए अनुशंसित मूल्यों को देखा bs=1024है bs=32M, जो वास्तव में सबसे अच्छा है?

partition hard-disk dd cloning

— रे एंड्रयूज
स्रोत

ध्यान दें, यदि dd इष्टतम ब्लॉक आकार की गणना करना उपयोगी है

— Wilf

7

भौतिक ड्राइव को धूम्रपान शुरू नहीं करना चाहिए, कम से कम, लेकिन संभावना बहुत अच्छी है कि आपका फाइल सिस्टम अब काम नहीं करेगा (मेरा मतलब है, लक्ष्य फाइल सिस्टम; यदि आप सिर्फ नकल करते हैं और स्रोत में कुछ भी नहीं छूते हैं, तो स्रोत खुद ठीक होना चाहिए। )। विभाजन के अंदर डेटा आवश्यक रूप से बढ़ते क्रम में आवंटित नहीं किया गया है। इसमें से कुछ विभाजन के अंत में हो सकता है भले ही विभाजन पूर्ण न हो (वास्तव में, मुझे लगता है कि यह कुछ फाइलसिस्टम के साथ नियत रूप से होता है, लेकिन मैं विवरण में प्राप्त करने के लिए पर्याप्त नहीं जानता हूं)। वहां मौजूद डेटा फाइलसिस्टम की अखंडता के लिए आवश्यक हो सकता है। इसलिए मैं आपको दृढ़ता से सलाह देता हूं कि ऐसी प्रति पर भरोसा न करें।

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

के लिए bsमूल्य, आमतौर पर सबसे अच्छा विचार वास्तविक प्रतिलिपि शुरू करने से पहले परीक्षण के एक जोड़े है। कुछ उपकरण हैं जो आपको इस चेक को स्वचालित करने में मदद करते हैं, लेकिन मुझे नाम याद नहीं है। मेरे अनुभव में, सबसे अच्छी सीमा आमतौर पर 4M और 16M के बीच होती है। इससे ज्यादा आप अब ज्यादा नहीं कमाते हैं। लेकिन यह कई चीजों पर निर्भर करता है, जिसमें डिस्क भी शामिल हैं। उदाहरण के लिए, मैंने शायद ही कभी वास्तविक हाई-एंड डिस्क के साथ काम किया हो, जो बड़ी गति और कैश आकार के कारण उच्च मूल्यों के लिए उपयुक्त हो सकता है।

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

— जियोवानी मस्केलानी
स्रोत

कृपया संपादित प्रश्न देखें :)

— रे एंड्रयूज

1

@rayandrews सुनिश्चित नहीं हैं कि आप किस अपडेट की उम्मीद कर रहे हैं, लेकिन मूल रूप ddसे बाइट्स कॉपी करता है। यह बाइट 0 पर शुरू होगा, और तब तक कॉपी करता रहेगा जब तक कि कुछ (आपके मामले में, गंतव्य पर मीडिया का अंत) इसे रोक नहीं देता। यह आपको एक विभाजन तालिका के साथ छोड़ देगा जो ड्राइव के बाहर वास्तविकता और विभाजन से बड़ी ड्राइव को निर्दिष्ट करता है ... लेकिन यदि आप इसे ठीक करते हैं, तो यह ठीक होना चाहिए। हालांकि डेटा की प्रतिलिपि बनाने के लिए dd प्रति-विभाजन का उपयोग करना आसान होगा। [डुप्लिकेट UUIDs की तरह यह आपको सभी सामान्य dd समस्याओं के साथ छोड़ देगा]

— derobert

मुझे जो पसंद है वह यह है कि यह विभाजन और फ़ाइल सिस्टम को बनाता है और लेबल करता है - जैसे कि समय की बचत। UUIDs tho के बारे में सही।

— रे एंड्रयूज

1

आप दूसरे जीपीटी तालिका को कैसे पुनर्स्थापित करते हैं?

— user230910

2

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

यह विचार है कि प्रत्येक विभाजन को व्यक्तिगत रूप से dd'ing में सोचा जाए और शुरू में एक बार में पूरी डिस्क नहीं। और भी पूरा किया जा सकता है: जिस विभाजन (टुकड़े) को काट दिया जाएगा, उन्हें भी फाइल सिस्टम रि-साइजिंग टूल की थोड़ी मदद से सुरक्षित रूप से माइग्रेट किया जा सकता है। दरअसल, फाइलसिस्टम मैटाटाटा और एक्सटेंडेड फाइल एट्रिब्यूट्स को संरक्षित करने के लिए इस तरह का माइग्रेशन दिलचस्प होता है जिसे आसानी से cp, rsync, pax जैसे टूल्स से कॉपी नहीं किया जा सकता ... जो फाइल सिस्टम लेयर में काम करते हैं और डिवाइस लेयर को ब्लॉक नहीं करते हैं। Dd का उपयोग OS को फिर से स्थापित करने या SELinux के साथ समस्याओं से बचने के लिए FS को पुनः स्थापित करने की आवश्यकता को समाप्त करता है।

नीचे मैं समान कार्य पूरा करने के लिए आमतौर पर करता हूं:

1) सबसे पहले आपने प्रभावित विभाजन के अंदर फाइलसिस्टम (एस) को कम कर दिया है जिसे छोटा किया जाएगा। इसके लिए, resize2fs टूल का उपयोग करें (यह मानते हुए कि हम एक ext2 / ext3 / ext4 fs के बारे में बात कर रहे हैं - अन्य आधुनिक FSs में भी समान उद्देश्य के लिए रिसाइज़िंग टूल हैं)। ध्यान दें कि हालांकि - स्पष्ट कारणों के लिए - एक फाइल सिस्टम विभाजन से बड़ा नहीं हो सकता है जो उसके भीतर रहता है, यह सुरक्षित रूप से छोटा हो सकता है। यहाँ सुरक्षा चाल "जरूरत से ज्यादा" को कम करना है। उदाहरण के लिए: कल्पना करें कि आपके पास 1TB का एक फाइल सिस्टम है जिसे आप 500 गिग ड्राइव पर माइग्रेट करना चाहते हैं। इस मामले में, मैं सुझाव देता हूं कि एफएस को कम करें, मान लें कि 450 गिग (आपके पास इसके लिए पर्याप्त खाली जगह है, ज़ाहिर है, अर्थात, इस फाइल सिस्टम में वर्तमान में कब्जा किया गया स्थान 450 गिग से अधिक नहीं हो सकता है)। डेटा माइग्रेशन के बाद स्पष्ट रूप से बर्बाद किए गए 50 गीगा स्थान को ठीक किया जाएगा।

2) अपने अंतरिक्ष बाधाओं पर विचार करने के लिए उपयुक्त ज्यामिति के साथ गंतव्य डिस्क का विभाजन;

3) डेटा को पार्टीशन डिवाइस (एस) का उपयोग करके और डिड डिवाइस (यानी, का उपयोग dd if=/dev/sda# of=/dev/sdb#करने के बजाय प्रत्येक विभाजन के लिए उपयोग करें if=/dev/sda of=/dev/sdb) नहीं। नोट: यहाँ एसडीए और एसडीबी सिर्फ उदाहरण हैं; महत्वपूर्ण नोट: जब एक बड़े विभाजन डिवाइस से dd'ing, dd ब्लॉक डिवाइस के अंत तक पोस्ट लिखने के प्रयास के बारे में शिकायत करेगा, तो यह ठीक है क्योंकि फाइल सिस्टम डेटा को उस बिंदु तक पहुंचने से पहले पूरी तरह से कॉपी किया गया होगा। इस तरह के त्रुटि संदेश से बचने के लिए आप सिकुड़ते फाइलसिस्टम के आकार से मिलान करने के लिए कॉपी का उपयोग bs=और count=मापदंडों को निर्दिष्ट कर सकते हैं , लेकिन इसके लिए कुछ (सरल) गणना की आवश्यकता होगी, लेकिन यदि गलत तरीके से किया गया है तो यह आपके डेटा को जोखिम में डाल सकता है।

4) डेटा dd'ing के बाद, गंतव्य विभाजन के भीतर संबंधित फाइल सिस्टम (ओं) का आकार बदलकर फिर से resize2fs का उपयोग करें। इस बार नए फाइलसिस्टम का आकार निर्दिष्ट न करें। जब एक आकार विनिर्देश के बिना चलाया जाता है, तो resize2fs फाइल सिस्टम को बढ़ाता है ताकि यह अधिकतम अनुमत आकार पर कब्जा कर ले, इसलिए, इस मामले में, 450 गिग फाइल सिस्टम पूरे 500 गिग विभाजन पर कब्जा करने के लिए फिर से बढ़ेगा और कोई भी बाइट बर्बाद नहीं होगा। ("आवश्यकता से अधिक कम करें" दृष्टिकोण आपको गलती से आकारों को गलत तरीके से निर्दिष्ट करने और आपके डेटा को जोखिम में डालने से बचाता है। ध्यान दें कि GB बनाम GiB इकाइयां मुश्किल हो सकती हैं)।

अधिक जटिल कार्यों के लिए ध्यान दें: यदि आपके पास एक बूट प्रबंधक है जिसे आप साथ में कॉपी करने का इरादा रखते हैं, जो कि मामला होने की संभावना है, तो आप विभाजन उपकरणों के बजाय डिस्क डिवाइस का उपयोग करके डिस्क के पहले कुछ KB को dd कर सकते हैं (जैसे dd if=/dev/sda of=/dev/sdb bs=4096 count=5), और फिर ज्यामिति को / dev / sdb में पुन: कॉन्फ़िगर करें (जिसमें अस्थायी रूप से नई ड्राइव के लिए एक अमान्य ज्यामिति होगी लेकिन एक अक्षुण्ण और वैध बूट प्रबंधक)। अंत में विभाजन उपकरणों का उपयोग करके आगे बढ़ें जैसा कि एक समय में विभाजन को dd'ing के लिए ऊपर वर्णित किया गया है। मैंने कई बार इस तरह के ऑपरेशन किए। काफी हाल ही में, मैंने अपने मैकमिनी 6,2 में एक छोटे एसडीडी में मैकओएसएक्स और लिनक्स इंस्टॉलेशन के मिश्रण वाले एचडीडी से अपग्रेड करते समय एक जटिल प्रवासन सफलतापूर्वक किया। इस मामले में, मुझे एक बाहरी ड्राइव से लिनक्स को बूट करना था, बूटमैनर को डीडी, नए डिस्क में जीपीटी को ठीक करने के लिए gdisk भागना और अंत में बस सिकुड़ी हुई फाइलस्टीज़ वाले प्रत्येक विभाजन को dd'ed करना था। (ध्यान दें कि GPT विभाजन योजना विभाजन तालिका की दो प्रतियां रखती है, एक शुरुआत में और दूसरी डिस्क के अंत में। gdisk बहुत शिकायत करता है क्योंकि यह PT की दूसरी प्रति नहीं खोज सकता है और क्योंकि विभाजन डिस्क के आकार से अधिक है, लेकिन यह सही ढंग से PT प्रतिलिपि समस्या को ठीक करता है जब आप डिस्क ज्यामिति को फिर से परिभाषित करते हैं)। यह एक अधिक जटिल मामला था, लेकिन ध्यान देने योग्य है क्योंकि यह दर्शाता है कि इस तरह का ऑपरेशन भी पूरी तरह से संभव है।

सौभाग्य! ... और इस तरह के ऑपरेशन से पहले सभी महत्वपूर्ण डेटा का बैकअप लेना सबसे महत्वपूर्ण है। एक गलती और आप निश्चित रूप से अपरिवर्तनीय रूप से आपके डेटा को नुकसान पहुंचा सकते हैं।

और बस के मामले में मैंने पर्याप्त जोर नहीं दिया: प्रवास से पहले अपने डेटा का बैकअप लें! :)

— मार्सेलो
स्रोत

बहुत अच्छी व्याख्या, धन्यवाद!

— निर्वाण-सू

1

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

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

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

यदि डिस्क या आंशिक विभाजन LVM भौतिक आयतन है, और आप उस भौतिक आयतन की आंशिक प्रति बनाते हैं, तो आप परिणाम से कोई उपयोगी डेटा प्राप्त करना सुनिश्चित नहीं कर सकते।

यदि आप बड़ी डिस्क से केवल कुछ डेटा को छोटी डिस्क पर कॉपी करना चाहते हैं, तो छोटी डिस्क पर विभाजन बनाएं। यदि आप किसी विभाजन को समान आकार के विभाजन में कॉपी करना चाहते हैं, तो आप इसके साथ कर सकते हैं cat। आप एक छोटे विभाजन के लिए एक विभाजन की प्रतिलिपि बनाना चाहते हैं, तो लक्ष्य विभाजन पर एक फाइल सिस्टम बना सकते हैं और की तरह कुछ के साथ एक फ़ाइल-स्तर की नकल करना cp -aया pax -rw -pe -t।

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

— गिल्स 'SO- बुराई होना बंद करो'
स्रोत

हाँ, मैं पिछले विभाजन खोने के साथ ठीक हूँ। मेरे सभी डिस्क पर, सभी महत्वपूर्ण सामान हमेशा मेरे डिस्क के सबसे छोटे के आकार के भीतर फिट होते हैं। इससे परे विभाजन हमेशा गैर-जरूरी होते हैं। 'बिल्ली' के साथ बात यह है कि यह विभाजन या एक MBR (जब तक मैं गलत नहीं हूँ) नहीं

— रे एंड्रयूज

@rayandrews यदि आप catपूरी डिस्क पर चलते हैं , तो यह समान विभाजन (MBR विभाजनों के लिए एक चेतावनी के साथ, मेरा संपादन देखें) बनाएगा। वही करने के लिए जाता है dd, का उपयोग ddकरना सिर्फ एक जटिल तरीका है cat। यदि आप catविभाजन पर चलते हैं , तो निश्चित रूप से यह विभाजन नहीं बनाएंगे; उसके लिए fdisk / gdisk / parted /… का उपयोग करें।

— गाइल्स का SO- बुराई पर रोक '1

बहुत ही रोचक। ठीक है, मुझे एक उदाहरण कमांड दिखाएं, फिर मैं इसे आज़माऊंगा, और अगर यह अच्छा है तो यह सबसे अच्छा समाधान है।

— रे एंड्रयूज

@rayandrews एक उदाहरण कमांड क्या करना है?

— गिल्स एसओ- बुराई को रोकें '

डिस्क को क्लोन करने के लिए 'कैट' का उपयोग करके सिर्फ एक नमूना कमांड। इसे नया उत्तर दें ताकि मैं इसे स्वीकार कर सकूं।

— रे एंड्रयूज

0

मैं इस विषय के साथ अपने अनुभव को साझा करना चाहूंगा, क्या यह दूसरे पाठक के लिए उपयोगी साबित होना चाहिए। हाल ही में मैंने DDRESCUE का उपयोग एक खराब हार्ड ड्राइव से NTFS विभाजन के पहले 1/3 को पुनर्प्राप्त करने के लिए किया था, और विभाजन के पुनर्प्राप्त खंड को सफलतापूर्वक एक छोटे हार्ड ड्राइव पर फिर से बनाया था - जिससे कैप्चर की गई फ़ाइलों (और बाकी को खोना) से बचाया जा सके। मैंने ऐसा करने के लिए कदम उठाए हैं (निश्चित रूप से एक HACKSAW दृष्टिकोण !!) ...

स्रोत हार्ड ड्राइव में NTR में 750GB शामिल है, जो MBR फाइल करने योग्य है। मैंने इसे केवल कुछ समय के लिए फ़ाइलों का बैकअप लेने के लिए उपयोग किया था, इसलिए अधिकांश फाइलें ड्राइव की शुरुआत में थीं, लगभग 160GB मूल्य की। एक परिवार के सदस्य ने फर्श पर हार्ड ड्राइव (बाहरी रूप से घुड़सवार) को खटखटाया - इसके बाद कभी ठीक से काम नहीं किया! Ddrescue (श्रमसाध्य रूप से) का उपयोग करके मैं ड्राइव की शुरुआत के एक बड़े हिस्से को पुनर्प्राप्त करने में सक्षम था। शारीरिक क्षति के कारण, यह पूरी प्रक्रिया में बहुत बार बंद हो जाता है ...

मेरे पास एक छोटा लैपटॉप हार्ड ड्राइव उपलब्ध था 150GB (बाहरी रूप से घुड़सवार), जिसे मैंने सीधे ddrescue डेटा को निकाला। वैकल्पिक रूप से मैं डेटा को एक छवि फ़ाइल में निकाल सकता था, और बाद में फ़ाइल को माउंट कर सकता था, हालांकि मैंने सोचा कि डेटा को अधिक कठोर बनाने के लिए सीधे हार्ड ड्राइव पर लिखना चाहिए।

बचाव के लिए महत्वपूर्ण चाल, बचाव हार्ड ड्राइव पर MBR और NTFS बूट सेक्टर डेटा दोनों को मैन्युअल रूप से संपादित करना था। ऐसा किए बिना, हार्ड ड्राइव किसी भी ऑपरेटिंग सिस्टम द्वारा पहचाना नहीं गया है। मुझे ऐसा करने के लिए लिनक्स में एक उपयुक्त कार्यक्रम नहीं मिल रहा था, इसलिए मैंने खिड़कियों की ओर रुख किया। विंडोज सपोर्ट टूल्स नाम का एक आसान पैकेज है, जिसे अब भी उपयोगी नहीं रखा गया है (नीचे लिंक देखें)! विभाजन को संपादित करने के लिए मैंने जिस उपकरण का उपयोग किया था, वह है डिस्क जांच। अपनी हार्ड ड्राइव के अंतिम क्षेत्र मूल्य को जानना सुनिश्चित करें (मैंने उबंटू में fdisk -l का इस्तेमाल किया)

https://en.wikipedia.org/wiki/Windows_Support_Tools

एक अच्छे कैलकुलेटर और कुछ रचनात्मकता का उपयोग करते हुए मैंने विंडोज में डिस्क जांच में हार्ड ड्राइव को लोड किया और माउंट किया और अंतिम सेक्टर मानों को संपादित किया। MBR में मूल्यों के दो सेटों को बदलना पड़ा, अर्थात् (a) हार्ड ड्राइव एंड सेक्टर और b) NTFS पार्टीशन एंड सेक्टर। NTFS बूट सेक्टर में विभाजन कुल सेक्टर मान को बदलना पड़ा। प्रत्येक मामले में संख्यात्मक मूल्य को छोटे हार्ड ड्राइव के घटे हुए "आयाम" से मिलान करने के लिए घटाया गया था (अंत क्षेत्रों को 750GB से 150GB में बदल दिया गया था)। इन मानों को संपादित करने के लिए दृश्य टैब पर क्लिक करें।

यहां NTFS बूट सेक्टर डेटा को संपादित करने की कार्रवाई में डिस्क जांच की एक छवि है

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

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

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

— डैन गार्डनर
स्रोत

1

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

— फॉक्स

1

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

— रे एंड्रयूज

0

आपको पहले स्रोत पर विभाजन को छोटा करना होगा (या उन आउट-ऑफ-बाउंड्स को हटाना होगा)।
थान ddऔर उसके बाद आपको संभवतः विभाजन तालिका को सुधारने की आवश्यकता होगी और तालिका को सुधारने के gdisk /dev/sd<target>
लिए महत्वपूर्ण अनुक्रम है। v r d w
मेरा सुझाव है कि आप विभाजन को जरूरत से थोड़ा छोटा करें और लक्ष्य डिस्क के पूर्ण आकार में वापस विस्तार करने के बाद।
(यह उत्तर मेरे व्यक्तिगत अनुभव पर आधारित है जब मेरे HDD को छोटे SSD में क्लोन किया जाता है)

— ज़िगालिन - सीएम बहाल
स्रोत

+1। यह विधि मेरे लिए भी काम करती है: क्लोनिंग तब काम करती है जब सभी विभाजन लक्ष्य ड्राइव के भीतर फिट होते हैं :-) बस एक टिप्पणी: आपको GUID partiiton तालिका (GPT) के बैकअप विभाजन तालिका को सुधारने की आवश्यकता है, लेकिन अगर कोई पुरानी शैली का MSDOS है विभाजन तालिका, मरम्मत के लिए कोई बैकअप विभाजन तालिका नहीं है।

— सूडोडस