با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
Retention مدت نگهداری است
Retention مشخص میکند نسخههای Backup چه مدت نگه داشته شوند؛ نیاز کسبوکار، قانون و ظرفیت Storage را در نظر بگیر Retention کوتاه ممکن است خرابی دیرکشفشده را بدون نسخه سالم باقی بگذارد Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد
Versioning بازگشت به نسخه قبلی میدهد
Versioning چند نسخه زمانی از یک فایل یا Object نگه میدارد و برای حذف یا تغییر اشتباه مفید است؛ جای Backup مستقل در برابر خرابی کامل سرویس را نمیگیرد Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد
GFS الگوی نگهداری دورهای است
Grandfather-Father-Son الگوی نگهداری نسخههای روزانه، هفتگی و ماهانه است تا Retention بلندمدت با تعداد نسخه کنترلشده ترکیب شود Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد
Retention طولانی هزینه دارد
Retention مشخص میکند نسخههای Backup چه مدت نگه داشته شوند؛ نیاز کسبوکار، قانون و ظرفیت Storage را در نظر بگیر در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد برای کامل شدن تصویر این موضوع، در این درس موضوع را از دید قابلیت بازیابی بررسی میکنیم؛ داشتن Storage یا اجرای موفق Backup بهتنهایی کافی نیست و باید بدانی در خرابی واقعی چه دادهای، تا چه نقطه زمانی و در چه مدت باید برگردد؛ RPO، RTO، سازگاری Application، محل نگهداری نسخه و آزمون Restore معیارهایی هستند که طراحی و عیبیابی را هدایت میکنند
حذف خودکار با نیاز بازیابی هماهنگ باشد
Retention تعیین میکند نسخهها چه مدت بمانند؛ اگر نسخهها زودتر از نیاز قانونی یا کسبوکار حذف شوند Backup وجود داشته ولی نقطه بازیابی مورد نیاز دیگر در دسترس نیست Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد
فرض کن در سامانه Backup و Storage مشکلی گزارش شده و احتمال میدهی به Retention و Versioning مربوط باشد. قبل از تغییر، وضعیت فعلی را با Backup Console، Job History و Restore Test بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- Versioning چند نسخه زمانی از یک فایل یا Object نگه میدارد و برای حذف یا تغییر اشتباه مفید است؛ جای Backup مستقل در برابر خرابی کامل سرویس را نمیگیرد
- تغییر دادن تنظیمات مرتبط با Retention و Versioning قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره Retention و Versioning فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با Retention و Versioning، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با Backup Console، Job History و Restore Test وضعیت مرتبط با Retention و Versioning را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با Retention و Versioning بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- Retention مدت نگهداری است
- Versioning بازگشت به نسخه قبلی میدهد
- GFS الگوی نگهداری دورهای است
- Retention طولانی هزینه دارد
- حذف خودکار با نیاز بازیابی هماهنگ باشد
- موفق بودن Job بهتنهایی کافی نیست؛ Restore را هم آزمایش کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: Retention مدت نگهداری است. بعد بگو در عمل چطور آن را بررسی میکنی.
Retention مشخص میکند نسخههای Backup چه مدت نگه داشته شوند؛ نیاز کسبوکار، قانون و ظرفیت Storage را در نظر بگیر
این نکته را با یک مثال توضیح بده: Versioning بازگشت به نسخه قبلی میدهد. بعد بگو در عمل چطور آن را بررسی میکنی.
Versioning چند نسخه زمانی از یک فایل یا Object نگه میدارد و برای حذف یا تغییر اشتباه مفید است؛ جای Backup مستقل در برابر خرابی کامل سرویس را نمیگیرد
این نکته را با یک مثال توضیح بده: GFS الگوی نگهداری دورهای است. بعد بگو در عمل چطور آن را بررسی میکنی.
Grandfather-Father-Son الگوی نگهداری نسخههای روزانه، هفتگی و ماهانه است تا Retention بلندمدت با تعداد نسخه کنترلشده ترکیب شود
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
