آموزش بکاپ‌گیری از وردپرس و آزمایش بازیابی سایت

برای بکاپ‌گیری از وردپرس، باید هم فایل‌های سایت و هم دیتابیس (پایگاه داده) را نگه دارید؛ سپس مطمئن شوید می‌توانید از همین نسخه، سایت را در یک محیط جدا بازیابی کنید. پیام «بکاپ با موفقیت انجام شد» به‌تنهایی نشان نمی‌دهد تصاویر، سفارش‌ها، تنظیمات و مسیر ورود به مدیریت سالم برمی‌گردند.

این راهنما نیاز یک سایت وردپرسی معمولی روی هاست یا سرور را در نظر می‌گیرد. روش دستی را قدم‌به‌قدم توضیح می‌دهد و نشان می‌دهد چطور بدون دست‌زدن به سایت اصلی، بازیابی را آزمایش کنید. شبکهٔ چندسایتی وردپرس، دیتابیسِ بسیار بزرگ یا سامانه‌ای که به چند سرویس بیرونی وابسته است، به برنامهٔ اختصاصی‌تری نیاز دارد.

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

طبق راهنمای رسمی بکاپ وردپرس، بازیابی کامل یک نصب معمولی به فایل‌ها و دیتابیس نیاز دارد. دانلود پوشهٔ سایت معمولاً دیتابیس را همراه خود نمی‌آورد؛ سرویس جداگانهٔ MySQL یا MariaDB دیتابیس را نگه می‌دارد.

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

در راهنمای پشتیبان‌گیری از فایل‌های وردپرس، نویسندگان بر اهمیت پوشهٔ wp-content و فایل wp-config.php تأکید می‌کنند. هنگام تهیهٔ نسخهٔ کامل، زیرپوشه‌ها و فایل‌های مخفی مانند .htaccess را نیز بررسی کنید. اگر رسانه‌ها را بیرون از سرور سایت ذخیره می‌کنید، برای آن‌ها برنامهٔ جداگانه‌ای داشته باشید. بکاپ وردپرس لزوماً شامل ایمیل‌های هاست، رکوردهای DNS یا پیکربندی وب‌سرور نیست.

کنار هر مجموعه، تاریخ و ساعت با منطقهٔ زمانی، نام دامنه، نسخهٔ WordPress و PHP، نام دیتابیس و روش تهیه را ثبت کنید. رمز عبور را در این یادداشت ننویسید. چنین ثبت ساده‌ای کمک می‌کند فایل‌های دو روز متفاوت را هنگام بازیابی با هم ترکیب نکنید.

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

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

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

پیش از شروع، زمان تهیه و محل نگهداری را مشخص کنید

بکاپی که هفتهٔ قبل گرفته‌اید، تغییرات امروز را ندارد. ابتدا مشخص کنید از دست رفتن چه مقدار داده برای کسب‌وکارتان قابل‌تحمل است. این فاصلهٔ زمانی را هدف نقطهٔ بازیابی یا RPO می‌نامند. همچنین تعیین کنید پس از حادثه، بازگشت سرویس حداکثر چقدر می‌تواند طول بکشد؛ این هدف زمان بازیابی یا RTO است. هدف را با آزمون واقعی بسنجید، نه صرفاً با فاصلهٔ زمان‌بندی ابزار.

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

فضای لازم برای ساخت، انتقال و استخراج نسخه را پیش از اجرا کنترل کنید. یک مسئول مشخص برای رسیدگی به خطاها تعیین کنید و چند نقطهٔ بازیابی را متناسب با نیاز نگه دارید؛ نسخهٔ جدید نباید تنها نسخهٔ سالم قبلی را بی‌بررسی جایگزین کند. اگر خرابی یا آلودگی را دیر کشف کنید، فقط داشتن آخرین بکاپ کافی نیست.

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

بکاپ‌گیری از وردپرس به روش دستی: فایل‌ها و دیتابیس

هدف این روش، ساخت یک مجموعهٔ قابل‌شناسایی از داده‌ها و فایل‌هاست. از یک پوشهٔ خصوصی با نام شامل تاریخ و ساعت استفاده کنید. ابتدا مطمئن شوید دسترسی به پنل، دیتابیس و فایل‌های سایت دارید؛ در روز حادثه نباید برای نخستین بار به دنبال این دسترسی‌ها بگردید.

سازگاری داده‌ها را هنگام تهیه حفظ کنید

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

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

خروجی دیتابیس را بگیرید

در فایل wp-config.php، مقدار DB_NAME نام دیتابیسِ مورد استفاده را مشخص می‌کند. آن را با دیتابیسی که در phpMyAdmin انتخاب کرده‌اید تطبیق دهید. اطلاعات اتصال را برای کسی ارسال نکنید.

در phpMyAdmin، دیتابیسِ درست را انتخاب کنید، به بخش Export بروید و خروجی SQL بگیرید. در حالت Custom، همهٔ جدول‌های مورد نیاز سایت را انتخاب کنید؛ جدول‌های افزونه‌ها را هم در نظر بگیرید. فایل خروجی را در همان پوشهٔ خصوصی مجموعهٔ بکاپ ذخیره کنید و گزارش پایان کار یا خطا را بررسی کنید. راهنمای رسمی بکاپ دیتابیسِ وردپرس جزئیات خروجی و ورود دوبارهٔ فایل را توضیح می‌دهد.

اگر به SSH و ابزار WP-CLI دسترسی دارید، برای خروجی دیتابیس می‌توانید از دستور wp db export استفاده کنید. نمونهٔ زیر برای مدیر فنی روی لینوکس است؛ مسیرها نمونه‌اند، پوشهٔ مقصد باید خصوصی و قابل‌نوشتن باشد و دستور را با کاربر مناسب اجرا کنید.

wp --path=/var/www/example db export /srv/private-backups/site.sql

این دستور فقط دیتابیس را خروجی می‌گیرد. پس از اجرا، خروجی موفقیت و وجود فایل را کنترل کنید؛ رسیدگی به مجوزها، خطا و فضای ذخیره‌سازی همچنان لازم است. اگر از گزینهٔ single-transaction استفاده می‌کنید، محدودیت‌های mysqldump را رعایت کنید: سازگاری آن به جدول‌های تراکنشی مانند InnoDB مربوط است و هم‌زمان نباید ساختار جدول‌ها تغییر کند. این گزینه سازگاری فایل‌ها با دیتابیس را به‌تنهایی حل نمی‌کند.

فایل‌های سایت را کامل دریافت کنید

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

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

خروجی دیتابیس و فایل‌ها را با یادداشت همان مجموعه نگه دارید و نسخه‌ای مستقل منتقل کنید. پس از تأیید پایان کار، مسیرهایی را که برای ثبت داده متوقف کرده‌اید، دوباره فعال و عملکرد سایت اصلی را بررسی کنید. برای کار تکرارشونده، اجرای خودکار باید نتیجه و خطا را ثبت کند و شکست انتقال یا پرشدن مقصد را اطلاع دهد؛ وجود یک زمان‌بندی بدون این کنترل‌ها کافی نیست.

اگر از سی‌پنل بکاپ می‌گیرید، مسیر بازیابی را هم بشناسید

در cPanel، بخش Files و سپس Backup Wizard مسیر متداول تهیهٔ نسخه است. بعد از انتخاب Back Up، می‌توانید نسخهٔ کامل حساب یا بکاپ بخش‌های مشخص را تهیه کنید. برای یک نصب معمولی وردپرس، پوشش فایل‌ها و دیتابیس را جداگانه کنترل کنید. اگر مقصد Home Directory است، فایل روی همان حساب می‌ماند؛ پس از تکمیل، آن را دریافت و در مقصد مستقل نگه دارید.

طبق مستندات Backup Wizard سی‌پنل، بازیابی خودکار یک Full Backup از رابط cPanel در دسترس نیست و به WHM یا همکاری ارائه‌دهنده نیاز دارد. بازیابی بخش‌ها مسیر متفاوتی دارد. بنابراین پیش از اتکا به فول‌بکاپ، مسئول بازیابی و شیوهٔ تحویل نسخه را روشن کنید. گزینه‌ها و دسترسی‌ها نیز ممکن است با تنظیمات میزبان تفاوت داشته باشند.

بازیابی را در محیط جدا آزمایش کنید

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

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

برای جلوگیری از تغییر نشانی‌های سایت در یک آزمون فنی، می‌توان دامنهٔ اصلی را فقط روی دستگاه آزمایش‌کننده، با فایل hosts به IP محیط آزمایشی هدایت کرد؛ این کار DNS عمومی را تغییر نمی‌دهد. وب‌سرور آزمایشی و گواهی HTTPS را از قبل برای همان دامنه درست تنظیم کنید. اگر این پیش‌نیازها فراهم نیست، از دامنهٔ آزمایشی با تنظیمات صحیح استفاده کنید؛ هشدار گواهی را دور نزنید. مسدودکردن ایندکس به‌تنهایی حفاظت از اطلاعات کاربران نیست.

فایل‌ها و دیتابیس را در مقصد آزمایشی برگردانید

ابتدا فایل‌ها را در پوشهٔ خالی مقصد آزمایشی قرار دهید و مالکیت و مجوزهای لازم را مطابق وب‌سرور تنظیم کنید؛ مجوز عمومی 777 راه‌حل مناسبی برای خطای دسترسی نیست. سپس یک دیتابیسِ خالی و مستقل بسازید و فایل SQL همان مجموعه را در بخش Import ابزار phpMyAdmin وارد کنید. قبل از اجرا، نام مقصد را دوباره کنترل کنید. ورود فایل بکاپ در دیتابیسِ اصلی می‌تواند داده‌های جدید آن را بازنویسی کند.

در wp-config.php نسخهٔ آزمایشی، نام، کاربر، رمز و میزبان دیتابیس مقصد را تنظیم کنید و تطابق پیشوند جدول‌ها را بررسی کنید. برای مدیر فنی، دستور wp db import نیز مسیر ورود فایل است؛ آن را فقط در نصب آزمایشی پس از کنترل تنظیمات اتصال اجرا کنید. خطای ورود داده را حل کنید و آزمون را با واردات ناقص ادامه ندهید.

اگر دامنهٔ آزمایشی متفاوت است، نشانی‌ها را فقط در دیتابیس آزمایشی اصلاح کنید. جایگزینی خام متن در فایل SQL ممکن است داده‌های سریال‌شدهٔ افزونه‌ها را خراب کند. ابزار رسمی جایگزینی نشانی‌ها این نوع داده‌ها را در نظر می‌گیرد؛ ابتدا با dry-run نتیجه را بررسی کنید و محدودهٔ جدول‌ها را متناسب با نصب تعیین کنید. این مرحله با بکاپ اصلی کار ندارد و نباید نسخهٔ محفوظ را تغییر دهد.

نتیجه را با معیار مشخص بررسی کنید

پس از بازیابی، فقط صفحهٔ نخست را باز نکنید. پیش از آزمون، چند رکورد موجود در همان نقطهٔ بکاپ را به‌عنوان نمونه مشخص کنید و انتظار خود را بنویسید. از آن نسخه، انتظار داده‌ای را نداشته باشید که بعد از زمان بکاپ ایجاد کرده‌اید.

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

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

پس از پایان، تغییر hosts دستگاه آزمایش‌کننده را برگردانید و دسترسی نسخهٔ آزمایشی را همچنان محدود نگه دارید. برای اطلاعات واقعی که در این محیط کپی کرده‌اید، دورهٔ نگهداری و حذف کنترل‌شده تعیین کنید؛ نسخهٔ آزمایشی حاوی داده‌های کاربران را عمومی و بدون مراقبت رها نکنید.

در بازیابی واقعی، داده‌های جدید را از دست ندهید

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

پیش از بازنویسی داده‌ها، از وضعیت فعلی قابل‌دسترسی نسخهٔ محافظتی بگیرید. سفارش‌ها، پرداخت‌ها یا پیام‌های فرمی که پس از زمان بکاپ دریافت کرده‌اید را شناسایی کنید و برای حفظ یا تطبیق آن‌ها برنامه داشته باشید. بازگرداندن کل دیتابیس به نسخهٔ قدیمی می‌تواند رکورد تازه را حذف کند، در حالی که سامانهٔ بیرونی پرداخت آن را ثبت کرده باشد. بازیابی انتخابی یا ادغام سفارش‌ها به شناخت ساختار افزونه و بررسی مسئول فنی نیاز دارد؛ کپی چند جدول بدون تحلیل، روش قابل اتکایی نیست.

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

بکاپ زیرساخت را با برنامهٔ بازیابی وردپرس هماهنگ کنید

اسنپ‌شات معمولاً وضعیت یک منبع مانند دیسک یا ماشین را در یک نقطهٔ زمانی ثبت می‌کند. میزان استقلال آن، پوشش داده و سازگاری برنامه به پیاده‌سازی وابسته است؛ نام Snapshot به‌تنهایی اثبات نمی‌کند نسخهٔ مستقلی از فایل‌ها و دیتابیس دارید. بکاپ زیرساخت را نیز از نظر شمول دیسک‌ها، دیتابیسِ بیرونی، دسترسی بازیابی و زمان نگهداری بررسی کنید.

در ابر آراد، پشتیبان‌گیری ابری و Snapshot قابل استفاده هستند. برای برنامهٔ سایت خود، دامنهٔ پوشش، شرایط بازیابی و مسئولیت هر طرف را پیش از اتکا به آن‌ها روشن کنید. تهیه و کنترل نسخهٔ مناسب وردپرس، مهار ارتباطات محیط آزمایشی و تطبیق سفارش‌ها همچنان بخشی از برنامهٔ نگهداری برنامه است؛ صرف داشتن یک قابلیت زیرساخت، جای انجام این کارها را نمی‌گیرد.

برای سایت وردپرسی خود، ابتدا مشخص کنید چه داده‌ای باید برگردد، چه مقدار از دست رفتن داده قابل‌تحمل است و بازیابی چقدر می‌تواند طول بکشد. اگر سایت را روی سرور مجازی ابر آراد اجرا می‌کنید، از مرکز پشتیبانی ابر آراد شرایط Backup و Snapshot و حدود مسئولیت پشتیبانی را برای سرویس خود بررسی کنید. سپس با یک آزمون در محیط جدا، برنامهٔ بازیابی را بسنجید.