آموزش گام‌به‌گام بکاپ منظم وردپرس؛ روندی که کار می‌کند
- بکاپ وردپرس؛ چه چیزی باید داخل آن باشد؟
- سه لایهٔ پشتیبان: فایلها، پایگاه داده و پیکربندی
- ریتم بکاپ؛ هر چند وقت یکبار، برای کدام تغییر؟
- کجا ذخیره کنیم؛ قاعدهٔ ۳-۲-۱ به زبان ساده
- آموزش گام‌به‌گام؛ روند شش‌قدمی پشتیبان‌گیری
- آزمون بازگردانی؛ بکاپی که تست نشده، بکاپ نیست
- پنج خطای رایج و اصلاح هرکدام
- جمع‌بندی؛ روند کوچک، بیمهٔ بزرگ
هیچ ابزار امنیتی، هیچ هاستی و هیچ قراردادی، جایگزین پشتیبان سالم نیست؛ بکاپ تنها لایه‌ای است که وقتی بقیهٔ لایه‌ها شکست خورده‌اند — آپدیت ناسازگار، خطای انسانی، دسترسی غیرمجاز — کار را ادامه می‌دهد. در پروژه‌های بازیابی که دیده‌ایم، تفاوت سایت‌های سریع برگشته و سایت‌های چندروز معلق، تقریباً همیشه یک چیز بوده است: داشتن یا نداشتن یک روند منظم و تست‌شدهٔ پشتیبان‌گیری.
این مقاله روند را می‌سازد، نه اضطرار. برای سناریوی بدترین حالت — وقتی سایت از دست رفته — راهنمای جداگانهٔ بازیابی سایت هک‌شده مسیر برگشت را باز می‌کند؛ و برای انتخاب ابزارهای مراقبت روزمره، مقایسهٔ بهترین افزونهٔ امنیتی وردپرس معیارها را می‌دهد. این‌جا روی چیزی تمرکز می‌کنیم که قبل از هر اتفاقی باید ساخته باشد: پشتیبان منظم.
بکاپ وردپرس؛ چه چیزی باید داخل آن باشد؟
بکاپ وردپرس فقط «یک فایل زیپ» نیست؛ سه چیز را باید هم‌زمان پوشش دهد و کمبود هر کدام، در روز بازگردانی آشکار میشود. اول، فایل‌های سایت: پوشهٔ محتوای شما — قالب‌ها، افزونه‌ها و هر تصویری که آپلود شده — به‌همراه فایل پیکربندی اصلی که مشخصات اتصال پایگاه داده در آن است. دوم، پایگاه داده: تمام متن‌ها، برگه‌ها، سفارش‌ها، کاربران و تنظیماتی که در دیتابیس زندگی می‌کنند؛ سایتی که فقط فایل‌هایش را دارد و دیتابیس ندارد، بدنه را دارد و روح را ندارد.
سوم، پیکربندیهای بیرون از وردپرس: تنظیمات هاست، گواهی امنیتی، رکوردهای دامنه و هر کاری که ادمین سرور مستقیم انجام داده. این لایهٔ سوم کمتر گفته میشود و در بازیابی‌های واقعی، بیشترین وقت را می‌گیرد، چون هیچ افزونه‌ای آن را شامل نمی‌شود. یک برگهٔ ساده بنویسید و فهرست کنید چه چیزهایی جایی بیرون از وردپرس تنظیم شده؛ همین فهرست، در روز بازگردانی، از چند ساعت جست‌وجوی حدسی جلوگیری می‌کند.
سه لایهٔ پشتیبان: فایلها، پایگاه داده و پیکربندی
تفکیک سه لایه، یک پیامد عملی دارد: ریتم بکاپ هر لایه می‌تواند متفاوت باشد. پایگاه داده با هر سفارش، هر مقاله و هر نظر تغییر می‌کند و نیازمند پشتیبان پرتکرار است؛ فایلها فقط وقتی عوض می‌شوند که چیز جدیدی آپلود یا کدی تغییر کند؛ پیکربندی سرور تقریباً ساکن است و فقط در تغییرهای زیرساختی به‌روزرسانی می‌خواهد. پشتیبانی یکنواخت برای هر سه لایه، یعنی یا دیتابیسِ کهنه یا فایل‌های تکراری بی‌فایده.
یک نکتهٔ اجرایی هم دربارهٔ «کامل بودن» بکاپ بگوییم: پشتیبانی که وسطش ناتمام مانده — سرور پر شده باشد یا پردازه نیمه‌کاره قطع شود — بدتر از نبودِ پشتیبان است، چون حس امنیت کاذب می‌دهد. برای همین در روند بخش پنج، گام پایانِ کار را جدی می‌گیریم: اندازهٔ فایل را چک کنید، گزارش تکمیل را ببینید و فقط بعد اعلام کنید این نسخه، نسخهٔ مرجع است.
ریتم بکاپ؛ هر چند وقت یکبار، برای کدام تغییر؟
پاسخ «هر چند وقت؟» به سرعت تغییر سایت وابسته است، نه به یک عدد طلایی. جدول، نقطهٔ شروع پیشنهادی ما بر اساس تجربهٔ سایت‌های رایج است؛ آن را با ریتم واقعی تغییر خودتان تنظیم کنید:
| نوع سایت / رویداد | ریتم پیشنهادی پشتیبان | نگهداری نسخه‌ها |
|---|---|---|
| فروشگاه با سفارش روزانه | دیتابیس روزانه؛ فایلها هفتگی | چرخهٔ کوتاه + چند نسخهٔ ماهانه |
| وبلاگ و سایت محتوایی | پیش از هر انتشار مهم + هفتگی | چرخهٔ چند نسخهٔ اخیر |
| سایت شرکتی کم‌تغییر | دوهفتگی دیتابیس + قبل از هر تغییر | چرخهٔ ساده + نسخهٔ پیش از آپدیت |
| پیش از هر آپدیت قالب/افزونه | پشتیبان کامل، همیشه | حداقل یک نسخهٔ پیش از آپدیت |
| پیش از مهاجرت یا تغییر هاست | پشتیبان کامل دستی + خروجی دیتابیس | تا تأیید سلامت مقصد |
ریتم را به تغییر گره بزنید: هر رویداد پرخطری مثل آپدیت، خودش یک بکاپ تازه می‌خواهد.
قاعدهٔ رفتاری ما ساده است: بکاپ، شرطِ کارِ خطرناک است، نه واکنش به تقویم. هر آپدیت، هر تغییر قالب، هر نصب افزونهٔ جدید، قبل از شروع باید پشتیبان تازهٔ خودش را بگیرد؛ تکرار این عادت به‌تنهایی، بیشترین حوادثی را که در پشتیبانی‌ها دیده‌ایم از ریشه مهار می‌کند، چون اکثر خرابی‌ها از خودِ تغییر شروع میشود، نه از بیرون.
کجا ذخیره کنیم؛ قاعدهٔ ۳-۲-۱ به زبان ساده
بکاپی که روی همان سرور سایت ذخیره شده، نیمی از کارهایش را نکرده است؛ وقتی سرور از دست برود یا قفل شود، پشتیبان هم با آن میرود. قاعدهٔ رایج میان متخصصان، ۳-۲-۱ است: سه نسخه از داده، روی دو رسانهٔ متفاوت، با یک نسخهٔ بیرون از سایت. در عمل وردپرسی یعنی: نسخهٔ سرور برای دسترسی سریع، نسخهٔ روی فضای ابری یا دایسک شخصی، و نسخه‌ای که واقعاً جایی دور از دسترسی عمومی نگه داشته میشود.
دو نکته دربارهٔ مقصدها. اول، دسترسی مقصد خودش یک ریسک است: حساب ابری که رمزش ضعیف است، پشتیبان شما را از بیرون لو می‌دهد؛ برای نسخه‌های دیتابیس — که دادهٔ مشتری در آن است — رمزگذاری یا حداقل حساب محافظت‌شده با ورود دومرحله‌ای بگذارید. دوم، چرخهٔ حذف: نگه‌داشتن بی‌پایان نسخه‌ها هم هزینه دارد هم خودش عامل اشتباه میشود؛ چرخه‌ای ساده تعریف کنید — نسخه‌های روزانهٔ اخیر، چند نسخهٔ هفتگی و یک نسخهٔ ماهانهٔ ماندگار — و به همان پایبند بمانید.
آموزش گام‌به‌گام؛ روند شش‌قدمی پشتیبان‌گیری
روند شش‌قدمی زیر را برای هفتهٔ معمولی تنظیم کنید؛ با هر افزونه یا سرویس پشتیبانی قابل اجراست و کمتر از چند دقیقه می‌گیرد. قدم اول، فهرست چکِ پیش از شروع: فضای کافی روی مقصد، حساب‌های متصل، سالم‌بودن دسترسی‌ها. قدم دوم، پشتیبان دیتابیس به‌عنوان لایهٔ پرتکرار. قدم سوم، پشتیبان فایلها طبق ریتم جدول بخش سه. قدم چهارم، انتقال یا هم‌گام‌سازی خودکار نسخهٔ تازه به مقصد دوم — این گام باید خودکار باشد؛ بکاپی که به حافظهٔ انسان وابسته است، دیر یا زود از تقویم جا می‌ماند.
قدم پنجم، تأیید تکمیل: گزارش موفقیت، اندازهٔ منطقی فایل و — هر چند هفته یکبار — بازگردانی آزمایشی طبق بخش بعد. قدم ششم، ثبت در برگهٔ روند: تاریخ، نسخه، مقصد. این ثبت ساده، در روز بحران حافظهٔ پروژه است؛ جایی که حدس‌زدنِ «آخرین بکاپ سالم کِی بود؟» گران‌ترین بازی سایت میشود. به تجربهٔ ما همین برگه، مرز میان تیم‌های آرام و تیم‌هایی است که هر بحران را از صفر حل می‌کنند.
آزمون بازگردانی؛ بکاپی که تست نشده، بکاپ نیست
آزمون بازگردانی، تنها راه اطمینان واقعی است: پشتیبانی که بازگردانی نشده، فقط یک امید مکتوب است. روند سبکش سه قدم است: روی زیردامنه یا محیط آزمایشی، آخرین نسخهٔ کامل را برگردانید؛ سایت آزمایشی را باز کنید و سه چیز را چک کنید — ورود، یک برگهٔ محتوایی و یک روند کلیدی مثل ثبت سفارش یا فرم؛ بعد گزارش کوتاه بنویسید چه چیزهایی جا افتاده بود. چند دقیقه تست، از ساعت‌ها بازیابی بدون نقشه در روز حادثه جلوگیری می‌کند.
دو اتفاق رایج را در همین آزمون‌ها می‌گیرید: نسخه‌هایی که ظاهرشان کامل است و دیتابیس‌شان ناقص، و وابستگی‌هایی که فقط روی سرور قبلی کار می‌کنند — مسیر فایل، نسخهٔ پی‌اچ‌پی، افزونه‌ای که لایسنسش را باید دوباره فعال کرد. پیدا شدن این‌ها در محیط آزمایشی، یعنی اصلاح در آرامش؛ پیدا شدنشان در روز حادثه، یعنی توقف فروش تا زمانی نامعلوم. برای مسیر کامل بازیابی بعد از دسترسی غیرمجاز، همان بازیابی سایت هک‌شده سناریو را مرحله‌به‌مرحله دارد.
پنج خطای رایج و اصلاح هرکدام
خطای اول و پرتکرارترین: بکاپ فقط روی همان هاست؛ با خرابی سرور، همه‌چیز با هم میرود و این دقیقاً همان حالتی است که پشتیبان برایش ساخته میشود. خطای دوم، بکاپی که هرگز تست نشده؛ فایل موجود بودنش با قابل بازگشتی‌بودنش یکی نیست. خطای سوم، ریتم منظم برای دیتابیس و فراموشی فایلها؛ گالری‌ها و پوشهٔ آپلودها فقط با فایلها برمی‌گردند.
خطای چهارم، نسخه‌های بی‌پایان بدون چرخهٔ حذف که فضای سرور را می‌خورند و خودشان عامل خطای «فضای کافی نیست» می‌شوند — درست وقتی بکاپ بعدی باید گرفته شود. خطای پنجم، شلوغ‌کردن ابزار: چند افزونهٔ پشتیبان هم‌زمان با تنظیمات متضاد؛ نتیجه، پشتیبانِ ناقص و گزارش‌های متناقض است. مثل تصاویر و بهینه‌سازی، این‌جا هم قاعدهٔ یک‌مالک‌بودن اجرا میشود: یک روش اصلی، یک مقصد دوم، یک برگهٔ روند. برای سخت‌گیرشدن روی ابزارهای مراقبت، مقایسهٔ بهترین افزونهٔ امنیتی وردپرس معیارهای انتخاب را می‌دهد.
جمع‌بندی؛ روند کوچک، بیمهٔ بزرگ
جمع کنیم: بکاپ منظم وردپرس سه لایه را با ریتمِ متناسب با تغییر پوشش می‌دهد، در دستکم دو مقصد جدا از سرور می‌نشیند، با روند شش‌قدمی خودکار جلو میرود و با آزمون بازگردانی دورهای اثبات میشود که کار می‌کند. هیچ‌کدام از این‌ها گران نیست؛ گران‌ترین حالت، نداشتنشان در روزی است که به آن‌ها نیاز دارید. روند را امروز یکبار کامل اجرا کنید و برگه‌اش را در دسترس تیم بگذارید؛ از آن بعد، فقط اجرا و بازبینی فصلی می‌ماند.
اگر می‌خواهید وضعیت فعلی دامنه‌تان — از امنیت تا ساختار محتوا — قبل از ساختن این روند دیده شود، ممیزی رایگان دامنه تصویر واقعی را می‌دهد؛ و برای مدیریت منظم انتشار و پایش سایت‌ها بدون وابستگی به حافظه و برگه‌های دستی، قابلیت‌های پلتفرم و صفحهٔ سئو و رشد فروشگاه اینترنتی نگاه سوئیت به این چرخه را نشان می‌دهند. پشتیبان، بیمهٔ ارزان پروژه است؛ فقط باید منظم و تست‌شده باشد.
رصد ما، رشد شما.
سؤالات پرتکرار
بکاپ وردپرس باید شامل چه چیزهایی باشد؟
سه لایه: فایلها (قالب، افزونه، پوشهٔ آپلود و فایل پیکربندی)، پایگاه داده و پیکربندیهای بیرون از وردپرس مثل تنظیمات هاست و رکوردهای دامنه؛ کمبود هر لایه در روز بازگردانی آشکار میشود.
هر چند وقت یکبار باید بکاپ بگیرم؟
به سرعت تغییر سایت وابسته است: فروشگاه با سفارش روزانه دیتابیس روزانه می‌خواهد و سایت کم‌تغییر دوهفتگی کافی است؛ مهم‌تر از تقویم، بکاپ تازهٔ پیش از هر آپدیت و تغییر خطرناک است.
بکاپ روی همان هاست کافی است؟
نه؛ با از دست رفتن سرور، پشتیبان هم با آن میرود. قاعدهٔ ۳-۲-۱ را اجرا کنید: چند نسخه، روی دو رسانهٔ متفاوت، با دستکم یک نسخهٔ بیرون از سرور.
چطور مطمئن شوم بکاپم واقعاً بازگردانی میشود؟
با آزمون بازگردانی دورهای: برگرداندن آخرین نسخه روی زیردامنه یا محیط آزمایشی و چککردن ورود، یک برگهٔ محتوایی و یک روند کلیدی مثل سفارش یا فرم؛ هر چند هفته یکبار کافی است.
بعد از هک شدن سایت، بکاپ قدیمی را برگردانم؟
فقط نسخهٔ سالمِ پیش از نفوذ و بعد از پاکسازی محیط؛ بازگردانی روی سایت آلوده، مشکل را دوباره وارد می‌کند. مسیر کامل را در مقالهٔ بازیابی سایت هک‌شده نوشته‌ایم.
