rm -rf سے حذف فائلیں واپس کیسے لائیں؟

پہلے ساٹھ سیکنڈ میں کیا کرنا ہے

rm -rf سے حذف شدہ فائلیں بحال ہوں گی یا نہیں، اس کا فیصلہ دو اقدامات کرتے ہیں، اور یہ دونوں اقدامات search engine کھولنے سے پہلے کرنے ہوتے ہیں۔ اس filesystem پر لکھنا بند کریں۔ پھر اسے استعمال سے ہٹا دیں؛ اسے unmount کریں یا read-only کے طور پر دوبارہ mount کریں۔

rm کوئی چیز erase نہیں کرتا۔ یہ پہلے directory entry ہٹاتا ہے، پھر inode اور فائل کے data blocks کو free کے طور پر نشان زد کرتا ہے۔ bytes ابھی device پر موجود رہتے ہیں۔ یہ اس وقت تک وہیں رہتے ہیں جب تک block allocator ان blocks کو کسی دوسری چیز کے حوالے نہ کر دے اور وہ چیز ان پر نیا data نہ لکھ دے۔ filesystem کے mounted اور مصروف رہنے والے ہر سیکنڈ میں کوئی daemon log line لکھ سکتا ہے یا database کوئی page flush کر سکتا ہے، اور ان میں سے کوئی بھی write ان blocks پر ہو سکتی ہے جنہیں آپ واپس حاصل کرنا چاہتے ہیں۔

اس لیے پہلے وہ commands چلائیں جو writes روکتی ہیں، نہ کہ وہ جو فائلیں بحال کرتی ہیں۔

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 کے طور پر دوبارہ mount کریں۔ 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 فائلوں کو writing کے لیے open رکھتی ہیں اور kernel انہیں زبردستی بند نہیں کرے گا۔ VPS پر عملی حل provider کا rescue یا recovery mode ہے: یہ ایک الگ live system boot کرتا ہے، جس میں آپ کی disk attached ہوتی ہے لیکن mounted نہیں ہوتی۔ اس کے بعد نیچے دی گئی ہر command ایسے device پر چلتی ہے جس پر کوئی write نہیں کر رہا ہوتا۔

اس پوری guide پر ایک اصول لاگو ہوتا ہے۔ recovered files، disk image یا نیا installed tool کبھی بھی اسی filesystem پر نہ لکھیں جس سے آپ data recover کر رہے ہیں۔ دوسری volume attach کریں، یا output کو SSH کے ذریعے کسی دوسری machine پر بھیجیں۔

ext4 پر rm -rf کے بعد recovery کی امید عموماً نہیں رہتی

کسی بھی چیز کو install کرنے سے پہلے اپنی توقعات واضح کر لیں۔ پہلے تصدیق کریں کہ آپ کون سا filesystem استعمال کر رہے ہیں:

lsblk -f

تقریباً ہر VPS image پر default filesystem ext4 ہوتا ہے۔ ext4 میں file کے data کا مقام inode کے اندر extent tree میں محفوظ ہوتا ہے۔ extent ایک ایسا record ہے جو بتاتا ہے کہ اس file کا logical block N، physical block M سے شروع ہوتا ہے اور L blocks تک جاری رہتا ہے۔ چھوٹی files اپنے inode کے اندر زیادہ سے زیادہ چار ایسے records رکھتی ہیں۔ بڑی files باقی tree رکھنے والے اضافی blocks کی طرف اشارہ کرتی ہیں۔

جب file کا آخری link بھی ختم ہو جاتا ہے تو ext4 اس tree کو traverse کرتا ہے، ہر extent کو block allocator کے حوالے کر دیتا ہے، اور inode سے tree صاف کر دیتا ہے۔ اس کے بعد inode کو free نشان زد کیا جاتا ہے اور اس میں deletion time درج کیا جاتا ہے۔ اصل data بدستور موجود رہتا ہے۔ تاہم، اس data کا مقام بتانے والا واحد record مٹا دیا جاتا ہے۔

یہ ext3 سے مختلف ہے، جہاں deleted inode میں اتنی معلومات باقی رہتی تھیں کہ ext3grep جیسا tool اسے follow کر سکتا تھا۔ ext4 پر بھی آپ deleted inodes کی فہرست دیکھ سکتے ہیں:

sudo debugfs -R lsdel /dev/vdb1

جب تک آپ -w نہ دیں، debugfs device کو read-only کھولتا ہے۔ اس لیے unmounted device پر یہ محفوظ ہے اور اسے آزمانے میں کوئی نقصان نہیں۔ inodes کی فہرست ظاہر ہو جائے گی۔ مسئلہ کسی inode کو dump کرنے پر آتا ہے، کیونکہ اس inode میں موجود block map صاف ہو چکا ہوتا ہے اور dump کے پاس follow کرنے کے لیے کچھ نہیں رہتا۔

دو tools journal پڑھ کر اس مسئلے کو دور کرنے کی کوشش کرتے ہیں۔ journal ایک fixed-size ring ہے جسے ext4 crash کے بعد metadata کو consistent رکھنے کے لیے استعمال کرتا ہے۔ delete ہونے سے پہلے کا inode کا ایک پرانا copy اب بھی اس میں موجود ہو سکتا ہے۔ extundelete اور ext4magic دونوں journal میں تلاش کرتے ہیں۔ پہلے معلوم کریں کہ آپ کس size کے journal کے ساتھ کام کر رہے ہیں:

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

journal میں صرف metadata ہوتا ہے اور اس کا حجم بھی کم ہوتا ہے، اس لیے عام write activity اسے تیزی سے overwrite کرتی رہتی ہے۔ چلتے ہوئے server پر delete سے پہلے والے inode کے باقی رہنے کی مدت چند منٹ ہوتی ہے۔ دونوں tools کی active maintenance نہیں ہو رہی، اور ہر distribution میں یہ package کی صورت میں دستیاب بھی نہیں ہوتے۔ دونوں کو کم امکان والی کوشش سمجھیں، انہیں unmounted device یا disk image پر چلائیں، اور اگر یہ کچھ واپس نہ دیں تو حیران نہ ہوں۔

اگر lsblk -f، xfs report کرے تو صورت حال بہتر نہیں ہوتی، کیونکہ XFS کے لیے بھی کوئی supported undelete موجود نہیں ہے۔ ذیل میں options کی ترتیب تبدیل کرنے سے نتیجہ نہیں بدلے گا۔

کیا فائل اب بھی چلتے ہوئے process میں کھلی ہے؟

اس صفحے پر یہی واحد recovery طریقہ ہے جس کے کامیاب ہونے کے امکانات اچھے ہیں۔ اسی لیے اس service کو restart نہیں کرنا چاہیے جو یہ فائل استعمال کر رہی تھی۔

فائل اس وقت مکمل طور پر ختم ہوتی ہے جب دو counts صفر ہو جائیں: اس کے inode کی طرف اشارہ کرنے والی directory entries کی تعداد، اور کھلے ہوئے file descriptors کی تعداد۔ rm پہلے count کو صفر کرتا ہے۔ اگر کوئی process اب بھی فائل کو کھولے ہوئے ہے تو دوسرا count صفر نہیں ہوتا۔ اس لیے inode اور اس کے blocks اب بھی allocated رہتے ہیں، اور data اب بھی پڑھا جا سکتا ہے۔

ایسی open files تلاش کریں جن کا link count صفر ہو چکا ہو:

sudo lsof +L1

+L1 کا مطلب ہے کہ ایک سے کم link count والی open files کی فہرست بنائیں۔ ہر 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 کھولنے سے اسی inode پر offset zero سے نیا handle بنتا ہے۔ اس طرح پوری فائل ملتی ہے، نہ کہ صرف وہ حصہ جو writer کی موجودہ position کے بعد موجود ہو۔

دو حدود جاننا ضروری ہے۔ Deleted directory tree اس طریقے سے واپس نہیں آتا، کیونکہ صرف وہ individual files اب بھی held رہتی ہیں جنہیں کسی process نے کھولا ہوا تھا۔ اسی طرح، engine کے write کے دوران copy کی گئی database file crash-consistent copy ہوتی ہے۔ اس لیے اسے clean copy نہ سمجھیں؛ اس پر engine کی اپنی recovery چلانے کا منصوبہ بنائیں۔ جن entries میں lsof descriptor number کی جگہ mem دکھاتا ہے، وہ memory mapped ہوتی ہیں۔ ان کے لیے copy کرنے کو /proc/<pid>/fd entry موجود نہیں ہوتی۔

کیا آپ کے پاس btrfs، ZFS یا LVM پر snapshot موجود ہے؟

اگر filesystem snapshots بناتا ہے تو حذف شدہ files پہلے سے کسی 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 hidden ہوتی ہے اور dataset root پر سادہ ls میں ظاہر نہیں ہوتی، لیکن آپ نام کے ذریعے اس میں داخل ہو سکتے ہیں۔ وہاں سے files copy کر لیں۔ zfs rollback پورے dataset کو آپ کے بتائے ہوئے snapshot کی حالت میں واپس لے جاتا ہے اور اس snapshot کے بعد بننے والے تمام نئے snapshots کو تباہ کر دیتا ہے، اس لیے اسے آخری حل کے طور پر رکھیں۔

LVM snapshots مقررہ size والے copy-on-write volumes ہوتے ہیں:

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

اسے read-only mount کریں اور files copy کر لیں۔ اس پر بھروسا کرنے سے پہلے lvs چیک کریں، کیونکہ LVM snapshot اپنی مختص جگہ بھر جانے پر kernel کے ذریعے invalid کر دیا جاتا ہے، اور ایسا ہونے کے بعد اس کا content ختم ہو جاتا ہے۔

snapshot، backup نہیں ہوتا۔ یہ original کے اسی disk یا اسی pool پر موجود ہوتا ہے، اس لیے original کو متاثر کرنے والی ہر خرابی snapshot کو بھی متاثر کر سکتی ہے۔ یہ دو منٹ پہلے کی غلطی واپس کرنے کے لیے بہت مؤثر ہے، اور اس صورتِ حال میں یہی اس کا مقصد ہے۔

PhotoRec کے ذریعے carving، image پر، live disk پر نہیں

اگر اوپر دیے گئے طریقوں میں سے کوئی بھی قابلِ اطلاق نہ ہو تو باقی طریقہ carving ہے: raw device کو ان byte patterns کے لیے scan کرنا جو کسی معلوم file type کے آغاز کی نشاندہی کرتے ہیں، اور پھر اس کے بعد ملنے والا تمام data لکھ دینا۔ Carving صرف file data پڑھتی ہے۔ Filenames، directory structure، timestamps اور ownership سب filesystem metadata ہیں، اور یہی metadata rm نے تباہ کیا ہے، اس لیے ان میں سے کچھ بھی واپس نہیں آئے گا۔ آپ کو f0384512.jpg جیسے ناموں والی files ایک numbered output directory میں ملیں گی، اور انہیں دستی طور پر ترتیب دینا ہوگا۔

دو اصول طے کرتے ہیں کہ یہ طریقہ بالکل کام کرے گا یا نہیں۔

پہلا اصول یہ ہے کہ کسی بھی دوسرے tool کو device پر چلانے سے پہلے اس کی image بنائیں۔ Debian اور Ubuntu پر package کا نام gddrescue ہے، اور یہ جو binary install کرتا ہے اس کا نام 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 پر ہونی چاہیے، اور اس میں اتنی free space لازماً ہو جتنی partition کا حجم ہے۔ lsblk -b bytes میں درست sizes دکھاتا ہے۔ map file سے interrupted copy دوبارہ شروع کی جا سکتی ہے، اس لیے عمل ابتدا سے شروع نہیں کرنا پڑتا۔ Image بن جانے کے بعد آپ بعد میں اسی بالکل یکساں byte data پر دوسرا tool آزما سکتے ہیں۔ اگر پہلے tool نے disk پر data لکھ دیا ہو تو یہ ممکن نہیں رہتا۔

دوسرا اصول یہ ہے کہ 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 کو support کرتا ہے۔ ext4 پر اس کا نتیجہ photorec رہ جاتا ہے۔

توقع رکھیں کہ fragmented files خراب حالت میں واپس آئیں گی۔ Carving یہ فرض کرتی ہے کہ file کے blocks مسلسل موجود ہیں، اس لیے allocator نے جس file کو disk پر مختلف جگہوں میں تقسیم کیا ہو، وہ یا تو غلط طور پر دوبارہ جوڑی جائے گی یا مکمل طور پر نظر انداز ہو جائے گی۔ Media files عموماً مناسب طریقے سے carve ہو جاتی ہیں، کیونکہ ان کے headers واضح ہوتے ہیں۔ Plain text، configuration اور source code کی carving ناقص رہتی ہے، کیونکہ ایسا کوئی byte signature نہیں ہوتا جو shell script کے آغاز کی نشاندہی کرے۔

غلط space: غلط path کیسے delete ہوا

تقریباً ہر rm -rf حادثہ shell کا مسئلہ ہوتا ہے۔ rm کو paths کی فہرست ملتی ہے اور وہ ہر path کو باری باری remove کرتا ہے۔ اسے کبھی معلوم نہیں ہوتا کہ آپ کا اصل ارادہ کیا تھا۔

عام مثال ایک single space ہے:

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

پہلی line میں دو arguments ہیں۔ یہ application کو delete کرتی ہے، پھر /old کو delete کرتی ہے۔ اگر /old موجود نہ ہو تو rm بالکل کچھ print نہیں کرتا، کیونکہ -f missing-file error کو suppress کرتا ہے۔ خاموشی confirmation نہیں ہوتی۔

دوسری صورت unquoted variable ہے جس کی value میں space ہو:

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

shell value کو whitespace پر split کرتا ہے، اس لیے rm کو /srv/my اور app دو الگ paths کے طور پر ملتے ہیں۔ rm -rf "$dir" کی صورت میں یہ ایک ہی path ہے۔

تیسری صورت empty variable ہے۔ عموماً ایسا اس لیے ہوتا ہے کہ اسے value دینے والی command ناکام ہو گئی ہو:

rm -rf "$TARGET"/*

TARGET unset ہونے پر یہ rm -rf /* میں expand ہوتا ہے۔ GNU rm اس bare form کو قبول نہیں کرتا: rm -rf / rm: it is dangerous to operate recursively on '/' print کر کے رک جاتا ہے۔ glob form کو ایسی protection حاصل نہیں ہوتی، کیونکہ shell /* کو حقیقی top-level paths کی فہرست سے replace کر دیتا ہے، اس سے پہلے کہ rm چلے، اور / ان paths میں شامل نہیں ہوتا؛ اس لیے guard فعال نہیں ہوتا۔

اگلی بار کی روک تھام کرنے والی عادات

• path کے طور پر استعمال ہونے والے ہر variable کو quote کریں۔ ہر بار "$dir" لکھیں، tests اور loops کے اندر بھی۔
• خالی value پر عمل روک دیں۔ rm -rf "${TARGET:?TARGET is not set}"/* آپ کے message کے ساتھ shell کو روک دیتا ہے، اس سے پہلے کہ rm شروع ہو، جب بھی TARGET unset یا خالی ہو۔ حذف کرنے والی ہر script کے شروع میں set -euo pipefail رکھیں۔
• --one-file-system شامل کریں۔ یہ rm کو ہدایت دیتا ہے کہ دیے گئے argument سے مختلف filesystem پر موجود directory کو چھوڑ دے، تاکہ recursive delete کسی mounted backup volume یا bind mount کے اندر نہ جا سکے۔
• root کے طور پر حذف نہ کریں۔ service account صرف وہی چیزیں حذف کر سکتا ہے جن کی ملکیت اس کے پاس ہو۔ یہی ہر service کو اپنے unprivileged user کے طور پر چلانے کی بنیادی وجہ ہے۔ اگر آپ کو یقین نہ ہو کہ کوئی account کن paths تک پہنچ سکتا ہے، تو ls listing میں permission bits پڑھنے سے ایک command میں جواب مل جاتا ہے۔
• عمل کرنے سے پہلے list print کریں۔ script میں paths بنائیں، انہیں printf '%s\n' کریں، output پڑھیں، پھر دوسرے pass میں حذف کریں۔
• trash command کو فوری دستیاب رکھیں۔ sudo apt install trash-cli آپ کو trash-put، trash-list، trash-restore اور trash-empty فراہم کرتا ہے۔ حذف شدہ files ~/.local/share/Trash میں منتقل ہو جاتی ہیں، اور trash-empty 30 تیس دن سے پرانی ہر چیز صاف کر دیتا ہے۔

rm کو trash-put کا alias بنانا اگلا واضح قدم معلوم ہوتا ہے، لیکن یہ ایک trap ہے۔ یہ alias ایسی عادت بنا دیتا ہے جو اگلے ایسے server پر ناکام ہو جاتی ہے جہاں یہ موجود نہ ہو۔ مزید یہ کہ aliases scripts کے اندر لاگو نہیں ہوتے، حالانکہ مہنگی غلطیاں عموماً وہیں ہوتی ہیں۔ اس کے بجائے جان بوجھ کر trash-put type کریں۔

ہر بار مؤثر ثابت ہونے والا واحد recovery طریقہ

اوپر بیان کیا گیا ہر طریقہ محض امکان ہے۔ Backup امکان نہیں ہے۔

دو چیزیں backup کو حقیقی بناتی ہیں۔ یہ مقررہ schedule کے مطابق آپ کی یاد دہانی کے بغیر چلتا ہے، اور آپ نے کم از کم ایک بار اس سے restore کیا ہوتا ہے۔ جس repository سے کبھی restore نہ کیا گیا ہو، وہ صرف ایک مفروضہ ہے، کیونکہ وہ مسائل جو اسے بے کار بناتے ہیں، مثلاً include list میں غلط path یا repository کا وہ password جو کسی نے لکھ کر محفوظ نہ کیا ہو، صرف اسی دن سامنے آتے ہیں جب آپ کو اس کی ضرورت پڑتی ہے۔

restic کے ساتھ restore کے لیے دو commands کافی ہیں۔

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

Live path کے بجائے کسی خالی directory میں restore کریں، تاکہ کسی بھی چیز کو اصل جگہ منتقل کرنے سے پہلے دونوں کا موازنہ کر سکیں۔ VPS پر restic backups ترتیب دینا میں repository setup اور اسے چلانے والے 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 match کرتا ہے اور /srv/appdata کسی چیز سے match نہیں کرتا۔ borg extract موجودہ working directory میں لکھتا ہے، اس لیے پہلے cd کو scratch directory کی طرف بھیجیں۔

اگر آپ نے ابھی تک دونوں میں سے کسی ایک کا انتخاب نہیں کیا، تو restic اور Borg کا موازنہ deduplication اور append-only repositories کا احاطہ کرتا ہے۔ یہی خاصیت breached server کو اپنی backup history حذف کرنے سے روکتی ہے۔ دونوں میں سے کوئی بھی tool مناسب ہے۔ غلط انتخاب یہ ہے کہ ان میں سے کوئی بھی نہ چل رہا ہو۔

نیا server اس setup کے لیے سب سے کم خرچ وقت ہوتا ہے، یعنی اس سے پہلے کہ اس پر ایسی کوئی چیز موجود ہو جسے کھونا نقصان دہ ہو۔ نئے VPS کے پہلے دس منٹ میں یہ کام SSH اور firewall setup کے ساتھ شامل ہونا چاہیے۔

اس کے بعد اپنے calendar میں ایک recurring entry شامل کریں: ہر ماہ repository سے ایک directory کو /tmp میں restore کریں اور files پڑھیں۔ یہ ایک عادت اس صفحے کے ہر tool سے زیادہ اہم ہے۔

FAQ

کیا ext4 پر فائل کو undelete کیا جا سکتا ہے؟

عام طور پر نہیں۔ جب فائل کا آخری link ختم ہو جاتا ہے تو ext4 inode سے extent tree صاف کر دیتا ہے، اس لیے disk پر یہ ریکارڈ باقی نہیں رہتا کہ data کہاں موجود تھا۔ extundelete اور ext4magic ext4 journal میں اس inode کی پرانی copy تلاش کرتے ہیں۔ یہ صرف اسی صورت میں مددگار ہے جب delete چند منٹ پہلے ہوا ہو اور اس کے بعد filesystem خاموش رہا ہو۔ دونوں projects کی فعال maintenance نہیں ہو رہی۔ ان میں سے کسی بھی tool کو 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 مکمل ہو جاتا ہے۔ sudo lsof +L1 چلائیں تاکہ 0 link count والی open files کی فہرست مل جائے۔ PID اور file descriptor number نوٹ کریں، پھر sudo cp /proc/1234/fd/3 /mnt/rescue/events.log کے ساتھ /proc کے ذریعے copy بنائیں۔ Copy کو مختلف filesystem پر لکھیں۔ جن entries میں descriptor number کے بجائے mem دکھایا جائے، وہ memory mapped ہیں اور ان کے پاس copy کرنے کے لیے کوئی /proc/<pid>/fd path نہیں ہوتا۔

Recovery tool چلانے کے بجائے disk کی image کیوں بنانی چاہیے؟

کیونکہ ہر tool کو اپنا output کہیں نہ کہیں لکھنا ہوتا ہے، اور جس filesystem سے آپ recovery کر رہے ہیں اسی پر ہونے والی write ان free blocks پر جا سکتی ہے جن میں آپ کا data اب بھی موجود ہو۔ پہلے sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map کے ذریعے partition کو کسی مختلف device پر copy کریں، پھر photorec کو image file کی طرف point کریں۔ Image آپ کو بعد میں بالکل انہی bytes پر دوسرا tool آزمانے کی سہولت بھی دیتی ہے۔ اصل data پر کچھ لکھ دیے جانے کے بعد یہ ممکن نہیں رہتا۔

کیا rm -rf / اب بھی Linux system کو مکمل طور پر تباہ کر دیتا ہے؟

صرف یہ command ایسا نہیں کرتی۔ GNU rm اسے مسترد کرتا ہے اور rm: it is dangerous to operate recursively on '/' دکھاتا ہے۔ خطرناک صورتیں وہ ہیں جو کسی دوسرے طریقے سے پیدا ہوتی ہیں۔ TARGET کے ساتھ rm -rf "$TARGET"/*، جب unset ہو، تو rm -rf /* میں expand ہوتا ہے۔ اس کے بعد shell rm کو حقیقی top-level directories کی فہرست دیتا ہے، جن میں / شامل نہیں ہوتا، اس لیے حفاظتی رکاوٹ فعال نہیں ہوتی۔ اس کے بجائے "${TARGET:?TARGET is not set}" لکھیں، تو shell rm چلنے سے پہلے رک جاتا ہے۔

کیا filesystem snapshot ایک backup ہوتا ہے؟

نہیں۔ btrfs یا ZFS snapshot اسی pool پر رہتا ہے جس پر محفوظ کیا جانے والا data موجود ہے، اس لیے failed disk یا تباہ شدہ pool دونوں کو ایک ساتھ ختم کر دیتا ہے۔ LVM snapshot کا اضافی مسئلہ اس کا fixed size ہے۔ جب یہ بھر جاتا ہے تو kernel اسے invalid کر دیتا ہے اور اس کا content ختم ہو جاتا ہے۔ دو منٹ پہلے کی delete واپس کرنے کے لیے snapshots بہترین ہیں۔ باقی تمام صورتوں میں الگ hardware پر repository رکھیں۔