rm -rf से डिलीट हुई फाइलें रिकवर कैसे करें

पहले साठ सेकंड में क्या करें

rm -rf से डिलीट की गई फाइलों को रिकवर करने की संभावना दो बातों पर निर्भर करती है, और ये दोनों ही बातें सर्च इंजन खोलने से पहले होती हैं। उस फाइलसिस्टम पर लिखना तुरंत बंद करें। फिर उसे unmount करके या read-only मोड में remount करके उपयोग से बाहर कर दें।

rm कुछ भी मिटाता नहीं है। यह केवल डायरेक्टरी एंट्री को हटाता है, और फिर inode तथा फाइल के डेटा ब्लॉक्स को 'free' के रूप में चिह्नित कर देता है। बाइट्स अभी भी डिवाइस पर मौजूद रहते हैं। वे तब तक वहां रहते हैं जब तक कि ब्लॉक एलोकेटर उन ब्लॉक्स को किसी और प्रक्रिया को नहीं सौंप देता और वह प्रक्रिया उन पर कुछ नया नहीं लिख देती। हर सेकंड जब फाइलसिस्टम mounted और व्यस्त रहता है, कोई न कोई डेमन लॉग लाइन लिखता है या डेटाबेस पेज फ्लश करता है, और इनमें से कोई भी राइट ऑपरेशन उन ब्लॉक्स पर हो सकता है जिन्हें आप वापस पाना चाहते हैं।

इसलिए, पहली कमांड्स वे हैं जो राइट ऑपरेशंस को रोकती हैं, न कि वे जो फाइलों को रिकवर करती हैं।

sudo systemctl stop nginx postgresql
sudo umount /mnt/data

यदि umount का उत्तर umount: /mnt/data: target is busy. है, तो पता लगाएँ कि फाइलसिस्टम को किसने open रखा है।

sudo fuser -vm /mnt/data
sudo lsof +D /mnt/data

यदि आप इसे free नहीं कर सकते, तो इसके बजाय इसे read-only मोड में remount करें। एक read-only माउंट नए एलोकेशन्स को रोक देता है, जो कि आपकी अधिकांश आवश्यकता के लिए पर्याप्त है।

sudo mount -o remount,ro /mnt/data

यदि डिलीट किया गया पाथ रूट फाइलसिस्टम पर था, तो यह अधिक कठिन है। sudo mount -o remount,ro / आमतौर पर mount: /: cannot remount /dev/vda1 read-only. के साथ विफल हो जाएगा, क्योंकि चल रही प्रक्रियाएं फाइलों को राइट मोड में ओपन रखती हैं और कर्नल उन्हें जबरन बंद नहीं करेगा। VPS पर इसका व्यावहारिक समाधान आपके प्रोवाइडर का rescue या recovery मोड है: यह एक अलग live सिस्टम बूट करता है जिसमें आपकी डिस्क अटैच तो होती है लेकिन माउंट नहीं होती। इसके बाद नीचे दी गई हर कमांड एक ऐसे डिवाइस पर चलती है जिस पर कोई भी कुछ लिख नहीं रहा होता है।

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

ext4 पर rm -rf रिकवरी लगभग असंभव क्यों है

कुछ भी install करने से पहले अपनी अपेक्षाएं स्पष्ट रखें। पुष्टि करें कि आप किस filesystem के साथ काम कर रहे हैं:

lsblk -f

ext4 पर, जो लगभग हर VPS image में default होता है, किसी फ़ाइल के डेटा का स्थान उसके inode में एक extent tree के रूप में रहता है। एक extent एक रिकॉर्ड है जो बताता है कि इस फ़ाइल का logical block N, physical block M से शुरू होता है और L blocks तक चलता है। छोटी फ़ाइलें इनमें से चार रिकॉर्ड स्वयं inode के भीतर रखती हैं। बड़ी फ़ाइलें उन अतिरिक्त blocks की ओर इशारा करती हैं जिनमें tree का शेष भाग होता है।

जब किसी फ़ाइल का अंतिम link हट जाता है, तो ext4 उस tree को traverse करता है, प्रत्येक extent को block allocator को वापस कर देता है, और inode से tree को हटा देता है। इसके बाद inode को free चिह्नित कर दिया जाता है और उस पर deletion time की मुहर लगा दी जाती है। डेटा स्वयं सुरक्षित रहता है। डेटा कहाँ था, इसका एकमात्र रिकॉर्ड मिट चुका होता है।

यही ext3 से अंतर है, जहाँ एक deleted inode में इतना कुछ शेष रहता था कि ext3grep जैसा टूल उसे ट्रैक कर सके। आप अभी भी ext4 पर deleted inodes की सूची देख सकते हैं:

sudo debugfs -R lsdel /dev/vdb1

debugfs डिवाइस को read-only मोड में खोलता है जब तक कि आप -w पास न करें, इसलिए unmounted डिवाइस पर यह सुरक्षित है और इसे आज़माने में कोई नुकसान नहीं है। Inodes की सूची दिखाई देगी। लेकिन एक inode को dump करने पर प्रक्रिया समाप्त हो जाती है, क्योंकि वह block map जिसे inode होल्ड करता था, उसे साफ़ कर दिया गया है, इसलिए dump के पास अनुसरण करने के लिए कुछ नहीं बचता।

दो टूल journal को पढ़कर इसे हल करने का प्रयास करते हैं। journal एक निश्चित आकार की ring है जिसका उपयोग ext4 क्रैश के दौरान metadata को सुसंगत रखने के लिए करता है, और इसमें delete होने से पहले के inode की पुरानी copy हो सकती है। extundelete और ext4magic दोनों इसे खोजते हैं। जाँचें कि आप किस आकार के साथ काम कर रहे हैं:

sudo dumpe2fs -h /dev/vdb1 | grep -i journal

journal में केवल metadata होता है और यह छोटा होता है, इसलिए सामान्य write activity इसमें तेज़ी से घूमती रहती है। एक चल रहे सर्वर पर, वह समय-सीमा जिसमें delete से पहले का inode मौजूद रहता है, केवल कुछ मिनटों की होती है। न तो किसी टूल का सक्रिय रूप से रखरखाव किया जाता है, और न ही वे हर distribution में packaged होते हैं। दोनों को एक अंतिम प्रयास (long shot) मानें, उन्हें unmounted डिवाइस या disk image पर चलाएं, और यदि वे कुछ भी न लौटाएं तो आश्चर्यचकित न हों।

यदि lsblk -f, xfs रिपोर्ट करता है, तो स्थिति बेहतर नहीं है, क्योंकि XFS के लिए भी कोई समर्थित undelete सुविधा नहीं है। नीचे दिए गए विकल्पों का क्रम नहीं बदलता है।

क्या फाइल अभी भी किसी चल रही प्रक्रिया में खुली है?

यह इस पेज पर रिकवरी का एकमात्र तरीका है जिसके सफल होने की अच्छी संभावना है, और यही कारण है कि आपको उस सर्विस को रीस्टार्ट नहीं करना चाहिए जो उस फाइल का उपयोग कर रही थी।

एक फाइल वास्तव में तभी हटती है जब दो गणनाएँ शून्य तक पहुँच जाती हैं: इसके inode की ओर इशारा करने वाली डायरेक्टरी प्रविष्टियों की संख्या, और खुले फाइल डिस्क्रिप्टर की संख्या। rm पहली गणना को शून्य कर देता है। यदि कोई प्रक्रिया अभी भी फाइल को खुला रखती है, तो दूसरी गणना शून्य नहीं होती है, इसलिए inode और उसके ब्लॉक्स अभी भी आवंटित रहते हैं और डेटा अभी भी पठनीय होता है।

उन खुली फाइलों को खोजें जिनका लिंक काउंट शून्य हो गया है:

sudo lsof +L1

+L1 का अर्थ है उन खुली फाइलों को सूचीबद्ध करना जिनका लिंक काउंट 1 से कम है। प्रत्येक मिलान प्रक्रिया, फाइल डिस्क्रिप्टर नंबर, 0 का एक NLINK, और (deleted) पर समाप्त होने वाला एक पाथ दिखाता है। PID और डिस्क्रिप्टर नंबर को /proc में उपयोग करें:

sudo ls -l /proc/1234/fd

एक प्रविष्टि 3 -> /var/log/app/events.log (deleted) जैसी दिखती है। वह लिंक अभी भी डेटा तक पहुँचता है। इसे एक अलग फाइलसिस्टम पर कॉपी करें:

sudo cp /proc/1234/fd/3 /mnt/rescue/events.log

mv के बजाय cp का उपयोग करें। /proc/1234/fd/3 को खोलने से आपको उसी inode पर शून्य ऑफसेट से एक नया हैंडल मिलता है, इसलिए आपको राइटर की वर्तमान स्थिति के बाद के हिस्से के बजाय पूरी फाइल मिल जाती है।

दो सीमाएँ हैं जिन्हें जानना उपयोगी है। एक हटाई गई डायरेक्टरी ट्री इस तरह से वापस नहीं आती है, क्योंकि केवल वे व्यक्तिगत फाइलें ही सुरक्षित रहती हैं जिन्हें किसी प्रक्रिया ने खुला रखा था। और इंजन के लिखते समय कॉपी की गई डेटाबेस फाइल एक क्रैश-कंसिस्टेंट कॉपी होती है, इसलिए इसे क्लीन मानने के बजाय इंजन की अपनी रिकवरी प्रक्रिया चलाने की योजना बनाएँ। जिन प्रविष्टियों को lsof डिस्क्रिप्टर नंबर के स्थान पर mem के साथ दिखाता है, वे मेमोरी मैप्ड होती हैं, और उनके पास कॉपी करने के लिए कोई /proc/<pid>/fd प्रविष्टि नहीं होती है।

क्या आपके पास btrfs, ZFS या LVM पर कोई snapshot है?

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

btrfs, snapshots को subvolumes के रूप में रखता है:

sudo btrfs subvolume list /

Snapshot को browse करें और जिन paths की आपको आवश्यकता है, उन्हें cp -a के साथ copy करें। पूरे subvolume को rollback करने के बजाय केवल चुनिंदा paths को copy करना बेहतर है, क्योंकि rollback करने से snapshot लिए जाने के बाद लिखी गई हर चीज़ हट जाती है।

ZFS हर snapshot को एक read-only directory के रूप में दिखाता है:

zfs list -t snapshot
ls /tank/data/.zfs/snapshot/

.zfs directory छिपी हुई होती है और dataset root की सामान्य ls में दिखाई नहीं देगी, लेकिन आप नाम से इसमें प्रवेश कर सकते हैं। वहां से फाइलें copy करें। zfs rollback पूरे dataset को वापस ले जाता है और आपके द्वारा नाम दिए गए snapshot के बाद के सभी snapshots को नष्ट कर देता है, इसलिए इसे अंतिम उपाय के रूप में ही रखें।

LVM snapshots निश्चित आकार वाले copy-on-write volumes होते हैं:

sudo lvs
sudo mount -o ro /dev/vg0/data-snap /mnt/snap

इसे read-only mount करें और फाइलें copy करें। उस पर भरोसा करने से पहले lvs की जाँच करें, क्योंकि यदि LVM snapshot अपनी आवंटित जगह भर लेता है, तो kernel उसे अमान्य कर देता है और एक बार ऐसा होने पर उसकी सामग्री नष्ट हो जाती है।

Snapshot कोई backup नहीं है। यह मूल डेटा की तरह ही उसी disk या pool पर रहता है, इसलिए मूल डेटा की सभी विफलताएं इसमें भी हो सकती हैं। यह दो मिनट पहले की गई गलती को सुधारने के लिए बहुत उपयोगी है, जो कि यहाँ बिल्कुल वही काम है।

PhotoRec के साथ carving, हमेशा image पर करें, live disk पर कभी नहीं

यदि ऊपर दी गई कोई भी विधि काम न करे, तो अंतिम विकल्प carving है: raw device को उन byte patterns के लिए स्कैन करना जो किसी ज्ञात फ़ाइल प्रकार की शुरुआत को दर्शाते हैं, और फिर उसके बाद आने वाले डेटा को लिखना। Carving केवल फ़ाइल डेटा को पढ़ती है। फ़ाइल नाम, निर्देशिका संरचना, टाइमस्टैम्प और स्वामित्व सभी filesystem metadata हैं, और यही वह metadata है जिसे rm ने नष्ट कर दिया है, इसलिए इनमें से कुछ भी वापस नहीं आता है। आपको एक numbered output directory में f0384512.jpg नाम की फ़ाइलें मिलेंगी, और आपको उन्हें हाथ से छांटना होगा।

दो नियम तय करते हैं कि क्या यह प्रक्रिया काम करेगी।

पहला, किसी भी अन्य टूल का उपयोग करने से पहले डिवाइस की image लें। Debian और Ubuntu पर पैकेज gddrescue है और यह जो binary इंस्टॉल करता है वह ddrescue है।

sudo apt update && sudo apt install -y gddrescue testdisk
sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map

/mnt/rescue को एक अलग डिवाइस पर होना चाहिए, जिसमें कम से कम उतनी खाली जगह हो जितनी partition में है। lsblk -b बाइट्स में सटीक आकार प्रिंट करता है। map फ़ाइल interrupted copy को शुरू से शुरू करने के बजाय वहीं से फिर से शुरू करने की अनुमति देती है। एक बार जब आपके पास image आ जाती है, तो आप बाद में बिल्कुल उन्हीं बाइट्स के खिलाफ दूसरे टूल का प्रयास कर सकते हैं, जो आप तब नहीं कर सकते यदि पहले टूल ने डिस्क पर कुछ लिख दिया हो।

दूसरा, recovery टूल को image फ़ाइल पर पॉइंट करें।

sudo photorec /d /mnt/rescue/recup /mnt/rescue/vdb1.img

photorec एक text menu खोलता है। partition चुनें, फिर filesystem का प्रकार, फिर खोजने के लिए फ़ाइल signatures, और अंत में destination directory। शुरू करने से पहले उस signature सूची को उन फ़ाइल प्रकारों तक सीमित करें जिन्हें आपने वास्तव में खो दिया है, क्योंकि डिफ़ॉल्ट सूची सब कुछ ढूंढ लेती है और आपको छानने के लिए हजारों fragments दे देती है।

उसी पैकेज से testdisk का अपना undelete फ़ंक्शन है, और यह केवल FAT, exFAT, NTFS और ext2 को कवर करता है। ext4 पर इसके लिए photorec का उपयोग करना पड़ता है।

उम्मीद रखें कि fragmented फ़ाइलें टूटी हुई वापस आएंगी। Carving यह मानकर चलती है कि फ़ाइल के blocks contiguous हैं, इसलिए जिस फ़ाइल को allocator ने डिस्क पर अलग-अलग हिस्सों में रखा है, वह या तो गलत तरीके से reassemble होगी या पूरी तरह से छूट जाएगी। Media फ़ाइलें carving में काफी अच्छी तरह से रिकवर हो जाती हैं क्योंकि उनके headers मजबूत होते हैं। Plain text, configuration और source code की carving खराब होती है, क्योंकि ऐसा कोई byte signature नहीं होता जो shell script की शुरुआत को चिह्नित करे।

अतिरिक्त स्पेस: गलत पाथ कैसे डिलीट हुआ

लगभग हर rm -rf दुर्घटना एक शेल समस्या होती है। rm को पाथ की एक सूची मिलती है और यह एक-एक करके सबको हटा देता है। इसे कभी पता नहीं चलता कि आपका इरादा क्या था।

सबसे आम समस्या एक सिंगल स्पेस है:

rm -rf /home/deploy/app /old
rm -rf /home/deploy/app/old

पहली लाइन दो आर्गुमेंट्स है। यह पहले application को डिलीट करता है, फिर यह /old को डिलीट करता है। यदि /old मौजूद नहीं है, तो rm कुछ भी प्रिंट नहीं करता है, क्योंकि -f गायब फाइल की त्रुटि को दबा देता है। चुप्पी का मतलब पुष्टि नहीं है।

दूसरा रूप एक अनकोटेड वेरिएबल है जिसमें स्पेस होता है:

dir="/srv/my app"
rm -rf $dir

शेल वैल्यू को व्हाइटस्पेस पर विभाजित करता है, इसलिए rm को /srv/my और app दो अलग-अलग पाथ के रूप में मिलते हैं। rm -rf "$dir" के रूप में लिखे जाने पर यह एक ही पाथ होता है।

तीसरा एक खाली वेरिएबल है, जो आमतौर पर इसलिए होता है क्योंकि जिस कमांड को इसे भरना चाहिए था, वह विफल हो गया:

rm -rf "$TARGET"/*

TARGET के अनसेट होने पर, वह rm -rf /* में विस्तारित हो जाता है। GNU rm इस खाली रूप को स्वीकार करने से इनकार कर देता है: rm -rf /, rm: it is dangerous to operate recursively on '/' प्रिंट करता है और रुक जाता है। ग्लोब फॉर्म को ऐसी कोई सुरक्षा नहीं मिलती, क्योंकि शेल rm के चलने से पहले ही /* को वास्तविक टॉप-लेवल पाथ की सूची से बदल देता है, और / उनमें से एक नहीं है, इसलिए सुरक्षा गार्ड कभी सक्रिय नहीं होता।

ऐसी आदतें जो अगली गलती को रोकती हैं

• उपयोग किए गए प्रत्येक variable को path के रूप में quote करें। हर बार "$dir" लिखें, जिसमें tests और loops के अंदर का उपयोग भी शामिल है।
• खाली होने पर विफल हो जाएं। जब भी TARGET unset या खाली हो, तो rm -rf "${TARGET:?TARGET is not set}"/* शेल को आपके संदेश के साथ रोक देता है, इससे पहले कि rm शुरू हो। किसी भी ऐसी script के शीर्ष पर set -euo pipefail रखें जो delete करती है।
• --one-file-system जोड़ें। यह rm को निर्देश देता है कि वह आपके द्वारा दिए गए argument से अलग filesystem पर स्थित किसी भी directory को छोड़ दे, ताकि recursive delete किसी mounted backup volume या bind mount में न चला जाए।
• root के रूप में delete न करें। एक service account केवल उसी को नष्ट कर सकता है जिसका वह स्वामी है, जो प्रत्येक service को उसके अपने unprivileged user के रूप में चलाने का मुख्य तर्क है। यदि आप सुनिश्चित नहीं हैं कि कोई विशेष account कहाँ तक पहुँच सकता है, तो ls listing में permission bits को पढ़ना एक ही command में इसका उत्तर दे देता है।
• कार्य करने से पहले सूची प्रिंट करें। एक script में, paths बनाएँ, उन्हें printf '%s\n' करें, output पढ़ें, और फिर दूसरे pass में delete करें।
• एक trash command को पहुँच में रखें। sudo apt install trash-cli आपको trash-put, trash-list, trash-restore और trash-empty प्रदान करता है। Deleted files ~/.local/share/Trash में चली जाती हैं, और trash-empty 30 तीस दिन से पुरानी किसी भी चीज़ को हटा देता है।

rm को trash-put पर alias करना अगला स्पष्ट कदम लग सकता है, लेकिन यह एक जाल है। यह alias एक ऐसी आदत डालता है जो अगले सर्वर पर विफल हो जाती है जहाँ यह मौजूद नहीं है, और aliases scripts के अंदर लागू नहीं होते, जहाँ सबसे महंगी गलतियाँ होती हैं। जानबूझकर trash-put टाइप करें।

एकमात्र रिकवरी जो हर बार काम करती है

ऊपर बताई गई हर चीज़ केवल एक संभावना है। बैकअप कोई संभावना नहीं है।

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

restic के साथ, रिस्टोर करना केवल दो commands का काम है।

restic -r /srv/restic-repo snapshots
restic -r /srv/restic-repo restore latest --target /mnt/rescue --include /srv/appdata

लाइव पाथ पर ओवरराइट करने के बजाय एक खाली डायरेक्टरी में रिस्टोर करें, ताकि कुछ भी अपनी जगह बदलने से पहले आप दोनों की तुलना कर सकें। VPS पर restic बैकअप सेटअप करना रिपॉजिटरी सेटअप और इसे चलाने वाले systemd टाइमर को कवर करता है।

Borg के साथ:

borg list /srv/borg-repo
borg extract /srv/borg-repo::daily-2026-08-08 srv/appdata

Borg आर्काइव के अंदर के पाथ बिना लीडिंग स्लैश के स्टोर किए जाते हैं, इसलिए srv/appdata मैच करता है और /srv/appdata कुछ भी मैच नहीं करता। borg extract वर्तमान वर्किंग डायरेक्टरी में लिखता है, इसलिए पहले cd को एक स्क्रैच डायरेक्टरी में करें।

यदि आपने अभी तक दोनों के बीच चुनाव नहीं किया है, तो restic और Borg की तुलना डिडुप्लीकेशन और append-only रिपॉजिटरी को कवर करती है। यह वह विशेषता है जो एक compromised सर्वर को अपना बैकअप इतिहास मिटाने से रोकती है। कोई भी टूल ठीक है। गलत उत्तर यह है कि इनमें से कोई भी न चल रहा हो।

नया सर्वर इसे सेटअप करने का सबसे सस्ता समय है, इससे पहले कि उस पर कुछ भी ऐसा हो जिसे खोना नुकसानदेह हो। नए VPS पर पहले दस मिनट वह जगह है जहाँ यह काम होना चाहिए, SSH और फायरवॉल सेटअप के साथ।

फिर अपने कैलेंडर में एक आवर्ती एंट्री डालें: हर महीने रिपॉजिटरी से एक डायरेक्टरी को /tmp में रिस्टोर करें और फाइलों को पढ़ें। वह एक आदत इस पेज पर मौजूद हर टूल से अधिक मूल्यवान है।

FAQ

क्या मैं ext4 पर डिलीट की गई फाइल को रिकवर कर सकता हूँ?

आमतौर पर नहीं। जब किसी फाइल का अंतिम लिंक हट जाता है, तो ext4 inode से extent tree को साफ कर देता है, इसलिए डिस्क पर कहीं भी यह रिकॉर्ड नहीं रहता कि डेटा कहाँ था। extundelete और ext4magic उस inode की पुरानी कॉपी के लिए ext4 journal को सर्च करते हैं, जो केवल तभी मददगार होता है जब डिलीट की प्रक्रिया कुछ मिनट पहले हुई हो और तब से फाइलसिस्टम शांत रहा हो। इनमें से कोई भी प्रोजेक्ट सक्रिय रूप से मेंटेन नहीं किया जा रहा है। किसी भी टूल को unmounted डिवाइस या डिस्क इमेज पर चलाएं, कभी भी mounted फाइलसिस्टम पर नहीं, और सबसे पहले sudo dumpe2fs -h /dev/vdb1 | grep -i journal का उपयोग करके यह जांच लें कि आप किस पर काम कर रहे हैं।

एक सर्विस ने अभी भी डिलीट की गई फाइल को ओपन रखा है। क्या मैं इसे वापस पा सकता हूँ?

हाँ, और यह सबसे अच्छी स्थिति है। जब तक कोई प्रोसेस फाइल को ओपन रखती है, उसका inode और डेटा ब्लॉक्स आवंटित रहते हैं, इसलिए डेटा अभी भी पढ़ने योग्य होता है। सर्विस को रीस्टार्ट न करें, क्योंकि अंतिम डिस्क्रिप्टर को बंद करने से डिलीट की प्रक्रिया पूरी हो जाती है। 0 लिंक काउंट वाली ओपन फाइलों को लिस्ट करने के लिए sudo lsof +L1 चलाएं, PID और फाइल डिस्क्रिप्टर नंबर नोट करें, फिर sudo cp /proc/1234/fd/3 /mnt/rescue/events.log के साथ /proc के माध्यम से कॉपी करें। कॉपी को किसी अलग फाइलसिस्टम पर लिखें। जो एंट्रीज डिस्क्रिप्टर नंबर के बजाय mem के साथ दिखाई देती हैं, वे मेमोरी मैप्ड होती हैं और कॉपी करने के लिए उनका कोई /proc/<pid>/fd पाथ नहीं होता है।

मुझे रिकवरी टूल को डिस्क पर चलाने के बजाय उसकी इमेज क्यों बनानी चाहिए?

क्योंकि हर टूल को अपना आउटपुट कहीं न कहीं लिखना पड़ता है, और जिस फाइलसिस्टम को आप रिकवर कर रहे हैं उस पर राइट करने से डेटा उन फ्री ब्लॉक्स पर ओवरराइट हो सकता है जिनमें अभी भी आपका डेटा मौजूद है। पहले sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map के साथ पार्टीशन को किसी अलग डिवाइस पर कॉपी करें, फिर photorec को इमेज फाइल पर पॉइंट करें। इमेज आपको बाद में उसी बाइट्स पर दूसरा टूल आज़माने की सुविधा भी देती है, जो मूल डिस्क पर कुछ भी लिखे जाने के बाद असंभव हो जाता है।

क्या rm -rf / अभी भी Linux सिस्टम को नष्ट कर देता है?

सिर्फ यह कमांड ऐसा नहीं करता है। GNU rm इसे अस्वीकार कर देता है और rm: it is dangerous to operate recursively on '/' प्रिंट करता है। खतरनाक रूप वे हैं जो किसी अन्य रास्ते से आते हैं। TARGET के unset होने पर rm -rf "$TARGET"/* का विस्तार rm -rf /* के रूप में होता है, और शेल rm को टॉप-लेवल डायरेक्टरीज की एक लिस्ट देता है, जिनमें से कोई भी / नहीं है, इसलिए सुरक्षा गार्ड कभी ट्रिगर नहीं होता। इसके बजाय "${TARGET:?TARGET is not set}" लिखें और rm के चलने से पहले शेल रुक जाएगा।

क्या फाइलसिस्टम स्नैपशॉट एक बैकअप है?

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