با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
سه نسخه داده نگه دار
قاعده ۳-۲-۱ میگوید دستکم سه نسخه از داده داشته باشی: داده اصلی و دو نسخه پشتیبان؛ هدف کاهش وابستگی به یک خرابی واحد است نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد برای کامل شدن تصویر این موضوع، در این درس موضوع را از دید قابلیت بازیابی بررسی میکنیم؛ داشتن Storage یا اجرای موفق Backup بهتنهایی کافی نیست و باید بدانی در خرابی واقعی چه دادهای، تا چه نقطه زمانی و در چه مدت باید برگردد؛ RPO، RTO، سازگاری Application، محل نگهداری نسخه و آزمون Restore معیارهایی هستند که طراحی و عیبیابی را هدایت میکنند
دو نوع Storage متفاوت ریسک مشترک را کم میکند
در قاعده ۳-۲-۱ داشتن کپیها روی دو نوع رسانه یا سامانه متفاوت کمک میکند یک خرابی واحد همه نسخهها را همزمان از بین نبرد؛ دو Folder روی همان Disk دو رسانه مستقل نیستند برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد برای کامل شدن تصویر این موضوع، در این درس موضوع را از دید قابلیت بازیابی بررسی میکنیم؛ داشتن Storage یا اجرای موفق Backup بهتنهایی کافی نیست و باید بدانی در خرابی واقعی چه دادهای، تا چه نقطه زمانی و در چه مدت باید برگردد؛ RPO، RTO، سازگاری Application، محل نگهداری نسخه و آزمون Restore معیارهایی هستند که طراحی و عیبیابی را هدایت میکنند
یک نسخه Offsite باشد
نسخه Offsite در محل یا سامانهای جدا نگهداری میشود تا آتشسوزی، سرقت یا خرابی کامل سایت همه نسخهها را همزمان از بین نبرد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد برای کامل شدن تصویر این موضوع، در این درس موضوع را از دید قابلیت بازیابی بررسی میکنیم؛ داشتن Storage یا اجرای موفق Backup بهتنهایی کافی نیست و باید بدانی در خرابی واقعی چه دادهای، تا چه نقطه زمانی و در چه مدت باید برگردد؛ RPO، RTO، سازگاری Application، محل نگهداری نسخه و آزمون Restore معیارهایی هستند که طراحی و عیبیابی را هدایت میکنند
Offline یا Immutable در Ransomware مهم است
Ransomware داده را رمز یا غیرقابل دسترس میکند و ممکن است قبل از آن داده را سرقت کند؛ در رخداد مشکوک ایزولهسازی کنترلشده و حفظ شواهد اهمیت دارد اتصال سریع Backup آنلاین بدون بررسی میتواند نسخه پشتیبان را هم در خطر قرار دهد نسخه Immutable برای مدت مشخص قابل تغییر یا حذف نیست و در برابر حذف عمدی یا Ransomware لایه دفاعی مهمی میسازد راهنمای CISA و NIST بر چند پایه تکرارشونده تأکید دارد: استفاده از MFA برای حسابهای مهم، بهروزرسانی منظم، محدود کردن دسترسی مدیریتی، نگهداری Backup قابل بازیابی، ثبت رویدادها و آموزش مقابله با فیشینگ؛ در رخداد مشکوک، هدف اول حفظ شواهد و محدود کردن دامنه اثر است، نه انجام تغییرهای متعدد و بدون ثبت؛ حسابهای مدیریتی باید از حساب روزمره جدا باشند و سطح دسترسی فقط به اندازه نیاز کاری داده شود در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد
این قاعده شروع طراحی است نه همه طراحی
قاعده ۳-۲-۱ تعداد و محل کپیها را بهتر میکند، اما Retention، Encryption، Immutability، Monitoring و Test Restore همچنان باید جدا طراحی شوند در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد برای کامل شدن تصویر این موضوع، در این درس موضوع را از دید قابلیت بازیابی بررسی میکنیم؛ داشتن Storage یا اجرای موفق Backup بهتنهایی کافی نیست و باید بدانی در خرابی واقعی چه دادهای، تا چه نقطه زمانی و در چه مدت باید برگردد؛ RPO، RTO، سازگاری Application، محل نگهداری نسخه و آزمون Restore معیارهایی هستند که طراحی و عیبیابی را هدایت میکنند
فرض کن در سامانه Backup و Storage مشکلی گزارش شده و احتمال میدهی به قاعده ۳-۲-۱ مربوط باشد. قبل از تغییر، وضعیت فعلی را با Backup Console، Job History و Restore Test بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- اتصال سریع Backup آنلاین بدون بررسی میتواند نسخه پشتیبان را هم در خطر قرار دهد
- تغییر دادن تنظیمات مرتبط با قاعده ۳-۲-۱ قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره قاعده ۳-۲-۱ فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با قاعده ۳-۲-۱، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با Backup Console، Job History و Restore Test وضعیت مرتبط با قاعده ۳-۲-۱ را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با قاعده ۳-۲-۱ بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- سه نسخه داده نگه دار
- دو نوع Storage متفاوت ریسک مشترک را کم میکند
- یک نسخه Offsite باشد
- Offline یا Immutable در Ransomware مهم است
- این قاعده شروع طراحی است نه همه طراحی
- موفق بودن Job بهتنهایی کافی نیست؛ Restore را هم آزمایش کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید سه نسخه داده نگه داری و از کجا میفهمی نتیجه درست است؟
قاعده ۳-۲-۱ میگوید دستکم سه نسخه از داده داشته باشی: داده اصلی و دو نسخه پشتیبان؛ هدف کاهش وابستگی به یک خرابی واحد است
این نکته را با یک مثال توضیح بده: دو نوع Storage متفاوت ریسک مشترک را کم میکند. بعد بگو در عمل چطور آن را بررسی میکنی.
در قاعده ۳-۲-۱ داشتن کپیها روی دو نوع رسانه یا سامانه متفاوت کمک میکند یک خرابی واحد همه نسخهها را همزمان از بین نبرد. دو Folder روی همان Disk دو رسانه مستقل نیستند
این نکته را با یک مثال توضیح بده: یک نسخه Offsite باشد. بعد بگو در عمل چطور آن را بررسی میکنی.
نسخه Offsite در محل یا سامانهای جدا نگهداری میشود تا آتشسوزی، سرقت یا خرابی کامل سایت همه نسخهها را همزمان از بین نبرد
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
