در باهم۱۴۰۵ مطرح شد: نسخه پشتیبان کافی نیست؛ سازمان‌ها چقدر برای بازیابی سرویس‌ها آماده‌اند؟

در باهم۱۴۰۵ مطرح شد: نسخه پشتیبان کافی نیست؛ سازمانها چقدر برای بازیابی سرویسها آمادهاند؟

گزارش دیجیاتو از کارگاه «Data Protection؛ هنر زنده نگهداشتن داده» و گفتگو با علی قادری را میتوانید در ادامه ببینید.

داشتن نسخه پشتیبان از دادهها یا راهاندازی سایت بازیابی بحران، لزوماً به معنای آمادگی سازمان برای بازگرداندن سرویسهای حیاتی نیست. علی قادری، متخصص مجازیسازی و بازیابی بحران ابرآمد، در کارگاه «Data Protection؛ هنر زنده نگهداشتن داده» در سومین روز رویداد «باهم ۱۴۰۵» همکاران سیستم، توضیح داد که سازمانها برای مواجهه با اختلال باید از پیش، اولویت سرویسها، میزان ازدسترفتن قابلقبول داده و زمان بازیابی را مشخص کنند و با آزمایشهای دورهای، از کارآمدی راهکارهای خود مطمئن شوند.

قادری در ابتدای این کارگاه به چالش کسبوکارها در حفظ و نگهداری دادهها و زیرساخت شبکه اشاره کرد و اهمیت آمادگی سازمانها برای مواجهه با اختلالهای زیرساختی را توضیح داد. به گفته او، Data Protection صرفاً به معنای حفظ دادهها نیست، بلکه سازمان باید بتواند تداوم سرویسدهی و کسبوکار خود را نیز تضمین کند.

هزینه اختلال؛ نقطه شروع برنامهریزی برای بازیابی

قادری در این کارگاه گفت: «وقوع اختلال تنها به از دست رفتن اطلاعات یا توقف موقت سرویسها محدود نمیشود. سازمانها در چنین شرایطی با مجموعهای از هزینههای مستقیم و غیرمستقیم مواجه میشوند؛ از جمله درآمد ازدسترفته در زمان توقف سرویسها، هزینههای Recovery و جریمههای احتمالی ناشی از عمل نکردن به تعهدات SLA.»

او همچنین افزود که در کنار این هزینهها، کاهش اعتماد مشتریان میتواند بر قراردادهای آینده و اعتبار برند تأثیر بگذارد. تیم فنی سازمان نیز بهجای تمرکز بر توسعه و ارتقای زیرساخت، ناچار است زمان و منابع خود را صرف بازیابی سرویسها کند.

سه لایه آمادگی برای اختلال؛ دسترسپذیری، تکثیر داده و پشتیبانگیری

قادری در این کارگاه سه لایه مکمل را برای حفاظت از دادهها و افزایش آمادگی زیرساخت در برابر اختلال تشریح کرد: دسترسپذیری (Availability)، تکثیر دادهها (Replication) و پشتیبانگیری (Backup). دسترسپذیری با کاهش نقاط شکست منفرد، احتمال توقف سرویس را محدود میکند. Replication امکان نگهداری نسخهای همگام یا نزدیک به همگام از دادهها و سامانهها را در زیرساخت دیگر فراهم میکند و در کنار سازوکارهای بازیابی، میتواند به کاهش زمان بازگشت سرویس کمک کند. پشتیبانگیری نیز نسخههایی از دادهها را برای بازیابی در صورت حذف، تخریب یا بروز اختلال نگهداری میکند.

این سه لایه جایگزین یکدیگر نیستند. وجود نسخه پشتیبان، دسترسپذیری مداوم سرویس را تضمین نمیکند و تکثیر دادهها نیز بهتنهایی سازمان را از نیاز به نسخههای پشتیبان مستقل بینیاز نمیسازد. آمادگی واقعی زمانی شکل میگیرد که این راهکارها متناسب با اهمیت سرویسها طراحی و بهصورت دورهای آزمایش شوند.

چرا پشتیبانگیری به تنهایی برای تضمین تداوم کسبوکار کافی نیست؟

یکی از راهکارهای پایه برای حفاظت از دادهها، استفاده از الگوی پشتیبانگیری ۳-۲-۱-۱-۰ است. در این الگو، سه نسخه از دادهها نگهداری میشود، از دو نوع رسانه یا بستر ذخیرهسازی استفاده میشود و دستکم یک نسخه در محلی خارج از سایت اصلی قرار میگیرد. همچنین یک نسخه با حفاظت بیشتر، مانند نسخه آفلاین یا تغییرناپذیر، در نظر گرفته میشود و صحت نسخههای پشتیبان باید بهگونهای آزمایش شود که خطایی در فرایند اعتبارسنجی و بازیابی باقی نماند.

بااینحال، علی قادری تأکید کرد که حتی وجود نسخه پشتیبان سالم نیز به معنای امکان بازگرداندن سریع سرویسها نیست. بازیابی حجم زیادی از دادهها ممکن است ساعتها یا روزها طول بکشد و به همین دلیل، سازمانها در کنار پشتیبانگیری به برنامه مشخصی برای بازیابی سرویسهای حیاتی نیاز دارند.

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

شاخصهای RPO و RTO باید براساس نیازهای کسبوکار تعیین شوند

قادری در ادامه این کارگاه از دو شاخص کلیدی در برنامهریزی برای بازیابی زیرساخت، به نام RPO و RTO اشاره کرد. RPO یا Recovery Point Objective میزان Data Loss قابلقبول برای سازمان را مشخص میکند؛ به این معنا که سازمان در صورت وقوع اختلال، تا چه میزان از اطلاعات را میتواند از دست بدهد.

در مقابل، RTO یا Recovery Time Objective حداکثر زمان قابلقبول برای بازیابی سرویس و بازگشت آن به وضعیت عملیاتی را نشان میدهد.

قادری در کارگاه تأکید کرد که این دو شاخص نباید صرفاً از منظر فنی تعیین شوند، بلکه باید از نیازهای کسبوکار استخراج شوند. برای تعیین آنها، میزان تأثیر توقف هر سرویس بر فعالیت سازمان، هزینههای ناشی از اختلال و وابستگی سرویسهای مختلف به یکدیگر باید بررسی شود. پس از این ارزیابی، سرویسها بر اساس اهمیتشان Tier بندی میشوند و برای هر دسته، RPO و RTO متناسبی در نظر گرفته میشود.

چرا سازمانها در زمان بحران نمیتوانند به برآوردهای خود از توانایی Recovery عمل کنند؟

یکی از چالشهای اصلی در حوزه Data Protection، فاصله میان آمادگی اعلامشده سازمانها و عملکرد واقعی آنها هنگام وقوع اختلال است. قادری به آماری اشاره کرد که براساس آن، ۹۰ درصد سازمانها پیش از بروز اختلال اعلام کرده بودند توانایی بازیابی زیرساختهای خود را دارند؛ اما در زمان وقوع بحران، تنها حدود ۲۸ درصد توانستند به بازیابی کامل دست پیدا کنند.

او در گفتوگو با دیجیاتو نیز سه عامل را در این زمینه مؤثر دانست:

- نخست اینکه پشتیبانگیری بهتنهایی یک راهکار کامل DR نیست؛ زیرا بازیابی حجم زیادی از دادهها میتواند زمانبر باشد.

- دوم اینکه سازمان باید مطمئن شود سایت DR علاوه بر فراهم بودن زیرساختهای موردنیاز، واقعاً قابلیت راهاندازی سرویسها را دارد.

- سوم اینکه فرایند انتقال سرویسها به سایت دوم باید تا حد امکان بهصورت خودکار انجام شود و به دخالت نیروی انسانی وابسته نباشد.

قادری همچنین بر ضرورت انجام تست و مانورهای دورهای پشتیبانگیری و DR تأکید کرد. به گفته او، مشاهده گزارش موقفیتآمیز پشتیبانگیری لزوماً به معنای سلامت کامل نسخه پشتیبان نیست و سازمان باید با اجرای دورهای فرایند بازیابی، از صحت اطلاعات اطمینان پیدا کند. همچنین پس از راهاندازی Replication باید فرایند Failover بین سایت اصلی و سایت دوم آزمایش شود تا قابلیت عملیاتی آن پیش از وقوع بحران مشخص باشد.

آیا سرمایهگذاری روی DR برای همه سرویسها ضروری است؟

یکی از پرسشهای مهم در طراحی زیرساخت DR، میزان سرمایهگذاری موردنیاز برای کاهش RPO و RTO است. کاهش زمان بازیابی از چند ساعت به چند دقیقه میتواند به سرمایهگذاری قابلتوجهی نیاز داشته باشد؛ اما این سطح از آمادگی برای تمام سرویسهای سازمان ضروری نیست.

قادری در گفتوگو با دیجیاتو توضیح داد که سازمانها ابتدا باید با استفاده از BIA، سرویسهای خود را تحلیل و براساس اهمیت آنها Tier بندی کنند. سپس برای سرویسهای حیاتی که توقف آنها خسارت بیشتری به کسبوکار وارد میکند، به سراغ راهکارهایی مانند Replication و کاهش RPO و RTO بروند.

به گفته او، برای همه سرویسها نیز لزوماً نباید از یک مکانیزم یکسان استفاده کرد. بسته به نوع سرویس، میتوان از راهکارهایی مانند Application Replication یا Storage Replication استفاده کرد که هزینه متفاوتی دارند. در نهایت، هزینه پیادهسازی این راهکارها باید با خسارت احتمالی ناشی از توقف سرویس مقایسه شود.

در نهایت، آمادگی واقعی برای اختلال زمانی شکل میگیرد که سازمان نهتنها زیرساخت پشتیبانگیری و DR را راهاندازی کرده باشد، بلکه بتواند در شرایط واقعی، سلامت دادهها را بررسی کند، سرویسها را در زمان تعیینشده بازیابی کند و به اهداف RPO و RTO خود دست پیدا کند.

نویسنده: ترانه رسولیان