Disaster Recovery Site (DR Site)

هو عباره عن مكان تانى للدتاسنتر بتاعتك ممكن يكون يكون فى نفس البلد بس فى منطقه تانيه “محافظه” او ممكن يكون فى بلد تانيه خالص او حتى ممكن يكون على الكلاود الغرض منه وهو الحفاظ على انظمه الشركه وعلى السيستم الخاصه بيها فى حاله حدوث كوارث زى الفيضانات او الحروب او حتى انقطاع الكهرباء لفترات طويله

مش شرط يكون DR site نسخه طبقه الاصل من Main Site من حيث عدد السرفيرات او الاستورج او حتى جزئيه النتورك لان بيتم تصميم DR Site بناءا على السرفيس اللى هتكون موجوده فيه وبناءا على احتياج الكاستمر اللى بيقدر يحقق بيها جزئيه Business continuity بمعنى ان ممكن يكون عندى فى Main site مجموعه من السرفيس زى “Domain Service, Emil Service, ERP system, AV System, Application System” ولكن بناءا على الاتفاق مع الكاستمر عند بناء DR site اتفقنا انه DR Site هيكون فيه “Domain Service, Email Service, ERP System” فى الحاله دى انا مش محتاج نفس عدد Host Server ولا نفس مساحه Storage لان بناءا على تصميم الDR site بيتم تحديد التكلفه لان فى نقط كتير بنحطها فى الاعتبار بالذات اذا كان DR site موجود بالذات فى بلد تانيه او على الكلاود

بتنقسم Application اللى هتبقى موجوده فى DR site الى نوعين Application-Aware Disaster Recovery & Application-non Aware Disaster Recovery

Application-Aware Disaster Recovery

هو الابلكيشن اللى بيكون فيه جزئيه DR site كجزء من مكوناته زى “AD, Exchange, SQL” بمعنى ان فى حاله اضافه اى ابلكيشن من الابلكيشن دى فى DR site فانا بطبق prerequisites الخاصه بالابلكيشن وبتبع التعليمات اللى منزلها الفيندور عشان ابنى DR node الخاصه بالابلكيشن ده بمعنى ان الابلكيشن ده بيكون عنده DR solution الخاص بيه باذن الله هتكلم عن بعض النقط المهمه فى مقالات منفصله

Application-non Aware Disaster Recovery

ده بيكون عباره عن الابلكيشن اللى ملوش جزء DR site من مكوناته زى “File Server, IIS application, costume application” فى الحاله دى بحتاج ابلكيشن تانى عشان اقدر اعمل Replication للسرفير ده فى DR site زى “VMware SRM, RP4VM, Veeam Replication, Double-Take” وكل نوع من الابلكيشن ده بتشتغل بطريقه معينه هنتلكم عليها ان شاء الله فى مقالات منفصله

Disaster Recovery Documents

لازم يكون موجود مجموعه من Documents الخاصه بالDR بتكون موجوده ومتاحه للاشخاص المسؤلين عن اعاده الخدمه فى حاله حدوث اى كارثه بسببها تم انقطاع الخدمه فى Main site

DR Run Book

هى Document الاساسيه اللى بتحتوى على كل الخطوات بالتفصيل لعمل Failover لاعاده تشتغيل الخدمه من DR site او حتى عمل Failback لعاده تشغيل الخدمه مره تانيه من Main Site بعد حل المشكله وبيكون متحدد فيها كل نقطه بالتفصيل ومين التيم المسؤل عن تنفيذ النقطه دى ومين بيكون الشخص الاساسى ومين بيكون الشخص الثانوى فى حاله عدم وجود الشخص الاساسى وكم الوقت المتوقع لتنفيذ النقطه دى

ممكن يكون فى Run book منفصله لكل سرفيس موجوده فى DR site وممكن يكون فى Run Book مجمعه لكل السرفيس الموجوده المهم تحديد RPO, RTO الخاصه بكل سرفيس على حدي

والRPO هى اختصار RECOVERY POINT OBJECTIVE وهى بختصار هو حجم البيانات اللى يمكن للشركة تحمل خسارتها والاستمرار في العمل دون التسبب في ضرر كبير للبزنيس

وال RTO واختصار RECOVERY TIME OBJECTIVE وهى بختصار الوقت اللى تقدر الشركه ان تتحمله والسرفيس غير متاحه لحين اعاده الخدمه مره اخرى بدون التاثير على سير العمل

لو هناخود مثال عشان نوضح النقطه دى ولو نفترض ان المثال بتعنا هيكون على الايميل سرفيس فالسوال هنا هيكون ماهو الوقت الى الشركه تقدر تتحمله وخدمه الايميل مقطوعه لحد ما نقدر اننا نشغل الخدمه من DR Site مثلا بدون التاثير على سير العميل “RTO” وماهى حجم البيانات المفقوده اللى تقدر الشركه ان تتحملها فى حاله مثلا احتجنا نعمل restore من backup فهيكون “RPO” بتاعنا مثلا 24 ساعه لو عملنا restore من باكب اليوم اللى قبله وطبعا كل ما قل RPO, RTO كلما زادت التكلفه وبناءا عليه بيتم تحديد RPO & RTO بناءا على التكنولوجي المستخدمه فى عمليه replication وبناءا على Bandwidth وبناءا على اذا كان عمليه failover هتكون بشكل automated ولا بشكل Manual وغيرها من النقط اللى بيتم الاتفاق عليها وتحديد وقت RPO & RTO الخاص بكل سرفيس فى Run Book الخاص بيها

Server List Document

وهى Document اللى بيكون موجود فيها المعلومات الاساسيه عن Servers اللى هتكون موجوده فى DR site وظيفتها ونوع replication المستخدم ومين التيم المسؤل عنها وكمان بيكون فيها معلومات عن servers اللى مش موجوده فى DR site بس هيحصلها impact فى خلال عمليه failover
وممكن تكون Server List Document جزء من Run Book وممكن تكون Document منفصله

Contacts List Document

وهى Document اللى بيكون فيها كل اسامى الاشخاص والفيندور المسؤلين عن اعاده الخدمه من DR site وارقام تليفونتهم وطرق التواصل الخاصه بيهم وبيتحدد فيها مين الشخص الاساسي ومين الشخص الثانوى فى حاله عدم وجود الشخص الاساسى وكمان بيكون فيها كل المعلومات الاساسيه فى حاله ان التيم اتطر انه يفتح تيكت مع الفيندور زى Customer ID Number وكمان Account المستخدم فى فتح التكيت دى واوقات بيكون متحدد فيها Contact Person
وممكن تكون Contacts List Document جزء من Run Book وممكن تكون Document منفصله

Test Plan Document

وهى Document اللى بيكون فيها Test Plan لكل سرفيس من حيث اسامي Servers المسؤله عن service دى والخطوات المتبعه لاختبار السرفيس بعد Failover او Failback ومين الشخص او التيم المسؤل عن الاختبار ده وايه هى ملاحظاته بعد عمليه الاختبار
وممكن تكون Test Plan Document جزء من Run Book وممكن تكون Document منفصله

DR Drill

هى محاكه لنفس الخطوات اللى هيتم تنفيذها فى حاله حدوث كارثه Disaster لتشغيل الخدمه من DR site لغرض التدريب لانه ماينفعش فى حاله حدوث كارثه حقيقه نكتشف ان فى خطوه ناقصه او المهندس المسؤل عن تشتغيل الخدمه مايعرفش معلومه معينه والغرض التانى هو التاكد من ان السرفيس الموجوده فى DR تعمل بشكل سليم لانه برضوا ماينفعش اننا نكتشف فى حاله حدوث كارثه ان الداتا الموجوده فى DR site بايظه او Replication مش شغال مزبوط بناءا عليه بيتم تحديد DR Drill فى اوقات معينه من السنه بتالاتفاق مع الكلاينت يعنى مثلا فى كلاينت بيعمل DR Drill كل 3 شهور وفى كل 6 شهور وفى كل سنه حسب Police الخاصه بالشركه
وبيتم عمل Failover كامل لكل السرفيس الموجوده فى DR site او جزء منها وتنفيذ Run Book والتاكد ان كل الخطوات فيها مزبوطه ومعظم الاحوال بتم عمليه DR Drill فى اجازه الاسبوعيه او فى الاجازات الرسميه لانها بتكون فيها service impact وبتاثر على الخدمه المتاحه خلال عمليه التدريب

اخيرا حابب اوضح ان المقال ده مش اكتر من مقدمه لسلسله مقالات جديده هبتدى اتكلم فيها عن DR site وعن Application المستخدمه وعن طريقه الدزين