بکاپ هاست وردپرس باید چند وقت یکبار تهیه شود؟
فاصله بکاپ باید از میزان دادهای که میتوانید از دست بدهید کمتر باشد. سایت شرکتی کمتغییر با بکاپ روزانه قابل مدیریت است، اما فروشگاه فعال ممکن است به بکاپ دیتابیس ساعتی یا پیوسته نیاز داشته باشد.
پاسخ کوتاه: بکاپ وردپرس را هر چند وقت یکبار بگیریم؟
فاصله بکاپ را بر اساس بیشترین داده قابلقبول برای از دستدادن تعیین کنید. سایت شرکتی که هفتهای یک بار تغییر میکند معمولاً با بکاپ روزانه و چند نقطه بازیابی پوشش مناسبی دارد. وبلاگ روزانه به بکاپ روزانه یا چندبار در روز نیاز دارد. فروشگاه فعال ممکن است برای دیتابیس به نسخه ساعتی، تراکنشی یا پیوسته نیاز داشته باشد.
زمانبندی مناسب بکاپ از «تعداد بازدید» نمیآید؛ از نرخ تغییر داده، ارزش سفارش، زمان بازیابی و تحمل از دست رفتن اطلاعات به دست میآید.
بکاپی که Restore آن آزمایش نشده، تضمین بازیابی نیست. علاوه بر زمانبندی، محل نگهداری، Retention، رمزنگاری و تمرین Restore را در برنامه وارد کنید.
بکاپ کامل وردپرس شامل چه چیزهایی است؟
سایت وردپرس از دیتابیس و فایلها تشکیل شده است. دیتابیس نوشته، تنظیمات، کاربر، سفارش، دیدگاه و بسیاری از دادههای افزونه را نگه میدارد. فایلها شامل هسته، قالب، افزونه، Upload، فایل پیکربندی و تنظیمات اختصاصی سرور هستند.
- دیتابیس MariaDB یا MySQL
wp-content/uploadsو رسانهها- قالب، Child Theme، افزونه و MU Plugin
wp-config.phpو فایلهای پیکربندی- قوانین وبسرور و Cronهای مرتبط
- در صورت نیاز، ایمیل و DNS بهصورت فرایند جدا
WordPress در راهنمای رسمی خود نیز Restore را با بازگرداندن فایلها و سپس Import دیتابیس توضیح میدهد. بکاپ فقط Export محتوای Tools نیست؛ Export وردپرس تمام تنظیمات و فایلهای سرویس را پوشش نمیدهد.
RPO و RTO را ساده تعریف کنیم
RPO بیشترین بازه دادهای است که میتوانید از دست بدهید. اگر RPO یک ساعت باشد، فاصله بکاپ یا Replication باید بتواند این هدف را پوشش دهد. RTO حداکثر زمان قابلقبول برای بازگرداندن سرویس است.
| مثال | RPO | RTO |
|---|---|---|
| سایت شرکتی کمتغییر | تا یک روز | چند ساعت |
| وبلاگ خبری | چند ساعت | کمتر از یک ساعت |
| فروشگاه فعال | چند دقیقه تا یک ساعت | بسیار کوتاه |
| پرتال حیاتی | نزدیک صفر | طبق SLA مشخص |
بکاپ روزانه نمیتواند RPO یکساعته را تضمین کند. در مقابل، گرفتن نسخه ساعتی از سایت کمتغییر بدون Retention و تست، فقط هزینه ذخیرهسازی را بالا میبرد.
جدول زمانبندی پیشنهادی بکاپ وردپرس
| نوع سایت | دیتابیس | فایلها | نکته |
|---|---|---|---|
| سایت شرکتی کمتغییر | روزانه | روزانه یا پس از تغییر | نسخه قبل از Update ضروری است. |
| وبلاگ با انتشار روزانه | روزانه یا هر ۶ تا ۱۲ ساعت | روزانه | Upload جدید را در نظر بگیرید. |
| سایت عضویت | هر ۱ تا ۶ ساعت | روزانه | کاربر و فعالیت در دیتابیس تغییر میکند. |
| فروشگاه کوچک | هر ۱ تا ۶ ساعت | روزانه | ارزش سفارش فاصله را تعیین میکند. |
| فروشگاه پرتراکنش | ساعتی، Incremental یا پیوسته | روزانه + تغییرات | بازیابی تراکنش باید طراحی شود. |
| قبل از Deploy یا مهاجرت | فوری | فوری | Snapshot مستقل از برنامه عادی بگیرید. |
این اعداد نقطه شروعاند، نه قانون ثابت. RPO تجاری، ظرفیت ذخیرهسازی و سرعت Restore باید برنامه نهایی را مشخص کنند.
دیتابیس را بیشتر از فایلها بکاپ بگیریم؟
در بسیاری از سایتها بله. فایل قالب و افزونه بین Updateها ثابت میماند، اما دیتابیس با هر سفارش، دیدگاه، ثبتنام یا تغییر تنظیمات عوض میشود. رسانه نیز هنگام Upload تغییر میکند. میتوان دیتابیس را پرتکرارتر و فایلها را روزانه یا پس از تغییر ذخیره کرد.
بااینحال فایل و دیتابیس باید برای یک نقطه زمانی سازگار باشند. Restore دیتابیس جدید روی فایل افزونه بسیار قدیمی ممکن است ناسازگاری ایجاد کند. نسخههای مرتبط را با Timestamp و Manifest نگهداری کنید.
Full Backup و Incremental Backup چه تفاوتی دارند؟
Full Backup تمام داده انتخابشده را ذخیره میکند و بازیابی آن سادهتر است، اما زمان و فضای بیشتری مصرف میکند. Incremental فقط تغییرات بعد از نسخه پایه را نگه میدارد و برای دفعات بیشتر مناسب است، ولی Restore به زنجیره سالم وابسته میشود.
| نوع | مزیت | ریسک یا هزینه |
|---|---|---|
| Full | Restore ساده و مستقل | فضا و زمان بیشتر |
| Incremental | سریعتر و کمحجمتر | وابستگی به زنجیره |
| Differential | تعادل میان دو روش | حجم افزایشی تا Full بعدی |
| Snapshot | بازگشت سریع در سطح Storage | ممکن است خارج از همان زیرساخت نباشد |
معماری حرفهای معمولاً ترکیبی از Full دورهای، Incremental پرتکرار و نسخه Offsite دارد.
قبل از چه تغییراتی بکاپ فوری لازم است؟
- بهروزرسانی هسته، قالب و افزونه مهم
- تغییر PHP، دیتابیس یا تنظیمات کش
- Deploy کد و Migration دیتابیس
- Import یا حذف گروهی محصول و کاربر
- تغییر دامنه، HTTPS یا Search Replace
- پاکسازی بدافزار و Hardening
- انتقال به هاست جدید
این Snapshot جای برنامه دورهای را نمیگیرد؛ نقطه بازگشت نزدیک به تغییر است. برای مهاجرت، مقاله انتقال وردپرس به هاست جدید بدون قطعی را دنبال کنید.
چند نسخه نگه داریم و Retention چگونه باشد؟
نگهداشتن فقط آخرین نسخه خطرناک است؛ خرابی یا بدافزار ممکن است پیش از تهیه نسخه شناسایی نشده باشد. Retention باید چند بازه زمانی ایجاد کند: نسخههای نزدیک برای خطای اخیر و نسخههای قدیمیتر برای مشکل دیرکشفشده.
- چند نسخه روزانه اخیر
- چند نسخه هفتگی
- نسخه ماهانه برای آرشیو بلندمدت در صورت نیاز
- Snapshot جدا قبل از تغییرات پرریسک
تعداد دقیق به قانون نگهداری داده، هزینه و ریسک وابسته است. نسخههای قدیمی حاوی اطلاعات شخصی نیز باید تحت سیاست امنیت و حذف قرار بگیرند.
قاعده 3-2-1 برای بکاپ چیست؟
یک الگوی رایج این است که سه نسخه از داده، روی دو نوع رسانه یا سامانه، و حداقل یک نسخه خارج از محل اصلی نگهداری شود. هدف جلوگیری از نقطه شکست مشترک است. اگر Production و تمام Backupها روی یک دیسک یا یک حساب باشند، خرابی یا نفوذ میتواند همه را همزمان از بین ببرد.
برای سرویس حیاتی، نسخه Immutable یا با دسترسی محدودتر نیز ارزشمند است تا باجافزار یا Credential سرقتشده نتواند تاریخچه را حذف کند.
چرا بکاپ باید خارج از سرور اصلی باشد؟
- خرابی Storage یا RAID میتواند Production و Backup محلی را درگیر کند.
- نفوذ به حساب ممکن است فایلهای Backup را نیز حذف کند.
- پرشدن دیسک میتواند فرایند Backup را ناقص کند.
- خطای انسانی در حذف Account ممکن است نسخه محلی را پاک کند.
- حادثه دیتاسنتر به نسخه جغرافیایی جدا نیاز دارد.
نسخه خارج از سرور باید با Credential مستقل، رمزنگاری و سیاست دسترسی محدود نگهداری شود. فقط انتقال به پوشه دیگری روی همان دیسک Offsite محسوب نمیشود.
آیا بکاپ شرکت هاستینگ بهتنهایی کافی است؟
بکاپ میزبان یک لایه مهم است، اما مالک سایت باید سیاست را بداند: دفعات، Retention، محل نگهداری، امکان Restore، هزینه، زمان و استثناها. برخی قراردادها Backup را «بهترین تلاش» میدانند و مسئولیت نهایی داده را بر عهده مشتری میگذارند.
- آیا Backup روی سرور یا Storage جداست؟
- چند نقطه بازیابی وجود دارد؟
- فایل و دیتابیس جداگانه Restore میشوند؟
- Restore سلفسرویس است یا با Ticket؟
- سلامت Job و خطای Backup چگونه اعلام میشود؟
برای داده حیاتی، یک نسخه مستقل تحت کنترل خودتان کنار بکاپ میزبان نگه دارید.
تست بازیابی مهمتر از تعداد بکاپهاست
فایل Backup ممکن است ناقص، رمز عبور آن فراموششده یا زنجیره Incremental شکسته باشد. Restore Drill روی محیط جدا نشان میدهد آیا واقعاً میتوانید سایت را در زمان هدف بازگردانید.
- حداقل بهصورت دورهای یک Restore کامل آزمایشی انجام دهید.
- Login، رسانه، فرم، Cron و Checkout را تست کنید.
- زمان دانلود، استخراج، Import و DNS را ثبت کنید.
- Hash، تعداد فایل و اندازه دیتابیس را مقایسه کنید.
- Runbook بازیابی را پس از هر تست اصلاح کنید.
بکاپ ووکامرس و سفارشها چه تفاوتی دارد؟
هر سفارش جدید در دیتابیس ارزش مالی دارد. اگر فروشگاه در روز صد سفارش ثبت کند، بکاپ روزانه میتواند در بدترین حالت بخش بزرگی از سفارشها را از دست بدهد. RPO را با ارزش و تعداد تراکنش تعیین کنید.
- دیتابیس را پرتکرارتر از فایلها ذخیره کنید.
- Action Scheduler، Session و Webhook را در Restore تست کنید.
- درگاه پرداخت را با Order ID تطبیق دهید.
- برای RPO بسیار کوتاه، Replication یا Backup تراکنشی بررسی کنید.
- Restore انتخابی سفارش بدون دانش ساختار دیتابیس انجام نشود.
امنیت، رمزنگاری و دسترسی بکاپ
Backup شامل Credential، اطلاعات مشتری و داده حساس است. فایل را در URL عمومی رها نکنید و دسترسی Storage را محدود کنید. رمزنگاری در انتقال و در حالت ذخیره، MFA، Log دسترسی و کلیدهای مستقل ریسک افشا را کم میکنند.
اگر Backup رمزگذاری شده است، کلید باید خارج از همان حساب و با روش بازیابی مشخص نگهداری شود. رمزنگاری بدون مدیریت کلید میتواند Restore را ناممکن کند.
چه فایلهایی را میتوان از بکاپ حذف کرد؟
- Cache قابل بازتولید
- Logهای قدیمی و حجیم با آرشیو جدا
- Backupهای تو در تو داخل مسیر سایت
- فایل موقت Import یا Extract
- Thumbnailهای قابل بازسازی فقط در صورت داشتن برنامه روشن
حذف باید با شناخت افزونه انجام شود. بعضی مسیرها ظاهراً Cache هستند اما داده موردنیاز برنامه را نگه میدارند. Manifest فایلهای حذفشده را ثبت کنید.
چطور از موفق یا ناموفق بودن Backup باخبر شویم؟
- اعلان موفقیت و خطا به ایمیل یا سیستم مانیتورینگ
- هشدار در صورت قدیمی شدن آخرین نسخه
- بررسی تغییر غیرعادی اندازه Backup
- کنترل فضای مقصد و تاریخ انقضا
- ثبت Duration و سرعت انتقال
- آزمون دورهای Integrity یا Restore
«Job اجرا شد» با «نسخه قابل بازیابی است» یکسان نیست. هر دو وضعیت باید قابل مشاهده باشند.
چکلیست Restore Drill
- یک نقطه بازیابی مشخص انتخاب کنید.
- نسخه را روی محیط جدا و ایزوله Restore کنید.
- Credential و فایل پیکربندی را هماهنگ کنید.
- فایل، دیتابیس و URL را بررسی کنید.
- Login، رسانه، فرم، Cron و API را تست کنید.
- برای فروشگاه، سفارش و Checkout آزمایشی انجام دهید.
- زمان کل را با RTO مقایسه کنید.
- اشکالها را در Runbook و برنامه Backup اصلاح کنید.
اشتباههای رایج در بکاپ وردپرس
- نگهداری روی همان سرور: نقطه شکست مشترک باقی میماند.
- فقط بکاپ دیتابیس: رسانه و کد اختصاصی از دست میروند.
- فقط بکاپ فایل: سفارش و تنظیمات بازیابی نمیشوند.
- نداشتن Retention: نسخه سالم قدیمی در دسترس نیست.
- عدم تست Restore: خرابی در زمان حادثه کشف میشود.
- Backup همزمان با پیک: CPU و I/O سایت را اشباع میکند.
- نسخه عمومی و بدون رمز: داده حساس افشا میشود.
برنامه پیشنهادی برای انواع سایت
| سایت | برنامه پایه | لایه تکمیلی |
|---|---|---|
| شرکتی | Full روزانه با ۷ نقطه | Snapshot قبل از Update |
| وبلاگ فعال | دیتابیس ۶ تا ۱۲ ساعته + فایل روزانه | نسخه هفتگی Offsite |
| فروشگاه کوچک | دیتابیس ۱ تا ۶ ساعته + فایل روزانه | Restore Drill و نسخه مستقل |
| فروشگاه پرتراکنش | Incremental/تراکنشی پرتکرار | Replication و Runbook حادثه |
| پیش از Deploy | Snapshot فوری | Rollback تستشده |
FluxCDN برای هاست اشتراکی بکاپ روزانه با هفت نقطه بازیابی ارائه میکند. این سطح برای بسیاری از سایتهای معمولی پایه مناسبی است؛ فروشگاه پرتراکنش باید بر اساس RPO خود لایه مستقل پرتکرارتری اضافه کند.
جمعبندی: فاصله بکاپ را با ارزش داده تنظیم کنید
برنامه بکاپ وردپرس باید از نرخ تغییر سایت، RPO و RTO شروع شود. سایت کمتغییر با نسخه روزانه و Retention چندروزه پوشش خوبی میگیرد، اما سفارش و فعالیت کاربر ممکن است به دیتابیس ساعتی یا پیوسته نیاز داشته باشد.
نسخه خارج از سرور، چند نقطه زمانی، اعلان خطا و تست Restore اجزای ضروریاند. برای مشاهده شرایط بکاپ روزانه و هفت نقطه بازیابی، پلنهای هاست FluxCDN را بررسی کنید.