اسنپ‌شات یا بک‌آپ؟

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

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

تفاوت‌ها در یک نگاه

سطر «در برابر از دست رفتن سرور» تمام ماجراست. اسنپ‌شات روی همان زیرساختی ذخیره می‌شود که سرور روی آن اجرا می‌شود؛ اگر مشکلی آن زیرساخت را در بر بگیرد، اسنپ‌شات هم همراهش می‌رود.

اسنپ‌شات برای چه خوب است

اسنپ‌شات ابزار «قبل از اینکه دست به چیزی بزنم» است. موارد درست استفاده‌اش:

• پیش از ارتقای نسخه سیستم‌عامل — ارتقا معمولاً بدون مشکل انجام می‌شود، ولی «معمولاً» روی سرور فعال کافی نیست
• پیش از به‌روزرسانی بزرگ یک سرویس — نسخه جدید دیتابیس، تغییر پیکربندی وب‌سرور
• پیش از تغییرات شبکه و فایروال — همان تغییری که ممکن است دسترسی شما را ببندد
• پیش از نصب چیزی که مطمئن نیستید — امتحان یک پنل یا بسته ناآشنا

مزیت اسنپ‌شات سرعت است. اگر تغییری خراب شد، در چند دقیقه به وضعیت قبل برمی‌گردید، بدون اینکه لازم باشد چیزی را دوباره نصب یا بازیابی کنید.

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

بک‌آپ برای چه خوب است

بک‌آپ ابزار «اگر سرور دیگر نباشد» است. اسنپ‌شات در این موقعیت‌ها کاری از پیش نمی‌برد:

• سرور یا زیرساختش از دسترس خارج شود
• سرور به‌اشتباه حذف شود
• داده‌ای پاک شود و هفته‌ها بعد متوجه شوید
• باج‌افزار یا نفوذی داده‌ها را رمزگذاری یا خراب کند
• بخواهید داده را روی سروری در لوکیشن دیگر بالا بیاورید

مورد سوم را جدی بگیرید. اگر جدولی از دیتابیس ماه پیش خراب شده و تازه فهمیده‌اید، اسنپ‌شات دیروز کمکی نمی‌کند — چون داده خراب داخل آن هم هست. تنها چیزی که نجاتتان می‌دهد، نگه داشتن چند نسخه در فواصل زمانی مختلف است.

روش خودکار و رمزگذاری‌شده آن در راهنمای بک‌آپ خودکار سرور با Restic گام‌به‌گام آمده است، و اگر می‌خواهید نسخه‌ها را روی زیرساختی جدا از سرور اصلی نگه دارید، سرور ابری برای بک‌آپ همین کار را پوشش می‌دهد.

قاعده‌ای که باید رعایت کنید

قاعده رایج در این حوزه، همان قاعده ۳-۲-۱ است: سه نسخه از داده، روی دو نوع رسانه یا زیرساخت متفاوت، که یکی از آن‌ها خارج از محل اصلی باشد.

ترجمه عملی‌اش برای یک سرور مجازی:

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

دیتابیس یک استثنای مهم دارد

کپی کردن فایل‌های یک دیتابیس در حال اجرا می‌تواند نسخه‌ای ناسازگار بدهد: بخشی از تراکنش‌ها نوشته شده و بخشی نه. چنین نسخه‌ای ممکن است اصلاً بالا نیاید.

راه درست، استفاده از ابزار خروجی گرفتن خود دیتابیس است:

pg_dump -U postgres -Fc mydb > mydb.dump
mysqldump --single-transaction -u root -p mydb > mydb.sql

سپس همین فایل خروجی را به مقصد بک‌آپ بفرستید. راهنمای نصب و پیکربندی در آموزش نصب PostgreSQL و انتخاب منابع مناسب در سرور مجازی برای دیتابیس آمده است.

بک‌آپی که تست نشده، بک‌آپ نیست

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

سطر سوم را حذف نکنید. با پرداخت روزانه، ساخت یک سرور موقت برای تست بازیابی و حذفش پس از چند ساعت هزینه‌ای ندارد که ارزش صرف‌نظر کردن داشته باشد — پرداخت روزانه یا ماهانه دقیقاً همین آزادی را توضیح می‌دهد.

جمع‌بندی

پرسش درست «اسنپ‌شات یا بک‌آپ» نیست؛ هر دو، برای دو کار متفاوت.

اسنپ‌شات بگیرید پیش از هر تغییری که ممکن است خراب شود: ارتقای نسخه، تغییر فایروال، به‌روزرسانی بزرگ. بازگشتش چند دقیقه است و همین ارزشش را می‌سازد.

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

اگر امروز فقط یکی از این دو را دارید، آن یکی احتمالاً اسنپ‌شات است — و آن یکی است که در بدترین سناریو کمکی نمی‌کند.

ساخت سرور ابری برای بک‌آپ