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