بازیابی فایل‌های حذف شده با دستور rm -rf در لینوکس

اقدامات لازم در 60 ثانیه نخست

دو عامل تعیین می‌کنند که آیا می‌توانید فایل‌های حذف‌شده با rm -rf را بازیابی کنید یا خیر؛ هر دو عامل پیش از آنکه موتور جستجو را باز کنید، اهمیت پیدا می‌کنند. نوشتن روی آن فایل‌سیستم را متوقف کنید. سپس با unmount کردن یا remount کردن آن به حالت read-only، آن را از دسترس خارج کنید.

rm هیچ چیزی را پاک نمی‌کند. این دستور تنها ورودی دایرکتوری را حذف کرده و inode و بلوک‌های دادهٔ فایل را به عنوان فضای آزاد علامت‌گذاری می‌کند. بایت‌ها همچنان روی دستگاه باقی می‌مانند. آن‌ها تا زمانی که block allocator آن بلوک‌ها را به فرآیند دیگری اختصاص ندهد و آن فرآیند روی آن‌ها ننویسد، در جای خود باقی می‌مانند. هر ثانیه‌ای که فایل‌سیستم mount و فعال باقی بماند، یک دیمون ممکن است یک خط لاگ بنویسد یا یک دیتابیس یک صفحه را flush کند؛ هر کدام از این عملیات نوشتن ممکن است دقیقاً روی بلوک‌هایی که قصد بازیابی‌شان را دارید، انجام شود.

بنابراین، دستورات اولیه باید برای متوقف کردن عملیات نوشتن باشند، نه برای بازیابی فایل‌ها.

sudo systemctl stop nginx postgresql
sudo umount /mnt/data

اگر umount پاسخ umount: /mnt/data: target is busy. را برگرداند، بررسی کنید چه چیزی فایل‌سیستم را باز نگه داشته است.

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

اگر نمی‌توانید آن را آزاد کنید، به جای آن، فایل‌سیستم را به حالت read-only remount کنید. mount کردن به صورت read-only از تخصیص‌های جدید جلوگیری می‌کند که این دقیقاً همان چیزی است که به آن نیاز دارید.

sudo mount -o remount,ro /mnt/data

اگر مسیر حذف‌شده روی فایل‌سیستم ریشه (root) باشد، کار دشوارتر است. sudo mount -o remount,ro / معمولاً با خطای mount: /: cannot remount /dev/vda1 read-only. شکست می‌خورد، زیرا فرآیندهای در حال اجرا فایل‌ها را برای نوشتن باز نگه می‌دارند و کرنل آن‌ها را به اجبار نمی‌بندد. در یک VPS، راهکار عملی استفاده از حالت rescue یا recovery ارائه‌دهندهٔ سرویس شماست: این حالت یک سیستم live جداگانه بوت می‌کند که دیسک شما به آن متصل است اما mount نشده است. در این صورت، تمام دستورات زیر روی دستگاهی اجرا می‌شوند که هیچ‌کس در حال نوشتن روی آن نیست.

یک قانون کلی برای تمام این راهنما وجود دارد: هرگز فایل‌های بازیابی‌شده، image دیسک یا ابزارهای تازه نصب‌شده را روی فایل‌سیستمی که در حال بازیابی از آن هستید، ننویسید. یک volume دوم متصل کنید یا خروجی را از طریق SSH به ماشین دیگری بفرستید.

چرا بازیابی فایل‌های حذف‌شده با rm -rf در ext4 تقریباً غیرممکن است

پیش از نصب هر ابزاری، انتظارات خود را واقع‌بینانه تنظیم کنید. ابتدا تأیید کنید که با چه سیستم فایلی سروکار دارید:

lsblk -f

در ext4 که سیستم فایل پیش‌فرض تقریباً تمام ایمیج‌های VPS است، موقعیت داده‌های یک فایل در inode آن به صورت یک درخت extent ذخیره می‌شود. هر extent رکوردی است که می‌گوید بلاک منطقی N از این فایل، از بلاک فیزیکی M شروع شده و به طول L بلاک ادامه می‌یابد. فایل‌های کوچک تا 4 رکورد از این دست را درون خود inode نگه می‌دارند. فایل‌های بزرگ‌تر به بلاک‌های اضافی اشاره می‌کنند که باقی‌ماندهٔ درخت را در خود جای داده‌اند.

وقتی آخرین لینک به یک فایل حذف می‌شود، ext4 آن درخت را پیمایش کرده، تمام extentها را به تخصیص‌دهندهٔ بلاک (block allocator) بازمی‌گرداند و درخت را از inode پاک می‌کند. سپس inode به عنوان آزاد علامت‌گذاری شده و زمان حذف روی آن ثبت می‌شود. خودِ داده‌ها دست‌نخورده باقی می‌مانند، اما تنها رکورد موجود از محل قرارگیری آن داده‌ها پاک شده است.

این تفاوت اصلی با ext3 است؛ در ext3، یک inode حذف‌شده اطلاعات کافی برای ابزارهایی مانند ext3grep باقی می‌گذاشت تا بتوانند آن را دنبال کنند. شما هنوز هم می‌توانید inodeهای حذف‌شده را در ext4 لیست کنید:

sudo debugfs -R lsdel /dev/vdb1

ابزار debugfs دستگاه را به صورت فقط‌خواندنی (read-only) باز می‌کند، مگر اینکه فلگ -w را ارسال کنید؛ بنابراین استفاده از آن روی یک دستگاه unmount شده ایمن است و امتحان کردنش هزینه‌ای ندارد. inodeها لیست خواهند شد، اما کار در مرحلهٔ dump کردن متوقف می‌شود؛ زیرا نقشهٔ بلاک‌هایی که inode قبلاً نگه می‌داشت پاک شده است و dump چیزی برای دنبال کردن ندارد.

دو ابزار سعی می‌کنند با خواندن journal این مشکل را دور بزنند. journal یک حلقه با اندازهٔ ثابت است که ext4 از آن برای حفظ ثبات متادیتای سیستم فایل در هنگام کرش استفاده می‌کند و ممکن است هنوز نسخهٔ قدیمی inode را از پیش از حذف در خود داشته باشد. extundelete و ext4magic هر دو در آن جستجو می‌کنند. اندازهٔ آن را بررسی کنید:

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

journal فقط متادیتا را نگه می‌دارد و حجم آن کوچک است، بنابراین فعالیت‌های نوشتن عادی به‌سرعت آن را بازنویسی می‌کنند. در یک سرور در حال اجرا، بازهٔ زمانی که در آن inode پیش از حذف هنوز وجود دارد، در حد چند دقیقه است. هیچ‌کدام از این دو ابزار به‌طور فعال نگهداری نمی‌شوند و در تمام توزیع‌ها نیز بسته‌بندی نشده‌اند. به هر دو به چشم یک شانس بسیار ضعیف نگاه کنید، آن‌ها را روی یک دستگاه unmount شده یا یک ایمیج دیسک اجرا کنید و اگر نتیجه‌ای نگرفتید، تعجب نکنید.

اگر lsblk -f گزارش دهد که سیستم فایل xfs است، وضعیت بهتر نخواهد بود، زیرا برای XFS نیز هیچ ابزار پشتیبانی‌شده‌ای برای بازیابی فایل‌های حذف‌شده وجود ندارد. ترتیب گزینه‌های زیر تغییری نمی‌کند.

آیا فایل هنوز در یک پردازش در حال اجرا باز است؟

این تنها روش بازیابی در این صفحه است که شانس موفقیت بالایی دارد و به همین دلیل است که نباید سرویسی را که از فایل استفاده می‌کرده است، restart کنید.

یک فایل تنها زمانی واقعاً از بین می‌رود که دو شمارنده به صفر برسند: تعداد ورودی‌های دایرکتوری که به inode آن اشاره می‌کنند و تعداد توصیف‌گرهای فایل (file descriptor) باز. دستور rm شمارنده اول را به صفر می‌رساند. اگر پردازشی هنوز فایل را باز نگه داشته باشد، شمارنده دوم صفر نیست؛ بنابراین inode و بلوک‌های آن همچنان تخصیص‌یافته باقی می‌مانند و داده‌ها قابل خواندن هستند.

فایل‌های بازی را که تعداد لینک آن‌ها به صفر رسیده است، پیدا کنید:

sudo lsof +L1

دستور +L1 به معنای لیست کردن فایل‌های بازی است که تعداد لینک آن‌ها کمتر از 1 است. هر نتیجه، پردازش، شماره توصیف‌گر فایل، یک NLINK از نوع 0 و مسیری که به (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

از cp استفاده کنید، نه mv. باز کردن /proc/1234/fd/3 یک دستگیره (handle) جدید روی همان inode از آفست صفر به شما می‌دهد، بنابراین به جای بخشی از فایل که پس از موقعیت فعلی نویسنده قرار دارد، کل فایل را دریافت می‌کنید.

دو محدودیت وجود دارد که باید از آن‌ها آگاه باشید. یک درخت دایرکتوری حذف‌شده از این طریق بازنمی‌گردد، زیرا فقط فایل‌های تکی که یک پردازش باز نگه داشته است، حفظ می‌شوند. همچنین، فایل دیتابیسی که در حین نوشتن توسط موتور کپی می‌شود، یک کپی crash-consistent است؛ بنابراین برنامه‌ریزی کنید که به جای در نظر گرفتن آن به عنوان یک فایل سالم، از ابزارهای بازیابی خودِ موتور روی آن استفاده کنید. ورودی‌هایی که lsof با mem به جای شماره توصیف‌گر نشان می‌دهد، memory mapped هستند و هیچ ورودی /proc/<pid>/fd برای کپی کردن ندارند.

آیا اسنپ‌شات (snapshot) روی btrfs، ZFS یا LVM دارید؟

اگر فایل‌سیستم از اسنپ‌شات پشتیبانی می‌کند، فایل‌های حذف‌شده هم‌اکنون بدون تغییر درون یکی از آن‌ها قرار دارند. این روش تنها در صورتی کارآمد است که اسنپ‌شات پیش از حذف فایل ایجاد شده باشد. هیچ چیزی که اکنون ایجاد کنید، به گذشته بازنمی‌گردد.

btrfs اسنپ‌شات‌ها را به عنوان subvolume نگه می‌دارد:

sudo btrfs subvolume list /

اسنپ‌شات را مرور کنید و مسیرهای مورد نیاز خود را با cp -a کپی کنید. کپی کردن مسیرهای تکی را به بازگردانی (rollback) کل یک subvolume ترجیح دهید، زیرا بازگردانی باعث از دست رفتن تمام داده‌هایی می‌شود که پس از ایجاد اسنپ‌شات نوشته شده‌اند.

ZFS هر اسنپ‌شات را به عنوان یک دایرکتوری فقط‌خواندنی نمایش می‌دهد:

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

دایرکتوری .zfs مخفی است و در لیست معمولی ls از ریشه دیتاست ظاهر نمی‌شود، اما می‌توانید با وارد کردن نام آن واردش شوید. فایل‌ها را از آنجا کپی کنید. دستور zfs rollback کل دیتاست را به عقب برمی‌گرداند و تمام اسنپ‌شات‌های جدیدتر از اسنپ‌شاتی که نام می‌برید را نابود می‌کند، بنابراین آن را به عنوان آخرین راهکار در نظر بگیرید.

اسنپ‌شات‌های LVM، ولوم‌های copy-on-write با اندازه ثابت هستند:

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

آن را به صورت فقط‌خواندنی mount کنید و فایل‌ها را کپی کنید. پیش از اعتماد به آن، lvs را بررسی کنید، زیرا اگر فضای اختصاص‌یافته به اسنپ‌شات LVM پر شود، توسط کرنل غیرمعتبر می‌شود و پس از آن، محتویاتش از دست می‌رود.

اسنپ‌شات یک نسخه پشتیبان (backup) نیست. اسنپ‌شات روی همان دیسک یا همان pool اصلی قرار دارد، بنابراین در تمام خرابی‌هایی که دیسک اصلی را تهدید می‌کند، شریک است. اسنپ‌شات برای خنثی کردن اشتباهاتی که دو دقیقه پیش رخ داده‌اند بسیار عالی است، که دقیقاً همان کاری است که در اینجا نیاز داریم.

بازیابی فایل با PhotoRec، فقط روی image و نه دیسک زنده

اگر هیچ‌کدام از روش‌های بالا کارساز نبود، تنها گزینه باقی‌مانده carving است: اسکن کردن raw device برای یافتن الگوهای بایتی که نشان‌دهنده شروع یک نوع فایل شناخته‌شده هستند و سپس ذخیره کردن هر آنچه در ادامه می‌آید. عملیات carving فقط داده‌های فایل را می‌خواند. نام فایل‌ها، ساختار دایرکتوری، مُهرهای زمانی و مالکیت، همگی جزو metadata سیستم‌فایل هستند و این همان metadataای است که rm از بین برده است، بنابراین هیچ‌کدام از آن‌ها بازیابی نمی‌شوند. شما فایل‌هایی با نام f0384512.jpg در یک دایرکتوری خروجی شماره‌گذاری‌شده دریافت می‌کنید و باید آن‌ها را به‌صورت دستی مرتب کنید.

دو قانون تعیین می‌کند که آیا این روش اصلاً نتیجه می‌دهد یا خیر.

نخست، پیش از آنکه هر ابزار دیگری را به سمت دستگاه بگیرید، از آن image تهیه کنید. در Debian و Ubuntu، نام بسته gddrescue و نام باینری که نصب می‌کند 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 باید روی یک دستگاه متفاوت باشد که حداقل به اندازه حجم پارتیشن، فضای خالی داشته باشد. lsblk -b اندازه دقیق را به بایت چاپ می‌کند. فایل map اجازه می‌دهد که در صورت قطع شدن کپی، عملیات از همان‌جا ادامه یابد و نیازی به شروع مجدد نباشد. وقتی image را در اختیار دارید، می‌توانید بعداً ابزار دوم را روی دقیقاً همان بایت‌ها امتحان کنید؛ کاری که اگر ابزار اول مستقیماً روی دیسک نوشته باشد، امکان‌پذیر نیست.

دوم، ابزار بازیابی را به سمت فایل image نشانه بروید.

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

photorec یک منوی متنی باز می‌کند. پارتیشن، سپس نوع سیستم‌فایل، سپس امضاهای فایلی که باید جستجو شوند و در نهایت دایرکتوری مقصد را انتخاب کنید. پیش از شروع، لیست امضاها را به نوع فایل‌هایی که واقعاً از دست داده‌اید محدود کنید، زیرا لیست پیش‌فرض همه چیز را پیدا می‌کند و ده‌ها هزار قطعه فایل به شما تحویل می‌دهد که باید آن‌ها را غربال کنید.

testdisk که از همان بسته است، تابع undelete مخصوص خود را دارد و فقط FAT، exFAT، NTFS و ext2 را پوشش می‌دهد. در ext4، گزینه باقی‌مانده photorec است.

انتظار داشته باشید که فایل‌های تکه‌تکه شده (fragmented)، خراب بازیابی شوند. عملیات carving فرض می‌کند که بلوک‌های یک فایل به‌صورت پیوسته هستند، بنابراین فایلی که توسط تخصیص‌دهنده (allocator) در نقاط مختلف دیسک پخش شده، یا اشتباه سرهم می‌شود یا کلاً نادیده گرفته می‌شود. فایل‌های رسانه‌ای به دلیل داشتن headerهای قوی، نسبتاً خوب بازیابی می‌شوند. متن ساده، فایل‌های پیکربندی و کدهای منبع به خوبی بازیابی نمی‌شوند، زیرا هیچ امضای بایتی برای مشخص کردن شروع یک shell script وجود ندارد.

فاصلهٔ ناخواسته: چگونه مسیر اشتباه حذف شد

تقریباً هر حادثهٔ مربوط به rm -rf ناشی از مشکلات shell است. دستور rm فهرستی از مسیرها را دریافت کرده و هر کدام را به نوبت حذف می‌کند. این دستور هرگز قصد شما را متوجه نمی‌شود.

حالت کلاسیک، یک فاصلهٔ اضافه است:

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

خط اول شامل دو آرگومان است. این دستور ابتدا برنامه را حذف می‌کند و سپس /old را پاک می‌کند. اگر /old وجود نداشته باشد، rm هیچ خروجی‌ای چاپ نمی‌کند، زیرا -f خطای مربوط به فایل‌های موجود نبودن را سرکوب می‌کند. سکوت به معنای تأیید نیست.

شکل دوم، یک متغیر بدون کوتیشن است که حاوی یک فاصله است:

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

شل مقدار را بر اساس فضای خالی (whitespace) جدا می‌کند، بنابراین 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 '/' را چاپ کرده و متوقف می‌شود. فرم glob چنین محافظتی ندارد، زیرا شل پیش از آنکه rm اجرا شود، /* را با فهرستی از مسیرهای واقعی سطح بالا جایگزین می‌کند و از آنجا که / یکی از آن‌ها نیست، محافظ (guard) هرگز فعال نمی‌شود.

عادت‌هایی که از بروز خطای بعدی جلوگیری می‌کنند

• هر متغیری که به عنوان مسیر استفاده می‌شود را داخل کوتیشن قرار دهید. هر بار از "$dir" استفاده کنید، حتی در داخل تست‌ها و حلقه‌ها.
• در صورت خالی بودن متغیر، عملیات را متوقف کنید. rm -rf "${TARGET:?TARGET is not set}"/* باعث می‌شود اسکریپت شل با پیام شما قبل از شروع rm متوقف شود، هر زمان که TARGET تنظیم نشده یا خالی باشد. set -euo pipefail را در ابتدای هر اسکریپتی که عملیات حذف انجام می‌دهد، قرار دهید.
• از --one-file-system استفاده کنید. این دستور به rm می‌گوید از هر دایرکتوری که روی فایل‌سیستم متفاوتی نسبت به آرگومان ارسالی قرار دارد صرف‌نظر کند، تا حذف بازگشتی (recursive) نتواند به یک volume پشتیبان mount شده یا یک bind mount وارد شود.
• به عنوان root حذف نکنید. یک حساب کاربری سرویس فقط می‌تواند آنچه را که مالک آن است تخریب کند، که این خود دلیل اصلی اجرای هر سرویس با کاربر بدون دسترسی ویژه (unprivileged) مخصوص به خود است. اگر مطمئن نیستید یک حساب کاربری خاص به چه چیزی دسترسی دارد، خواندن بیت‌های مجوز در خروجی دستور ls با یک دستور پاسخ آن را می‌دهد.
• پیش از اقدام، لیست را چاپ کنید. در یک اسکریپت، مسیرها را بسازید، آن‌ها را printf '%s\n' کنید، خروجی را بخوانید و سپس در مرحله دوم عملیات حذف را انجام دهید.
• یک دستور trash در دسترس داشته باشید. sudo apt install trash-cli به شما trash-put، trash-list، trash-restore و trash-empty را می‌دهد. فایل‌های حذف شده به ~/.local/share/Trash منتقل می‌شوند و trash-empty 30 هر فایلی که قدیمی‌تر از سی روز باشد را پاکسازی می‌کند.

ساختن alias برای rm به trash-put گام بعدی منطقی به نظر می‌رسد، اما این یک تله است. این alias یک واکنش شرطی ایجاد می‌کند که در سرور بعدی که آن را ندارد با شکست مواجه می‌شود، و aliasها در داخل اسکریپت‌ها اعمال نمی‌شوند؛ یعنی همان‌جایی که اشتباهات پرهزینه رخ می‌دهند. دستور trash-put را عمداً تایپ کنید.

تنها بازیابی که همیشه کار می‌کند

هر آنچه در بالا گفته شد، یک احتمال است. پشتیبان‌گیری (Backup) یک احتمال نیست.

دو عامل پشتیبان‌گیری را واقعی می‌کند. اول اینکه طبق یک زمان‌بندی و بدون نیاز به یادآوری شما اجرا شود، و دوم اینکه حداقل یک‌بار از روی آن بازیابی (Restore) انجام داده باشید. مخزنی که هرگز از آن بازیابی نشده، صرفاً یک باور است؛ زیرا عواملی که باعث بی‌فایده بودن آن می‌شوند (مانند یک مسیر اشتباه در لیست شامل‌سازی، یا رمز عبور مخزنی که هیچ‌کس یادداشت نکرده است) تنها در روزی که به آن نیاز دارید، خود را نشان می‌دهند.

با restic، بازیابی تنها دو دستور است.

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

بازیابی را به جای مسیر اصلی (live path)، در یک دایرکتوری خالی انجام دهید تا بتوانید پیش از جایگزینی هر فایلی، آن دو را با هم مقایسه کنید. راه‌اندازی پشتیبان‌گیری restic روی VPS به تنظیمات مخزن و تایمر 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 به موضوع deduplication و مخازن فقط‌افزودنی (append-only) می‌پردازد؛ ویژگی‌ای که مانع از آن می‌شود که یک سرورِ نفوذشده، تاریخچه پشتیبان خود را حذف کند. هر دو ابزار مناسب هستند. انتخاب اشتباه، استفاده نکردن از هیچ‌کدام است.

یک سرور جدید، ارزان‌ترین زمان برای تنظیم این موارد است، پیش از آنکه چیزی روی آن باشد که ارزش از دست دادن داشته باشد. ده دقیقه اول روی یک VPS جدید جایی است که این کار باید در کنار تنظیمات SSH و فایروال انجام شود.

سپس یک یادآور تکرارشونده در تقویم خود قرار دهید: هر ماه یک دایرکتوری را از مخزن در /tmp بازیابی کنید و فایل‌ها را بخوانید. این عادتِ واحد، از تمام ابزارهای موجود در این صفحه ارزشمندتر است.

FAQ

آیا می‌توانم فایلی را در ext4 بازیابی کنم؟

معمولاً خیر. هنگامی که آخرین لینک به یک فایل حذف می‌شود، ext4 درخت extent را از inode پاک می‌کند، بنابراین هیچ رکوردی روی دیسک باقی نمی‌ماند که نشان دهد داده‌ها کجا بوده‌اند. extundelete و ext4magic ژورنال ext4 را برای یافتن نسخه‌ای قدیمی از آن inode جستجو می‌کنند، که تنها در صورتی مفید است که حذف فایل چند دقیقه پیش رخ داده باشد و فایل‌سیستم از آن زمان تاکنون ساکت بوده باشد. هیچ‌کدام از این دو پروژه فعالانه نگهداری نمی‌شوند. هر یک از آن‌ها را فقط روی یک دستگاه unmount شده یا یک image از دیسک اجرا کنید، هرگز روی فایل‌سیستم mount شده اجرا نکنید، و ابتدا با استفاده از sudo dumpe2fs -h /dev/vdb1 | grep -i journal بررسی کنید که با چه چیزی کار می‌کنید.

یک سرویس هنوز فایل حذف‌شده را باز نگه داشته است. آیا می‌توانم آن را پس بگیرم؟

بله، و این بهترین حالت ممکن است. تا زمانی که یک پردازش فایل را باز نگه داشته باشد، inode و بلوک‌های دادهٔ آن تخصیص‌یافته باقی می‌مانند، بنابراین داده‌ها همچنان قابل خواندن هستند. سرویس را restart نکنید، زیرا بستن آخرین descriptor، عملیات حذف را تکمیل می‌کند. دستور sudo lsof +L1 را اجرا کنید تا فایل‌های باز با تعداد لینک 0 را لیست کنید، PID و شماره file descriptor را یادداشت کنید، سپس با استفاده از /proc و sudo cp /proc/1234/fd/3 /mnt/rescue/events.log فایل را کپی کنید. کپی را روی یک فایل‌سیستم دیگر ذخیره کنید. ورودی‌هایی که با mem به جای شماره descriptor نمایش داده می‌شوند، در حافظه map شده‌اند و هیچ مسیر /proc/<pid>/fd برای کپی کردن ندارند.

چرا باید به جای اجرای ابزار بازیابی روی دیسک، از آن image بگیرم؟

زیرا هر ابزاری باید خروجی خود را در جایی بنویسد، و نوشتن روی فایل‌سیستمی که در حال بازیابی آن هستید ممکن است باعث شود داده‌ها روی بلوک‌های آزادی که هنوز حاوی اطلاعات شما هستند، بازنویسی شوند. ابتدا پارتیشن را با sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map روی یک دستگاه دیگر کپی کنید، سپس photorec را به فایل image اشاره دهید. این image همچنین به شما اجازه می‌دهد بعداً یک ابزار دوم را دقیقاً روی همان بایت‌ها امتحان کنید، کاری که پس از نوشتن هر چیزی روی دیسک اصلی، غیرممکن است.

آیا دستور rm -rf / هنوز یک سیستم لینوکسی را نابود می‌کند؟

این دستور به تنهایی خیر. ابزار rm در گنو از اجرای آن خودداری کرده و rm: it is dangerous to operate recursively on '/' را چاپ می‌کند. حالت‌های خطرناک آن‌هایی هستند که از مسیر دیگری وارد می‌شوند. rm -rf "$TARGET"/* در صورتی که TARGET تنظیم نشده باشد، به rm -rf /* بسط می‌یابد و شل لیستی از دایرکتوری‌های سطح بالای واقعی را به rm می‌دهد که هیچ‌کدام از آن‌ها / نیست، بنابراین محافظ فعال نمی‌شود. به جای آن "${TARGET:?TARGET is not set}" را بنویسید تا شل پیش از اجرای rm متوقف شود.

آیا snapshot فایل‌سیستم یک نسخه پشتیبان (backup) محسوب می‌شود؟

خیر. یک snapshot در btrfs یا ZFS روی همان poolای قرار دارد که داده‌های اصلی در آن هستند، بنابراین خرابی دیسک یا نابودی pool، هر دو را همزمان از بین می‌برد. snapshot در LVM مشکل اضافیِ اندازه ثابت را دارد: به محض پر شدن، کرنل آن را نامعتبر می‌کند و محتویاتش از دست می‌رود. snapshotها برای بازگرداندن یک حذف که دو دقیقه پیش رخ داده، عالی هستند. برای هر چیز دیگری، یک مخزن (repository) روی سخت‌افزار جداگانه نگهداری کنید.