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

به علاوه ترمیم یک حادثه چه در سطح عملیات (به صورت خودکار) و چه در سطح مدیریت (به صورت غیر خودکار) باید تحت نظارت انسان انجام شده و یک زنجیره از دستورات ایجاد شود. تیم ترمیم فاجعه باید جهت تولید طرح ترمیم شکل بگیرد. تیم باید ابتدا مرکز پردازش داده شامل پیکربندی سخت¬افزار و نرم¬افزار و محیط سیستم، ورودی و خروجی داده، تقسیم¬بندی کارها به کارهای بحرانی و غیر بحرانی ، رویه پشتیبان پایگاه داده و طرح های ترمیم فاجعه موجود را مورد بررسی قرار می دهد.پیکربندی برای سیستم بهبود پذیر در برابر حادثه معرفی شده و پشتیبان پایگاه داده و رویه های حافظه off-site به وجود می¬آیند. طراحی سایت پشتیبان و توانایی های آن بازبینی و پیاده سازی شده و در پایان طرح ترمیم تست می شود. جزئیات طرح ترمیم بستگی به حمایت های سیستم دارد.[۲]
اغلب سیستم های پایگاه داده تجاری عمومی مانند Sybase , Oracle , DB2 پشتیبانی¬های کاملی از ترمیم فاجعه فراهم نمی آورند. Sysbase گزینه هایی برای تحمل خطا و بهبود توانایی سیستم فراهم می آورد از جمله پشتیبانی های چند پردازنده مناسب ، سرورهای همنشین ، ابزار منعکس شده ، سرورهای هدایت کننده . به علاوه برای پشتیبانی ترمیم crash به پایگاه داده اجازه می دهد که پشتیبان تهیه کند و Checkpoint ایجاد کند. هم سرور های هم نشین و هم ابزار های منعکس شده در فرایند ترمیم شرکت می کنند. یک سرور همنشین با روشی مشابه روش سرور اولیه / پشتیبان در مقابل خطای پردازنده مقاومت می کند. هنگامی که سایت اولیه خراب می شود تراکنش های تثبیت نشده قبل از اینکه توسط همنشین گرفته شوند بازگردانده می شوند.
شیوه منعکس شده یک بسط از دیسک است که برای مقابله با خطا های سخت افزاری بوجود آمده اند. داده ها تکرار شده و در اولیه و انعکاس آن به صورت شفافی ذخیره می شوند. برای حمایت از ترمیم فاجعه ، ناظر سیستم باید طرح ترمیم فاجعه را تهیه و رویه های پشتیبان پایگاه داده ، حافظه و بازیابی را راه اندازی کند .
در Oracle پشتبان گیری پایگاه داده هم بوسیله پایگاه داده بسته ( پشتیبان سرد ) وهم بوسیله پایگاه داده در دسترس ( پشتیبان گرم ) انجام می گیرد. ترمیم خطا های crash می-تواند به صورت خودکار باشد. تراکنش های تثبیت نشده پس بازگرداندن اطلاعات فایل های کنترل ضروری بازگردانده می شوند . دیسک منعکس شده برای مقابله در برابر خطاهای مدیا اتخاذ می شود . تنها ضروری است که فایل¬های ثبت انجام دوباره موجود و نیز فایل های ثبت انجام دوباره بایگانی شده در شکلی از حافظه پایدار ، برای ترمیم خطای مدیا ، منعکس شوند. کارایی Oracle می تواند بوسیله تکرار داده دور در یک سرور محلی بهبود یابد. کپی های کش شده می توانند از طریق مکانیسم ماشه Oracle به محض اینکه نسخه اصلی دور تغییر کرد ، تغییر یابند .
محیط DB2 برای ترمیم خودکار حادثه طراحی نشده است مگر اینکه سیستم پشتیبان و کنترل کننده¬های حافظه نصب شده و برای ارایه خدمات پیکر بندی شوند. با این وجود ابزارهای استاندارد می توانند اجزاء داده شامل پشتیبان کپی تصویر ، نوارهای ثبت، جدول¬های داخلی DB2 و مجموعه داده را در ترمیم عادی دستکاری نمایند. تیم ترمیم فاجعه باید طرح ترمیم خودشان را گسترش دهند.[۲]
از آنجایی که اغلب سیستم¬های پایگاه¬داده پشتیبانی ترمیم فاجعه را فراهم نمی¬کنند ، سخت افزارهای خاصی برای مدیریت حافظه باید نصب شوند به طوری که داده¬های مورد نیاز برای ترمیم را در دسترس قرار دهند. به عنوان مثال، مدیر دادهEMC به عنوان یک سیستم پشتیبان کامل یک راه حل برای پشتیبانی شبکه¬ای بدون تاخیر و ترمیم برای Oracle و Sybase می¬باشد.EMC از سیستم ۵۰۰۰ حافظه سیمتریکس که امکان داده دور سیمتریکس ( SRDF ) و نیز امکان پشتیبان / بازیاب سیمتریکس ( SBRF ) را فراهم می¬کند استفاده می¬کند .از طریق SRDF ، داده¬ها در زیر سیستم¬های حافظه دور در زمان واقعی تکرار می¬شوند. SBRF ممکن است برای تهیه یک عملیات سیستم پیوسته از طریق راه گزینی زیر سیستم سریع و کوچ داده¬ها در بین زیر سیسستم¬ها استفاده شود. کنترل کننده ۳۹۹۰ آی بی ام یک کپی دور برای پشتیبان دور بدون تاخیر که به صورت سست همزمان شده است فراهم می¬آورد .[۱] این گزینه کپی دور مبسوط (XRC) پیش فرض ، برای دسترسی داده بالا جهت پشتیبان داده غیر همزمان مفید است .کنترل کننده همچنین کپی دور جفت- به – جفت ( PPRC ) که پشتیبان داده دور Lock-step شده را پشتیبانی می کنند را فراهم می آورد. این موضوع عمل ترمیم را تسهیل می بخشد. یک طرح ترمیم فاجعه به صورت عادی بوسیله بازیابی داده های پشتیبان دور و پردازش تغییرات از دست رفته برای سیستم های پشتیبان غیرهمزمان اجرا می شود.
بسته به سازماندهی داده پشتیبان و رویه های ترمیم ، سه طرح ترمیم عمومی وجود دارد : اولین روش به روش پتک مشهور است ک روش با تاخیر برای کاربردهای غیر بحرانی وغیر فراری است که در طول ۲۴ ساعات شبانه روز اجرا نمی شوند. در این روش نیاز است که اجرای پایگاه داده متوقف شده ، از پایگاه داده موجود روبرداری شده و به صورت off-site مانند پشتیبان سرد ارسال شود. استراتژی دوم ، فضای جدول ها و شاخص مجموعه داده های ” عقب پشت ” یک پایگاه داده مانند DB2 را کپی می کند. به وسیله استرتژی سوم که به نام چاقو شناخته می شود پشتیبان های کپی تصویر بدون تاخیر زمانی روی نوارها ایجاد شده و نوارها برای پشتیبان گیری یک جدول در یک زمان به سایت دور ارسال می شوند.
دو محصول پایگاه داده ، IMS/ESA ی IBM و امکان داده دور Tandem حمایت ترمیم فاجعه کاملی تهیه می کنند . IMS / ESA ترمیم سایت دور ( RSR ) را پشتیبانی می کنند که بسط ترمیم IMS به سایت های دور است . امکان داده دور Tandem هم یک جریان log عادی برای سیستم های پایگاه داده ای است که سرویس های بدون وقفه ارایه می کنند.
هنگامی که یک خطا در سایت اولیه ییدا می شود اپراتور باید تصمیم بگیرد که آیا نسخه پشتیبان باید مورد استفاده قرار گیرد. از آنجا که ممکن است سیستم قادر به تشخیص یک خطای ارتباط با خطای سایت نباشد ، این تصمیم نباید بوسیله پشتیبان به صورت خودکار اتخاذ شود. مدت زمان خروج سایت اولیه ممکن است کوتاه بوده و به گرفتن پشتیبان نیازی نباشد. پس از اینکه تصمیم گرفتن پشتیبان اتخاذ شد ، پشتیبان بر اساس اطلاعات موجود در log خود ابتدا تاثیرات تراکنش های تثبیت شده را نصب کرده و تاثیر تراکنش های تثبیت نشده را خنثی می کند . سپس خروجی از ترمینال ها به سوی پشتبان که حالا به عنوان اولیه شناخته می شود ، هدایت می شوند. هنگامی که سیستم اولیه تعمیر شد، تلاش می کند بر اساس یک log محلی خود را به حالتی سازگار ترمیم کند.[۳]
اگر خطا به اندازه ای سخت باشد که سیستم اولیه اصل نتواند خود را به حالتی سازگار بازگرداند ، یک روبرداری پایگاه داده از اولیه جاری به روی سیستم اصلی نصب خواهد شد . سپس اولیه اصلی خود را به یک سیستم پشتیبان تبدیل کرده و پروتکل های ترمیم خطا برای سیستم های پشتبان را دنبال می کند . در انتهای رویه ترمیم نقش دو سیستم تعویض می شود یعنی اولیه اصلی تبدیل به پشتیبان و پشتیبان اصلی تبدیل به اولیه می شود. اگر ضروری باشد می تواند پیکربندی اصلی بوسیله یک طرح تعویض بازیابی شود . اگر پشتیبان خاموش شود ، اولیه می تواند به صورت عادی به فعالیت خود ادامه دهد ولی رکوردهای log نمی توانند به سایت پشتیبان ارسال شوند.به محض اینکه پشتیبان تعمیر شد دریافت رکوردهای log را از نقطه ای که آنها را ترک کرده بود از سر می گیرد. اگر مدت خطا طولانی باشد ممکن است زمان زیادی برای همگام شدن پشتیبان با اولیه صرف شود. اگر پشتیبان برای دوره مبسوطی از زمان در دسترس نباشد ، اجازه دادن به پشتیبان برای همگام شدن با اولیه به صورت تدریجی امکان ناپذیر است.[۱] در عوض یک اپراتور می تواند یک روبردای جدید بدون تاخیر از پایگاه داده اولیه تهیه و روی سیستم پشتیبان نصب کند.سپس log های تولید شده پس از روبرداری بدون تاخیر به پشتیبان اعمال می شوند. هنگامی که پشتیبان به اولیه همگام شد تمام سیستم به حالت عادی برمی گردد .
رویه های طرح تعویض به این صورت عمل می کنند : ابتدا اولیه دریافت تراکنش های جدید را متوقف می کند . پس از اینکه تمام تراکنش های موجود تکمیل شدند ، اولیه یک نشان خاص درون log خود نوشته و سپس خودش را به یک پشتیبان تبدیل می کند . پشتیبان اصلی می تواند پس از پردازش تمام رکوردهای log تا قبل از نشان ویژه خود را به اولیه تبدیل کند . سپس سیستم با پذیرفتن ورودی های دوباره هدایت شده توسط سیستم اولیه جدید ، عملیات عادی خود را از سر می گیرد.