تفاوت Snapshot، بکاپ و Replication چیست؟
داشتن چند نسخه از داده الزاماً به معنی چند راه مستقل برای برگشت نیست. ممکن است همه به یک ذخیره‌ساز وابسته باشند، یک حذف به مقصد دوم هم منتقل شود یا نسخه سالم قبل از خطا دیگر وجود نداشته باشد. برای مقایسه این سه مفهوم باید مسیر بازیابی را بشناسیم.
آخرین بازبینی متن:
در این صفحه
هرکدام برای چه کاری استفاده می‌شوند؟
| سازوکار | کاربرد معمول | پرسش تعیین‌کننده |
|---|---|---|
| Snapshot؛ اسنپ‌شات | ثبت نقطه بازگشت برای داده، دیسک یا ماشین؛ مثلاً پیش از تغییر برنامه. | آیا به دیسک یا ذخیره‌ساز اصلی وابسته است و تا چه زمانی نگه داشته می‌شود؟ |
| Backup؛ بکاپ | بازیابی فایل یا سرویس از نسخه سالم انتخاب‌شده. | چه داده‌ای پوشش دارد، نسخه کجا محافظت می‌شود و بدون منبع اصلی قابل خواندن است؟ |
| Replication؛ تکثیر | نگه‌داشتن داده یا ماشین در مقصد دوم برای ادامه کار یا بازیابی. | مقصد چقدر به‌روز است، خطا یا حذف را هم می‌گیرد و چه نقاط قدیمی‌ای دارد؟ |
برای دیدن همه ستون‌ها، جدول را به چپ یا راست بکشید؛ با کیبورد از کلیدهای جهت استفاده کنید.
بکاپ ممکن است برای ثبت وضعیت منسجم از Snapshot استفاده کند؛ Snapshot هم ممکن است به مقصد دیگری منتقل شود. کپی‌کردن خود فایل‌های بکاپ به مخزن دوم نیز نوعی تکثیر داده است. برای فهم طرح، روشن کنید چه چیزی تکثیر می‌شود: داده زنده، ماشین قابل راه‌اندازی، اسنپ‌شات یا نسخه‌های بکاپ.
آیا Snapshot همیشه به داده اصلی وابسته است؟
در اسنپ‌شات متعارف ماشین مجازی VMware، فایل تغییرات به دیسک پایه وابسته است؛ با حذف دیسک پایه، فایل اسنپ‌شات به‌تنهایی ماشین را برنمی‌گرداند. این نمونه برای بازگشت کوتاه‌مدت پیش از تغییر مفید است، اما بکاپ مستقل محسوب نمی‌شود. نگهداری طولانی آن نیز می‌تواند فضا و کارایی را درگیر کند.
اما نمی‌توان این رفتار را به هر محصولی با نام Snapshot تعمیم داد. برای نمونه، Amazon EBS Snapshot داده را به‌صورت افزایشی در زیرساخت ذخیره‌سازی سرویس نگه می‌دارد و از آن می‌توان فضای ذخیره‌سازی تازه (Volume) ساخت. در این سازوکار، نسخه در زیرساخت ذخیره‌سازی سرویس نگهداری می‌شود و به فایل تغییرات محلی کنار دیسک اصلی محدود نیست.
پس به‌جای حکم کلی «اسنپ‌شات بکاپ هست یا نیست»، بررسی کنید با از دست‌رفتن منبع چه چیزی باقی می‌ماند، چه کسی می‌تواند نسخه را حذف کند و بازگشت به کدام تاریخ ممکن است. اسنپ‌شات روی همان NAS ممکن است حذف اشتباه را جبران کند، اما خرابی کامل همان دستگاه مسئله دیگری است.
چرا Replication لزوماً بکاپ را حذف نمی‌کند؟
تکثیر، تغییرات را به مقصد می‌رساند؛ بسته به روش، این انتقال می‌تواند دوره‌ای باشد و مقصد از منبع عقب بماند. «وظیفه فعال است» با «آخرین داده لازم به مقصد رسیده است» فرق دارد. برای ادامه کار، شبکه، دسترسی کاربران، ظرفیت مقصد و سرویس‌های وابسته هم باید آماده باشند.
اگر یک فایل اشتباه حذف یا داده‌ای خراب شود، همان تغییر ممکن است تکثیر شود. یک مقصد با آخرین وضعیت، الزاماً نسخه پیش از خطا را ندارد. برخی راهکارها نقاط بازیابی قبلی را هم نگه می‌دارند؛ مثلاً Veeam برای Replica ماشین مجازی، زنجیره نقاط بازیابی دارد. تعداد و مدت حفظ آن‌ها باید با زمان کشف خطا متناسب باشد.
بنابراین دو گزاره کلی نادرست‌اند: «تکثیر همیشه فقط آخرین وضعیت را دارد» و «با داشتن تکثیر دیگر بکاپ لازم نیست». باید تاریخچه واقعی، حفاظت نسخه و استقلال از خرابی یا دسترسی مدیریتی مشترک بررسی شود. جدا بودن محل فیزیکی به‌تنهایی مانع حذف با یک حساب پرقدرت نمی‌شود.
مثال: تغییر ناموفق، حذف فایل و خرابی میزبان
فرض کنید یک شرکت قبل از به‌روزرسانی نرم‌افزار، نقطه بازگشت محلی می‌سازد؛ ماشین کاری را به میزبان دوم تکثیر می‌کند و بکاپ‌های دارای تاریخچه را در مخزن جدا نگه می‌دارد. این سناریو فرضی، نقش هر لایه را در اتفاق‌های متفاوت نشان می‌دهد.
| اتفاق | مسیر قابل بررسی | شرطی که نباید فراموش شود |
|---|---|---|
| تغییر نرم‌افزار نتیجه مطلوب نداده و ذخیره‌ساز سالم است. | نقطه بازگشت قبل از تغییر، اگر روش برنامه آن را پشتیبانی کند. | بازگشت کل ماشین می‌تواند کار ثبت‌شده بعد از آن نقطه را هم کنار بگذارد؛ داده تازه و وابستگی برنامه باید بررسی شوند. |
| حذف اشتباه چند روز بعد کشف شده است. | نسخه سالم پیش از حذف، از بکاپ یا تاریخچه مناسب مقصد. | نسخه باید هنوز موجود و قابل خواندن باشد؛ آخرین کپی ممکن است حذف را هم داشته باشد. |
| میزبان اصلی از دسترس خارج شده است. | Replica آماده یا بازیابی بکاپ روی مقصد سازگار. | تازگی داده، منابع مقصد و راه اتصال کاربران باید بررسی شوند؛ روشن‌شدن ماشین به‌تنهایی ادامه کار نیست. |
| ذخیره‌ساز اصلی و نسخه‌های محلی از بین رفته‌اند. | نسخه‌ای که مستقل از همان خرابی باقی مانده است. | وجود نام Snapshot یا Backup کافی نیست؛ محل، دسترسی و اجزای لازم برای بازیابی باید باقی مانده باشند. |
برای دیدن همه ستون‌ها، جدول را به چپ یا راست بکشید؛ با کیبورد از کلیدهای جهت استفاده کنید.
اگر مشکل از دست‌رفتن یک دیسک است، RAID و تحمل خرابی دیسک نیز نقش جداگانه‌ای دارند. RAID تاریخچه فایل یا نسخه خارج از دستگاه ایجاد نمی‌کند.
ثبت وضعیت دیسک، سلامت نرم‌افزار را ثابت می‌کند؟
برنامه در حال کار ممکن است داده‌هایی در حافظه یا عملیات ناتمام داشته باشد. نسخه‌ای که فقط وضعیت دیسک را ثبت کرده، لزوماً همان نتیجه نسخه هماهنگ با برنامه را نمی‌دهد. در اصطلاح، Crash-consistent به وضعیت قابل مقایسه با قطع ناگهانی اشاره دارد؛ Application-consistent با سازوکار پشتیبانی‌شده برنامه برای ثبت وضعیت هماهنگ تهیه می‌شود.
برای نمونه، قابلیت Application-Aware Processing در Veeam برنامه‌های پشتیبانی‌شده را برای تهیه نسخه هماهنگ آماده می‌کند. داشتن نام این قابلیت یا پیام موفق یک کار، جای کنترل تنظیمات، پوشش برنامه و آزمون بازیابی را نمی‌گیرد. روش مناسب به نرم‌افزار و نسخه واقعی محیط وابسته است؛ مراحل تنظیم یکسان برای همه برنامه‌ها وجود ندارد.
تازگی، تاریخچه و سرعت بازگشت را جدا ببینید
تازگی نشان می‌دهد داده مقصد تا کدام زمان رسیده است؛ تاریخچه نشان می‌دهد تا چه گذشته‌ای می‌توان برگشت؛ زمان بازگشت هم مدت آماده‌کردن سرویس قابل استفاده است. ممکن است مقصد بسیار تازه باشد ولی نسخه پیش از حذف هفته قبل را نداشته باشد، یا بکاپ قدیمی موجود باشد اما آماده‌سازی مقصد زمان ببرد.
بکاپ هم الزاماً هر بار کپی کامل همه داده نیست. مقایسه بکاپ کامل، افزایشی و تفاضلی نشان می‌دهد یک نقطه بازیابی ممکن است به چند بخش وابسته باشد. برای انتخاب بازه‌ها، راهنمای برنامه و نگهداری بکاپ ادامه مناسب است.
برای ارزیابی راهکار موجود چه چیزهایی روشن باشد؟
- داده تحت پوشش و اجزای لازم برای بازگرداندن کار شرکت؛ فایل تنها یا برنامه همراه وابستگی‌هایش.
- آخرین نقطه قابل استفاده و قدیمی‌ترین نسخه موردنیاز؛ همراه وضعیت انتقال به مقصد دوم.
- محل نسخه و آنچه با خرابی منبع باقی می‌ماند؛ همچنین حساب‌ها و کلیدهای لازم برای بازیابی.
- مسئول نگهداری و نتیجه آزمون واقعی؛ شامل کار برنامه پس از بازیابی و مواردی که هنوز بررسی نشده‌اند.
برای تغییر کوتاه‌مدت، نقطه بازگشت مناسب می‌تواند مفید باشد؛ برای ادامه کار پس از خرابی، آماده‌بودن مقصد دوم مهم است؛ برای خطاهای قدیمی و حادثه‌ای که نسخه زنده را هم درگیر می‌کند، تاریخچه سالم و حفاظت‌شده لازم است. این نیازها را در یک طرح کنار هم ببینید.
جزئیات محل نگهداری بکاپ و آزمون بازیابی در راهنماهای جدا آمده است. برای اجرای طرح یا بررسی نسخه‌های موجود، خدمات بکاپ و بازیابی نت‌مسترز قابل سفارش است؛ لازم نیست پیش از تماس ابزار را انتخاب کرده باشید.