چگونه از دیتابیس وردپرس بکاپ بگیریم؟ | بکاپ دیتابیس وردپرس

روزی که یکی از مشتریان با صدای مضطرب تماس گرفت و گفت «محتواهای سایت پاک شده‌اند»، اولین کارم رفتن به پیشخوان و بررسی دیتابیس بود. مشکل این نبود که فایل‌های وردپرس از بین رفته باشند؛ مشکل این بود که صاحب سایت هر ماه بکاپ فایل‌ها را می‌گرفت، ولی از دیتابیس بکاپ نداشت. یک آپدیت ناقص افزونهٔ ووکامرس، بیش از دو هزار سفارش را در دیتابیس از بین برده بود. آن روز برای من تبدیل به درس همیشگی شد: در وردپرس، محتوا زندگی می‌کند در دیتابیس؛ فایل‌ها فقط ظاهر سایت هستند. اگر روی نسخهٔ فایل تمرکز کنید و دیتابیس را فراموش کنید، در روز حادثه با سایتی مواجه می‌شوید که ظاهرش سالم است ولی محتوایش خالی. این مقاله، همان مسیری است که از آن روز تا امروز برای بکاپ دیتابیس وردپرس طی می‌کنم — سه روش عملی، نکات فنی و بازگردانی.

چرا دیتابیس از فایل‌ها مهم‌تر است؟

در یک سایت وردپرسی، دو بخش اصلی وجود دارد: فایل‌ها (شامل هستهٔ وردپرس، قالب، افزونه‌ها و تصاویر آپلودی) و دیتابیس (شامل محتوا، کاربران، تنظیمات، سفارش‌های ووکامرس و متادیتای همهٔ آن‌ها). یکی از دو بخش را می‌توان به‌سادگی از مخزن رسمی وردپرس و مارکت‌ها بازسازی کرد: فایل‌ها. ولی دیتابیس را نمی‌توان بازسازی کرد — چون در آن، تمام کارِ شما ذخیره شده. اگر فایل‌های سایت را از دست بدهید، با نصب دوبارهٔ وردپرس و قالب و افزونه‌ها و آپلود تصاویر، طی چند ساعت به وضعیت اول برمی‌گردید (به شرطی که تصاویر را داشته باشید). ولی اگر دیتابیس را از دست بدهید، هیچ راهی برای بازسازی محتوا و سفارش‌ها وجود ندارد. به همین دلیل، بکاپ دیتابیس را در پروژه‌های خودم با اولویت بالاتری از بکاپ فایل‌ها انجام می‌دهم. برای تصویر کامل از استراتژی بکاپ، مقالهٔ چگونه از سایت وردپرسی بکاپ بگیریم؟ را ببینید.

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

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

دیتابیس وردپرس، مجموعه‌ای از جدول‌ها با پیشوند مشخص (پیش‌فرض wp_) است. سه دستهٔ مهم:

محتوا و متادیتا: جدول‌های posts، postmeta، terms، term_taxonomy، comments و commentmeta. این‌ها قلب سایت شما هستند.
کاربران و تنظیمات: users، usermeta و options. جدول options محل ذخیرهٔ تمام تنظیمات وردپرس، افزونه‌ها و قالب است.
جدول‌های افزونه‌ای: افزونه‌های پیچیده مثل ووکامرس، فرم‌سازها و LMSها، جدول‌های اختصاصی خودشان را دارند. مثلاً ووکامرس، woocommerce_order_items و woocommerce_order_itemmeta دارد. بی‌توجهی به این جدول‌ها در بکاپ، خطای رایجی است که در پروژه‌های فروشگاهی زیاد دیده‌ام.

یک نکتهٔ فنی: قبل از بکاپ، بهتر است جدول‌های باقی‌مانده از افزونه‌های حذف‌شده را بررسی کنید. اگرچه این کار بخشی از بکاپ نیست، ولی به تمیزی دیتابیس و کاهش حجم بکاپ کمک می‌کند. راهنمای کامل در چگونه دیتابیس وردپرس را پاک‌سازی کنیم؟.

سه روش بکاپ از دیتابیس

بکاپ دیتابیس وردپرس، سه روش اصلی دارد که هر یک برای سناریوی خاصی مناسب است:

phpMyAdmin: رابط گرافیکی وب، ساده و بدون نیاز به خط فرمان. مناسب دیتابیس‌های تا حدود ۵۰۰ مگابایت.
mysqldump: ابزار خط فرمان MySQL، سریع‌ترین و پایدارترین روش. مناسب دیتابیس‌های بزرگ و خودکارسازی.
افزونه‌های بکاپ: مثل UpdraftPlus و BackWPup که فایل‌ها و دیتابیس را با هم بکاپ می‌گیرند. مناسب کاربران غیرفنی.

روش اول: phpMyAdmin

در پنل هاست، از بخش Databases → phpMyAdmin، دیتابیس خود را باز کنید. در تب Export، فرمت SQL را انتخاب کنید. گزینه‌های مهم:

Custom: به‌جای Quick، گزینهٔ Custom را انتخاب کنید تا بتوانید جدول‌های خاص را انتخاب کنید.
Structure and Data: هر دو را انتخاب کنید؛ اگر فقط Structure را انتخاب کنید، بکاپ بدون محتوا می‌شود.
Add DROP TABLE / VIEW: این گزینه را فعال کنید تا در بازگردانی، جدول‌های قبلی حذف و با نسخهٔ بکاپ جایگزین شوند.
Charset utf8mb4: برای پشتیبانی کامل از کاراکترهای یونیکد و اموجی، این کاراکترست را انتخاب کنید.

یک نکتهٔ عملی: برای دیتابیس‌های بالای ۵۰۰ مگابایت، phpMyAdmin ممکن است با محدودیت اجرای PHP یا محدودیت حجم فایل مواجه شود. در آن صورت، یا باید حجم را از طریق حذف داده‌های قدیمی کاهش دهید، یا به روش دوم بروید. برای بکاپ cPanel به‌طور کامل، راهنمای چگونه از cPanel بکاپ بگیریم؟ را ببینید.

روش دوم: خط فرمان با mysqldump

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

mysqldump -u username -p --single-transaction --routines --triggers --events dbname > /path/backup-$(date +%Y-%m-%d).sql

پارامترهای مهم: --single-transaction برای بکاپ سازگار در دیتابیس‌های InnoDB بدون قفل کردن جدول‌ها، --routines برای پروسیجرهای ذخیره‌شده، --triggers برای تریگرها و --events برای رویدادهای زمان‌بندی‌شده. سپس فایل خروجی را با gzip فشرده کنید تا حجم آن به‌طور قابل توجهی کاهش یابد:

gzip /path/backup-2026-09-18.sql

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

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

برای کاربران غیرفنی، افزونه‌های بکاپ ساده‌ترین راه هستند. UpdraftPlus و BackWPup، محبوب‌ترین گزینه‌ها هستند و امکان ذخیره‌سازی در Google Drive، Dropbox یا Amazon S3 را می‌دهند. سه نکته در استفاده از این افزونه‌ها: اول، ذخیره‌سازی خارج از سرور را فعال کنید — بکاپ روی همان سرور، در برابر حمله یا خرابی سرور بی‌اثر است. دوم، فاصلهٔ بین بکاپ‌ها را متناسب با حجم تغییرات تنظیم کنید — روزانه برای فروشگاه، هفتگی برای وبلاگ. سوم، گاهی بازگردانی را تست کنید — بکاپ بدون تست، فقط یک فایل است. مقایسهٔ تفصیلی افزونه‌ها در بهترین افزونه‌های پشتیبان‌گیری وردپرس کدامند؟ آمده است. برای فروشگاه‌های ووکامرس، حتماً جدول‌های اختصاصی ووکامرس را هم در بکاپ لحاظ کنید — راهنمای تکمیلی در بکاپ‌گیری از فروشگاه ووکامرس.

جدول مقایسه سه روش

معیار	phpMyAdmin	mysqldump	افزونه
مناسب برای	دیتابیس تا ۵۰۰ MB	هر حجم	کاربر غیرفنی
سرعت	متوسط	سریع	متوسط
خودکارسازی	خیر	بله با cron	بله
ذخیره‌سازی خارجی	دستی	دستی	خودکار
کنترل دقیق	متوسط	کامل	محدود
مناسب فروشگاه ووکامرس	بله (با احتیاط)	بله	بله با افزودنی

بازگردانی: آزمون واقعی بکاپ

بکاپ بدون بازگردانی، بیمه‌نامه‌ای است که هیچ‌کس نمی‌داند در روز حادثه کار می‌کند یا نه. سه مرحلهٔ بازگردانی: اول، بکاپ را روی یک محیط تست بازگردانید. همیشه. هرگز روی سایت زنده. دوم، قبل از بازگردانی از حالت فعلی هم بکاپ بگیرید تا اگر بازگردانی ناقص بود، امکان بازگشت باشد. سوم، در سایت‌های ووکامرس، بعد از بازگردانی، جدول‌های سفارش و تراکنش‌ها را به‌صورت دستی بررسی کنید. یکی از پرونده‌های واقعی که بررسی کرده‌ام، بکاپی داشت که ظاهراً سالم بود ولی جدول woocommerce_order_items را نداشت و همهٔ سطرهای سفارش از بین رفته بودند. اگر آن بکاپ را به‌عنوان مرجع می‌گرفتیم، فاجعه بود. مسیر گام‌به‌گام بازگردانی در بازیابی سایت از بکاپ چگونه انجام می‌شود؟ آمده است.

اشتباهات رایج در بکاپ دیتابیس

بی‌توجهی به جدول‌های اختصاصی افزونه‌ها: در بکاپ دستی، اگر از phpMyAdmin استفاده می‌کنید و فقط جدول‌های wp_* را انتخاب می‌کنید، جدول‌های افزونه‌های با پیشوند متفاوت (مثل جدول‌های ووکامرس در بعضی نصب‌ها) از دست می‌روند.
ذخیرهٔ بکاپ روی همان سرور: بکاپ روی همان سرور، در برابر خرابی سرور یا حملهٔ ransomware (باج‌گیر) بی‌اثر است.
نگه‌داری بکاپ رمزنگاری‌نشده: فایل SQL، تمام داده‌های حساس سایت را در متن ساده دارد. اگر این فایل به دست مهاجم بیفتد، به‌اندازهٔ خودِ دیتابیس خطرناک است — مسیر رمزنگاری در پشتیبان‌گیری امن از دیتابیس چگونه است؟.
نبود بازگردانی تست‌شده: اکثر بکاپ‌ها در روز حادثه، به‌دلیل نبود آزمون بازگردانی، بی‌فایده از آب درمی‌آیند.
حذف بکاپ‌های قدیمی به‌طور بی‌برنامه: بعضی از مشکلات پس از چند ماه خودشان را نشان می‌دهند و در آن صورت، به بکاپ چند ماه قبل نیاز پیدا می‌کنید.

نگاه لایه‌ای: بکاپ دیتابیس به‌عنوان پروژهٔ حفاظت از داده

برای توسعه‌دهندهٔ ارشد، بکاپ دیتابیس یک «پروژهٔ حفاظت از داده» است، نه یک عملیات تک‌بار. این پروژه در سه لایهٔ اصلی اجرا می‌شود. لایهٔ اول، انتخاب بکاپ کامل یا افزایشی. بکاپ کامل، تمام داده را در هر اجرا کپی می‌کند — ساده ولی سنگین. بکاپ افزایشی، فقط تغییرات از بکاپ قبلی را نگه می‌دارد — سبک‌تر ولی نیاز به بازیابی زنجیره‌ای دارد. برای سایت‌های بزرگ با تغییرات روزانهٔ کم، بکاپ افزایشی (incremental) بهینه‌تر است؛ برای سایت‌های کوچک، بکاپ کامل کافی است. لایهٔ دوم، چرخهٔ نگهداری. یک قاعدهٔ عملی که در پروژه‌ها استفاده می‌کنم: نگه‌داشتن بکاپ‌های روزانه به مدت یک هفته، بکاپ‌های هفتگی به مدت یک ماه، بکاپ‌های ماهانه به مدت یک سال. این چرخه، هم فضای ذخیره‌سازی را مدیریت می‌کند و هم امکان بازگشت به دوره‌های زمانی مختلف را می‌دهد. در فروشگاه‌ها، بکاپ‌های روزانه معمولاً به مدت یک ماه حفظ می‌شوند، چون پروندهٔ اختلاف سفارش‌ها ممکن است چند هفته بعد ظاهر شود.

لایهٔ سوم، تفکیک محیط عملیاتی از محیط بکاپ. بکاپ نباید روی همان سروری باشد که دیتابیس اصلی روی آن کار می‌کند. اگر سرور از کار بیفتد، بکاپ هم از بین می‌رود. راه‌حل استاندارد: ذخیره‌سازی در Object Storage (مثل Amazon S3) یا در سرور مستقل، با رمزنگاری در حالت انتقال و ذخیره‌سازی. در پروژه‌های فروشگاهی که با داده‌های مالی سر و کار دارند، توصیه می‌کنم دو مقصد مختلف برای بکاپ در نظر بگیرید — یکی سرویس ابری معتبر و یکی فضای شخصی — تا در صورت اختلال یا قطعی یکی، دیگری کار کند. در یکی از پروژه‌ها، دیتابیس هفت گیگابایتی ووکامرس داشتیم که در ماه آخر هر فصل، سه بار بکاپ کامل می‌گرفتیم؛ این تعداد زیاد به‌دلیل حجم تراکنش‌های فصلی بود و در بقیهٔ ماه‌ها، بکاپ افزایشی کافی بود. اجرای درست همین استراتژی، هم مصرف پهنای باند را کاهش داد و هم بازگردانی سریع‌تر شد. برای مطالعهٔ بیشتر در این زمینه، مسیر چند نسخه بکاپ باید نگهداری کنیم؟ و اشتباهات رایج در پشتیبان‌گیری از سایت را پیشنهاد می‌کنم. قاعدهٔ نهایی که در پروژه‌های اخیر روی آن تأکید کرده‌ام: اگر بازگردانی بکاپ را در سه ماه گذشته تست نکرده‌اید، بکاپ شما یک فایل ذخیره‌شده است، نه یک نسخهٔ پشتیبان قابل اتکا.

اگر در پروژه‌ای تجربهٔ بازگردانی دیتابیس داشته‌اید — چه بازگردانی موفق و چه کشف یک نقص در بکاپ — سناریو را در دیدگاه بنویسید. تجربه‌های واقعی در حوزهٔ بکاپ دیتابیس، از هر مستند فنی، ملموس‌تر هستند. 💾