نکات کلیدی
- نسخهٔ دوم همان نسخهٔ اول نیست که کپی شده باشد؛ باید مستقل باشد.
- یک مخزن بسازید که از سرور اصلی جدا باشد و فضای آن دست کم دو برابر حجم دادهٔ فعلی باشد؛ فضای بیشتر برای نسخه های دوره ای لازم می شود.
- مخزن روی همان آرایهٔ داده: یک خرابی، هم داده و هم نسخه را از بین می برد.
بکاپ Veeam چیست و چه مسئله‌ای را حل می‌کند؟
بکاپ Veeam یک راهکار پشتیبان‌گیری در سطح تصویر است: به‌جای کپی‌کردن فایل‌ها، از کل ماشین یا دیسک یک تصویر قابل بازیابی می‌سازد. نتیجهٔ این انتخاب ساده اما مهم آن است که در روز حادثه، سرویس را در چند ساعت برمی‌گردانید، نه در چند روز. تفاوت این روش با کپی فایل را می‌توان مانند تفاوت عکس ساختمان با فهرست وسایل هر اتاق دانست: با عکس، کل ساختمان را دوباره می‌سازید؛ با فهرست، فقط وسایل را جابه‌جا می‌کنید.
سه پرسش پیش از هر طراحی، مسیر را روشن می‌کند: چه داده‌ای حیاتی است، اگر یک دیسک از کار بیفتد چه چیزی از دست می‌رود، و بازیابی باید در چند ساعت تمام شود. پاسخ این سه پرسش، هم مخزن و هم سیاست نگهداری را تعیین می‌کند.
دو نوع نسخه که در عمل به هر دو نیاز دارید
- بازیابی کل ماشین: برای خرابی سیستم‌عامل، حملهٔ باج‌افزار یا جابه‌جایی به سخت‌افزار دیگر.
- بازیابی آیتمی: برای وقتی که یک فایل، یک صندوق پستی یا یک جدول پایگاه داده حذف شده و بازگرداندن کل ماشین منطقی نیست.
اجزای کاری و نقش هر کدام
در هر طرح عملی سه نقش وجود دارد: سروری که وظیفه‌ها را می‌سازد و زمان‌بندی می‌کند، پردازه‌ای که داده را می‌خواند و منتقل می‌کند، و مقصدی که نسخه‌ها روی آن می‌مانند. اگر این سه روی یک ماشین جمع شوند، سادگی بیشتر می‌شود اما یک خرابی، هر سه را از بین می‌برد. تفکیک نقش‌ها هزینهٔ کمی دارد و ریسک را چند برابر کم می‌کند.
چیدمان استاندارد یک طرح بکاپ
مخزن اصلی: سریع و نزدیک
مخزن اصلی باید سرعت نوشتن پایداری داشته باشد، چون پنجرهٔ زمانی نسخه‌گیری معمولاً کوتاه است. دیسک محلی سرور یا فضای شبکه‌ای پرسرعت برای این نقش مناسب است، به شرطی که از آرایهٔ داده جدا باشد.
نسخهٔ دوم: دور از محل حادثه
نسخهٔ دوم همان نسخهٔ اول نیست که کپی شده باشد؛ باید مستقل باشد. فایلی که روی همان سرور اصلی افتاده، در برابر حذف اشتباه، باج‌افزار و خرابی کنترلر محافظت نمی‌کند. نسخهٔ دوم معمولاً روی فضای ذخیره‌سازی شیءگرا یا سروری در محل دیگر نگه داشته می‌شود.
قفل تغییرناپذیری
مخزن قفل‌شده اجازهٔ حذف یا تغییر نسخه‌ها را تا پایان دورهٔ نگهداری نمی‌دهد. یعنی حتی اگر مهاجم به سرور مدیریت هم دسترسی پیدا کند، نمی‌تواند نسخه‌ها را پاک کند. این ویژگی، مهم‌ترین لایهٔ دفاعی در برابر باج‌افزاری است که اول سراغ بکاپ‌ها می‌رود.
| نوع مقصد | سرعت | مقاومت در برابر حذف | مناسب برای |
|---|---|---|---|
| دیسک محلی سرور مدیریت | بالا | کم | نسخهٔ سریع روزانه |
| مخزن لینوکسی قفل‌شده | متوسط تا بالا | بالا | مخزن اصلی سازمان‌های کوچک |
| فضای شیءگرا | وابسته به شبکه | بالا در صورت فعال‌سازی قفل | نسخهٔ دوم بیرون از محل |
| اشتراک شبکه‌ای | متوسط | کم | محیط آزمایشی |
سیاست نگهداری: چند نسخه و تا چه زمانی؟
نگهداری نسخه‌ها را با نیاز سازمان تعیین کنید، نه با فضای خالی دیسک. یک سیاست ساده و رایج چنین است: نسخهٔ روزانه برای یک ماه، نسخهٔ هفتگی برای یک فصل و نسخهٔ ماهانه برای یک سال. اگر الزام قانونی یا قرارداد داخلی دارید، همان را مبنا بگذارید و نسخهٔ سالانه را جدا نگه دارید.
| دوره | تناوب | مدت نگهداری |
|---|---|---|
| کوتاه‌مدت | هر شب | ۱۴ تا ۳۰ روز |
| میان‌مدت | هفتگی | ۸ تا ۱۲ هفته |
| بلندمدت | ماهانه | ۱۲ ماه |
از نصب تا اولین نسخهٔ سالم
گام یک: تعریف زیرساخت
سرور میزبان یا ماشین‌هایی که باید محافظت شوند را اضافه کنید و اعتبارنامه‌ای با حداقل دسترسی لازم بسازید.
گام دو: ساخت مخزن
یک مخزن بسازید که از سرور اصلی جدا باشد و فضای آن دست‌کم دو برابر حجم دادهٔ فعلی باشد؛ فضای بیشتر برای نسخه‌های دوره‌ای لازم می‌شود.
گام سه: هماهنگی با برنامه
برای پایگاه داده و سرویس‌های حساس، هماهنگی با سرویس سایه‌ای حجم را فعال کنید تا نوشتن‌ها در لحظهٔ نسخه‌گیری معلق شوند. بدون این هماهنگی، فایل سالم به نظر می‌رسد اما بازیابی ممکن است شکست بخورد.
گام چهار: زمان‌بندی و پایش
وظیفه را در ساعت کم‌ترافیک بگذارید و هشدار شکست را به ایمیل یا سامانهٔ پایش وصل کنید. وظیفه‌ای که شکستش را کسی نمی‌بیند، به اندازهٔ نداشتن وظیفه خطرناک است.
آزمون بازیابی؛ تنها معیار واقعی
گزارش موفقیت شبانه فقط می‌گوید داده خوانده و نوشته شده است. آزمون واقعی این است که ماشین را در شبکهٔ جداگانه بالا بیاورید و سرویس را بررسی کنید. فاصلهٔ منطقی این آزمون، ماهی یک بار برای یک فایل و یک بار در فصل برای یک ماشین کامل است. زمان صرف‌شده را ثبت کنید؛ همین عدد، وعدهٔ واقعی شما در روز حادثه است.
خطاهای پرتکرار
- مخزن روی همان آرایهٔ داده: یک خرابی، هم داده و هم نسخه را از بین می‌برد.
- نداشتن نسخهٔ دوم: نسخه‌ای که فقط در یک محل است، در برابر حریق و سرقت بی‌دفاع است.
- حساب پرمجوز: حسابی که برای نوشتن نسخه استفاده می‌شود نباید اجازهٔ حذف داشته باشد.
- آزمون‌نشدن: بکاپی که هرگز بازیابی نشده، فقط یک فرض است.
- فراموش‌کردن فضای رشد: مخزن پر می‌شود و زنجیرهٔ نسخه‌ها ناقص می‌ماند.
پرسش‌های پرتکرار
آیا برای چند ماشین مجازی هم این روش لازم است؟
هر محیطی که داده‌اش بازسازی‌شدنی نیست به نسخهٔ مستقل نیاز دارد. برای دو ماشین هم یک مخزن جدا و یک سیاست ساده کافی است.
چقدر فضای مخزن لازم است؟
به حجم داده، نرخ تغییر روزانه و مدت نگهداری بستگی دارد. با اندازه‌گیری تغییرات یک هفته، برآورد دقیقی به دست می‌آید.
تفاوت بکاپ با اسنپ‌شات چیست؟
اسنپ‌شات یک نقطهٔ بازگشت کوتاه‌مدت روی همان فضای ذخیره‌سازی است و با خرابی آرایه از بین می‌رود؛ بکاپ نسخه‌ای مستقل و قابل انتقال است.
جمع‌بندی
ارزش این راهکار در روز حادثه سنجیده می‌شود، نه در گزارش شبانه. سه تصمیم بیشترین اثر را دارند: مخزنی جدا از داده، نسخهٔ دومی بیرون از محل، و آزمون بازیابی دوره‌ای. اگر این سه درست باشند، ابزار و نسخهٔ انتخابی جزئیات فرعی است.
کمپین ابتکار نو
کمپین ایده های نو
کمپین آینده روشن
کمپین طراحی مدرن