با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
Database در حال کار نیاز به Consistency دارد
Database در زمان نوشتن تراکنش چند فایل و حافظه را هماهنگ نگه میدارد؛ Copy ساده Disk ممکن است نقطه سازگار منطقی نداشته باشد Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد
Application-consistent تراکنش را در نظر میگیرد
Backup سازگار با برنامه قبل از ثبت داده با نرمافزار هماهنگ میشود تا تراکنشها در وضعیت قابل بازیابی قرار گیرند Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد
Crash-consistent فقط Disk را ثبت میکند
Crash-consistent تقریباً مانند قطع ناگهانی برق از Disk نسخه میگیرد؛ File System ممکن است بازیابی شود اما نرمافزار باید خودش Recovery تراکنش را انجام دهد Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد
AD و SQL روش Restore خاص دارند
Restore عمل بازگرداندن داده یا سیستم از Backup است و تنها راه اثبات قابل استفاده بودن Backup است؛ بهصورت دورهای Restore آزمایشی با سناریوی واقعی انجام بده صرف دیدن وضعیت موفق Job تضمین بازیابی نیست Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد
Job موفق سلامت منطقی نرمافزار را تضمین نمیکند
موفق بودن Job فقط میگوید فرایند Backup طبق گزارش پایان یافته است؛ ممکن است داده در سطح نرمافزار ناسازگار یا غیرقابل استفاده باشد. Test Restore و بررسی خود برنامه لازم است Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد
فرض کن در سامانه Backup و Storage مشکلی گزارش شده و احتمال میدهی به Backup سازگار با نرمافزار مربوط باشد. قبل از تغییر، وضعیت فعلی را با Backup Console، Job History و Restore Test بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با Backup سازگار با نرمافزار قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره Backup سازگار با نرمافزار فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با Backup سازگار با نرمافزار، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با Backup Console، Job History و Restore Test وضعیت مرتبط با Backup سازگار با نرمافزار را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با Backup سازگار با نرمافزار بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- Database در حال کار نیاز به Consistency دارد
- Application-consistent تراکنش را در نظر میگیرد
- Crash-consistent فقط Disk را ثبت میکند
- AD و SQL روش Restore خاص دارند
- Job موفق سلامت منطقی نرمافزار را تضمین نمیکند
- موفق بودن Job بهتنهایی کافی نیست؛ Restore را هم آزمایش کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: Database در حال کار نیاز به Consistency دارد. بعد بگو در عمل چطور آن را بررسی میکنی.
Database در زمان نوشتن تراکنش چند فایل و حافظه را هماهنگ نگه میدارد؛ Copy ساده Disk ممکن است نقطه سازگار منطقی نداشته باشد
این نکته را با یک مثال توضیح بده: Application-consistent تراکنش را در نظر میگیرد. بعد بگو در عمل چطور آن را بررسی میکنی.
Backup سازگار با برنامه قبل از ثبت داده با نرمافزار هماهنگ میشود تا تراکنشها در وضعیت قابل بازیابی قرار گیرند
این نکته را با یک مثال توضیح بده: Crash-consistent فقط Disk را ثبت میکند. بعد بگو در عمل چطور آن را بررسی میکنی.
Crash-consistent تقریباً مانند قطع ناگهانی برق از Disk نسخه میگیرد؛ File System ممکن است بازیابی شود اما نرمافزار باید خودش Recovery تراکنش را انجام دهد
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
