rm -rf ने हटवलेल्या फाइल्स कशा परत मिळवाव्यात

पहिल्या साठ सेकंदांत काय करावे

rm -rf ने हटवलेल्या फाइल्स परत मिळतील की नाही, हे दोन गोष्टी ठरवतात. या दोन्ही गोष्टी search engine उघडण्यापूर्वी कराव्या लागतात. त्या filesystem वर लिहिणे थांबवा. त्यानंतर तो वापरातून काढा. यासाठी तो unmount करा किंवा read-only म्हणून remount करा.

rm काहीही erase करत नाही. ते आधी directory entry काढते. त्यानंतर inode आणि फाइलचे data blocks free म्हणून चिन्हांकित करते. Bytes अजूनही device वर असतात. Block allocator ते blocks दुसऱ्या कामासाठी देतो आणि त्या ठिकाणी नवीन data लिहिला जातो, तोपर्यंत ते तिथेच राहतात. Filesystem mounted आणि busy असलेल्या प्रत्येक सेकंदाला एखादा daemon log line लिहितो किंवा database एखादे page flush करते. यापैकी कोणतेही write तुम्हाला परत हवे असलेल्या blocks वर होऊ शकते.

म्हणून सुरुवातीच्या commands या writes थांबवणाऱ्या असाव्यात. त्या files recover करणाऱ्या commands नसाव्यात.

sudo systemctl stop nginx postgresql
sudo umount /mnt/data

जर umount चे उत्तर umount: /mnt/data: target is busy. असेल, तर filesystem open ठेवणारी गोष्ट शोधा.

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

तो मोकळा करता येत नसेल, तर त्याऐवजी read-only म्हणून remount करा. Read-only mount मुळे नवीन allocations थांबतात. तुम्हाला आवश्यक असलेले बहुतेक नियंत्रण यामुळे मिळते.

sudo mount -o remount,ro /mnt/data

हटवलेला path root filesystem वर असेल, तर हे अधिक कठीण असते. sudo mount -o remount,ro / साधारणपणे mount: /: cannot remount /dev/vda1 read-only. सह fail होईल, कारण running processes files writing साठी open ठेवतात आणि kernel त्यांना जबरदस्तीने बंद करणार नाही. VPS वर व्यावहारिक उपाय म्हणजे provider चा rescue किंवा recovery mode वापरणे. हा mode तुमचा disk जोडलेला, पण mounted नसलेला स्वतंत्र live system boot करतो. त्यानंतर खालील प्रत्येक command अशा device वर चालतो, ज्यावर कोणीही write करत नाही.

या संपूर्ण guide साठी एक नियम लागू आहे. Recover केलेल्या files, disk image किंवा नव्याने installed tool यापैकी काहीही ज्या filesystem मधून recovery करत आहात, त्यावर लिहू नका. दुसरा volume जोडा किंवा output SSH द्वारे दुसऱ्या machine वर पाठवा.

ext4 वर rm -rf नंतर पुनर्प्राप्ती बहुतेक वेळा अशक्य का असते

काहीही install करण्यापूर्वी अपेक्षा वास्तववादी ठेवा. तुम्ही कोणती filesystem वापरत आहात ते निश्चित करा:

lsblk -f

जवळजवळ प्रत्येक VPS image मध्ये default असलेल्या ext4 वर, फाइलमधील data location तिच्या inode मध्ये extent tree म्हणून साठवलेले असते. Extent म्हणजे एक record असतो. त्यात या फाइलचा logical block N, physical block M पासून सुरू होतो आणि L blocks पर्यंत चालतो असे नमूद केलेले असते. लहान फाइल्समध्ये असे जास्तीत जास्त चार records inode मध्येच साठतात. मोठ्या फाइल्समध्ये उर्वरित tree असलेल्या अतिरिक्त blocks कडे निर्देश केले जातात.

फाइलची शेवटची link काढली गेल्यावर ext4 त्या tree मधून जाते, प्रत्येक extent block allocator कडे परत करते आणि inode मधील tree साफ करते. त्यानंतर inode free म्हणून चिन्हांकित केला जातो आणि त्यावर deletion time नोंदवली जाते. Data स्वतः बदलले जात नाही. मात्र तो data कुठे होता याची एकमेव नोंद नष्ट झालेली असते.

हा ext3 पेक्षा महत्त्वाचा फरक आहे. ext3 मध्ये deleted inode मध्ये `ext3grep` सारख्या tool ला पुढे जाण्यासाठी पुरेशी माहिती शिल्लक राहत असे. ext4 वर deleted inodes ची यादी अजूनही पाहता येते:

sudo debugfs -R lsdel /dev/vdb1

तुम्ही -w पास न केल्यास debugfs device read-only पद्धतीने उघडते. त्यामुळे unmounted device वर हे सुरक्षित असते आणि प्रयत्न करण्यासाठी कोणताही खर्च येत नाही. Inodes ची यादी दिसेल. मात्र एखादा inode dump करण्याच्या टप्प्यावर प्रक्रिया थांबते. त्या inode मध्ये असलेला block map साफ झालेला असतो. त्यामुळे dump कडे पुढे जाण्यासाठी काहीही उरत नाही.

Journal वाचून या समस्येवर मात करण्याचा प्रयत्न करणारी दोन tools आहेत. Crash नंतर metadata सुसंगत ठेवण्यासाठी ext4 वापरत असलेला journal हा ठरावीक आकाराचा ring असतो. Delete करण्यापूर्वीची inode ची जुनी प्रत त्यात अजूनही असू शकते. extundelete आणि ext4magic दोन्ही त्यात शोध घेतात. तुम्ही कोणत्या आकारासोबत काम करत आहात ते तपासा:

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

Journal मध्ये फक्त metadata असते आणि त्याचा आकार लहान असतो. त्यामुळे नेहमीची write activity त्यातील जुनी माहिती लवकरच फिरवून टाकते. चालू server वर delete करण्यापूर्वीची inode अजून उपलब्ध असण्याचा कालावधी काही मिनिटांचा असतो. यापैकी कोणतेही tool सक्रियपणे maintain केले जात नाही. तसेच प्रत्येक distribution मध्ये त्यांचे package उपलब्ध असेलच असे नाही. दोन्ही tools कडून फारशी अपेक्षा ठेवू नका. ते unmounted device वर किंवा disk image वर चालवा. काहीही output मिळाले नाही तरी आश्चर्य वाटू देऊ नका.

lsblk -f ने xfs दाखवले, तरी परिस्थिती सुधारत नाही. XFS साठीही supported undelete उपलब्ध नाही. खालील पर्यायांचा क्रम बदलल्याने परिणाम बदलत नाही.

चालू प्रक्रियेमध्ये ही फाइल अजूनही उघडी आहे का?

या पृष्ठावरील ही एकमेव पुनर्प्राप्ती पद्धत आहे जिचे यशस्वी होण्याची शक्यता चांगली आहे. त्यामुळे ही फाइल वापरणारी सेवा restart करू नका.

दोन संख्या शून्यावर गेल्यावरच फाइल खरोखरच हटते: तिच्या inode कडे निर्देश करणाऱ्या directory entries ची संख्या आणि उघडलेल्या file descriptors ची संख्या. rm पहिली संख्या शून्यावर आणते. एखाद्या प्रक्रियेकडे फाइल अजूनही उघडी असल्यास दुसरी संख्या शून्य नसते. त्यामुळे inode आणि त्याचे blocks अजूनही allocated असतात आणि डेटा अजूनही वाचता येतो.

ज्यांचा link count शून्यावर आला आहे अशा उघड्या फाइल शोधा:

sudo lsof +L1

+L1 म्हणजे link count 1 पेक्षा कमी असलेल्या उघड्या फाइलची यादी करा. प्रत्येक match मध्ये प्रक्रिया, file descriptor number, NLINK of 0 आणि (deleted) ने समाप्त होणारा path दिसतो. PID आणि descriptor number घेऊन /proc करा:

sudo ls -l /proc/1234/fd

एखादी entry 3 -> /var/log/app/events.log (deleted) सारखी दिसते. त्या link द्वारे अजूनही डेटा उपलब्ध आहे. तो वेगळ्या filesystem वर कॉपी करा:

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

cp वापरा, mv नाही. /proc/1234/fd/3 उघडल्यावर त्याच inode साठी offset zero पासून नवीन handle मिळतो. त्यामुळे writer च्या सध्याच्या position नंतरचा भाग नव्हे, तर संपूर्ण फाइल मिळते.

दोन मर्यादा लक्षात ठेवा. अशा प्रकारे हटवलेला directory tree परत मिळत नाही, कारण प्रक्रियेने उघडलेल्या individual files एवढ्याच अजूनही उपलब्ध असतात. तसेच engine लिहीत असताना कॉपी केलेली database file ही crash-consistent copy असते. त्यामुळे ती clean समजण्याऐवजी त्यावर engine ची स्वतःची recovery चालवण्याची योजना करा. lsof ज्या entries मध्ये descriptor number ऐवजी mem दाखवते त्या memory mapped असतात. त्यांच्याकडून कॉपी करण्यासाठी कोणतीही /proc/<pid>/fd entry उपलब्ध नसते.

btrfs, ZFS किंवा LVM वर snapshot आहे का?

Filesystem snapshots घेत असेल, तर हटवलेल्या फाइल्स त्यापैकी एखाद्या snapshot मध्ये बदल न होता अजूनही उपलब्ध असतात. हे फक्त delete करण्यापूर्वी snapshot अस्तित्वात असेल तरच उपयोगी ठरते. तुम्ही आता तयार केलेली कोणतीही गोष्ट मागील स्थिती परत मिळवू शकत नाही.

btrfs snapshots subvolume म्हणून ठेवते:

sudo btrfs subvolume list /

snapshot मधील आवश्यक paths पाहा आणि cp -a वापरून त्या बाहेर copy करा. संपूर्ण subvolume rollback करण्याऐवजी एकेक path 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 पेक्षा नवीन प्रत्येक snapshot नष्ट करते. त्यामुळे ते शेवटचा उपाय म्हणूनच वापरा.

LVM snapshots या निश्चित आकाराच्या copy-on-write volumes असतात:

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

ते read-only म्हणून mount करा आणि डेटा बाहेर copy करा. त्यावर विश्वास ठेवण्यापूर्वी lvs तपासा, कारण allocated space पूर्ण भरल्यास kernel LVM snapshot invalid करते. असे झाल्यानंतर त्यातील contents नष्ट होतात.

Snapshot म्हणजे backup नाही. ते मूळ डेटाप्रमाणेच त्याच disk किंवा त्याच pool वर असते. त्यामुळे मूळ डेटावर परिणाम करणाऱ्या प्रत्येक failure चा परिणाम snapshot वरही होतो. दोन मिनिटांपूर्वी झालेली चूक पूर्ववत करण्यासाठी snapshot अत्यंत उपयुक्त आहे. नेमके हेच येथे आवश्यक आहे.

PhotoRec वापरून carving करा, live disk वर कधीही नाही

वरीलपैकी काहीही लागू होत नसेल, तर carving हा उरलेला पर्याय आहे. यात raw device वर ज्ञात file type ची सुरुवात दर्शवणारे byte patterns शोधले जातात आणि त्यानंतरचा उपलब्ध डेटा लिहून काढला जातो. Carving फक्त file data वाचते. Filenames, directory structure, timestamps आणि ownership हे सर्व filesystem metadata असतात. rm ने हे metadata नष्ट केले आहे. त्यामुळे यापैकी काहीही परत मिळत नाही. numbered output directory मध्ये f0384512.jpg नावाच्या files मिळतात. त्या तुम्हाला manually वर्गीकृत कराव्या लागतात.

हे कार्य करेल की नाही, हे दोन नियम ठरवतात.

पहिले, device वर इतर कोणतेही operation करण्यापूर्वी त्याची image तयार करा. Debian आणि Ubuntu वर package चे नाव gddrescue आहे आणि त्यातून install होणाऱ्या 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 वेगळ्या device वर असणे आवश्यक आहे. त्या device वर partition च्या आकाराएवढी किंवा त्याहून अधिक मोकळी जागा असावी. lsblk -b अचूक sizes bytes मध्ये दाखवते. Map file मुळे copy मध्ये व्यत्यय आल्यास ती पुन्हा सुरुवातीपासून करावी लागत नाही. Image तयार झाल्यावर त्याच bytes वर दुसरे tool वापरून पुन्हा प्रयत्न करता येतो. पहिले tool disk वरच लिहित असेल, तर हे शक्य होत नाही.

दुसरे, recovery tool ला image file द्या.

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

photorec text menu उघडते. Partition, त्यानंतर filesystem type, मग शोधायचे file signatures आणि शेवटी destination directory निवडा. सुरुवात करण्यापूर्वी signature list तुम्ही प्रत्यक्षात गमावलेल्या file types पुरती मर्यादित करा. Default list सर्वकाही शोधते आणि तपासण्यासाठी हजारो fragments देते.

याच package मधील testdisk मध्ये स्वतंत्र undelete function आहे. ते फक्त FAT, exFAT, NTFS आणि ext2 साठी काम करते. ext4 साठी यामुळे photorec उरते.

Fragmented files तुटलेल्या स्वरूपात परत मिळण्याची शक्यता गृहीत धरा. Carving मध्ये file चे blocks सलग आहेत असे मानले जाते. त्यामुळे allocator ने disk वर वेगवेगळ्या ठिकाणी विभागलेली file चुकीच्या पद्धतीने पुन्हा जोडली जाऊ शकते किंवा पूर्णपणे वगळली जाऊ शकते. Media files मध्ये मजबूत headers असल्यामुळे त्या तुलनेने चांगल्या प्रकारे recover होतात. Plain text, configuration आणि source code मात्र खराब पद्धतीने recover होतात, कारण shell script ची सुरुवात दर्शवणारा कोणताही byte signature नसतो.

एक अनावश्यक space: चुकीचा path कसा delete झाला

जवळपास प्रत्येक rm -rf अपघात हा shell मधील समस्येमुळे होतो. rm ला paths ची यादी मिळते आणि तो प्रत्येक path एकामागोमाग delete करतो. तुम्हाला नेमके काय अभिप्रेत होते हे त्याला माहीत नसते.

सर्वात सामान्य प्रकार म्हणजे एकच space:

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

पहिल्या ओळीत दोन arguments आहेत. ती application delete करते आणि त्यानंतर /old delete करते. /old अस्तित्वात नसेल, तर rm काहीही output देत नाही, कारण -f missing-file error दडवतो. शांतता म्हणजे यशाची पुष्टी नाही.

दुसरा प्रकार म्हणजे space असलेला, पण quotes न केलेला variable:

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

shell value मधील whitespace नुसार ती विभागतो. त्यामुळे rm ला /srv/my आणि app हे दोन स्वतंत्र paths मिळतात. rm -rf "$dir" म्हणून लिहिल्यास तो एकच path असतो.

तिसरा प्रकार म्हणजे रिकामा variable. साधारणपणे तो भरणारी command fail झाल्यामुळे असे होते:

rm -rf "$TARGET"/*

TARGET unset असल्यास त्याचा विस्तार rm -rf /* असा होतो. GNU rm हा रिकामा प्रकार स्वीकारत नाही: rm -rf / rm: it is dangerous to operate recursively on '/' print करून थांबतो. glob प्रकाराला अशी सुरक्षा मिळत नाही, कारण rm चालण्यापूर्वीच shell /* चे रूपांतर प्रत्यक्ष top-level paths च्या यादीत करते. / त्या यादीत नसल्यामुळे guard कधीच कार्यान्वित होत नाही.

पुढील समस्या टाळणाऱ्या सवयी

• Path म्हणून वापरल्या जाणाऱ्या प्रत्येक variable भोवती quotes वापरा. Tests आणि loops मध्येही प्रत्येक वेळी "$dir" लिहा.
• रिकाम्या मूल्यावर प्रक्रिया थांबवा. rm -rf "${TARGET:?TARGET is not set}"/* मुळे TARGET unset किंवा रिक्त असल्यास rm सुरू होण्यापूर्वी shell तुमच्या संदेशासह थांबतो. कोणत्याही गोष्टी delete करणाऱ्या script च्या सुरुवातीला set -euo pipefail ठेवा.
• --one-file-system जोडा. तुम्ही दिलेल्या argument पेक्षा वेगळ्या filesystem वर असलेली कोणतीही directory वगळण्यास ते rm ला सांगते. त्यामुळे recursive delete mounted backup volume किंवा bind mount मध्ये जाऊ शकत नाही.
• root म्हणून delete करू नका. Service account फक्त त्याच्या मालकीच्या गोष्टी delete करू शकतो. प्रत्येक service स्वतःच्या unprivileged user म्हणून चालवण्यामागील हा मुख्य हेतू आहे. एखाद्या account ला कोणत्या गोष्टींवर प्रवेश आहे याची खात्री नसल्यास, ls listing मधील permission bits वाचणे एका command मध्ये उत्तर देते.
• कृती करण्यापूर्वी list print करा. Script मध्ये paths तयार करा, printf '%s\n' करा, output वाचा आणि त्यानंतर दुसऱ्या pass मध्ये delete करा.
• trash command सहज उपलब्ध ठेवा. sudo apt install trash-cli तुम्हाला trash-put, trash-list, trash-restore आणि trash-empty देते. Delete केलेल्या files ~/.local/share/Trash मध्ये हलवल्या जातात आणि trash-empty 30 तीस दिवसांपेक्षा जुन्या सर्व गोष्टी clear करते.

rm ला trash-put चे alias करणे हा पुढचा स्वाभाविक टप्पा वाटतो, पण ती एक चूक आहे. ज्या पुढील server वर ते alias उपलब्ध नसेल, तेथे ही सवय अपयशी ठरते. तसेच aliases scripts मध्ये लागू होत नाहीत आणि महागड्या चुका प्रामुख्याने scripts मध्ये होतात. त्याऐवजी trash-put जाणीवपूर्वक type करा.

प्रत्येक वेळी कार्य करणारी एकमेव पुनर्प्राप्ती

वरील सर्व उपाय हे केवळ शक्यता आहेत. Backup ही शक्यता नाही.

Backup खरोखर उपयुक्त ठरण्यासाठी दोन गोष्टी आवश्यक आहेत. तो तुमच्या लक्षात ठेवण्याची गरज न पडता ठरलेल्या वेळापत्रकानुसार चालला पाहिजे. तसेच, त्यातून तुम्ही किमान एकदा restore केलेले असले पाहिजे. ज्यातून आजपर्यंत कोणीही restore केलेले नाही, असे repository म्हणजे केवळ एक विश्वास आहे. Include list मधील चुकीचा path किंवा कोणीही लिहून न ठेवलेला repository password यांसारख्या त्रुटी backup निरुपयोगी करतात. त्या त्रुटी तुम्हाला backup ची गरज भासेल त्या दिवशीच समोर येतात.

restic वापरल्यास restore करण्यासाठी दोन commands पुरेसे आहेत.

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

Live path वर restore करण्याऐवजी रिकाम्या directory मध्ये restore करा. त्यामुळे काहीही मूळ ठिकाणी हलवण्यापूर्वी दोन्हींची तुलना करता येते. VPS वर restic backups सेट करणे येथे repository setup आणि backup चालवणारा systemd timer समजावला आहे.

Borg वापरताना:

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

Borg archive मधील paths सुरुवातीचा slash वगळून साठवले जातात. त्यामुळे srv/appdata जुळते, तर /srv/appdata कशाशीही जुळत नाही. borg extract सध्याच्या working directory मध्ये लिहिते. त्यामुळे आधी cd scratch directory कडे वापरा.

तुम्ही restic आणि Borg यांपैकी अजून निवड केलेली नसेल, तर restic आणि Borg यांची तुलना deduplication आणि append-only repositories समजावते. Compromised server ला स्वतःचा backup history हटवता येऊ नये, यासाठी हा गुणधर्म महत्त्वाचा आहे. यांपैकी कोणतेही tool योग्य आहे. एकही tool चालू नसणे हे चुकीचे उत्तर आहे.

नवीन server उभारल्यानंतर हे setup करण्यासाठीचा काळ सर्वांत स्वस्त असतो. Server वर गमावण्यासारखे काही निर्माण होण्यापूर्वीच हे करा. SSH आणि firewall setup सोबत नवीन VPS वरील पहिली दहा मिनिटे येथे हे काम करायचे आहे.

त्यानंतर तुमच्या calendar मध्ये recurring entry तयार करा: दर महिन्याला repository मधून एक directory /tmp मध्ये restore करा आणि files वाचा. ही एक सवय या पृष्ठावरील प्रत्येक tool पेक्षा अधिक उपयुक्त आहे.

FAQ

ext4 वर हटवलेली फाइल परत मिळवता येते का?

सामान्यतः नाही. फाइलची शेवटची link नष्ट झाल्यावर ext4 inode मधील extent tree साफ करते. त्यामुळे डेटा डिस्कवर कुठे होता याची नोंद शिल्लक राहत नाही. extundelete आणि ext4magic ext4 journal मध्ये त्या inode ची जुनी प्रत शोधतात. हे फक्त delete काही मिनिटांपूर्वी झाले असेल आणि त्यानंतर filesystem वर कोणतीही हालचाल झाली नसेल, तरच उपयोगी ठरते. यापैकी कोणताही प्रकल्प सध्या सक्रियपणे maintain केला जात नाही. दोन्हीपैकी कोणतेही साधन unmounted device किंवा disk image वर चालवा. ते mounted filesystem वर कधीही चालवू नका. प्रथम sudo dumpe2fs -h /dev/vdb1 | grep -i journal वापरून तुम्ही कोणत्या device वर काम करत आहात ते तपासा.

एखाद्या सेवेकडे हटवलेली फाइल अजूनही open आहे. ती परत मिळवता येईल का?

होय. ही सर्वात चांगली परिस्थिती आहे. एखादी process फाइल open ठेवते तोपर्यंत तिचा inode आणि data blocks allocated राहतात. त्यामुळे डेटा अजूनही वाचता येतो. सेवा restart करू नका. शेवटचा descriptor बंद झाल्यावर delete प्रक्रिया पूर्ण होते. link count 0 असलेल्या open files ची यादी करण्यासाठी sudo lsof +L1 चालवा. PID आणि file descriptor number नोंदवा. त्यानंतर /proc आणि sudo cp /proc/1234/fd/3 /mnt/rescue/events.log वापरून डेटा copy करा. ही copy वेगळ्या filesystem वर लिहा. descriptor number ऐवजी mem दिसणाऱ्या entries memory mapped असतात. त्यांच्याकडून copy करण्यासाठी कोणताही /proc/<pid>/fd path उपलब्ध नसतो.

recovery tool थेट डिस्कवर चालवण्याऐवजी डिस्कची image का तयार करावी?

कारण प्रत्येक tool ला त्याचे output कुठेतरी लिहावे लागते. तुम्ही recover करत असलेल्या filesystem वर केलेली write अजून डेटा असलेल्या free blocks वर जाऊ शकते. प्रथम sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map वापरून partition वेगळ्या device वर copy करा. त्यानंतर image file कडे photorec निर्देशित करा. नंतर त्याच bytes वर दुसरे tool वापरून पाहणेही image मुळे शक्य होते. मूळ डिस्कवर काहीतरी overwrite झाल्यावर हे शक्य नसते.

rm -rf / मुळे Linux system अजूनही पूर्णपणे नष्ट होते का?

मूळ command मुळे तसे होत नाही. GNU rm ते नाकारते आणि rm: it is dangerous to operate recursively on '/' प्रदर्शित करते. धोकादायक command structure दुसऱ्या मार्गाने तयार होतात. rm -rf "$TARGET"/* मध्ये TARGET unset असल्यास ते rm -rf /* मध्ये expand होते. त्यानंतर shell rm कडे प्रत्यक्ष top-level directories ची यादी पाठवते. त्या यादीत / नसते. त्यामुळे guard लागू होत नाही. त्याऐवजी "${TARGET:?TARGET is not set}" लिहा. त्यामुळे rm चालण्यापूर्वी shell थांबते.

filesystem snapshot हा backup असतो का?

नाही. btrfs किंवा ZFS snapshot ज्या डेटाचे संरक्षण करतो त्याच pool वर असतो. त्यामुळे disk निकामी झाल्यास किंवा pool नष्ट झाल्यास दोन्ही एकाच वेळी गमावले जातात. LVM snapshot मध्ये fixed size ची अतिरिक्त अडचण असते. तो भरल्यावर kernel त्याला invalid करते आणि त्यातील contents नष्ट होतात. दोन मिनिटांपूर्वी झालेला delete पूर्ववत करण्यासाठी snapshots अत्यंत उपयुक्त आहेत. इतर सर्व बाबींसाठी वेगळ्या hardware वर repository ठेवा.