چرا بکاپ سمت هاست نتیجه نمی‌دهد؟ علت‌های پنهان
- بکاپ هاست کجا شکست می‌خورد؛ شش علت پنهان
- نسخه‌ای که با بحران همزمان خراب می‌شود؛ و بازهٔ نگهداری کوتاه
- بکاپ بدون دیتابیس یا ایمیل؛ نیمه‌ای که گم می‌شود
- آزمون بازیابی نشده و نگهداری روی همان سرور
- دسترسی محدود در پنجرهٔ انتقال هاست
- معماری بکاپ سه‌لایه‌ای که این شکاف‌ها را می‌بندد
- جمع‌بندی؛ پنج پرسش پیش از اعتماد به پشتیبان
مقالهٔ آموزش گام‌به‌گام بکاپ سمت هاست مسیر اجرا را باز کرده است: گرفتن بکاپ کامل از پنل، بکاپ جداگانهٔ دیتابیس و ریتم نگهداری چندنسخه‌ای. این مقاله یک لایه قبل‌تر می‌نشیند و سراغ موقعیتی می‌رود که بکاپ وجود دارد، اما در لحظهٔ نیاز جواب نمی‌دهد؛ سؤال «چرا» را جواب می‌دهد، نه سؤال «چگونه».
به تجربهٔ ما این شکاف معمولاً از سیاست می‌آید، نه از ابزار: دکمهٔ بکاپ روی پنل هست، اما هیچ‌کس نسخه‌ها را بیرون از سرور نبرده، هیچ‌کس بازیابی را تمرین نکرده و هیچ‌کس نپرسیده دیتابیس و ایمیل در همان فایل هست یا نه. نتیجه، حس امنیتی است که در روز بحران به نسخهٔ قابل بازیابی تبدیل نمی‌شود.
بکاپ هاست کجا شکست می‌خورد؛ شش علت پنهان
بکاپ هاست یعنی نسخهٔ فایل‌ها و دیتابیس سایت که روی خودِ زیرساخت هاستینگ گرفته و نگهداری می‌شود؛ همان نسخه‌ای که از پنل هاست قابل دانلود و بازگردانی است. این تعریف ایرادی ندارد؛ ایراد از انتظاری می‌آید که به آن وصل می‌شود. مدیری که «بکاپ داریم» را پاسخ نهایی می‌پذیرد، معمولاً سه پرسش را نپرسیده است: نسخه کجا ذخیره شده، چند روز پوشش می‌دهد و آیا تا حالا برگردانده شده است؟
شش علت پنهان از همین سه پرسش بی‌پاسخ زاده می‌شوند: نسخه‌ای که همزمان با خرابی بازنویسی می‌شود؛ بازهٔ نگهداری کوتاه؛ بکاپ بدون دیتابیس یا ایمیل؛ نسخه‌ای که آزمون بازیابی نشده؛ نگهداری همهٔ نسخه‌ها روی همان سرور؛ و دسترسی محدود در پنجرهٔ انتقال. هیچ‌کدام در پنل به‌عنوان خطا گزارش نمی‌شوند؛ همه از جنس «فکر می‌کردیم هست» هستند. هر علت در بخش‌های بعد با نشانه و اصلاحش می‌آید تا خواندن، به سیاست عملی تبدیل شود؛ سه پرسش آغازین، در آخرین بخش به چک‌لیست برمی‌گردند.
نسخه‌ای که با بحران همزمان خراب می‌شود؛ و بازهٔ نگهداری کوتاه
رایج‌ترین سناریو این است: مشکلی در سایت شکل میگیرد — آلودگی، تغییری بد در قالب، خرابی افزونه — و بکاپ خودکار شبانه همان حالت خراب را هر شب با نسخهٔ تازه ذخیره میکند. پس از چند شب، همهٔ نسخههای موجود، نسخهٔ خراب‌اند. بکاپ سمت هاست روتیینی است که بدون شرط «نسخهٔ سالم را جدا کن»، خرابی را هم با همان دقت آرشیو میکند.
علت دوم، بازهٔ نگهداری کوتاه است. پنجرهٔ هفت‌روزه وقتی کافی است که مشکل در همان هفته کشف شود؛ اما به تجربهٔ ما آلودگی‌ها و خرابی‌های سمت دیتابیس معمولاً دیر کشف می‌شوند، بعد از آن‌که تغییرات چند هفته روی داده انباشته شده است. نسخه‌ای که از پنجرهٔ نگهداری بیرون افتاده، دیگر وجود ندارد.
اصلاح هر دو از یک قاعده می‌آید: نسخهٔ سالمِ پیش از حادثه را همان لحظهٔ اول جدا کنید و بازهٔ نگهداری را لایه‌ای ببندید — نسخههای نزدیک پرتر، نسخههای دور کمتر ولی زنده. عدد دقیق بازه به ریتم تغییر سایت بستگی دارد — چند هفته برای سایتهای پرتغییر، چند ماه برای سایتهای آرام — و این بازه‌ها برآورد تجربی ماست، نه قانون بازار.
بکاپ بدون دیتابیس یا ایمیل؛ نیمه‌ای که گم می‌شود
علت سوم، بکاپ ناقص است: فایلی که فقط فایل‌های عمومی را میگیرد و دیتابیس را جا می‌گذارد، نیمی از سایت را نجات نداده است. در وردپرس نوشته‌ها، سفارش‌ها، کاربران و تنظیمات همه در دیتابیس‌اند؛ بکاپ کامل اکانت دیتابیس را در بر میگیرد، اما بکاپ‌های دستیِ فایل‌محور معمولاً نمی‌گیرند. پرسش سنجش برای هر بکاپ این است: اگر همین فایل را برگردانیم، سایت کامل بالا می‌آید یا فقط ظاهرش؟ سنجش سریع هم ساده است: حجم فایل بکاپ را با حجم واقعی دیتابیس در پنل مقایسه کنید؛ فایلی که کوچک‌تر است، دیتابیس را ندارد.
ایمیل‌ها هم معمولاً از قلم می‌افتند، چون روی سرویس ایمیلِ جدا از وب‌سرور می‌نشینند و در بکاپ فایل‌های سایت نیستند. صندوق‌های سازمانی که روی هاست ساخته شده‌اند، تاریخ مکاتبهٔ مجموعه‌اند؛ بدون نسخهٔ جداگانه، حذف یک اکانت یا خرابی سرویس، آرشیو را با خود می‌برد. مسیر ساخت و نگهداری صندوق‌ها در آموزش گام‌به‌گام ایمیل سازمانی با دامنهٔ خود باز شده است؛ سیاست بکاپ ایمیل را همزمان با بکاپ سایت ببندید، نه بعد از حادثه.
آزمون بازیابی نشده و نگهداری روی همان سرور
علت چهارم، نسخه‌ای است که هرگز برگردانده نشده است. فایلی که فقط ساخته شده، تست نشده است: ممکن است ناقص باشد، رمزش گم باشد یا در لحظهٔ بازگردانی با نسخهٔ PHP و افزونه‌های فعلی سازگار نباشد. به تجربهٔ ما بازگردانی آزمایشی — روی محیط موقت، نه روی سایت اصلی — تنها راهی است که «فایل بکاپ» را به «بکاپ» تبدیل میکند؛ تا پیش از آن، این فایل فقط یک وعدهٔ بایگانی‌شده است.
علت پنجم، همسایگی نسخه‌ها با خود سایت است: همهٔ بکاپ‌ها روی همان سرور یا همان دیتاسنتر. این حالت دستهٔ بزرگی از حوادث را پوشش نمی‌دهد: دیسکی که می‌سوزد نسخه‌ها را هم با خود می‌برد؛ حمله‌ای که به فایل‌های سایت دسترسی میگیرد به فولدر بکاپ هم می‌رسد؛ و حذف اشتباهی، بی‌تفاوت بین «سایت» و «بکاپِ سایت» عمل میکند. پرسش سنجش هم ساده است: اگر همین امشب سرور از دسترس خارج شود، فردا صبح از کدام نسخه بالا می‌آیید؟ حداقلِ سیاست، یک نسخهٔ کامل بیرون از سرور است؛ مکانی که کلید دسترسی‌اش با سرور گره نخورده باشد.
دسترسی محدود در پنجرهٔ انتقال هاست
علت ششم، موقعیتی است که کمتر برایش آماده می‌شوند: انتقال هاست. در این پنجره، بکاپ داخل سرور قدیمی معمولاً تنها نسخهٔ کامل است و دانلودش کند و حجم‌بر است؛ بعضی پنل‌ها هم ساخت یا دانلود بکاپ را در ساعات پایانی سرویس محدود می‌کنند. اگر انتقال نیمه‌کاره رها شود، نسخهٔ سالم مال سروری است که دیگر در اختیار شما نیست؛ و دانلود بکاپ چندگیگابایتی از سروری در حال خروج، همان ساعتی را میگیرد که برای تنظیم سایت جدید لازم دارید.
قاعدهٔ ما برای این پنجره ساده است: پیش از هر انتقال، یک نسخهٔ کامل بیرون از هر دو سرور بگیرید — مکان سوم — و بازگردانیاش را در محیط تست دیده باشید؛ بعد جابه‌جا شوید. مراحل خود انتقال، از جابه‌جایی فایل تا تنظیم DNS، در آموزش گام‌به‌گام انتقال هاست بدون قطعی آمده است؛ آن مقاله مسیر جابه‌جایی را می‌چیند و الزام بکاپیِ پیش از حرکت، همین بخش این مقاله است. سه نسخه در سه مکان؛ همین ساده‌بودن است که اجراشدن را در روز شلوغ ممکن میکند.
معماری بکاپ سه‌لایه‌ای که این شکاف‌ها را می‌بندد
سه لایه، شش علت را از دو سر می‌بندد. لایهٔ اول، نسخهٔ سریع روی خود هاست است: بازگردانی فوری برای خرابی‌های کوچک و برگشت‌پذیر؛ همین لایه باید بازهٔ نگهداری معقول و شرط «نسخهٔ پیش از تغییر» را داشته باشد. لایهٔ دوم، نسخهٔ کامل دور از سرور است: مکانی جدا که دسترسی‌اش مستقل از سرور است و بازهٔ نگهداری‌اش بلندتر.
لایهٔ سوم، نسخهٔ دستی پیش از تغییر است: قبل از آپدیت‌های بزرگ، تعویض قالب و انتقال، یک نسخهٔ کامل با برچسب تاریخ بگیرید و بیرون سرور بگذارید؛ این نسخه نقطهٔ برگشت مشخصی می‌سازد که آرشیو خودکار ندارد. ساختار سه‌لایه در مقالهٔ آموزشی پیش‌ین همین خوشه با گام‌های سی‌پنل اجرا می‌شود؛ کاری که این مقاله اضافه میکند، الزام سیاستیِ هر لایه است: چه چیزی بیرون بماند، چه چیزی تمرین شود و چه چیزی پیش از تغییر بسته شود.
اگر تیم ظرفیت اجرا و پایش این چرخه را ندارد، بخشی از آن در سوئیت خودکار می‌شود. قابلیت‌های پلتفرم انتشار و پایش محتوا را در یک پنل نگه می‌دارد و صفحهٔ امنیت و پشتیبان‌گیری در سوئیت سهم بکاپ را در معماری امنیت نشان می‌دهد.
جمع‌بندی؛ پنج پرسش پیش از اعتماد به پشتیبان
جمع‌بندی در سه خط: بکاپ سمت هاست کف امنیت است، نه سقف آن؛ نسخه‌ای که بیرون سرور نباشد و بازگردانیاش تمرین نشده باشد، در روز بحران فایل خاموشی است. معماری سه‌لایه — سریع روی هاست، کامل دور از سرور، دستی پیش از تغییر — هم شش علت پنهان را می‌بندد.
پنج پرسشی که وضعیت فعلی را روشن میکند: نسخهٔ کامل بیرون سرور دارید؟ آخرین بازگردانی آزمایشی کِی بود؟ دیتابیس و ایمیل در پوشش‌اند؟ بازهٔ نگهداری کشف دیرهنگام را پوشش می‌دهد؟ و نسخهٔ مکان سوم پیش از انتقال بعدی کجاست؟
برای شروع کم‌ریسک، ممیزی رایگان دامنه تصویر وضعیت فعلی را می‌دهد و نقشهٔ کامل خوشه در هاب هاست و زیرساخت جمع شده است. به تجربهٔ ما تیم‌هایی که این پنج پرسش را هر فصل جواب می‌دهند، بازیابی را از پروژهٔ اضطراری به روتین می‌رسانند؛ و روتین است که در روز حادثه زمان می‌خرد.
رصد ما، رشد شما.
سؤالات پرتکرار
بکاپ خودکار هاستینگ کافی است؟
بهتنهایی نه؛ نسخهٔ خودکار معمولاً روی همان سرور میماند و اگر شرط «نسخهٔ سالم جدا» نداشته باشد، خرابی را هم آرشیو میکند. حداقلِ کار، یک نسخهٔ کامل بیرون از سرور و یک بازگردانی تمرینشده است.
بازهٔ نگهداری بکاپ چند روز باشد؟
عدد قانونی وجود ندارد؛ به تجربهٔ ما برای سایتهای پرتغییر چند هفته و برای سایتهای آرام چند ماه معنا دارد، چون کشف حادثههای سمت دیتابیس معمولاً دیرتر از وقوع است.
چرا بکاپ باید بیرون از سرور ذخیره شود؟
چون دیسکِ معیوب، حمله و حذف اشتباهی مرز سرور را نمیشناسند و نسخههای همسایه را هم با خود میبرند؛ نسخهٔ بیرونی نقطهٔ برگشتی است که با سایت همزمان آسیب نمیبیند.
قبل از انتقال هاست چه بکاپی بگیریم؟
یک نسخهٔ کامل بیرون از هر دو سرور — مکان سوم — که بازگردانیاش در محیط تست دیده شده باشد؛ بکاپ داخل سرور قدیمی در پنجرهٔ انتقال قابل اتکا نیست.
فرق بکاپ هاست با بکاپ افزونهٔ وردپرس چیست؟
بکاپ هاست سطح زیرساخت را میگیرد و برای بازگردانی کامل اکانت کاربرد دارد؛ بکاپ افزونه سمت وردپرس است و سریعتر ولی وابسته به سلامت خود وردپرس. به تجربهٔ ما دو لایه مکملاند، نه جایگزین هم.
