1. مستندات
  2. سرور اختصاصی
  3. بازیابی اطلاعات در سرور اختصاصی لینوکس

بازیابی اطلاعات در سرور اختصاصی لینوکس

Calendar

انتشار:

1404/12/20
Update Calendar

به روز رسانی:

1404/12/20

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

مرحله اول: شناسایی سناریوهای خرابی و نیاز به بازیابی اطلاعات

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

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

حالت دوم مربوط به خرابی دیتابیس است. این خرابی می‌تواند به دلیل حذف جدول‌ها، خطای انسانی یا آسیب دیدن فایل‌های دیتابیس رخ دهد. در این حالت فقط دیتابیس باید بازیابی شود و فایل‌های سایت دست نخورده باقی می‌مانند.

در سناریوی شدیدتر ممکن است کل دیسک سیستم دچار مشکل شود یا سرور به طور کامل از دسترس خارج شود. در این وضعیت بازیابی کامل سیستم یا مهاجرت به سرور جدید ضروری است و باید از بکاپ کامل سیستم استفاده شود.

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

مرحله دوم: بررسی سلامت بکاپ قبل از هرگونه بازیابی

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

ls -lh /srv/backup/*.tar.gz

لیست فایل‌های tar.gz و تاریخ‌ها

ابتدا باید هش فایل بکاپ بررسی شود تا مطمئن شوید فایل در زمان ذخیره یا انتقال آسیب ندیده است. اگر هش با مقدار ثبت شده مطابقت نداشته باشد نباید عملیات بازیابی انجام شود.

sha256sum -c server_files_2026-02-02_0827.tar.gz.sha256

بعد از تایید هش باید ساختار آرشیو بدون استخراج کامل بررسی شود تا مطمئن شوید فایل قابل باز شدن است.

tar -tzf server_files_2026-01-28_0330.tar.gz | head

اگر این دو مرحله بدون خطا انجام شد می‌توان وارد فاز بازیابی شد.

خروجی لیست فایل‌های داخل بکاپ

مرحله سوم: بازیابی فایل‌ها از بکاپ فایل محور

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

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

sudo mkdir -p /srv/restore_tmp

سپس فایل بکاپ استخراج می‌شود.

sudo tar -xzf server_files_2026-01-28_0330.tar.gz -C /srv/restore_tmp

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

sudo rsync -aHAX /srv/restore_tmp/www/example.com/ /var/www/example.com/

این روش باعث می‌شود فقط فایل‌های مورد نیاز جایگزین شوند و سایر بخش‌ها دست نخورده باقی بمانند.

ریکاوری بک اپ

مرحله چهارم: بازیابی دیتابیس MySQL یا MariaDB از بکاپ منطقی

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

mysql -u root -p -e "CREATE DATABASE restore_db;"

سپس فایل بکاپ روی دیتابیس جدید بازگردانی می‌شود.

gunzip -c db_dbname_2026-01-28_0330.sql.gz | mysql -u root -p restore_db

بعد از اتمام بازیابی باید جدول‌ها بررسی شوند.

mysql -u root -p -e "SHOW TABLES FROM restore_db;"

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

نمای بازیابی موفق دیتابیس

مرحله پنجم: بازیابی دیتابیس بزرگ با بکاپ فیزیکی

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

sudo systemctl stop mysql

سپس دایرکتوری دیتابیس فعلی باید کنار گذاشته شود.

sudo mv /var/lib/mysql /var/lib/mysql_old

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

بعد از اتمام آماده‌سازی سرویس دیتابیس دوباره راه‌اندازی می‌شود و وضعیت بررسی می‌گردد.

sudo systemctl start mysql

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

مرحله ششم: بازیابی دیتابیس PostgreSQL

برای PostgreSQL نیز بهتر است ابتدا دیتابیس تست ساخته شود تا بازیابی بدون ریسک انجام شود.

sudo -u postgres createdb restore_test_db

سپس فایل بکاپ روی دیتابیس تست بازگردانی می‌شود.

sudo -u postgres pg_restore -d restore_test_db pg_dbname_2026-01-28_0330.dump

بعد از بازیابی باید جدول‌ها بررسی شوند تا از صحت عملیات مطمئن شوید.

sudo -u postgres psql -d restore_test_db -c "\dt"

در صورت تایید می‌توان دیتابیس اصلی را جایگزین کرد.

مرحله هفتم: بازیابی بکاپ از دیسک جدا یا فضای مانت شده

اگر بکاپ روی دیسک جدا یا بلاک استوریج نگهداری می‌شود ابتدا باید مطمئن شوید دیسک به درستی مانت شده است.

lsblk
mount | grep backup

در صورت نیاز باید دیسک به صورت دستی مانت شود.

sudo mount /dev/sdb1 /srv/backup

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

نمای مانت دیسک بکاپ

مرحله هشتم: بازیابی کامل سرور روی سیستم جدید

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

dpkg --set-selections < pkg_list_2026-01-28.txt
apt-get dselect-upgrade

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

در این مرحله تنظیمات شبکه و دسترسی SSH باید با دقت بررسی شوند تا از قطع شدن دسترسی جلوگیری شود.

مرحله نهم: تست نهایی بعد از بازیابی

بعد از هر نوع بازیابی باید سرویس‌ها بررسی شوند. وب سرور دیتابیس و سرویس‌های وابسته باید بدون خطا اجرا شوند.

systemctl status nginx
systemctl status mysql

لاگ‌ها باید بررسی شوند تا خطای پنهان وجود نداشته باشد.

journalctl -xe

بدون انجام این تست‌ها بازیابی کامل محسوب نمی‌شود.

مرحله دهم: ارتباط بازیابی با سیاست بکاپ

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

مدیر سرور باید بعد از هر بازیابی سیاست بکاپ را بازبینی کند تا مطمئن شود سناریوهای واقعی به درستی پوشش داده شده‌اند.


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

آیا توانستیم چالش شما را حل کنیم؟