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