क्या अधिलेखित फाइलें बरामद की जा सकती हैं?

42

मैं हटाई गई फ़ाइलों को पुनर्प्राप्त करने के बारे में बात नहीं कर रहा हूं , लेकिन फ़ाइलों को अधिलेखित कर रहा हूं । निम्नलिखित विधियों द्वारा

# move
mv new_file old_file

# copy
cp new_file old_file

# edit
vi existing_file
> D
> i new_content
> :x

क्या यह संभव है कि उपर्युक्त तीनों क्रियाओं में से कोई भी ऐसा करने के लिए संभव हो, जो यह मान ले कि कोई विशेष कार्यक्रम लिनक्स मशीन पर स्थापित नहीं हैं?

data-recovery ext4

— प्रश्न अतिप्रवाह
स्रोत

4

आप अपने बैकअप से अलग मतलब है?

— jasonwryan

@ajonwryan, हाँ, बिल्कुल।

— प्रश्न ओवरफ्लो

2

मैं केवल यह बताना चाहता हूं कि आपका पहला उदाहरण ( mv) हटाने के लिए समान है old_file, इसे अधिलेखित नहीं करना है, इसलिए हटाए गए फ़ाइलों को पुनर्प्राप्त करने के लिए तरीके (यदि कोई मौजूद हैं), जैसा कि अधिलेखित फ़ाइलों के विपरीत, उस मामले में लागू होगा। आपके अन्य दो उदाहरण क्रमशः एक मौजूदा old_fileऔर existing_file, को अधिलेखित करते हैं।

— सेलडा

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

— मार्क प्लॉटनिक

1

@MarkPlotnick, Celada की टिप्पणी के अनुसार, mvअलग है।

— प्रश्न अतिप्रवाह

60

जवाब है "शायद हां, लेकिन यह फाइलसिस्टम प्रकार, और समय पर निर्भर करता है।"

उन तीन उदाहरणों में से कोई भी मौका छोड़कर पुराने_फाइल या मौजूदा_फाइल के भौतिक डेटा ब्लॉक को अधिलेखित नहीं करेगा।

mv new_file old_file। यह ओल्ड_फाइल को अनलिंक कर देगा। अगर Old_file में अतिरिक्त हार्ड लिंक हैं, तो ब्लॉक उन शेष लिंक में अपरिवर्तित रहेंगे। अन्यथा, ब्लॉक आम तौर पर (यह फाइलसिस्टम प्रकार पर निर्भर करता है) एक स्वतंत्र सूची में रखा जाएगा। फिर, यदि mvप्रतिलिपि की आवश्यकता होती है (बस चलती निर्देशिका प्रविष्टियों के विपरीत), नए ब्लॉक को लिखित रूप में आवंटित किया जाएगा mv।

ये नव-आवंटित ब्लॉक वही हो सकते हैं या नहीं हो सकते हैं जिन्हें अभी मुक्त किया गया था । UFS जैसी फाइलसिस्टम पर , ब्लॉक संभव हैं, यदि संभव हो तो उसी सिलिंडर समूह से, जिस डायरेक्टरी में फाइल बनाई गई थी। इसलिए एक मौका है कि किसी डायरेक्टरी से फाइल को अनइंस्टॉल करके उसी डायरेक्टरी में एक फाइल बनाकर फिर से उपयोग करें ( और अधिलेखित) उन्हीं ब्लॉकों में से कुछ जिन्हें अभी मुक्त किया गया था। यही कारण है कि किसी फ़ाइल को गलती से निकालने वाले लोगों को मानक सलाह यह है कि वे अपनी निर्देशिका ट्री में फ़ाइलों के लिए कोई नया डेटा न लिखें (और अधिमानतः संपूर्ण फ़ाइल सिस्टम के लिए) जब तक कोई फ़ाइल पुनर्प्राप्ति का प्रयास नहीं कर सकता है।
cp new_file old_fileनिम्नलिखित करेंगे (आप straceसिस्टम कॉल को देखने के लिए उपयोग कर सकते हैं ):
```
open ("old_file", O_WRONLY | O_TRUNC) = 4
```
O_TRUNC ध्वज के कारण सभी डेटा ब्लॉक मुक्त हो जाएंगे, जैसा mvकि ऊपर किया गया था। और ऊपर के रूप में, वे आम तौर पर एक मुफ्त सूची में जोड़ दिए जाएंगे, और cpकमांड द्वारा किए गए बाद के लेखन द्वारा पुन: उपयोग नहीं किया जा सकता है या नहीं ।
vi existing_file। यदि viवास्तव में vim, :xकमांड निम्नलिखित करता है:
```
अनलिंक ("मौजूदा_फाइल ~") = -1 ENOENT (ऐसी कोई फ़ाइल या निर्देशिका नहीं)
```
```
नाम बदलें ("मौजूदा_फाइल", "मौजूदा_फाइल ~") = 0
```
```
खुला ("मौजूदा_फाइल", O_WRONLY | O_CREAT | O_TRUNC, 0664) - 3
```
तो यह पुराने डेटा को भी नहीं हटाता है; बैकअप फ़ाइल में डेटा संरक्षित है।

FreeBSD पर, viकरता है open("existing_file",O_WRONLY|O_CREAT|O_TRUNC, 0664), जिसमें cpऊपर जैसा ही शब्दार्थ होगा ।

आप विशेष कार्यक्रमों के बिना कुछ या सभी डेटा को पुनर्प्राप्त कर सकते हैं; आप सभी की जरूरत है grepऔर dd, और कच्चे उपकरण तक पहुंच।

छोटी पाठ फ़ाइलों के लिए, आपके द्वारा लिंक किए गए प्रश्न में @Steven D से उत्तरgrep में एकल कमांड सबसे आसान तरीका है:

grep -i -a -B100 -A100 'text in the deleted file' /dev/sda1

लेकिन बड़ी फ़ाइलों के लिए जो कई गैर-सन्निहित ब्लॉक में हो सकती हैं, मैं यह करता हूं:

grep -a -b "text in the deleted file" /dev/sda1
13813610612:this is some text in the deleted file

जो आपको मिलान लाइन के बाइट्स में ऑफसेट देगा। ddआदेशों की एक श्रृंखला के साथ इस का पालन करें , के साथ शुरू

dd if=/dev/sda1 count=1 skip=$(expr 13813610612 / 512)

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

बेशक, फ़ाइल सिस्टम पर जो डेटा को संपीड़ित या एन्क्रिप्ट करते हैं, पुनर्प्राप्ति यह सीधा नहीं हो सकता है।

यूनिक्स में वास्तव में बहुत कम उपयोगिताओं हैं जो एक मौजूदा फ़ाइल के डेटा ब्लॉक को अधिलेखित कर देंगे। जो मन में आता है वह है dd conv=notrunc। एक और है shred।

— मार्क प्लॉटनिक
स्रोत

3

तीन अलग-अलग ऑपरेशन के आंतरिक यांत्रिकी को समझाने के लिए धन्यवाद। यह वास्तव में उपयोगी है!

— प्रश्न अतिप्रवाह

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

— pqnet

पूर्ववर्ती पाठ ब्लॉक कैसे प्राप्त करें और स्किप क्या करता है?

— unixit

@Islam जब आप dd skip=पैरामीटर देते हैं, तो इनपुट की शुरुआत से पढ़ने के बजाय यह ब्लॉक की संख्या को छोड़ देगा। एक ब्लॉक डिफ़ॉल्ट रूप से 512 बाइट्स है, लेकिन bs=पैरामीटर के साथ बदला जा सकता है ।

— मार्क प्लॉटनिक

1

@Islam पूर्ववर्ती पाठ खंड को प्राप्त करने के लिए, मैं सुझाव दूंगा skip=कि 1 ब्लॉक (512 बाइट्स) कम दिया जाए। मेरे उदाहरण में, $(expr 13813610612 / 512 - 1)। यदि वह नहीं मिलता है जो आप चाहते हैं, तो 16 या 32 को घटाते हुए फिर से कोशिश करें, जो उन क्षेत्रों को देखेंगे जो 8192 और 16384 बाइट्स कम हैं; फ़ाइलें अक्सर 8192-बाइट विखंडू में आवंटित की जाती हैं। यदि आप एक बड़ी फ़ाइल को पुनर्प्राप्त करने का प्रयास कर रहे हैं, तो समय बचाने के लिए बड़ी गणना का प्रयास करें। मैं आमतौर count=16पर एक संपादक में परिणाम का उपयोग करता हूं और देखता हूं जैसे emacsकि अगर कुछ डेटा पाठ नहीं है तो कोई आपत्ति नहीं है।

— मार्क प्लॉटनिक

6

मैं (नहीं एक विशाल तार के साथ) कहने जा रहा हूँ।

डिस्क पर डेटा कैसे रखा जाता है, इसके बारे में सोचें। आपके पास ऐसे ब्लॉक हैं जिनमें डेटा होता है और अगले ब्लॉक पर इंगित होता है (यदि एक है)।

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

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

विखंडन के बारे में सोचने के लिए कुछ दिलचस्प हो सकता है।

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

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

छोटी कहानी, आपका डेटा शायद खो गया है (एक चरम फोरेंसिक प्रक्रिया से गुजरने के बिना, जहां आप इसे माइक्रोस्कोप के नीचे देखते हैं); हालाँकि, एक मौका है कि यह अभी भी है।

— SailorCire
स्रोत

1

आपका जवाब यह धारणा बनाता है कि ब्लॉक-आधारित नॉन-कॉपी-ऑन-राइट फाइलसिस्टम जैसे कि ext4या xfsउपयोग में है। लिखने के साथ फाइल सिस्टम पर कॉपी करें zfsऔर btrfsआप वास्तव में "ब्लॉक सामग्री को बदलना" कभी नहीं ; वे फाइल सिस्टम हमेशा नए डेटा को रखने के लिए एकदम नए ब्लॉक का उपयोग करते हैं। इसके अलावा, लॉग-आधारित फ़ाइल सिस्टम jffs2भी हमेशा नए स्थानों पर नए डेटा लिखते हैं ("ब्लॉक" नहीं, वे फाइल-सिस्टम ब्लॉक-आधारित नहीं हैं)। यह कहा जा रहा है, इसका मतलब यह नहीं है कि पुराने डेटा कहाँ रहते हैं और इसे रीसायकल करने से पहले इसे ढूंढना आसान है। तो आपका जवाब, जो नहीं है, अभी भी सही है

— सेलाडा

@Celada धन्यवाद! मुझे वह बहुत जानकारीपूर्ण लगी। मेरे पास यह देखने का समय नहीं है कि btrfs या zfs कैसे काम करते हैं, लेकिन मुझे पता था कि वे मौजूद हैं।

— सेलोरकेयर

2

सुनिश्चित करें कि आपके पास पर्याप्त डिस्क स्थान / var / tmp या कहीं बड़ा है।

प्रयत्न, कोशिश

 grep -i -a -B100 -A100 'a string unique to your file' /dev/sda1 |
 strings > /var/tmp/my-recovered-file

जहां / dev / sda1 आपके सिस्टम पर आपकी डिस्क होगी।

फिर आप स्ट्रिंग के लिए मेरी पुनर्प्राप्त-फ़ाइल खोजें।

यह ज्यादातर वहाँ हो सकता है, यदि आप इसे लापता लाइनों, कोष्ठक, sysmbols आदि के लिए जाँच पाते हैं।

अपनी फ़ाइल से एक खोज शब्द का उपयोग करें, जो काफी हद तक अनकिया या स्ट्रिंग है जो फ़ाइल में डेटा की मात्रा में कटौती करेगा। यदि आप "इको" जैसे शब्द की खोज करते हैं, तो आपको स्ट्रिंग्स का भार मिलेगा क्योंकि सिस्टम में बहुत सारी फाइलें होंगी, जिनमें ईको शब्द होता है।

— AndyM
स्रोत

0

मैंने 12 घंटे के परीक्षण डेटा के साथ एक टेक्स्ट फ़ाइल (VQ1.txt) को अधिलेखित कर दिया था :( एक धारणा जो टेक्सट टेक्स्ट में फ़ाइल के पिछले संस्करण को सहेजती है सूची में VQ1.txt ~ दिखाया गया था, जिसमें मेरा 'खोया' डेटा था!

$ cat VQ1.txt~  
Start time at: Thu Apr  2 18:07:23 PDT 2015
User, KW: 12hrFA_OEM_HelloVoiceQ
Test Case: 
Detection:  1, 1, 04-03 01:07:00.673 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  2, 1, 04-03 01:09:04.813 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  3, 1, 04-03 04:09:26.023 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  4, 1, 04-03 04:11:29.893 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  5, 1, 04-03 07:12:27.013 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  6, 1, 04-03 07:14:30.803 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  7, 1, 04-03 08:37:13.113 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  8, 1, 04-03 10:21:23.533 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  9, 1, 04-03 10:23:27.733 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  10, 1, 04-03 13:23:47.893 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  11, 1, 04-03 13:25:52.203 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1

12hrFA_OEM_HelloVoiceQ,  
KW detect count: 11

— catsat
स्रोत

4

क्या यह सामान्य रूप से यूनिक्स के बजाय कुछ पाठ संपादकों की विशेषता नहीं है? मुझे उस फ़ाइल सिस्टम के बारे में जानकारी नहीं है जो उस तरह के पुराने संस्करणों को सहेजता है।

— जॉय

0

TL, DR - यदि ओवरराइट फ़ाइल अभी भी चल रही प्रक्रिया द्वारा खुली रखी जा रही है, तो यह ब्लॉग पोस्ट आपके बेकन को बचा सकती है:

https://www.linux.com/news/bring-back-deleted-files-lsof/

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

— fulv
स्रोत