آموزش گام‌به‌گام ریستور بکاپ وردپرس؛ بازیابی سایت بدون استرس
- ریستور بکاپ وردپرس یعنی چه و کی لازم میشود؟
- قبل از ریستور؛ چهار تصمیمی که وقت بحران می‌خرند
- مسیر اول؛ بازیابی از پنل هاست
- مسیر دوم؛ بازیابی با افزونهٔ پشتیبان و مقایسهٔ سه مسیر
- مسیر سوم؛ بازیابی دستی برای وضعیت‌های بغرنج
- بعد از ریستور؛ چکلیست سلامت سایت
- اگر سایت هک شده بود؛ ریستور تنها کافی نیست
- جمع‌بندی؛ بازیابی را قبل از بحران تمرین کنید
این راهنما برای صبحی است که امیدواریم هرگز از سر نگذرانید: سایت به‌هم ریخته، صفحهٔ سفید شده یا پیام هک بالای سایت نشسته. در چنین لحظه‌ای، تصمیم‌های ده‌دقیقهٔ اول مهم‌تر از سرعت کلیک‌های بعدی است؛ ریستور درست یعنی برگشتن به نسخهٔ سالم بدون از دست دادن سفارش‌ها، محتواها و اطلاعات تازه.
لایهٔ قبل از این مطلب، ساختن پشتیبان است: در راهنمای بکاپ وردپرس روند منظم پشتیبان‌گیری و قاعدهٔ ۳-۲-۱ باز شده و در هاب امنیت و پشتیبان‌گیری نقشهٔ کامل حوزه است. اینجا سراغ روز بازیابی می‌رویم؛ همان روزی که کیفیت پشتیبان‌های گذشته را پس می‌گیرید.
ریستور بکاپ وردپرس یعنی چه و کی لازم میشود؟
بکاپ، نسخهٔ ذخیره‌شدهٔ سایت است؛ ریستور، عمل برگرداندن همان نسخه روی سایت زنده. این دو فاز یک فرایندند اما مهارت‌های جداگانه می‌خواهند: پشتیبان‌گیری روتین هفتگی است، ریستور یک عملیات بحرانی یک‌باره. سناریوهای رایجی که ریستور را لازم می‌کنند: آپدیت شکسته یا تداخل دو افزونه، حذف اشتباهی محتوا یا جدول دیتابیس، دستکاری ناموفق کد، و البته نفوذ. در هر چهار حالت، منطق کار یکی است اما دامنهٔ بازیابی فرق میکند.
دامنهٔ بازیابی همان چهار تصمیم اول است: کل سایت برمی‌گردد یا فقط فایل‌ها یا فقط دیتابیس؟ آیا محتوای تازهٔ بعد از آخرین پشتیبان — سفارش‌ها، ثبت‌نام‌ها، مقاله‌های جدید — قابل نجات است؟ به تجربهٔ ما اینجا جایی است که تیم‌ها دو سر اشتباه می‌افتند: یا همه‌چیز را با یک نسخهٔ چندروزه بازنویسی می‌کنند و دادهٔ سالم را هم می‌بازند، یا ساعت‌ها می‌جنگند تا «دست نزده» بازیابی کنند و در میانه، سایت نیمه‌تعمیر خودش را هم خراب می‌کنند. چهار تصمیم بخش بعد، همین استرس را از سر راه برمی‌دارد.
قبل از ریستور؛ چهار تصمیمی که وقت بحران می‌خرند
تصمیم اول، دامنه است: اگر فقط یک افزونه سایت را شکسته، ریستور کامل لازم نیست؛ فایل همان افزونه به نسخهٔ قبل برمی‌گردد و دیتابیس دست‌نخورده می‌ماند. اگر دیتابیس آسیب دیده، بازیابی فقط جدول‌های آسیبدیده گزینهٔ بعدی است. ریستور کامل — فایل‌ها به‌همراه دیتابیس — برای حالت‌های جدی مثل نفوذ یا خرابی گسترده کنار گذاشته میشود. تصمیم دوم، علت است: اگر علت معلوم نباشد، احتمال تکرارش بعد از ریستور بالا است؛ گزارش خطا و زمان دقیق شروع مشکل را یادداشت کنید.
تصمیم سوم، گرفتن نسخه از وضعیت فعلی است؛ عجیب به نظر می‌رسد اما حیاتی است: نسخهٔ خراب، شواهد را نگه می‌دارد. اگر در میانهٔ راه متوجه شوید آخرین بکاپ خیلی قدیمی است، همین نسخه شاید بشود سفارش‌ها یا مقاله‌های تازه را از آن بیرون کشید؛ در حالت نفوذ هم همین نسخه مبنای بررسی میشود. تصمیم چهارم، انتخاب بستر بازیابی است: پنل هاست، افزونه یا دستی — سه مسیر بخش‌های بعد. و اگر امکانش هست، اول در محیط آزمایشی بازیابی کنید؛ بازیابی تمرینی در حالت تعلیق، ریسک سایت زنده را نمی‌گیرد.
مسیر اول؛ بازیابی از پنل هاست
برای اغلب سایت‌ها، سریع‌ترین مسیر همان پنل هاست است: بخش پشتیبان یا Backup Wizard را باز کنید، تاریخ نسخهٔ سالم را انتخاب کنید و مشخص کنید چه چیزی برمی‌گردد — فایل‌ها، دیتابیس یا هر دو. قاعدهٔ مهم: فایل و دیتابیس باید از یک تاریخ باشند؛ ترکیب فایلِ امروز با دیتابیسِ دو روز قبل، نسخهای می‌سازد که هیچ‌وقت سالم نبوده و خطاهایی میدهد که ردیابی‌شان سخت است.
دو نکته در همین مسیر: اول، پیش از تأیید نهایی، ببینید پنل پیش از بازنویسی خودش نسخهٔ فعلی را ذخیره میکند یا نه؛ اگر نمی‌کند، دستی ذخیره کنید. دوم، بعد از پایان بازیابی، نسخهٔ PHP و تنظیمات هاست را هم چک کنید؛ گاهی مشکل از سازگاری نسخه بوده، نه از فایل‌ها، و ریستور همان مشکل را با همان محیط دوباره تکرار میکند. اگر هاست پشتیبان خودکار روزانه دارد، همیشه از کامل‌ترین و تازه‌ترین نسخهٔ موجود استفاده کنید، نه قدیمی‌ترین نسخهٔ قابل‌دسترس.
مسیر دوم؛ بازیابی با افزونهٔ پشتیبان و مقایسهٔ سه مسیر
مسیر دوم، افزونهٔ پشتیبان‌گیری است — هر افزونهٔ معتبری بخش بازیابی دارد و روند کلی یکسان است: برگهٔ Restore، انتخاب نسخه و انتخاب اجزا، سپس تأیید. سه نکتهٔ عملی: افزونهٔ بازیابی‌کننده باید همان نسخهای باشد که پشتیبان را ساخته؛ اگر سایت را از افزونه‌ای به افزونهٔ دیگر منتقل کرده‌اید، فرمت فایل‌ها سازگار نیست و بازیابی دستی می‌خواهد. دوم، قبل از ریستور، تداخل را کم کنید: افزونه‌های اضافی را موقتاً غیرفعال کنید تا فرایند نیمه‌کاره نماند. سوم، پیام‌های هشدار بازیابی — مثل نبودن فضا — را جدی بگیرید؛ کمبود فضا رایج‌ترین دلیل نیمه‌تمام ماندن بازگردانی است.
جدول زیر سه مسیر را کنار هم می‌گذارد تا انتخاب سریع باشد:
| مسیر | مناسب چه وضعیتی | ریسک اصلی |
|---|---|---|
| پنل هاست | ریستور کامل، سایت‌های بدون افزونهٔ پشتیبان | بازنویسی کامل؛ انتخاب تاریخ اشتباه برگشت‌پذیر نیست |
| افزونهٔ پشتیبان | بازیابی انتخابی فایل/دیتابیس، ریتم روزانه | تداخل افزونهها و نیمه‌تمام ماندن در کمبود فضا |
| بازیابی دستی | بغرنج‌ها: سایت قفل، افزونهٔ پشتیبان کار نمی‌کند | خطای انسانی در فایل‌ها و ایمپورت دیتابیس |
ترتیب پیشنهادی ما: پنل هاست برای ریستور کامل، افزونه برای بازیابی انتخابی، دستی فقط وقتی دو مسیر اول جواب نداده‌اند.
انتخاب افزونه برای جلوتر از بحران، بحث جدایی است که در بهترین افزونه امنیتی وردپرس به آن پرداخته‌ایم؛ اینجا فرض ما این است که پشتیبان از قبل درست ساخته شده و حالا وقت برداشت محصول است.
مسیر سوم؛ بازیابی دستی برای وضعیت‌های بغرنج
بازیابی دستی، مسیر نجات در وضعیت‌هایی است که سایت حتی پنل وردپرس را باز نمی‌کند. گام اول، فایل‌ها است: از مدیریت فایل هاست یا FTP، محتوای نسخهٔ پشتیبان را در پوشهٔ سایت بازنویسی کنید — پوشه‌های wp-content و فایل‌های اصلی وردپرس. گام دوم، دیتابیس است: در phpMyAdmin، دیتابیس را انتخاب، جدول‌های فعلی را حذف و فایل SQL پشتیبان را ایمپورت کنید؛ پیش از حذف، از وضعیت فعلی هم یک خروجی بگیرید.
گام سوم، اتصال است: در wp-config.php نام دیتابیس، کاربر و رمز باید با هاست فعلی بخواند؛ اگر دیتابیس را با نام دیگری ساخته‌اید همین‌جا اصلاح میشود. گام چهارم، آدرس‌هاست: اگر دامنه یا مسیر عوض شده، دو ردیف siteurl و home در جدول wp_options اصلاح شوند و برای لینک‌های داخل محتوا از ابزار جستجو‌و‌جایگزین مطمئنِ دیتابیس استفاده کنید، نه ویرایش دستی سریالی. گام پنجم، ساختارهای دائمی را یک‌بار در تنظیمات پیوندهای یکتا بازخوانی کنید و کش را پاک کنید. این مسیر مهارت پایگاه داده می‌خواهد؛ اگر میزبان دادهٔ فروشی هستید و تجربهٔ مشابه ندارید، همین گام‌ها را به متخصص بسپارید — هزینهٔ مشورت، بخشی از هزینهٔ خطای ایمپورت نیست.
بعد از ریستور؛ چکلیست سلامت سایت
ریستور تمام‌شده یعنی سایت بالا آمد؛ ریستور موفق یعنی چکلیست سلامت هم بسته شد. چکلیست ما هشت‌گانه است و ترتیب دارد: ورود مدیر و بازنشانی گذرواژهها — مدیریت کاربران و نقش‌ها را در مدیریت کاربران وردپرس نوشته‌ایم؛ به‌روز بودن وردپرس و افزونهها به همان تاریخی که پشتیبان ساخته شده نباید برگردد، فوری آپدیت کنید؛ سلامت گواهی امنیتی و باز بودن سایت با https؛ ثبت شدن سفارش تازهٔ آزمایشی در ووکامرس و رسیدن اعلان‌ها.
ادامهٔ لیست: آزمون فرمها و ارسال ایمیل؛ بازبینی پوشش ایندکس در سرچ‌کنسول برای دیدن خطاهای تازه؛ پاکسازی کامل کش سایت و CDN؛ و ثبت تاریخ بازیابی در یادداشت‌های سایت تا دفعهٔ بعد بدانید چه زمانی و با چه علتی ریستور شده است. این هشت مورد را یک بار به‌شکل برگه آماده کنید؛ در لحظهٔ بحران، برگهٔ آماده جای حافظهٔ استرس‌زده را می‌گیرد. هر موردی که برگه نداشته باشد، دقیقاً همان موردی است که وسط بازیابی فراموش میشود؛ برگه را کنار اطلاعات دسترسی هاست بایگانی کنید تا در نبود شما هم اجراشدنی باشد.
اگر سایت هک شده بود؛ ریستور تنها کافی نیست
در حالت نفوذ، ریستور فقط نیمی از کار است: اگر نسخهٔ سالم را روی سایت آلوده برگردانید یا درِ ورودی باز بماند، نفوذ تکرار میشود. ترتیب درست، همان فازبندی بازیابی سایت هکشده است: اول قرنطینه و ارزیابی آسیب، بعد پاکسازی، بعد بازگردانی نسخهٔ تمیز و در آخر مقاومسازی. نسخهٔ پشتیبانی که از قبل از کشف نفوذ ساخته شده، ممکن است خودش آلوده باشد؛ تاریخ نسخه را با زمان اولین نشانهٔ مشکل مقایسه کنید.
بعد از بازگشت، رمزهای حیاتی همه تازه شوند: گذرواژه‌های مدیران، کلیدهای امنیتی وردپرس و اطلاعات اتصال‌ها. و یک نکتهٔ سئویی که گاهی فراموش میشود: دورهٔ قفل‌شدن یا مشکلات امنیتی، روی سئو هم اثر می‌گذارد؛ بعد از پایدار شدن سایت، وضعیت ایندکس و ریدایرکت‌ها را در سرچ‌کنسول بررسی کنید تا اثر بحران روی دیده‌شدن سایت، بدون پاسخ نماند. اگر در ارزیابی آسیب مشخص شد کد تزریق‌شده داخل قالب یا دیتابیس بوده، پیش از ریستور، منشأ را پیدا کنید؛ وگرنه نسخهٔ تمیز، دوباره آلوده میشود و چرخه از اول تکرار میشود.
جمع‌بندی؛ بازیابی را قبل از بحران تمرین کنید
جمع‌بندی: ریستور بکاپ وردپرس سه مسیر دارد — پنل هاست برای ریستور کامل، افزونه برای بازیابی انتخابی و دستی برای بغرنج‌ها — و موفقیتش به دو تصمیم گره خورده: دامنهٔ بازیابی و نسخهٔ درست. چکلیست هشتگانهٔ پس از ریستور را از همین امروز آماده کنید و هر فصل یک‌بار در محیط آزمایشی، یک بازیابی کامل را تمرین کنید؛ بکاپی که بازگردانی‌اش هرگز تست نشده، از نظر عملیاتی وجود ندارد.
اگر مدیریت این چرخه را می‌خواهید برون‌سپاری کنید، در سوئیت پشتیبان و انتشار با امنیت سازمانی مدیریت میشود — ذخیرهٔ پشتیبان با امضای HMAC-SHA256 و رمزنگاری AES-256، و هر انتشار با بیش از ۹۰۰ تست خودکار — و جزئیاتش در صفحهٔ امنیت پلتفرم آمده است. روتین ماهانهٔ نگهداری را هم در نگهداری ماهانهٔ وردپرس نوشته‌ایم و ممیزی رایگان دامنه نشان میدهد وضعیت فعلی سایت‌تان از کدام لایه شروع شود. به تجربهٔ ما تیم‌هایی که بازیابی را تمرین کرده‌اند، بحران را با برگه مدیریت می‌کنند نه با هیجان؛ تفاوت این دو، چند ساعت قطعی کمتر است.
رصد ما، رشد شما.
سؤالات پرتکرار
ریستور بکاپ وردپرس چقدر طول می‌کشد؟
برای سایت کوچک و متوسط، از پنل هاست معمولاً زیر یک ساعت و با افزونهٔ پشتیبان در حدود یک تا دو ساعت؛ بازیابی دستی بسته به حجم دیتابیس بیشتر طول می‌کشد. زمان واقعی به حجم فایل‌ها و سرعت هاست بستگی دارد.
ریستور کامل بزنم یا فقط بخش آسیبدیده را؟
اول دامنهٔ آسیب را مشخص کنید؛ اگر یک افزونه یا یک بخش مشکلساز است، بازیابی انتخابی همان بخش کافی است. ریستور کامل فقط برای خرابی گسترده یا نفوذ کنار گذاشته میشود و دادهٔ تازهٔ بعد از نسخهٔ پشتیبان را از دست میدهد.
محتوای بعد از آخرین پشتیبان را از دست می‌دهم؟
در ریستور کامل بله؛ به همین دلیل اول از وضعیت فعلی هم نسخه بگیرید تا سفارش‌ها و محتوای تازه قابل بازیابی جداگانه بماند. بازیابی انتخابی فایل یا جدول، این ریسک را کم میکند.
سایت هکشده را مستقیم ریستور کنم؟
نه؛ اول قرنطینه و پاکسازی، بعد بازگردانی نسخهٔ تمیز و در آخر مقاومسازی. نسخهای که بعد از زمان نفوذ ساخته شده احتمالاً آلوده است و ریستور مستقیم، مشکل را تکرار میکند.
بعد از ریستور اولین کار چیست؟
ورود مدیر و بازنشانی گذرواژهها، سپس بهروزرسانی وردپرس و افزونهها به نسخهٔ امن و بعد چکلیست هشتگانهٔ سلامت: گواهی، سفارش آزمایشی، فرمها، ایندکس، کش و ثبت تاریخ بازیابی.
