rm -rf తో తొలగించిన ఫైళ్లను ఎలా తిరిగి పొందాలి

మొదటి అరవై సెకన్లలో చేయాల్సిన పని

rm -rf తో తొలగించిన ఫైళ్లను తిరిగి పొందగలరా లేదా అన్నది రెండు విషయాలు నిర్ణయిస్తాయి. ఈ రెండూ మీరు search engine తెరవకముందే చేయాలి. ఆ filesystem కు రాయడం ఆపండి. తరువాత దాన్ని వినియోగం నుంచి తొలగించండి. ఇందుకోసం దాన్ని unmount చేయండి లేదా read-only గా remount చేయండి.

rm ఏదీ చెరపదు. అది directory entry ను తొలగించి, inode మరియు file data blocks ను free గా గుర్తిస్తుంది. ఆ bytes ఇప్పటికీ device పై ఉంటాయి. Block allocator ఆ blocks ను మరొకదానికి కేటాయించి, ఆ కొత్త డేటాను వాటిపై రాసే వరకు అవి అక్కడే ఉంటాయి. Filesystem mounted గా మరియు busy గా ఉన్న ప్రతి సెకనులో daemon ఒక log line రాయవచ్చు లేదా database ఒక page ను flush చేయవచ్చు. ఆ writes లో ఏదైనా మీరు తిరిగి పొందాలనుకునే blocks పై పడవచ్చు.

కాబట్టి మొదట file recovery commands కాకుండా writes ను ఆపే 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 పై ఉంటే పరిస్థితి కష్టంగా ఉంటుంది. నడుస్తున్న processes files ను writing కోసం open గా ఉంచుతాయి. అందువల్ల sudo mount -o remount,ro / సాధారణంగా mount: /: cannot remount /dev/vda1 read-only. తో విఫలమవుతుంది; kernel వాటిని బలవంతంగా close చేయదు. VPS లో ఆచరణాత్మక పరిష్కారం provider అందించే rescue లేదా recovery mode. ఇది మీ disk ను జతచేసి, mount చేయకుండా ఒక ప్రత్యేక live system ను boot చేస్తుంది. ఆ తరువాతి ప్రతి command ను ఎవరూ రాయకుండా ఉన్న device పై అమలు చేయవచ్చు.

ఈ guide మొత్తానికి ఒక నియమం వర్తిస్తుంది. మీరు recovery చేస్తున్న filesystem పై recovered files, disk image లేదా కొత్తగా install చేసిన tool ను ఎప్పుడూ రాయకండి. రెండవ volume ను జతచేయండి లేదా SSH ద్వారా output ను మరొక machine కు పంపండి.

ext4లో rm -rf తర్వాత రికవరీ సాధారణంగా ఎందుకు దాదాపు అసాధ్యం

ఏదైనా ఇన్‌స్టాల్ చేయడానికి ముందు మీ అంచనాలను వాస్తవికంగా ఉంచండి. మీరు ఉపయోగిస్తున్న filesystem ఏదో నిర్ధారించండి:

lsblk -f

దాదాపు ప్రతి VPS imageలో defaultగా ఉండే ext4లో, ఫైల్ డేటా ఎక్కడ ఉందో inodeలో extent treeగా నిల్వ ఉంటుంది. extent అనేది ఈ ఫైల్‌కు చెందిన logical block N, physical block M వద్ద ప్రారంభమై L blocks వరకు కొనసాగుతుందని తెలిపే ఒక record. చిన్న ఫైళ్లు ఈ recordsలో గరిష్ఠంగా నాలుగింటిని inodeలోనే ఉంచుతాయి. పెద్ద ఫైళ్లు మిగిలిన tree ఉన్న అదనపు blocksను సూచిస్తాయి.

ఫైల్‌కు ఉన్న చివరి link తొలగినప్పుడు, ext4 ఆ treeను పరిశీలించి ప్రతి extentను block allocatorకు తిరిగి అప్పగిస్తుంది. తరువాత inodeలోని treeను clear చేస్తుంది. ఆ inodeను freeగా గుర్తించి deletion timeను నమోదు చేస్తుంది. డేటా మాత్రం అలాగే ఉంటుంది. ఆ డేటా ఎక్కడ ఉందో తెలిపే ఏకైక record మాత్రం తొలగిపోతుంది.

ఇదే ext3తో ఉన్న తేడా. ext3లో తొలగించిన inode, ext3grep వంటి tool దానిని అనుసరించడానికి అవసరమైన సమాచారాన్ని కొంతవరకు ఉంచేది. ext4లో తొలగించిన inodesను ఇప్పటికీ list చేయవచ్చు:

sudo debugfs -R lsdel /dev/vdb1

debugfs కు -w pass చేయకపోతే అది deviceను read-onlyగా open చేస్తుంది. అందువల్ల unmounted deviceపై ఇది సురక్షితం, ప్రయత్నించడానికి ఎలాంటి ఖర్చు ఉండదు. Inodes list అవుతాయి. అయితే వాటిలో ఒకదాన్ని dump చేయడం దగ్గరే ప్రక్రియ ఆగిపోతుంది. ఎందుకంటే ఆ inodeలో ఉండే block map clear అయిపోయింది; కాబట్టి dump అనుసరించడానికి ఏమీ ఉండదు.

Journalను చదవడం ద్వారా ఈ సమస్యను అధిగమించడానికి రెండు tools ప్రయత్నిస్తాయి. Journal అనేది fixed-size ring. Crash జరిగినప్పుడు metadata consistentగా ఉండేలా ext4 దీనిని ఉపయోగిస్తుంది. Deleteకు ముందు ఉన్న inode యొక్క పాత copy అందులో ఇంకా ఉండవచ్చు. extundelete మరియు ext4magic రెండూ journalలో search చేస్తాయి. మీరు ఉపయోగిస్తున్న journal sizeను పరిశీలించండి:

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

Journalలో metadata మాత్రమే ఉంటుంది, దాని పరిమాణం కూడా చిన్నదే. అందువల్ల సాధారణ write activity దానిలోని పాత సమాచారాన్ని త్వరగా overwrite చేస్తుంది. నడుస్తున్న serverలో deleteకు ముందు ఉన్న inode ఇంకా అందుబాటులో ఉండే వ్యవధి minutesలోనే ఉంటుంది. ఈ రెండు toolsలో ఏదీ actively maintained కాదు. ప్రతి distributionలోనూ ఇవి packagedగా ఉండవు. రెండింటినీ తక్కువ అవకాశమున్న ప్రయత్నాలుగా పరిగణించండి. వీటిని unmounted deviceపై లేదా disk imageపై అమలు చేయండి. ఇవి ఎలాంటి ఫలితమూ ఇవ్వకపోతే ఆశ్చర్యపడకండి.

lsblk -f, xfs అని report చేస్తే పరిస్థితి మెరుగ్గా ఉండదు. XFSకు కూడా supported undelete లేదు. దిగువ options క్రమాన్ని మార్చడం వల్ల ఫలితం మారదు.

నడుస్తున్న processలో ఆ file ఇంకా openగా ఉందా?

ఈ పేజీలో మంచి ఫలితాన్ని ఇచ్చే ఏకైక recovery విధానం ఇదే. ఆ fileను ఉపయోగిస్తున్న serviceను restart చేయకూడదనడానికి ఇదే కారణం.

ఒక file నిజంగా తొలగిపోవాలంటే రెండు counts సున్నాకు చేరాలి: దాని inodeను సూచించే directory entries సంఖ్య, మరియు open file descriptors సంఖ్య. rm మొదటి countను సున్నాకు చేరుస్తుంది. ఏదైనా process ఆ fileను ఇంకా openగా ఉంచితే రెండో count సున్నా కాదు. అందువల్ల inode మరియు దాని blocks ఇంకా allocatedగా ఉంటాయి. Dataను ఇంకా చదవవచ్చు.

Link count సున్నాకు తగ్గిన open filesను కనుగొనండి:

sudo lsof +L1

+L1 అంటే link count 1 కంటే తక్కువగా ఉన్న open filesను list చేయడం. ప్రతి matchలో process, file descriptor number, NLINK యొక్క 0, మరియు (deleted)తో ముగిసే path కనిపిస్తాయి. PID మరియు descriptor number తీసుకుని వాటిని /procకు ఇవ్వండి:

sudo ls -l /proc/1234/fd

ఒక entry ఇలా కనిపిస్తుంది: 3 -> /var/log/app/events.log (deleted). ఆ link ద్వారా dataను ఇంకా చేరుకోవచ్చు. దాన్ని వేరే filesystemకు copy చేయండి:

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

cpను ఉపయోగించండి, mvను కాదు. /proc/1234/fd/3ను open చేస్తే అదే inodeపై offset zero నుంచి కొత్త handle లభిస్తుంది. అందువల్ల writer ప్రస్తుత position తర్వాతి భాగం మాత్రమే కాకుండా మొత్తం file లభిస్తుంది.

తెలుసుకోవాల్సిన రెండు పరిమితులు ఉన్నాయి. తొలగించిన directory tree ఈ విధంగా తిరిగి రాదు, ఎందుకంటే process openగా ఉంచిన individual files మాత్రమే ఇంకా hold అవుతాయి. అలాగే engine write చేస్తున్న సమయంలో copy చేసిన database file crash-consistent copy మాత్రమే. కాబట్టి దాన్ని clean copyగా పరిగణించకుండా, engine స్వంత recoveryను దానిపై అమలు చేయడానికి ప్రణాళిక చేయండి. lsof చూపించే entriesలో descriptor number స్థానంలో mem కనిపిస్తే అవి memory mapped entries. వాటి నుంచి copy చేయడానికి /proc/<pid>/fd entry ఉండదు.

btrfs, ZFS లేదా LVMలో snapshot ఉందా?

ఫైల్‌సిస్టమ్ snapshots తీసుకుంటే, తొలగించిన ఫైళ్లు ఇప్పటికే ఒక snapshotలో మార్పులేకుండా ఉంటాయి. తొలగింపు జరగకముందే snapshot ఉండి ఉంటేనే ఇది సహాయపడుతుంది. ఇప్పుడు మీరు సృష్టించే ఏదీ గత స్థితిని తిరిగి పొందదు.

btrfs snapshots ను subvolumes గా ఉంచుతుంది:

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 కంటే కొత్తగా ఉన్న ప్రతి snapshotను కూడా తొలగిస్తుంది. అందువల్ల దీన్ని చివరి మార్గంగా మాత్రమే ఉపయోగించండి.

LVM snapshots స్థిర పరిమాణం కలిగిన copy-on-write volumes:

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

దాన్ని read-onlyగా mount చేసి, డేటాను బయటకు copy చేయండి. దానిపై నమ్మకం పెట్టుకునే ముందు lvs ను పరిశీలించండి. ఎందుకంటే కేటాయించిన స్థలం పూర్తిగా నిండితే kernel LVM snapshotను invalid చేస్తుంది. అది జరిగిన తర్వాత దాని contents పోతాయి.

Snapshot అనేది backup కాదు. అది original ఉన్న అదే disk లేదా అదే poolలో ఉంటుంది. అందువల్ల originalకు సంభవించే ప్రతి failure దానికీ సంభవించవచ్చు. రెండు నిమిషాల క్రితం చేసిన పొరపాటును రద్దు చేయడానికి ఇది చాలా ఉపయోగకరం. ఈ సందర్భంలో అదే దాని పని.

PhotoRecతో carving: live disk‌పై కాకుండా imageపై మాత్రమే

పై విధానాల్లో ఏదీ వర్తించకపోతే మిగిలేది carving మాత్రమే. ఇది raw deviceలో తెలిసిన file type ప్రారంభాన్ని సూచించే byte patterns కోసం scan చేసి, తరువాత కనిపించే డేటాను వేరుగా రాస్తుంది. Carving file dataను మాత్రమే చదువుతుంది. Filenames, directory structure, timestamps, ownership అన్నీ filesystem metadataకు చెందినవి. ఆ metadataనే rm నాశనం చేసింది కాబట్టి, వీటిలో ఏదీ తిరిగి రాదు. మీకు f0384512.jpg పేర్లతో files numbered output directoryలో లభిస్తాయి. వాటిని మీరు చేతితో వర్గీకరించాలి.

ఇది అసలు పనిచేస్తుందా లేదా అన్నది రెండు నియమాలపై ఆధారపడి ఉంటుంది.

మొదటిది, మరే ఇతర సాధనంతో deviceను access చేయకముందే దాని 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 ఖచ్చితమైన పరిమాణాలను bytesలో చూపిస్తుంది. Copy మధ్యలో ఆగిపోతే map file సహాయంతో మొదటి నుంచి కాకుండా అక్కడి నుంచే కొనసాగించవచ్చు. 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ని ఎంచుకోండి. ప్రారంభించే ముందు మీరు నిజంగా కోల్పోయిన file typesకే signature listను పరిమితం చేయండి. Default list అన్నింటినీ కనుగొంటుంది. దాంతో వడపోయేందుకు పదివేల fragments వస్తాయి.

అదే packageలోని testdisk కు ప్రత్యేక undelete function ఉంది. ఇది FAT, exFAT, NTFS మరియు ext2కు మాత్రమే మద్దతు ఇస్తుంది. ext4లో దీనివల్ల మిగిలేది photorec.

Fragmented files సరిగా తిరిగి రావని భావించండి. File blocks contiguousగా ఉంటాయని carving ఊహిస్తుంది. కాబట్టి allocator disk అంతటా విడగొట్టిన fileను తప్పుగా మళ్లీ కలపవచ్చు లేదా పూర్తిగా కనుగొనలేకపోవచ్చు. Media files సాధారణంగా బాగా recover అవుతాయి, ఎందుకంటే వాటికి స్పష్టమైన headers ఉంటాయి. Plain text, configuration మరియు source code files సరిగా carve కావు. Shell script ప్రారంభాన్ని సూచించే ప్రత్యేక byte signature వాటిలో ఉండదు.

తప్పిపోయిన ఖాళీ: తప్పు path ఎలా తొలగించబడింది

దాదాపు ప్రతి rm -rf ప్రమాదం shell సమస్య వల్లే జరుగుతుంది. rm paths జాబితాను స్వీకరించి, వాటిలో ప్రతి path ను వరుసగా తొలగిస్తుంది. మీరు ఉద్దేశించినది ఏమిటో దానికి తెలియదు.

సాధారణ కారణం ఒకే space:

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

మొదటి పంక్తిలో రెండు arguments ఉన్నాయి. అది application ను తొలగించిన తర్వాత /old ను తొలగిస్తుంది. /old లేకపోతే, rm ఎలాంటి output చూపదు, ఎందుకంటే -f కనిపించని file కు సంబంధించిన error ను suppress చేస్తుంది. మౌనం అంటే నిర్ధారణ కాదు.

రెండవ పరిస్థితి space కలిగిన, quote చేయని variable:

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

shell value ను whitespace వద్ద విభజిస్తుంది. అందువల్ల rm కు /srv/my మరియు app రెండు వేర్వేరు paths గా అందుతాయి. rm -rf "$dir" రూపంలో రాస్తే అది ఒకే path అవుతుంది.

మూడవ పరిస్థితి empty variable. సాధారణంగా దాన్ని నింపాల్సిన command విఫలమైనప్పుడు ఇలా జరుగుతుంది:

rm -rf "$TARGET"/*

TARGET unset గా ఉంటే, అది rm -rf /* గా expand అవుతుంది. GNU rm bare రూపాన్ని తిరస్కరిస్తుంది: rm -rf /, rm: it is dangerous to operate recursively on '/' ను చూపించి ఆగిపోతుంది. glob రూపానికి ఇలాంటి రక్షణ ఉండదు. ఎందుకంటే rm అమలు కావడానికి ముందే shell /* ను వాస్తవ top-level paths జాబితాతో భర్తీ చేస్తుంది. ఆ జాబితాలో / ఉండదు కాబట్టి guard అమలు కాదు.

తదుపరి ప్రమాదాన్ని నివారించే అలవాట్లు

• Path గా ఉపయోగించే ప్రతి variable ను quote చేయండి. Tests మరియు loops లో కూడా ప్రతిసారి "$dir" రాయండి.
• ఖాళీ విలువపై విఫలమయ్యేలా చేయండి. rm -rf "${TARGET:?TARGET is not set}"/* ద్వారా TARGET unset లేదా empty గా ఉన్నప్పుడు rm ప్రారంభమయ్యేలోపే shell మీ message తో ఆగుతుంది. ఏదైనా తొలగించే script పైభాగంలో set -euo pipefail ఉంచండి.
• --one-file-system జోడించండి. మీరు ఇచ్చిన argument కు భిన్నమైన filesystem పై ఉన్న ఏ directory నైనా దాటవేయమని ఇది rm కు చెబుతుంది. అందువల్ల recursive delete mounted backup volume లేదా bind mount లోకి ప్రవేశించదు.
• root గా delete చేయవద్దు. Service account దానికి చెందినవాటినే తొలగించగలదు. ప్రతి 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 అందిస్తుంది. Deleted files ~/.local/share/Trash కు తరలించబడతాయి. trash-empty 30 ద్వారా thirty days కంటే పాతవన్నీ తొలగించవచ్చు.

rm కు trash-put ను alias చేయడం తదుపరి సహజమైన చర్యలా అనిపించవచ్చు. కానీ అది ఒక trap. ఆ alias లేని తదుపరి server పై పనిచేయని అలవాటును alias పెంచుతుంది. అలాగే aliases scripts లో వర్తించవు. ఖరీదైన తప్పులు సాధారణంగా అక్కడే జరుగుతాయి. బదులుగా ఉద్దేశపూర్వకంగా trash-put టైప్ చేయండి.

ప్రతిసారీ పనిచేసే ఏకైక recovery విధానం

పైన చెప్పిన ప్రతిదీ ఒక అవకాశం మాత్రమే. Backup మాత్రం అవకాశం కాదు.

Backup నిజంగా ఉపయోగకరంగా ఉండాలంటే రెండు విషయాలు అవసరం. మీరు గుర్తు చేసుకోకపోయినా అది ఒక schedule ప్రకారం అమలు కావాలి. అలాగే దాని నుంచి కనీసం ఒక్కసారి restore చేసి ఉండాలి. ఎప్పుడూ restore చేయని repositoryపై ఆధారపడటం ఒక నమ్మకం మాత్రమే. దాన్ని పనికిరాకుండా చేసే సమస్యలు — include list లో తప్పు path లేదా ఎవరూ నమోదు చేయని repository password — 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 పోలిక deduplication మరియు append-only repositories గురించి వివరిస్తుంది. Compromised server తన backup historyని తానే తొలగించకుండా నిరోధించే లక్షణం ఇదే. ఈ రెండు toolsలో ఏదైనా సరిపోతుంది. తప్పు సమాధానం మాత్రం రెండింటిలో ఏదీ అమలు చేయకపోవడం.

కొత్త server ఏర్పాటు చేసిన వెంటనే దీన్ని సిద్ధం చేయడం అత్యంత తక్కువ ఖర్చుతో కూడిన సమయం. దానిలో కోల్పోవడానికి విలువైన ఏదీ ఇంకా ఉండదు. కొత్త VPSలో మొదటి పది నిమిషాలు అనే భాగంలో SSH మరియు firewall setupతో పాటు ఈ పనిని కూడా చేయాలి.

తర్వాత మీ calendarలో recurring entry పెట్టండి: ప్రతి నెల repository నుంచి ఒక directoryని /tmp లోకి restore చేసి, filesను చదవండి. ఈ ఒక్క అలవాటు ఈ పేజీలోని ప్రతి tool కంటే ఎక్కువ విలువైనది.

FAQ

ext4 లో ఫైల్‌ను undelete చేయవచ్చా?

సాధారణంగా కాదు. ఫైల్‌కు ఉన్న చివరి link తొలగినప్పుడు, ext4 inode నుంచి extent tree ను తొలగిస్తుంది. అందువల్ల ఆ data డిస్క్‌లో ఎక్కడ ఉందో నమోదు చేసే సమాచారం ఉండదు. extundelete మరియు ext4magic ext4 journal లో ఆ inode యొక్క పాత కాపీ కోసం వెతుకుతాయి. Delete చేసినది కొన్ని నిమిషాల క్రితమే జరిగి, అప్పటి నుంచి filesystem లో మార్పులు జరగకపోతే మాత్రమే ఇది ఉపయోగపడుతుంది. ఈ రెండు project లలో ఏదీ ప్రస్తుతం చురుకుగా నిర్వహించబడటం లేదు. వీటిలో ఏదైనా unmounted device లేదా disk image పై మాత్రమే అమలు చేయండి. Mounted filesystem పై ఎప్పుడూ అమలు చేయవద్దు. ముందుగా sudo dumpe2fs -h /dev/vdb1 | grep -i journal ఉపయోగించి మీరు ఏదిపై పనిచేస్తున్నారో నిర్ధారించండి.

ఒక service ఇంకా deleted file ను open చేసి ఉంచింది. దాన్ని తిరిగి పొందవచ్చా?

అవును. ఇది అత్యుత్తమ పరిస్థితి. ఒక process ఫైల్‌ను open చేసి ఉంచినంతకాలం, దాని inode మరియు data blocks allocated గానే ఉంటాయి. అందువల్ల data ఇంకా చదవవచ్చు. Service ను 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 జరిగితే, మీ data ఇంకా ఉన్న free blocks పై అది రాయబడవచ్చు. ముందుగా sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map ఉపయోగించి partition ను వేరే device కు copy చేయండి. తరువాత photorec ను image file పై అమలు చేయండి. అదే bytes పై తరువాత మరో tool ను ప్రయత్నించడానికి కూడా image అనుమతిస్తుంది. Original పై ఏదైనా రాసిన తర్వాత ఇది సాధ్యం కాదు.

rm -rf / ఇప్పటికీ Linux system ను పూర్తిగా నాశనం చేస్తుందా?

ఆ command ను యథాతథంగా అమలు చేస్తే కాదు. GNU rm దాన్ని తిరస్కరించి rm: it is dangerous to operate recursively on '/' ను ప్రింట్ చేస్తుంది. ప్రమాదకరమైన రూపాలు ఇతర మార్గం ద్వారా ఏర్పడేవి. TARGET unset గా ఉన్నప్పుడు rm -rf "$TARGET"/*, rm -rf /* కు expand అవుతుంది. అప్పుడు shell rm కు వాస్తవ top-level directories జాబితాను అందిస్తుంది. ఆ జాబితాలో / ఉండదు. కాబట్టి guard trigger కాదు. దాని బదులుగా "${TARGET:?TARGET is not set}" రాస్తే, rm అమలు కావడానికి ముందే shell ఆగిపోతుంది.

Filesystem snapshot backup అవుతుందా?

కాదు. btrfs లేదా ZFS snapshot, రక్షిస్తున్న data ఉన్న అదే pool లో ఉంటుంది. అందువల్ల disk విఫలమైనా లేదా pool నాశనమైనా రెండూ ఒకేసారి పోతాయి. LVM snapshot కు fixed size ఉండటం మరో సమస్య. అది నిండినప్పుడు kernel దాన్ని invalid చేస్తుంది. దాని contents కూడా పోతాయి. రెండు నిమిషాల క్రితం జరిగిన delete ను undo చేయడానికి snapshots చాలా ఉపయోగకరంగా ఉంటాయి. మిగతా సందర్భాల కోసం separate hardware పై repository ఉంచండి.