آموزش بازیابی فایل‌های پاک شده از سرور با نرم‌افزار

حذف فایل روی سرور با حذف فایل روی یک کامپیوتر شخصی تفاوت‌های بنیادین دارد. اینجا خبری از سطل زباله یا Recycle Bin نیست. فایل حذف می‌شود و در همان لحظه، فضای اشغالشده به سیستم فایل برمی‌گردد. اما ماجرا به همین سادگی تمام نمی‌شود. داده‌ها هنوز روی دیسک هستند؛ فقط آدرسشان از فهرست سیستم فایل پاک شده. درک این مکانیزم، کلید بازیابی موفق است.

سرورها چطور فایل‌ها را حذف می‌کنند؟

سیستم‌فایل‌های رایج سرور مثل ext4، XFS و NTFS هرکدام سازوکار حذف مخصوص خودشان را دارند. اما یک اصل مشترک بین همه هست: حذف یک فایل به معنای نابودی فیزیکی داده‌ها نیست. سیستم فایل فقط نشانگرهای آدرس‌دهی را حذف می‌کند و آن بلوک‌های داده را به عنوان فضای آزاد علامت‌گذاری می‌کند.

در ext4 (محبوب‌ترین سیستم فایل لینوکسی)، حذف فایل یعنی پاک شدن اشاره‌گر inode از جدول دایرکتوری و آزادسازی بلاک‌های مرتبط. خود inode و داده‌ها تا زمانی که اطلاعات جدیدی رویشان نوشته نشود، دست‌نخورده باقی می‌مانند. نکته مهم: ext4 از journaling استفاده می‌کند. ژورنال یک لاگ تراکنشی است که تغییرات متادیتا را ثبت می‌کند. در برخی شرایط، می‌شود از ژورنال برای ردیابی inodeهای اخیراً حذف‌شده استفاده کرد.

در XFS (سیستم فایل پیش‌فرض Red Hat و CentOS)، ماجرا کمی پیچیده‌تر است. XFS متادیتای فایل‌های حذف‌شده را تقریباً بلافاصله بازنویسی می‌کند. به همین دلیل بازیابی فایل از روی XFS سخت‌تر از ext4 است و معمولاً نتایج ضعیف‌تری دارد. این را کسانی می‌دانند که بارها بازیابی روی XFS را امتحان کرده‌اند.

روی سرورهای ویندوزی با NTFS، حذف فایل یعنی پاک شدن رکورد از Master File Table یا MFT. خود داده‌ها روی دیسک می‌مانند. اما NTFS یک عادت بد دارد: فضای خالی را سریع‌تر از ext4 بازاستفاده می‌کند، مخصوصاً روی حجم‌های پر. این یعنی زمان طلایی برای بازیابی کمتر است.

و اما ZFS. سیستم فایلی که روی FreeBSD، TrueNAS و برخی سرورهای لینوکسی استفاده می‌شود. ZFS از Copy-on-Write استفاده می‌کند. یعنی داده‌ها هیچ‌وقت مستقیماً بازنویسی نمی‌شوند. این ویژگی در تئوری بازیابی را آسان‌تر می‌کند، اما در عمل ابزارهای کمتری از ZFS پشتیبانی کامل دارند.

انواع حذف فایل در سرور؛ مسئله فقط Delete نیست

همه حذف‌ها شبیه هم نیستند. نوع حذف تعیین می‌کند چه روشی برای بازیابی جواب می‌دهد:

حذف ساده با rm یا delete: رایج‌ترین سناریو. اپراتور با دستور rm در لینوکس یا دکمه Delete در ویندوز سرور فایلی را پاک می‌کند. فایل از دید کاربر ناپدید می‌شود اما داده‌ها روی دیسک باقی هستند. این سناریو بیشترین شانس بازیابی را دارد.

حذف با shred یا پاک‌سازی امن: اگر کسی از shred، wipe یا sdelete استفاده کرده باشد، داده‌ها چندین بار بازنویسی شده‌اند. بازیابی تقریباً غیرممکن است. هیچ نرم‌افزاری هم کمکی نمی‌کند.

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

خرابی جدول پارتیشن یا RAID: گاهی فایل‌ها حذف نشده‌اند، بلکه ساختار دسترسی به آنها از بین رفته. خرابی MBR/GPT، حذف تصادفی Volume Group در LVM، یا شکست آرایه RAID. این موارد با ابزارهای بازیابی پارتیشن حل می‌شوند نه لزوماً ابزارهای بازیابی فایل.

Snapshot یا Shadow Copy پاک‌شده: روی سرورهای مجازی و برخی فایل‌سرورها، حذف یک اسنپ‌شات می‌تواند مجموعه‌ای از فایل‌ها را از دسترس خارج کند. اینجا بحث بازیابی خود اسنپ‌شات مطرح است، نه فایل تکی.

پیش‌نیازهای بازیابی؛ کارهایی که قبل از نصب نرم‌افزار باید انجام دهید

اولین و مهم‌ترین اقدام: آن پارتیشن را فقط خواندنی یا Read-Only کنید. روی لینوکس می‌توانید با دستور mount -o remount,ro پارتیشن را فقط خواندنی کنید. روی ویندوز سرور، سریعاً اشتراک‌های شبکه روی آن درایو را قطع کنید و سرویس‌هایی که ممکن است چیزی بنویسند متوقف کنید.

اگر سرور شما از LVM استفاده می‌کند، یک اسنپ‌شات از Volume بگیرید و عملیات بازیابی را روی اسنپ‌شات انجام دهید نه روی volume اصلی. این کار ریسک بازنویسی تصادفی را صفر می‌کند. دستور ایجاد اسنپ‌شات در LVM:

lvcreate -L 10G -s -n snap_name /dev/vg_name/lv_name

روی سرورهای فیزیکی با RAID سخت‌افزاری، اگر کنترلر RAID دارید، هرگز مستقیماً روی دیسک‌های عضو آرایه عملیات بازیابی انجام ندهید. اول یک ایمیج یا Clone از کل آرایه تهیه کنید. برای این کار می‌توانید از ddrescue استفاده کنید که حتی بدسکتورها را هم مدیریت می‌کند:

ddrescue /dev/sda /mnt/backup/disk_image.img /mnt/backup/rescue.log

برای سرورهای ابری (AWS EC2، DigitalOcean، ArvanCloud و غیره)، اگر Snapshot خودکار فعال دارید، اول اسنپ‌شات‌های موجود را چک کنید. بسیاری از سرویس‌های ابری دیسک را در سطح بلاک ذخیره می‌کنند و اسنپ‌شات‌های قدیمی بهترین راه بازیابی هستند. یک EBS Snapshot در AWS می‌تواند در عرض چند دقیقه کل یک volume را برگرداند.

برای سرورهای مجازی VMware یا Hyper-V، از قابلیت چک‌پوینت یا اسنپ‌شات هایپروایزر استفاده کنید. قبل از هر کاری یک چک‌پوینت از ماشین مجازی بگیرید. اگر عملیات بازیابی خراب‌کاری کرد، برگشت به حالت قبل چند ثانیه زمان می‌برد.

معرفی و مقایسه نرم‌افزارهای بازیابی مخصوص سرور

بازار نرم‌افزار بازیابی پر است از ابزارهای مختلف. اما همه برای سرور مناسب نیستند. تفاوت اصلی در پشتیبانی از سیستم‌فایل‌های سروری مثل ext4، XFS، ZFS و توانایی کار با آرایه‌های RAID و Volumeهای LVM است. ابزاری که روی یک فلش مموری جواب می‌دهد، لزوماً روی یک volume ده ترابایتی XFS کارایی ندارد.

یک نکته درباره ابزارهای رایگان: TestDisk و PhotoRec عالی هستند، اما محدودیت‌های جدی دارند. PhotoRec فایل‌ها را بر اساس الگوی هگزادسیمال شناسایی می‌کند و نام و ساختار پوشه اصلی را بازیابی نمی‌کند. اگر ۱۰۰ هزار فایل داشته باشید، خروجی PhotoRec تبدیل به کابوس می‌شود. هزاران فایل با نام‌هایی مثل f0012345.txt دریافت می‌کنید که باید تک‌تک بررسی شوند. برای سرور تولیدی با حجم بالای داده، این روش عملی نیست.

از طرف دیگر R-Studio و UFS Explorer می‌توانند ساختار کامل پوشه‌ها و نام فایل‌ها را بازیابی کنند. R-Studio مخصوصاً در شناسایی و بازسازی خودکار آرایه‌های RAID عالی عمل می‌کند. کافی است پارامترهای RAID مثل stripe size و ترتیب دیسک‌ها را به درستی تشخیص دهد که در ۸۰ درصد موارد همین کار را می‌کند.

راهنمای گام‌به‌گام بازیابی با R-Studio روی سرور لینوکسی

سناریو فرضی: یک سرور CentOS 7 با سیستم فایل XFS روی LVM. فایل‌های دیتابیس MySQL از مسیر /var/lib/mysql با دستور rm -rf اشتباهی پاک شده‌اند. سرور در دیتاسنتر است و دسترسی فیزیکی ندارید. این یک سناریوی واقعی است که بارها اتفاق افتاده.

گام اول – متوقف کردن سرویس‌ها: سرویس MySQL را فوراً متوقف کنید. اگر دیتابیس در حال نوشتن باشد، فایل‌های ibdata و ib_logfile مدام در حال تغییر هستند. دستور systemctl stop mysqld را اجرا کنید. سپس پارتیشنی که دیتابیس روی آن است را با mount -o remount,ro فقط خواندنی کنید.

گام دوم – تهیه ایمیج: یک دیسک خارجی با ظرفیت کافی به سرور متصل کنید (یا یک NFS mount با فضای کافی). با ddrescue از پارتیشن مورد نظر ایمیج بگیرید. مدت زمان این کار به حجم پارتیشن و سرعت دیسک بستگی دارد. برای یک volume یک ترابایتی روی SSD NVMe حدود ۳۰ تا ۴۵ دقیقه طول می‌کشد. روی HDD ممکن است ۳ تا ۴ ساعت زمان ببرد.

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

گام چهارم – اسکن ایمیج: در R-Studio گزینه Open Image را بزنید و فایل ایمیج را انتخاب کنید. سپس روی volume مورد نظر کلیک راست کرده و Scan را انتخاب کنید. در پنجره تنظیمات اسکن، گزینه Search for known file types را فعال کنید و فرمت‌های مورد نیاز (مثلاً .ibd, .frm, .myd) را تیک بزنید. اسکن کامل یک volume یک ترابایتی ممکن است ۲ تا ۶ ساعت طول بکشد.

گام پنجم – بررسی نتایج: پس از اتمام اسکن، R-Studio چندین volume شناخته‌شده را در پنل سمت چپ نشان می‌دهد. یکی از آنها با برچسب Recognized XFS ظاهر می‌شود. روی آن کلیک کنید. اگر ساختار پوشه‌ها سالم باشد، مسیر var/lib/mysql را می‌بینید. فایل‌های قابل بازیابی با یک علامت مشخص می‌شوند.

گام ششم – بازیابی: فایل‌های مورد نظر را انتخاب کنید، کلیک راست کرده و Recover Marked را بزنید. مسیر خروجی باید روی یک دیسک دیگر باشد، نه روی همان ایمیج یا پارتیشن اصلی. بازیابی فایل‌های دیتابیس معمولاً با موفقیت ۸۵ تا ۹۵ درصد همراه است، به شرطی که سرویس بلافاصله متوقف شده باشد.

بازیابی روی سرورهای RAID؛ پیچیدگی بیشتر اما شدنی

آرایه‌های RAID قصه را پیچیده می‌کنند. در RAID 0 داده‌ها بین دو یا چند دیسک توزیع می‌شوند . اگر یک فایل حذف شود، تکه‌های آن روی دیسک‌های مختلف پخش است. برای بازیابی باید آرایه را بازسازی کنید، یعنی stripe size، ترتیب دیسک‌ها و offset شروع داده را بدانید.

R-Studio و UFS Explorer قابلیت تشخیص خودکار این پارامترها را دارند. R-Studio با آنالیز هدر و فوتر فایل‌های شناخته‌شده روی دیسک‌های عضو آرایه، پارامترها را حدس می‌زند. برای RAID 5 با parity distributed دقت این تشخیص حدود ۷۰ تا ۸۰ درصد است. اگر تشخیص خودکار جواب نداد، باید پارامترها را دستی وارد کنید. این یعنی باید بدانید آرایه با چه stripe size ساخته شده (معمولاً ۶۴ کیلوبایت یا ۱۲۸ کیلوبایت) و ترتیب دیسک‌ها چه بوده.

در RAID 10 (ترکیب mirroring و striping) بازیابی آسان‌تر است. چون هر بلاک داده حداقل روی دو دیسک وجود دارد. حتی اگر یکی از دیسک‌ها مشکل داشته باشد، داده‌ها از mirror قابل بازیابی هستند.

نکته مهم: اگر کنترلر RAID سخت‌افزاری دارید (مثل HPE Smart Array، Dell PERC یا LSI MegaRAID)، هرگز دیسک‌ها را از کنترلر جدا نکنید و مستقیماً به مادربرد وصل نکنید. کنترلر RAID متادیتای مخصوص خودش را روی دیسک‌ها می‌نویسد و اگر دیسک‌ها را خارج از کنترلر بخوانید، داده‌ها به هم ریخته دیده می‌شوند. بهترین راه این است که کل Logical Drive را از طریق خود کنترلر به عنوان یک دیسک واحد ایمیج بگیرید.

ملاحظات SSD و تأثیر TRIM بر بازیابی

اگر سرور شما از SSD استفاده می‌کند، ماجرا فرق می‌کند. فرمان TRIM که در سیستم‌عامل‌های مدرن به صورت پیش‌فرض فعال است، بلوک‌های داده حذف‌شده را به کنترلر SSD اطلاع می‌دهد. کنترلر هم این بلوک‌ها را برای بازیابی عملکرد (garbage collection) پاک‌سازی می‌کند. نتیجه: داده‌های حذف‌شده روی SSD پس از مدت کوتاهی (گاهی چند دقیقه تا چند ساعت) برای همیشه از بین می‌روند.

در لینوکس، TRIM به دو صورت اجرا می‌شود: discard mount option که بلافاصله پس از هر حذف اجرا می‌شود، و fstrim که دوره‌ای (معمولاً هفتگی توسط systemd timer) اجرا می‌شود. اگر discard در fstab فعال باشد، شانس بازیابی از SSD تقریباً صفر است. اگر فقط fstrim هفتگی اجرا شود و فایل‌ها اخیراً حذف شده باشند، یک شانس محدود وجود دارد.

برای بررسی وضعیت TRIM روی لینوکس:

systemctl status fstrim.timer
mount | grep discard

روی SSDهای NVMe سازمانی (مثل Intel P4510 یا Samsung PM9A3)، فرآیند garbage collection تهاجمی‌تر است و داده‌های حذف‌شده سریع‌تر پاک می‌شوند. روی SSDهای SATA مصرفی، این فرآیند کندتر است. اما در هر دو حالت، به SSD به عنوان یک رسانه غیرقابل بازیابی برای فایل‌های حذف‌شده نگاه کنید. اگر SSD دارید و فایل مهمی پاک شده، هر ثانیه تأخیر یعنی کاهش شانس بازیابی.

بازیابی فایل‌های خاص: دیتابیس، ایمیل، ماشین مجازی

فایل‌های دیتابیس (MySQL/MariaDB، PostgreSQL، MongoDB) چالش ویژه‌ای دارند. این فایل‌ها مدام در حال نوشتن هستند. InnoDB دائماً در حال flush کردن بافر به دیسک است. وقتی یک فایل .ibd حذف می‌شود، ممکن است بخشی از داده‌ها قبلاً بازنویسی شده باشند. برای دیتابیس‌ها، بهترین استراتژی بازیابی از بک‌اپ است، نه نرم‌افزار بازیابی فایل. اما اگر بک‌اپ ندارید، شانس بازیابی برای دیتابیس‌هایی که روی HDD و با حجم write کم هستند، حدود ۶۰ تا ۷۰ درصد است. برای دیتابیس‌های پرتراکنش روی SSD، این عدد به زیر ۲۰ درصد می‌رسد.

فایل‌های ایمیل سرور (Maildir روی Postfix/Dovecot یا دیتابیس Exchange) الگوی مشابهی دارند. فایل‌های کوچک زیاد که هرکدام یک ایمیل را نگه می‌دارند. بازیابی این فایل‌ها با ابزارهای signature-based مثل PhotoRec نتیجه نسبتاً خوبی دارد، چون ساختار فایل‌های ایمیل (EML) الگوی مشخصی دارد.

فایل‌های ماشین مجازی (VMDK، VHDX، QCOW2) بدترین سناریو هستند. یک فایل VMDK ممکن است ۵۰۰ گیگابایت حجم داشته باشد. اگر چنین فایلی حذف شود، حتی اگر ۹۹ درصد داده‌ها سالم باشند، یک درصد خرابی می‌تواند کل فایل را غیرقابل استفاده کند. بازیابی فایل‌های حجیم ماشین مجازی نیازمند ابزارهایی است که fragmentهای فایل را به درستی سرهم کنند. R-Studio در این زمینه نسبتاً خوب عمل می‌کند، اما موفقیت کامل تضمین نیست.

چه زمانی باید از نرم‌افزار صرف‌نظر کنید و سراغ متخصص بروید

نشانه‌های واضحی وجود دارد که می‌گوید DIY جواب نمی‌دهد و باید با یک آزمایشگاه بازیابی داده تماس بگیرید:

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

دوم: دیسک اصلاً توسط BIOS یا سیستم‌عامل شناسایی نمی‌شود. این معمولاً خرابی برد الکترونیکی (PCB) یا firmware است.

سوم: پس از اسکن، R-Studio یا هر ابزار دیگری هیچ پارتیشنی پیدا نمی‌کند و signature scan هم چیزی برنمی‌گرداند. این می‌تواند نشانه بازنویسی کامل یا خرابی شدید ساختاری باشد.

چهارم: داده‌ها ارزش مالی یا حقوقی بسیار بالایی دارند. در این موارد حتی ۱ درصد ریسک هم قابل قبول نیست. آزمایشگاه‌های حرفه‌ای بازیابی داده با اتاق‌های Clean Room کلاس ۱۰۰ و تجهیزات تخصصی، شانس موفقیت را به حداکثر می‌رسانند.

سوالات متداول

آیا بعد از rm -rf در لینوکس واقعاً می‌شود فایل‌ها را برگرداند؟

بله، به شرطی که بلافاصله پارتیشن را فقط خواندنی کنید و سرویس‌هایی که ممکن است چیزی بنویسند متوقف شوند. rm فقط لینک فایل را از دایرکتوری حذف می‌کند. داده‌ها تا وقتی چیزی رویشان نوشته نشده، سر جای خود باقی هستند. موفقیت بازیابی روی ext4 معمولاً بالای ۸۰ درصد است، روی XFS حدود ۵۰ تا ۷۰ درصد.

برای سرور ویندوزی که فایل‌ها Shift+Delete شده‌اند چه نرم‌افزاری بهتر است؟

R-Studio نسخه ویندوز بهترین گزینه است. از NTFS و ReFS پشتیبانی کامل دارد و می‌تواند ساختار MFT را بازسازی کند. اگر سرور از Shadow Copy استفاده می‌کرد، اول نسخه‌های قبلی فایل‌ها را از طریق Properties > Previous Versions چک کنید. این روش رایگان و فوری است و نیاز به هیچ نرم‌افزار اضافه‌ای ندارد.

آیا نرم‌افزارهای بازیابی برای ZFS هم وجود دارند؟

بله ولی محدود. UFS Explorer بهترین پشتیبانی را از ZFS دارد، از جمله پشتیبانی از RAID-Z و ZVOL. R-Studio هم پشتیبانی نسبی دارد. اما ZFS به دلیل ساختار Copy-on-Write و اسنپ‌شات‌های داخلی، اصولاً باید از طریق خودش بازیابی شود. دستور zfs rollback اولین چیزی است که باید امتحان کنید.

چقدر زمان برای بازیابی فایل از سرور فرصت داریم؟

برای HDD بدون TRIM، تا زمانی که فضای مربوطه بازنویسی نشده باشد فرصت دارید. این می‌تواند چند ساعت تا چند هفته باشد، بستگی به میزان نوشتن روی دیسک دارد. برای SSD با TRIM فعال، پنجره فرصت بین چند دقیقه تا حداکثر چند ساعت است. برای سرورهای پرترافیک با دیسک تقریباً پر، این زمان می‌تواند کمتر از ۱۰ دقیقه باشد.

آیا می‌شود فایل‌های حذف‌شده روی سرور ابری را بازیابی کرد؟

بستگی به سرویس ابری دارد. در AWS اگر Snapshot خودکار یا دستی از EBS Volume داشته باشید، بازیابی کامل و ساده است. در DigitalOcean فقط از طریق Snapshot یا Backup داخلی می‌شود بازیابی کرد و به دیسک خام دسترسی ندارید. در سرورهای ابری ایران مثل ابر آروان، اگر Snapshot گرفته باشید قابل بازیابی است، وگرنه دسترسی سطح پایین به دیسک محدود است و نرم‌افزارهای معمول بازیابی کار نمی‌کنند.

تفاوت R-Studio و PhotoRec در چیست؟ کدام را انتخاب کنم؟

PhotoRec ساختار پوشه و نام فایل را بازیابی نمی‌کند. فایل‌ها را صرفاً بر اساس الگوی باینری شناسایی می‌کند و با نام‌های تصادفی ذخیره می‌کند. R-Studio ساختار کامل دایرکتوری، نام فایل، تاریخ ایجاد و حتی permissions را برمی‌گرداند. اگر یک فایل مشخص گم کرده‌اید، PhotoRec شاید کافی باشد. اگر یک دایرکتوری کامل با هزاران فایل حذف شده، R-Studio تنها گزینه عملی است.

آیا نصب نرم‌افزار بازیابی روی خود سرور کار درستی است؟

خیر. نصب نرم‌افزار یعنی نوشتن داده جدید روی دیسک. ممکن است دقیقاً روی همان بلوک‌هایی نوشته شود که فایل حذف‌شده شما آنجا قرار دارد. همیشه از یک سیستم دیگر برای بازیابی استفاده کنید و دیسک سرور را به عنوان دیسک Secondary یا از طریق ایمیج بررسی کنید. این قانون در هر شرایطی برقرار است.

جمع‌بندی

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

R-Studio و UFS Explorer انتخاب‌های اصلی برای سناریوهای پیچیده هستند. TestDisk و PhotoRec برای کارهای سریع و کم‌حجم جواب می‌دهند. اما هیچ‌کدام جای بک‌اپ منظم را نمی‌گیرند. بک‌اپی که هر شب گرفته شود و روی یک رسانه جداگانه ذخیره شود، همیشه ارزان‌تر و سریع‌تر از هر نرم‌افزار بازیابی‌ای است.