چرا Snapshot جای Backup را نمی‌گیرد؟ ۶ سناریوی واقعی از دست رفتن داده

خیلی از مدیران سرور بعد از یک حادثه متوجه می‌شوند که «بکاپ» آن‌ها در واقع فقط یک Snapshot بوده است. Snapshot ابزار فوق‌العاده‌ای برای بازگشت سریع است، اما در بسیاری از سناریوهای واقعی از دست رفتن داده، هیچ کمکی نمی‌کند. در این مقاله شش سناریوی واقعی را بررسی می‌کنیم که نشان می‌دهد چرا Snapshot جای Backup را نمی‌گیرد، و در پایان یک برنامه ساده برای استفاده درست از هر دو ارائه می‌دهیم.

پاسخ کوتاه

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

شش سناریو که Snapshot شما را نجات نمی‌دهد

۱. خرابی استوریج یا آرایه دیسک

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

۲. باج‌افزار (Ransomware)

اگر مهاجم به پنل مدیریت یا حساب کاربری شما دسترسی پیدا کند، اولین کاری که می‌کند حذف Snapshotها و بکاپ‌های در دسترس است. فقط بکاپی که در محلی جداگانه، با دسترسی متفاوت و ترجیحاً غیرقابل تغییر (Immutable) نگهداری شود، در برابر باج‌افزار مقاوم است.

۳. حذف یا اشتباه که دیر کشف شود

Snapshotها به دلیل هزینه عملکردی معمولاً کوتاه‌مدت نگهداری می‌شوند؛ چند ساعت یا چند روز. اگر یک جدول دیتابیس اشتباهی حذف شود و سه هفته بعد متوجه شوید، Snapshotی از آن زمان وجود ندارد. بکاپ با سیاست نگهداری مناسب (مثلاً روزانه برای یک هفته، هفتگی برای یک ماه، ماهانه برای یک سال) این مشکل را حل می‌کند.

۴. دیتابیس ناسازگار در لحظه Snapshot

Snapshot معمولی از دیسک، وضعیت حافظه دیتابیس را در نظر نمی‌گیرد. اگر در لحظه گرفتن Snapshot، MySQL یا PostgreSQL در حال نوشتن باشد، بعد از بازگردانی، دیتابیس باید فرایند بازیابی خودکار را طی کند و در موارد بدی ممکن است داده‌های آخرین تراکنش‌ها ناقص باشند. بکاپ منطقی دیتابیس با ابزارهایی مثل mysqldump یا pg_dump این مشکل را ندارد.

۵. نیاز به بازیابی فقط یک فایل

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

۶. مهاجرت یا تعطیلی سرویس

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

هزینه‌های پنهان نگه داشتن Snapshot

یک باور اشتباه رایج این است که «هرچه Snapshot بیشتر، امن‌تر». در عمل:

• کاهش سرعت دیسک: در بسیاری از پلتفرم‌ها، از جمله VMware، هر نوشتن روی دیسک دارای Snapshot در یک فایل تغییرات (Delta) ثبت می‌شود. هرچه زنجیره Snapshotها طولانی‌تر و قدیمی‌تر باشد، خواندن و نوشتن کندتر می‌شود.
• رشد حجم: فایل تغییرات با هر نوشتن بزرگ‌تر می‌شود و می‌تواند استوریج را پر کند.
• ریسک ادغام: حذف یک Snapshot قدیمی و بزرگ یعنی ادغام حجم زیادی تغییرات با دیسک اصلی؛ عملیاتی زمان‌بر که در صورت مشکل، خودش ریسک‌زاست.

توصیه رایج در محیط‌های مجازی‌سازی این است که هیچ Snapshotی بیش از چند روز نگه داشته نشود.

Snapshot دقیقاً برای چه کاری خوب است؟

Snapshot برای تغییرات برنامه‌ریزی‌شده و کوتاه‌مدت بی‌نظیر است:

• قبل از آپدیت سیستم‌عامل یا ارتقای نسخه PHP، دیتابیس یا کنترل‌پنل.
• قبل از تغییر تنظیمات حساس شبکه یا فایروال.
• قبل از نصب نرم‌افزاری که از نتیجه آن مطمئن نیستید.

اگر تغییر موفق بود، Snapshot را حذف کنید؛ اگر مشکل پیش آمد، در چند دقیقه به وضعیت قبل برمی‌گردید.

برنامه پیشنهادی: Snapshot و Backup در کنار هم

این برنامه همان قانون ۳-۲-۱ را پیاده می‌کند: سه نسخه از داده، روی دو نوع رسانه، و دست‌کم یک نسخه خارج از محل اصلی. ویژگی‌های یک بکاپ قابل اعتماد را در مقاله بکاپ سرور چیست توضیح داده‌ایم.

بکاپی که تست نشده، بکاپ نیست

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

سوالات متداول