चेतावनी
मैं हैरान था कि कितने फाइल फोटोरेक को मेरी डिस्क से मिटा सकते हैं, पोंछने के बाद भी।
चाहे "मुक्त स्थान" को भरने में अधिक सुरक्षा हो, केवल 1 बार 0x00 के साथ या 38 बार विभिन्न कैबलिस्टिक मानकों के साथ एक अकादमिक चर्चा का अधिक है। श्रेडिंग पर 1996 के सेमिनल के लेखक ने खुद को एक उपसंहार लिखा है कि यह आधुनिक हार्डवेयर के लिए अप्रचलित और आवश्यक है। डेटा को भौतिक रूप से प्रतिस्थापित शून्य और बाद में पुनर्प्राप्त किए जाने का कोई प्रलेखित मामला नहीं है।
इस प्रक्रिया में सही नाजुक लिंक फाइलसिस्टम है । कुछ फाइल सिस्टम विशेष उपयोग के लिए स्थान आरक्षित करते हैं, और इसे "मुक्त स्थान" के रूप में उपलब्ध नहीं कराया जाता है। लेकिन आपका डेटा हो सकता है । जिसमें तस्वीरें, व्यक्तिगत सादे-पाठ ईमेल शामिल हैं, जो भी हो। मैंने केवल आरक्षित + स्थान + ext4 को गुगला दिया है और यह जान लिया है कि मेरे homeविभाजन का 5% आरक्षित था। मुझे लगता है कि यह वह जगह है जहाँ photorecमेरे सामान का इतना पाया गया है। निष्कर्ष: श्रेडिंग विधि सबसे महत्वपूर्ण नहीं है, यहां तक कि मल्टी-पास विधि अभी भी जगह में डेटा छोड़ती है ।
आप # tune2fs -m 0 /dev/sdn0इसे माउंट करने से पहले कोशिश कर सकते हैं । (यदि यह रिबूटिंग के बाद रूट विभाजन होगा, तो सुनिश्चित करें कि इसे चलाएं -m 5या -m 1इसे अनमाउंट करने के बाद)।
लेकिन फिर भी, एक तरह से या किसी अन्य, कुछ जगह बची रह सकती है।
एकमात्र सही मायने में सुरक्षित तरीका पूरे विभाजन को मिटा देना है, फिर से एक फाइल सिस्टम बनाना है, और फिर अपनी फ़ाइलों को बैकअप से पुनर्स्थापित करना है।
तेज़ तरीका (अनुशंसित)
जिस सिस्टम पर आप पोंछना चाहते हैं उस पर एक निर्देशिका से चलाएँ:
dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
rm zero.file
नोट्स: छोटी फ़ाइल का उद्देश्य उस समय को कम करना है जब मुक्त स्थान पूरी तरह से शून्य हो; सिंक का उद्देश्य यह सुनिश्चित करना है कि डेटा वास्तव में लिखा गया है।
यह ज्यादातर लोगों के लिए काफी अच्छा होना चाहिए।
धीमा तरीका (पैरानॉयड)
उपरोक्त सफाई के बाद डेटा के बरामद होने का कोई दस्तावेज नहीं है। यह महंगा और संसाधन की मांग होगी, यदि संभव हो तो।
फिर भी, यदि आपके पास यह सोचने का कारण है कि गुप्त एजेंसियां आपकी फ़ाइलों को पुनर्प्राप्त करने के लिए बहुत सारे संसाधन खर्च करेंगी, तो यह पर्याप्त होना चाहिए:
dd if=/dev/urandom of=random.small.file bs=1024 count=102400
dd if=/dev/urandom of=random.file bs=1024
sync ; sleep 60 ; sync
rm random.small.file
rm random.file
इसमें ज्यादा समय लगता है।
चेतावनी। यदि आपने पैरानॉयड रास्ता चुना है, तो इसके बाद भी आप तेज पोंछना चाहते हैं, और यह व्यामोह नहीं है। विशुद्ध रूप से यादृच्छिक डेटा की उपस्थिति का पता लगाना आसान और सस्ता है, और यह संदेह पैदा करता है कि यह वास्तव में एन्क्रिप्टेड डेटा है। डिक्रिप्शन कुंजी का खुलासा नहीं करने के लिए आप यातना के तहत मर सकते हैं।
बहुत धीमा तरीका (पागल पागल)
यहां तक कि कतरन पर 1996 के सेमिनल के लेखक ने यह कहते हुए एक उपसंहार लिखा कि यह आधुनिक हार्डवेयर के लिए अप्रचलित और आवश्यक है।
लेकिन अगर अभी तक आपके पास बहुत खाली समय है और आप बहुत अधिक ओवरराइटिंग के साथ अपनी डिस्क को बर्बाद करने का मन नहीं करते हैं, तो यह हो जाता है:
dd if=/dev/zero of=zero.small.file bs=1024 count=102400
sync ; sleep 60 ; sync
shred -z zero.small.file
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
shred -z zero.file
sync ; sleep 60 ; sync
rm zero.file
नोट: यह अनिवार्य रूप से सिक्योर-डिलीट टूल के उपयोग के बराबर है।
सम्पादन से पहले, यह पोस्ट डेविड स्पिल्ट्स का पुनर्लेखन था। "कैट" कमांड एक त्रुटि संदेश उत्पन्न करता है, लेकिन मैं अन्य लोगों के पोस्ट पर टिप्पणी नहीं लिख सकता।