آموزش بکاپ‌گیری و بازیابی وردپرس؛ فایل، دیتابیس، cPanel و تست Restore

ارسال توسط Dev Source

24 مهر 1405

منتشرشده در 5 مرداد 1405

🗓 آخرین به‌روزرسانی: 24 مهر 1405

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

بکاپ وردپرس زمانی ارزش دارد که کامل، تازه، امن و قابل بازیابی باشد. داشتن یک فایل ZIP قدیمی روی همان هاست، یا خروجی دیتابیس بدون پوشه wp-content، به معنی داشتن برنامه پشتیبان‌گیری نیست. بکاپ واقعی باید بتواند سایت را پس از خرابی افزونه، حذف اشتباهی، نفوذ، مشکل سرور، مهاجرت ناموفق یا خراب‌شدن دیتابیس به وضعیت قابل قبول برگرداند.

یک سایت وردپرسی از دو بخش اصلی تشکیل می‌شود: فایل‌ها و پایگاه داده. تصاویر، قالب‌ها، افزونه‌ها، فایل‌های دانلودی، wp-config.php و تنظیمات وب‌سرور داخل فایل‌ها هستند؛ نوشته‌ها، کاربران، تنظیمات، محصولات، سفارش‌ها و بیشتر داده‌های پویا داخل دیتابیس ذخیره می‌شوند. اگر فقط یکی از این دو را داشته باشید، بازیابی کامل معمولاً ممکن نیست.

در این آموزش، طراحی سیاست بکاپ، قانون ۳-۲-۱، RPO و RTO، بکاپ فایل و دیتابیس، cPanel، phpMyAdmin، WP-CLI، افزونه‌های پشتیبان‌گیری، بکاپ ووکامرس، ذخیره خارج از هاست، رمزگذاری، نگهداری نسخه‌ها، تست Restore و رفع خطاهای رایج را مرحله‌به‌مرحله بررسی می‌کنیم.

وضعیت فعلی سایت: روی dev-source.ir افزونه تخصصی بکاپ فعال مشاهده نشد. سایت فروشگاهی است و سفارش، مجوز دانلود و افزونه‌های سفارشی دارد؛ بنابراین تکیه صرف به بکاپ احتمالی هاست کافی نیست. این مقاله هیچ بکاپ عملی یا Restore روی سایت زنده انجام نمی‌دهد و فقط برنامه صحیح را توضیح می‌دهد.

بکاپ کامل وردپرس شامل چه چیزهایی است؟

برای بازیابی کامل، یک Backup Set هماهنگ لازم دارید که فایل‌ها و دیتابیس را در یک بازه زمانی نزدیک ثبت کرده باشد.

بخش فایل‌ها

هسته وردپرس
پوشه wp-content/uploads
قالب فعال و Child Theme
افزونه‌های عمومی و سفارشی
فایل‌های دانلودی خارج یا داخل Media Library
wp-config.php
.htaccess یا تنظیمات وب‌سرور
فایل‌های سفارشی در Root یا پوشه‌های دیگر

بخش دیتابیس

نوشته‌ها، برگه‌ها و دیدگاه‌ها
کاربران و نقش‌ها
تنظیمات وردپرس، قالب و افزونه‌ها
محصولات، سفارش‌ها، کوپن‌ها و مشتریان ووکامرس
مجوزهای دانلود
منوها، ابزارک‌ها و تنظیمات طراحی
داده‌های Rank Math، WoodMart و افزونه‌های سفارشی

دانلود همه فایل‌های public_html معمولاً دیتابیس را شامل نمی‌شود؛ زیرا MySQL یا MariaDB خارج از پوشه سایت اجرا می‌شود. خروجی دیتابیس باید جداگانه ساخته و کنار فایل‌های همان نسخه نگهداری شود.

تفاوت Backup، Snapshot، Export و Revision

این چهار مفهوم یکسان نیستند:

Backup: نسخه‌ای برای بازیابی فایل و دیتابیس سایت
Snapshot: تصویر سریع از دیسک، سرور یا محیط در یک زمان مشخص
Export: خروجی بخشی از داده؛ مانند XML نوشته‌ها یا CSV محصولات
Revision: نسخه قبلی یک نوشته یا طراحی داخل دیتابیس

خروجی WordPress Tools → Export فقط محتوای WXR را می‌دهد و تنظیمات کامل سایت یا فایل واقعی پیوست‌ها را تضمین نمی‌کند. Revision نیز جایگزین بکاپ کل سایت نیست.

RPO و RTO چیست؟

RPO؛ چه مقدار داده را می‌توانید از دست بدهید؟

Recovery Point Objective مشخص می‌کند قدیمی‌ترین نسخه قابل قبول چند ساعت یا چند روز قبل است. اگر فروشگاه روزانه ۵۰ سفارش دارد، بکاپ هفتگی یعنی در حادثه ممکن است چندصد سفارش از دست بروند.

RTO؛ سایت باید در چه مدت برگردد؟

Recovery Time Objective مدت قابل قبول برای بازیابی سرویس است. فروشگاه فعال ممکن است RTO چندساعته بخواهد، اما وبلاگ کم‌ترافیک شاید یک روز قطعی را تحمل کند.

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

قانون ۳-۲-۱ برای بکاپ

یک الگوی شناخته‌شده این است:

حداقل ۳ نسخه از داده داشته باشید.
نسخه‌ها روی ۲ نوع فضای متفاوت باشند.
حداقل ۱ نسخه خارج از سرور اصلی نگهداری شود.

نمونه عملی:

نسخه اصلی روی هاست
بکاپ خودکار روی فضای ابری یا Object Storage
نسخه دوره‌ای رمزگذاری‌شده روی کامپیوتر یا فضای دوم

سه فایل در سه پوشه روی همان سرور، قانون ۳-۲-۱ نیست؛ زیرا خرابی یا نفوذ همان سرور می‌تواند همه را حذف کند.

بکاپ هاست کافی است؟

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

دوره نگهداری کوتاه
نامشخص‌بودن زمان آخرین نسخه سالم
هزینه یا تأخیر Restore
نبود دسترسی مستقیم به فایل بکاپ
قرارداشتن نسخه روی همان زیرساخت
حذف بکاپ پس از پرشدن Quota یا بسته‌شدن حساب

در cPanel، امکان Full Backup یا Partial Backup به تنظیمات میزبان وابسته است. بازیابی خودکار Full Account Backup معمولاً از خود cPanel کاربر ممکن نیست و ممکن است به همکاری شرکت میزبان یا WHM نیاز داشته باشد.

هر چند وقت یک بار بکاپ بگیریم؟

تناوب به سرعت تغییر داده بستگی دارد.

وبلاگ کم‌فعالیت

دیتابیس: روزانه یا چندبار در هفته
فایل‌ها: هفتگی و قبل از تغییر بزرگ

فروشگاه فعال

دیتابیس: ساعتی یا نزدیک به Real-time براساس حجم سفارش
فایل‌ها: روزانه یا Incremental
نسخه کامل: هفتگی

قبل از عملیات پرریسک

آپدیت هسته، قالب یا افزونه
ویرایش گروهی محصولات
تغییر PHP یا دیتابیس
مهاجرت دامنه و هاست
Import انبوه
فعال‌سازی HPOS یا قابلیت آزمایشی
پاک‌سازی دیتابیس یا فایل‌ها

Full، Incremental و Differential Backup

Full Backup

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

Incremental Backup

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

Differential Backup

همه تغییرات پس از آخرین Full Backup را ذخیره می‌کند. بازیابی معمولاً به Full و آخرین Differential نیاز دارد.

برای فروشگاه، ترکیب نسخه کامل دوره‌ای و بکاپ Incremental یا دیتابیس پرتکرار معمولاً منطقی است.

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

وارد cPanel شوید.
File Manager را باز کنید.
به پوشه نصب وردپرس، معمولاً public_html، بروید.
فایل‌های مخفی مانند .htaccess را قابل نمایش کنید.
همه فایل‌های مربوط به سایت را انتخاب نمایید.
از Compress و فرمت ZIP یا TAR.GZ استفاده کنید.
فایل نهایی را دانلود کنید.
پس از دانلود و تأیید، آرشیو را از فضای عمومی هاست حذف کنید.

رهاکردن فایل بکاپ با نام قابل حدس داخل public_html خطرناک است. فایل‌هایی مانند backup.zip یا site-old.tar.gz ممکن است مستقیماً دانلود شوند.

چه پوشه‌هایی مهم‌ترند؟

هسته وردپرس قابل دریافت مجدد است، اما این بخش‌ها منحصربه‌فردند:

wp-content/uploads
wp-content/themes مخصوصاً Child Theme
wp-content/plugins برای افزونه‌های سفارشی یا تجاری
فایل‌های دانلودی محصولات
wp-config.php
فایل‌های سفارشی خارج از ساختار استاندارد

بااین‌حال برای Restore سریع، داشتن کل ساختار فایل‌ها ساده‌تر است.

بکاپ فایل با SFTP یا SSH

برای دانلود امن، SFTP یا SSH را به FTP ساده ترجیح دهید. نمونه فشرده‌سازی در سرور لینوکسی:

tar -czf wordpress-files-2026-07-27.tar.gz public_html

فایل را خارج از Web Root ایجاد یا بلافاصله منتقل کنید. اجرای فشرده‌سازی روی هاست اشتراکی می‌تواند CPU و Disk I/O زیادی مصرف کند؛ در ساعت کم‌ترافیک انجام دهید.

بکاپ دیتابیس با phpMyAdmin

از cPanel وارد phpMyAdmin شوید.
دیتابیس صحیح وردپرس را انتخاب کنید.
Export را بزنید.
برای سایت کوچک Quick و SQL مناسب است.
برای کنترل بیشتر Custom را انتخاب کنید.
تمام جدول‌های مرتبط را انتخاب نمایید.
Compression را برای دیتابیس بزرگ روی gzip قرار دهید.
روی Go کلیک و فایل را دانلود کنید.

نام دیتابیس در wp-config.php و مقدار DB_NAME مشخص است. روی هاست‌هایی با چند سایت، انتخاب دیتابیس اشتباه یکی از خطاهای رایج است.

بکاپ دیتابیس با WP-CLI

اگر SSH و WP-CLI در دسترس است، می‌توانید از دستور رسمی زیر استفاده کنید:

wp db export wordpress-backup-2026-07-27.sql --add-drop-table

برای فشرده‌سازی:

wp db export - | gzip > wordpress-backup-2026-07-27.sql.gz

فایل خروجی شامل اطلاعات حساس مشتری و تنظیمات است. آن را در مسیر عمومی نگهداری نکنید.

تفاوت wp db export و wp export

wp db export کل دیتابیس MySQL را Export می‌کند.
wp export فایل WXR شامل نوشته‌ها، کاربران، Taxonomy و بخشی از محتوا می‌سازد.

WXR تنظیمات کامل سایت و فایل واقعی تصاویر را شامل نمی‌شود و برای بکاپ Disaster Recovery کافی نیست.

بکاپ با Backup Wizard در cPanel

Backup Wizard بسته به تنظیمات میزبان می‌تواند این موارد را ایجاد کند:

Full Account Backup
Home Directory Backup
MySQL Database Backup
Email Forwarders و Filters

Full Backup برای مهاجرت یا آرشیو حساب مفید است. Partial Backup برای بازیابی دستی فایل یا دیتابیس انعطاف بیشتری می‌دهد.

اگر حساب نزدیک سقف فضا باشد، ساخت بکاپ ممکن است شکست بخورد؛ زیرا سرور برای فایل موقت و آرشیو به فضای آزاد نیاز دارد.

انتخاب افزونه بکاپ وردپرس

افزونه مناسب باید بر اساس قابلیت انتخاب شود، نه فقط تعداد نصب.

پشتیبان‌گیری فایل و دیتابیس
زمان‌بندی مستقل
ذخیره خارج از هاست
رمزگذاری در انتقال و ذخیره
Incremental Backup
پشتیبانی سایت‌های بزرگ
بازیابی ساده و مستند
Log و اعلان شکست
سازگاری با WooCommerce و HPOS
توانایی Exclude پوشه Cache و بکاپ‌های قدیمی

افزونه‌ای که فقط روی همان سرور فایل ZIP می‌سازد، در برابر خرابی یا حذف حساب پوشش کافی ندارد.

بکاپ ووکامرس چه تفاوتی دارد؟

فروشگاه دائماً داده جدید تولید می‌کند:

سفارش و وضعیت پرداخت
موجودی
مشتری و آدرس
Transaction ID
Refund
مجوز دانلود
یادداشت سفارش

اگر Restore نسخه ساعت ۱۰ را ساعت ۱۴ انجام دهید، سفارش‌های چهار ساعت اخیر ممکن است حذف شوند. بنابراین بکاپ فروشگاه فقط بحث فایل نیست؛ باید RPO پایین و برنامه هماهنگ‌سازی سفارش‌های بعد از نسخه داشته باشید.

Consistency در زمان بکاپ فروشگاه

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

بکاپ دیتابیس Transaction-consistent استفاده شود.
عملیات طولانی در ساعت کم‌ترافیک اجرا شود.
برای مهاجرت نهایی، Checkout موقتاً محدود شود.
یک Delta Backup یا Export نهایی سفارش‌ها گرفته شود.
زمان دقیق شروع و پایان ثبت گردد.

کپی فایل در حالی که آپلود، Update یا تبدیل PDF در حال اجراست می‌تواند مجموعه ناهماهنگ بسازد.

چه چیزهایی را می‌توان از بکاپ حذف کرد؟

برای کاهش حجم می‌توان داده‌های بازتولیدپذیر را Exclude کرد، اما با دقت:

پوشه‌های Cache
فایل‌های موقت
Logهای بسیار قدیمی
آرشیوهای بکاپ قبلی
Thumbnailهایی که قابل تولید مجددند

فایل اصلی تصویر یا محصول دانلودی را حذف نکنید. قبل از Exclude مطمئن شوید افزونه یا قالب برای همان فایل وابستگی ندارد.

فایل‌های دانلودی و کتاب‌های PDF

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

چک کنید:

فایل‌های اصلی داخل Backup Set هستند.
نام فایل و مسیر بعد از Restore تغییر نکرده است.
مجوزهای دانلود در دیتابیس بازیابی شده‌اند.
فایل از URL عمومی ناامن ارائه نمی‌شود.
نسخه‌های WebP و Thumbnail در صورت نیاز قابل تولیدند.

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

سایت فعلی چند افزونه سفارشی دارد. فایل ZIP نصب اولیه کافی نیست؛ نسخه فعال ممکن است بعداً تغییر کرده باشد.

Source Code در Git خصوصی نگهداری شود.
نسخه Release هر افزونه آرشیو شود.
تغییرات مستقیم روی Production ممنوع یا ثبت شوند.
تنظیمات دیتابیس افزونه نیز داخل بکاپ باشد.
فایل License یا Secret جدا و امن نگهداری شود.

بکاپ جایگزین Version Control نیست و Git نیز جایگزین بکاپ دیتابیس و Uploads نیست.

ذخیره بکاپ خارج از هاست

مقصدهای رایج:

Object Storage سازگار با S3
فضای ابری سازمانی
سرور دوم از ارائه‌دهنده مستقل
NAS یا دیسک رمزگذاری‌شده

ویژگی‌های مقصد:

Versioning یا Object Lock در صورت امکان
رمزگذاری
حساب جدا با حداقل دسترسی
2FA
Log دسترسی
هشدار شکست Upload

رمزگذاری بکاپ

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

از HTTPS، SFTP یا اتصال رمزگذاری‌شده استفاده کنید.
آرشیو حساس را با الگوریتم معتبر رمزگذاری نمایید.
کلید رمز را در همان فضای بکاپ نگهداری نکنید.
دسترسی Cloud را با حساب محدود تنظیم کنید.
Secretها را در Log چاپ نکنید.

اگر رمز فایل بکاپ گم شود، نسخه عملاً غیرقابل استفاده است؛ مدیریت کلید بخشی از برنامه بازیابی است.

Checksum و بررسی سلامت بکاپ

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

sha256sum wordpress-backup.tar.gz

Checksum را جدا از فایل ذخیره و هنگام دانلود یا Restore مقایسه کنید. این کار بدافزار داخل نسخه را تشخیص نمی‌دهد؛ فقط تغییر بایت‌ها را نشان می‌دهد.

سیاست نگهداری نسخه‌ها

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

نمونه:

۷ نسخه روزانه
۴ نسخه هفتگی
۶ نسخه ماهانه
نسخه دستی قبل از تغییر مهم

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

نام‌گذاری و مستندسازی Backup Set

نام فایل باید زمان، نوع و سایت را مشخص کند:

dev-source-files-2026-07-27-2300.tar.gz
dev-source-db-2026-07-27-2300.sql.gz

یک Manifest کنار نسخه قرار دهید:

نسخه WordPress، PHP و WooCommerce
نام قالب و نسخه
لیست افزونه‌های فعال
تاریخ و منطقه زمانی
روش ساخت
Checksum
مقصد ذخیره

قبل از Restore چه کار کنیم؟

علت خرابی را مشخص کنید.
از وضعیت فعلی—even if broken—یک Snapshot بگیرید.
نسخه سالم و زمان آن را انتخاب نمایید.
Checksum و قابلیت بازشدن آرشیو را بررسی کنید.
فاصله سفارش‌ها و داده‌های جدید را محاسبه نمایید.
Restore را ابتدا روی Staging یا محیط جدا تست کنید.
برنامه Rollback از خود Restore داشته باشید.

اگر سایت هک شده، Restore قدیمی بدون بستن مسیر نفوذ باعث آلودگی دوباره می‌شود.

ترتیب عمومی بازیابی وردپرس

ترتیب معمول:

فایل‌های وردپرس را بازیابی کنید.
دیتابیس مقصد را آماده نمایید.
SQL را Import کنید.
اطلاعات دیتابیس در wp-config.php را هماهنگ کنید.
URL، HTTPS و Permalink را بررسی نمایید.
Cache را پاک کنید.
ورود، Frontend و WooCommerce را تست کنید.

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

بازیابی دیتابیس با phpMyAdmin

قبل از Import از دیتابیس فعلی Export بگیرید.
دیتابیس مقصد را انتخاب کنید.
در صورت نیاز جدول‌های فعلی را حذف یا دیتابیس خالی بسازید.
Import را باز کنید.
فایل .sql یا .sql.gz را انتخاب کنید.
Character Set و محدودیت حجم را بررسی نمایید.
Import را اجرا و خطاها را ثبت کنید.

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

بازیابی دیتابیس با WP-CLI

wp db import wordpress-backup-2026-07-27.sql

برای فایل فشرده:

gunzip -c wordpress-backup-2026-07-27.sql.gz | wp db import -

دستور wp db import دیتابیس را ایجاد نمی‌کند؛ Queryهای داخل فایل را روی دیتابیس معرفی‌شده در wp-config.php اجرا می‌کند.

Restore در دامنه یا مسیر جدید

اگر URL تغییر کند، جایگزینی ساده متن در SQL می‌تواند داده Serialized را خراب کند. از ابزار سازگار با Serialization مانند WP-CLI استفاده کنید:

wp search-replace 'https://old.example' 'https://new.example' --all-tables --dry-run

ابتدا --dry-run و سپس اجرای واقعی. آدرس ایمیل یا متن‌هایی که نباید عوض شوند را بررسی کنید.

تست Restore چیست؟

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

موارد تست

ورود مدیر
صفحه اصلی و صفحات مهم
تصاویر و فایل‌های CSS/JS
فرم تماس و ایمیل
محصول، جست‌وجو و دسته‌ها
Cart و Checkout
درگاه در حالت تست
سفارش‌ها و مشتریان
لینک دانلود محصول
Rank Math، Sitemap و Robots
Cron و Scheduled Actions

تاریخ آخرین Restore موفق را ثبت کنید. بکاپی که هرگز Restore نشده، فقط یک فرض است.

تست خاص ووکامرس بعد از بازیابی

آخرین شماره سفارش موجود است.
وضعیت سفارش‌ها درست است.
Transaction IDها باقی مانده‌اند.
موجودی با سفارش‌ها هماهنگ است.
Refundها و یادداشت‌ها وجود دارند.
مجوز دانلود فعال است.
HPOS و افزونه‌های سفارش سازگارند.
ایمیل Processing و Completed ارسال می‌شود.
Callback درگاه به دامنه صحیح اشاره دارد.

جزئیات سفارش‌ها در مقاله مدیریت سفارش‌های ووکامرس و تنظیم درگاه در آموزش درگاه پرداخت توضیح داده شده است.

Restore کل سایت یا فقط یک بخش؟

همیشه لازم نیست کل سایت برگردد.

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

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

بکاپ آلوده را چگونه تشخیص دهیم؟

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

زمان اولین نشانه نفوذ را مشخص کنید.
فایل‌های تغییرکرده و Userهای جدید را بررسی نمایید.
چند نسخه قدیمی‌تر را اسکن و مقایسه کنید.
Core، قالب و افزونه عمومی را از منبع رسمی جایگزین کنید.
فقط Uploads و کد سفارشی لازم را با دقت منتقل کنید.
همه Credentialها را تعویض نمایید.

راهنمای مادر امنیت در مقاله افزایش امنیت وردپرس قرار دارد.

خطا: بکاپ کامل نمی‌شود

فضای دیسک کافی نیست.
PHP Timeout یا Memory Limit پایین است.
فایل بسیار بزرگ وجود دارد.
Permission پوشه مقصد مناسب نیست.
Cron اجرا نمی‌شود.
اتصال فضای ابری قطع است.
WAF درخواست Upload را مسدود کرده است.

Log Job و فضای آزاد را بررسی کنید. افزایش بی‌حد منابع بدون یافتن فایل یا Query مشکل‌دار راه‌حل پایدار نیست.

خطا: فایل بکاپ صفر بایت یا ناقص است

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

خطا: Import دیتابیس متوقف می‌شود

فایل از سقف Upload بزرگ‌تر است.
Timeout رخ داده است.
Character Set ناسازگار است.
SQL Mode یا نسخه MySQL فرق دارد.
دستور Definer مربوط به سرور دیگر است.

برای فایل بزرگ از WP-CLI یا خط فرمان MySQL استفاده کنید. خطا را کورکورانه حذف نکنید؛ ممکن است جدول سفارش وارد نشده باشد.

خطا: Error establishing a database connection

بعد از Restore مقادیر DB_NAME، DB_USER، DB_PASSWORD و DB_HOST را بررسی کنید. User دیتابیس باید به Database متصل و دارای مجوز لازم باشد.

خطا: صفحه سفید یا Critical Error

نسخه PHP، افزونه‌ها، قالب و Log خطا را بررسی کنید. ممکن است فایل‌ها و دیتابیس مربوط به نسخه‌های متفاوت باشند.

خطا: تصاویر نمایش داده نمی‌شوند

پوشه Uploads ناقص است.
Permission اشتباه است.
URL دامنه قدیمی مانده است.
CDN به Origin قبلی اشاره می‌کند.
Thumbnail لازم تولید نشده است.

خطا: بعد از Restore سفارش جدید حذف شد

نسخه‌ای قدیمی روی دیتابیس زنده بازنویسی شده است. قبل از Restore فروشگاه باید Delta Orders و فاصله زمانی را مدیریت کنید. بازیابی سفارش‌ها از چند دیتابیس نیازمند متخصص است و با Import ساده همیشه امن نیست.

خطا: cPanel Full Backup قابل Restore نیست

در بسیاری از حساب‌ها کاربر می‌تواند Full Backup بسازد، اما Restore خودکار کامل در WHM انجام می‌شود. برای بازگردانی کامل با شرکت هاست تماس بگیرید یا فایل‌ها و دیتابیس را به‌صورت Partial و دستی بازیابی کنید.

خطا: بکاپ فضای هاست را پر کرده است

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

چک‌لیست انتخاب راهکار بکاپ

فایل و دیتابیس هر دو پوشش داده می‌شوند.
نسخه‌ها زمان‌بندی شده‌اند.
حداقل یک مقصد خارج از هاست وجود دارد.
RPO و RTO نوشته شده‌اند.
بکاپ فروشگاه با سفارش‌های زنده سازگار است.
ذخیره‌سازی رمزگذاری شده است.
شکست Job اعلان می‌شود.
Retention مشخص است.
فایل Backup عمومی نیست.
Checksum یا بررسی سلامت وجود دارد.
نسخه افزونه‌های سفارشی نگهداری می‌شود.
Restore دوره‌ای روی Staging آزمایش می‌شود.

برنامه پیشنهادی برای سایت فعلی

برای dev-source.ir با توجه به فروشگاه فایل و افزونه‌های سفارشی:

یک راهکار بکاپ خودکار سازگار با WooCommerce و HPOS انتخاب شود.
دیتابیس حداقل روزانه و در صورت شروع فروش پرتکرار، ساعتی یا Incremental ثبت شود.
فایل‌ها روزانه Incremental و هفتگی Full ذخیره شوند.
نسخه خارج از هاست با دسترسی جدا نگهداری شود.
پوشه فایل‌های PDF و افزونه‌های سفارشی به‌طور مشخص داخل Backup Set باشند.
هر ماه یک Restore کامل روی Staging اجرا شود.
قبل از Import محصول، آپدیت WoodMart یا تغییر افزونه سفارشی بکاپ دستی ساخته شود.
Manifest شامل نسخه WordPress، WooCommerce، WoodMart و افزونه‌ها نگهداری شود.

📌 همچنین بخوانید: ارتقای نسخه PHP وردپرس، نگهداری دوره‌ای وردپرس و انتقال وردپرس به هاست جدید

پرسش‌های متداول

آیا دانلود پوشه public_html برای بکاپ کافی است؟

خیر. دیتابیس معمولاً خارج از این پوشه قرار دارد و باید جدا Export شود.

آیا بکاپ هاست کافی است؟

بهتر است آن را یک لایه بدانید، نه تنها نسخه. حداقل یک بکاپ مستقل خارج از زیرساخت هاست داشته باشید.

چند نسخه بکاپ نگه داریم؟

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

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

فشرده‌سازی و Export منابع مصرف می‌کنند. زمان‌بندی کم‌ترافیک، Incremental Backup و مقصد خارجی می‌تواند اثر را کاهش دهد.

آیا WordPress Export بکاپ کامل است؟

خیر. WXR محتوا را منتقل می‌کند، اما تنظیمات کامل، افزونه‌ها، قالب و فایل واقعی Uploads را به‌طور کامل پوشش نمی‌دهد.

چرا باید Restore را تست کنیم؟

زیرا Job موفق ممکن است فایل ناقص، دیتابیس خراب یا نسخه ناسازگار تولید کرده باشد. فقط بازیابی آزمایشی قابلیت استفاده را ثابت می‌کند.

برای فروشگاه هر چند وقت بکاپ دیتابیس لازم است؟

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

جمع‌بندی

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

برای سایت فروشگاهی، بکاپ دیتابیس باید پرتکرارتر باشد؛ زیرا سفارش، پرداخت، موجودی و مجوز دانلود دائماً تغییر می‌کنند. پیش از Restore نیز باید فاصله زمانی نسخه و سفارش‌های جدید محاسبه شود.

مهم‌ترین معیار موفقیت، تعداد فایل‌های بکاپ نیست؛ آخرین تاریخ بازیابی موفق است. نسخه را دوره‌ای روی Staging Restore کنید، مسیرهای WooCommerce را آزمایش نمایید و نتیجه را مستند نگه دارید.

منابع رسمی

آموزش‌های تازه، کد آماده و رفع خطاهر هفته در کانال Dev Source؛ رایگان.

✈️ کانال تلگرام 🟣 کانال روبیکا