بکاپ ۳-۲-۱ چیست؟ چطور نسخه‌ای داشته باشیم که واقعاً برگردد؟

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

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

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

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

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

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

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

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

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

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

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

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

از ارائه‌دهنده بپرسید اگر کل سرور یا فضای اصلی در دسترس نباشد، آیا Snapshot هنوز قابل استفاده است؟ همین سؤال تفاوت یک امکان برگشت سریع با یک بکاپ مستقل را روشن می‌کند.

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

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

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