فایل‌های سایت و دیتابیس دو بخش جدا هستند؛ برای بازیابی قابل‌اعتماد باید به یک وضعیت سازگار تعلق داشته باشند. بکاپ فایلِ قبل از آپدیت همراه دیتابیسِ بعد از آپدیت ممکن است سایت را ناقص برگرداند. نزدیک‌بودن تاریخ دو فایل هم به‌تنهایی ثابت نمی‌کند هنگام تهیه، تغییر هم‌زمانی رخ نداده است.
۱. چرا دو بکاپِ سالم ناسازگار می‌شوند؟
در وردپرس، رسانه، قالب، افزونه و تنظیماتی مانند wp-config.php در فایل‌ها هستند؛ نوشته، کاربر و دادهٔ سفارش معمولاً در دیتابیس قرار می‌گیرند. محل دقیق سفارش به تنظیمات فروشگاه وابسته است، اما اصل جدایی فایل و داده تغییر نمی‌کند.
فرض کنید فایل‌ها ساعت ۱۰:۰۰ ذخیره شده‌اند و ساعت ۱۰:۳۰ یک تصویر جدید بارگذاری شده؛ دیتابیس ساعت ۱۱:۰۰ می‌تواند به آن تصویر اشاره کند ولی مجموعهٔ فایلِ ۱۰:۰۰ آن را نداشته باشد. نمونهٔ دیگر، افزونه‌ای است که میان دو بکاپ ساختار دیتابیس را ارتقا داده است. سالم‌بودن آرشیو جلوی این ناسازگاری منطقی را نمی‌گیرد.
۲. در سی‌پنل چه چیزی را جدا می‌بینید؟
در بخش Backup، گزینهٔ Home Directory و دانلود دیتابیس‌ها جدا نمایش داده می‌شوند. این جدایی کمک می‌کند اجزای مجموعه را بشناسید؛ وجود دو لینک، هماهنگی زمانی خودکار را ثابت نمی‌کند. در تصویر واقعی زیر، نام دیتابیس‌های خصوصی پیش از ذخیره محو شده است.
فایل‌های خصوصی، تنظیم اتصال و ایمیل هم ممکن است در دامنهٔ بازیابی لازم باشند. مسیر Home Directory را با «فقط public_html» یکسان فرض نکنید؛ محتوای دقیق بکاپ را از ابزار و مستند همان نسخه بررسی کنید.
۳. برای هر مجموعه شناسنامه بنویسید
| فیلد | کاربرد |
|---|---|
| شناسهٔ مجموعه | وصل‌کردن همهٔ اجزا به یک رخداد بکاپ |
| شروع و پایان هر بخش | دیدن فاصله و احتمال تغییر هم‌زمان |
| نسخهٔ کد و افزونه‌های مهم | بررسی سازگاری با ساختار داده |
| اجزای موجود و استثناها | مشخص‌شدن uploads، DB، تنظیمات و موارد حذف‌شده |
| روش تهیه و نتیجهٔ اعتبارسنجی | تفکیک وجود فایل، صحت انتقال و آزمون بازیابی |
نام‌گذاری یکسان دو فایل، جای این اطلاعات را نمی‌گیرد. همچنین تاریخ تغییر فایلِ دانلودشده می‌تواند زمان دانلود یا کپی باشد؛ زمان منطقیِ نقطهٔ بکاپ را از منبع تهیه بگیرید.
۴. اگر چند نسخه با زمان متفاوت دارید
- فهرست نسخه‌ها و اجزای هرکدام را بدون بازنویسی سایت تهیه کنید.
- نقطه‌های زمانی و نسخهٔ کد را کنار هم بگذارید.
- تغییرهای مهمِ میان دو زمان را از گزارش انتشار و فعالیت سایت پیدا کنید.
- برای آزمون در محیط جدا، یک مجموعهٔ سازگار پیشنهاد دهید؛ انتخاب را با مسئول داده تأیید کنید.
نکته: «همیشه جدیدترین دیتابیس را با هر فایل قدیمی برگردان» قاعدهٔ درستی نیست. بازگردانیِ یکی از اجزا روی سایت فعال می‌تواند دادهٔ جدید را از بین ببرد؛ این مقاله دستور اجرای Restore نمی‌دهد.
۵. چطور برای دفعات بعد هماهنگی ایجاد کنیم؟
مستند وردپرس توصیه می‌کند فایل و دیتابیس به‌عنوان یک backup set نگهداری شوند. برای برنامهٔ پرتغییر، راه تهیه باید دربارهٔ consistency برنامه و دیتابیس تصمیم روشنی داشته باشد؛ «هم‌زمان فشردن دو دکمه» تضمین snapshot اتمیک نیست.
در طراحی روش، مسئول فنی باید تراکنش‌های در حال اجرا، سازگاری ابزار و بازهٔ تغییر فایل‌ها را بررسی کند. اگر توقف نوشتن یا snapshot لازم است، آن یک تغییر عملیاتیِ برنامه‌ریزی‌شده با مسیر برگشت است؛ صرفِ مقاله‌خواندن مجوز اجرای آن روی فروشگاه نیست.
۶. نشانهٔ موفقیت بازیابی چیست؟
- صفحه‌ها و رسانه‌های همان بازه وجود دارند.
- نسخهٔ کد با داده سازگار است و خطای migration ندارد.
- تعداد و وضعیت داده‌های حساس با انتظار همان نقطهٔ بازیابی تطبیق دارد.
- هیچ ارسال ایمیل، پرداخت یا کار زمان‌بندی‌شدهٔ واقعی از محیط آزمایشی فعال نشده است.
این کنترل‌ها پیشنهاد طراحی آزمون‌اند و در این مقاله روی حساب زنده اجرا نشده‌اند. برای روش تهیهٔ اجزا، راهنماهای موجود بکاپ دیتابیس و برنامهٔ بکاپ وردپرس را ببینید.
اگر فایل‌ها و دیتابیس از یک نقطهٔ زمانی قابل‌بازیابی نیستند، فاصلهٔ از‌دست‌رفتن داده ممکن است از هدف کسب‌وکار بیشتر شود؛ برای تعیین این هدف، تفاوت RPO و RTO در برنامهٔ بازیابی را ببینید.
۷. مسیر مطالعهٔ مرتبط
- پشتیبان‌گیری از دیتابیس و بازگردانی آن در سی‌پنل
- بکاپ وردپرس؛ از چه چیزی، هر چند وقت و کجا نگه داریم؟
۸. منابع و روش بررسی
منابع رسمی در ۲۴ اکتبر ۲۰۲۶ بررسی شدند. این متن راهنمای تشخیص و برنامه‌ریزی است؛ بازیابی بکاپ، تغییر حفاظت و تست روی سایت زنده انجام نشده است.
