پاسخ کوتاه
Backup مستقل تنها راه قابل اتکا برای بازیابی از حذف اشتباه، خرابی دیسک، باج‌افزار، خطای Deploy و حادثه ارائه‌دهنده است.
Backup باید بر اساس RPO و RTO طراحی شود: چه مقدار داده قابل از دست‌رفتن است و سرویس در چه زمانی باید برگردد. داشتن فایل بدون آزمون Restore کافی نیست.
اول RPO و RTO را مشخص کنید
RPO می‌گوید حداکثر چه مقدار داده می‌توانید از دست بدهید و RTO می‌گوید سرویس باید در چه زمانی برگردد. Backup ساعتی برای کسب‌وکاری با RPO پنج دقیقه کافی نیست و بهترین Backup نیز اگر Restore آن چند روز طول بکشد، RTO کوتاه را برآورده نمی‌کند.
این دو عدد باید از نیاز کسب‌وکار بیایند، نه از قابلیت پیش‌فرض ابزار. دیتابیس سفارش، فایل عمومی و محیط آزمایشی می‌توانند سیاست‌های متفاوتی داشته باشند.
چه چیزی باید محافظت شود؟
فقط فایل داده کافی نیست. Schema، تنظیمات، Secretهای قابل بازیابی، نسخه نرم‌افزار، DNS، Ruleهای شبکه و دستور ترتیب راه‌اندازی نیز برای بازسازی سرویس لازم‌اند. فهرست دارایی باید مالک و محل هر مورد را نشان دهد.
- قاعده 3-2-1 تنوع نسخه و محل را افزایش می‌دهد.
- Backup دیتابیس باید سازگار و قابل Restore باشد.
- نسخه Immutable در برابر حذف مخرب کمک می‌کند.
طراحی و اجرای سیاست
دارایی‌ها را طبقه‌بندی، RPO/RTO را تعیین، Backup رمزنگاری‌شده خارج از سرور بسازید و Restore کامل را طبق برنامه تمرین کنید.
نسخه‌ها را رمزنگاری کنید، دسترسی حذف را از دسترسی Production جدا نگه دارید و حداقل یک کپی خارج از همان میزبان یا حساب داشته باشید. Retention باید نسخه‌های کوتاه‌مدت پرتعداد و نسخه‌های بلندمدت کم‌تعداد را با هزینه قابل پیش‌بینی ترکیب کند.
سازگاری داده
کپی فایل در میانه نوشتن ممکن است مجموعه‌ای ناسازگار بسازد. برای دیتابیس از ابزار native، transaction snapshot یا هماهنگی application-aware استفاده کنید و ترتیب بازیابی چند سرویس وابسته را مستند سازید.
پس از تهیه نسخه، checksum، اندازه و وضعیت Job را ثبت کنید؛ موفقیت Process به معنی قابل استفاده بودن محتوا نیست. نسخه‌ای که ناقص یا با کلید گم‌شده رمزنگاری شده باشد، در عمل Backup نیست.
آزمون Restore
Restore را در محیط جدا و با دستورالعملی که فرد دیگری هم بتواند اجرا کند آزمایش کنید. زمان شروع تا ارائه اولین درخواست سالم را اندازه بگیرید و آن را با RTO مقایسه کنید. برای دیتابیس، تعداد رکورد یا آزمون سازگاری و برای فایل، checksum نمونه‌ها را بررسی کنید.
آزمون فقط یک‌بار کافی نیست. با تغییر نسخه دیتابیس، حجم داده، کلید رمزنگاری یا معماری، مسیر بازیابی نیز تغییر می‌کند. آزمون دوره‌ای باید بخشی از تقویم عملیات باشد.
سناریوی خرابی کامل
فرض کنید سرور و حساب اصلی هم‌زمان در دسترس نیستند. آیا اطلاعات تماس، Credential اضطراری، DNS، Image یا Package مورد نیاز و Backup از یک مسیر مستقل قابل دسترسی‌اند؟ این سناریو وابستگی‌هایی را نشان می‌دهد که در Restore روی همان سرور دیده نمی‌شوند.
اشتباه رایج
Backup روی همان دیسک یا همان حساب Provider در برابر خرابی یا تصاحب حساب استقلال کافی ندارد.
گزارش سبز Job، تعداد زیاد Snapshot یا وجود Replica به‌تنهایی اثبات بازیابی نیست. معیار واقعی، Restore موفق در زمان هدف و با داده معتبر است.
پرسش‌های مهمی که قبل از اقدام باید جواب دهید
برای اینکه پاسخ «چرا Backup برای Server ضروری است؟» فقط در حد اطلاعات عمومی نماند، ابتدا وضعیت فعلی خود را با عدد توصیف کنید: نسخه سیستم‌عامل یا نرم‌افزار، تعداد کاربر هم‌زمان، مصرف معمول و اوج منابع، حجم و رشد داده، محدودیت شبکه و بیشترین قطعی قابل قبول. بدون این اطلاعات ممکن است توصیه‌ای که از نظر فنی درست است، برای محیط شما انتخاب مناسبی نباشد.
دو سؤال بعدی مستقیماً از نکات این موضوع می‌آیند: «قاعده 3-2-1 تنوع نسخه و محل را افزایش می‌دهد.» در زیرساخت شما چگونه اندازه‌گیری یا تأیید می‌شود؟ و «Backup دیتابیس باید سازگار و قابل Restore باشد.» چه اثری روی کاربر، هزینه یا مسیر بازیابی دارد؟ پاسخ را در قالب شواهدی مانند خروجی فرمان، نمودار متریک، نتیجه آزمون یا مستند ارائه‌دهنده ثبت کنید؛ اتکا به حافظه و حدس برای تصمیم عملیاتی کافی نیست.
یک برنامه عملی کم‌ریسک
کار را با ثبت وضعیت فعلی و یک معیار موفقیت آغاز کنید. سپس پیشنهاد اصلی این راهنما را در کوچک‌ترین محیط نماینده اجرا کنید: دارایی‌ها را طبقه‌بندی، RPO/RTO را تعیین، Backup رمزنگاری‌شده خارج از سرور بسازید و Restore کامل را طبق برنامه تمرین کنید. نتیجه را در حالت عادی و در یک سناریوی خطا یا فشار کنترل‌شده بسنجید. اگر معیار بهتر نشد، به‌جای افزودن تغییرات بیشتر، فرض اولیه را بازبینی کنید.
پیش از اعمال تغییر در سرویس اصلی، روش بازگشت، مسئول تصمیم و زمان توقف را روشن کنید. این هشدار را نیز به‌عنوان شرط توقف در نظر بگیرید: Backup روی همان دیسک یا همان حساب Provider در برابر خرابی یا تصاحب حساب استقلال کافی ندارد. پس از اجرا، نتیجه، نسخه‌ها و تنظیمات مؤثر را مستند کنید و یک زمان بازبینی تعیین کنید؛ تغییر بدون پایش ممکن است امروز سالم به نظر برسد اما در پیک بعدی شکست بخورد.
- قاعده 3-2-1 تنوع نسخه و محل را افزایش می‌دهد.
- Backup دیتابیس باید سازگار و قابل Restore باشد.
- نسخه Immutable در برابر حذف مخرب کمک می‌کند.
چک‌لیست نهایی
برای «چرا Backup برای Server ضروری است؟» باید RPO، RTO، دامنه داده، محل مستقل، رمزنگاری، Retention، مالک Job، Alert شکست، کلید بازیابی و تاریخ آخرین Restore موفق مشخص باشد. هر خانه خالی یک ریسک عملیاتی واقعی است.
- قاعده 3-2-1 تنوع نسخه و محل را افزایش می‌دهد.
- Backup دیتابیس باید سازگار و قابل Restore باشد.
- نسخه Immutable در برابر حذف مخرب کمک می‌کند.