نیاز و پوشش
داده، وابستگیها، مالک خدمت و هدف بازیابی را ثبت کنید.
در حال آمادهسازی صفحه
راهنمای بازیابی بحران یا DR؛ از هدف RPO و RTO تا وابستگی سرویسها، برنامهٔ بازگردانی، محیط پاک و تمرین پذیرش خدمت.
نقشهٔ آموزشی؛ وجود فایل بکاپ یا سرور جایگزین، بهتنهایی شاهد بازیابی موفق خدمت نیست.
Disaster Recovery یا بازیابی بحران برنامهای برای بازگرداندن خدمات فناوری اطلاعات پس از اختلال جدی است. بکاپ بخشی از آن است، اما وجود نسخه نمیگوید چه کسی تصمیم میگیرد، از کدام نقطه داده برمیگردد و کاربران چه زمانی دوباره کار میکنند. این مقاله چارچوب تعریف پروژه و تمرین را توضیح میدهد؛ هیچ دادهٔ تولیدی را بازگردانی یا هیچ سرویس زندهای را جابهجا نمیکند.
داده، وابستگیها، مالک خدمت و هدف بازیابی را ثبت کنید.
روش، محل نگهداری، اختیار اجرا و مسیر خطا را مشخص کنید.
بازیابی و پذیرش برنامه را در محیط مجاز و جدا بررسی کنید.
شاهد آزمون، مسئول پیگیری و برنامهٔ بازآزمون را نگه دارید.
از فعالیت مهم کسبوکار شروع کنید، نه فهرست سرورها. برای نمونه، برنامه ممکن است به دیتابیس، فایلها، DNS، احراز هویت و مجوز نرمافزار وابسته باشد. ترتیب راهاندازی و مالک هر جزء را مشخص کنید. روشن بودن ماشین مجازی بدون دسترسی کاربر به عملیات اصلی، شاهد بازگشت خدمت نیست؛ آزمون پذیرش باید به فرآیند واقعی مجموعه مربوط باشد.
در راهنمای NIST SP 800-34، RPO به نقطهٔ زمانی داده برای بازیابی و RTO به هدف زمان در دسترس نبودن منبع مربوط است. یکی دربارهٔ دادهٔ قابل برگشت و دیگری دربارهٔ زمان بازگشت است. اینها هدف توافقیاند، نه نتیجهٔ خودکار نصب ابزار؛ معیار اندازهگیری و دامنهٔ خدمت باید معلوم باشد.
خرابی یک دیسک، از دست رفتن سایت و حادثهٔ امنیتی نیاز یکسان ندارند. برای هر سناریوی داخل محدوده، منبع بازیابی، محیط جایگزین و محدودیتها را بنویسید. ممکن است راهکار فقط برخی خدمات را پوشش دهد؛ این موضوع باید از ابتدا روشن باشد. وعدهٔ پوشش تمام بحرانها بدون بررسی ریسک و وابستگی، معیار قابل تحویل نیست.
ظرفیت پردازش و ذخیره، مسیر شبکه، دسترسی مجاز و نیازهای برنامه را پیش از حادثه بررسی کنید. داشتن آرشیو در محل دیگر کافی نیست اگر زیرساخت خواندن آن آماده نباشد. دسترسی به اسناد و ابزار ضروری نباید فقط به سرویس ازکارافتاده وابسته باشد. هزینهٔ آمادهبهکار بودن و زمان آمادهسازی باید جدا در طراحی دیده شوند.
اگر حادثه امنیتی بوده، بازگردانی بیبررسی میتواند مشکل را دوباره وارد کند. تعیین نقطهٔ سالم و هماهنگی با مسئول پاسخ به حادثه لازم است. زمان فایل یا آخرین بکاپ بهتنهایی سلامت آن را ثابت نمیکند. در تمرین، از محیط ایزوله و دادهٔ مجاز استفاده کنید؛ اجرای آزمایش روی خدمت تولیدی بدون اختیار مناسب انجام نشود.
مراحل را به ترتیب قابل اجرا با پیشنیاز و مسئول بنویسید. مشخص کنید چه کسی طرح را فعال میکند، چه کسی تغییر مسیر را تأیید میکند و کاربران از کجا اطلاع میگیرند. اطلاعات حساس در اسناد عمومی نباشد. راه تماس جایگزین تیم باید در دسترس باشد تا قطع ابزار اصلی ارتباط، تصمیمگیری و هماهنگی را متوقف نکند.
بعد از فعالیت در محیط جایگزین، بازگشت فقط روشن کردن سرور قبلی نیست. مشخص کنید دادههای جدید کجا ثبت شدهاند و کدام نسخه مرجع است. پیش از تغییر دوبارهٔ مسیر، ناسازگاری و احتمال ثبت تکراری را بررسی کنید. نقطهٔ توقف، راه بازگشت و تأیید مالک برنامه لازماند تا بازسازی به حادثهٔ دوم تبدیل نشود.
در یک تمرین هماهنگ، بازیابی را از ابتدا تا عملیات مورد نیاز کاربر اندازه بگیرید. زمان انتظار برای مجوز، انتقال داده و کنترل برنامه را نیز ثبت کنید. موارد نرسیده به هدف باید مالک و اقدام اصلاحی داشته باشند. هزینه تابع سختگیری هدف، حجم داده و محیط جایگزین است؛ ادعای زمان قطعی بدون تمرین معتبر قابل اتکا نیست.
نوع سرویس، حجم تقریبی داده، هدف زمان بازیابی و شرایط نگهداری را مشخص کنید تا دامنهٔ کار و معیار پذیرش قابل تعریف باشند. تعداد کاربران و هدف بررسی را در بخش پشتیبانی ویوان نت توضیح دهید؛ رمز، کلید یا تنظیمات محرمانه را در درخواست معمولی نفرستید.
در یک سازمان فرضی، محل اصلی یک برنامه در دسترس نیست. طرح ابتدا مسئول فعالسازی و ترتیب بازگردانی دیتابیس، فایل و برنامه را مشخص میکند. تیم در محیط آموزشی مسیر ورود کاربر و عملیات ثبت نمونه را بررسی میکند و تفاوت هدف با زمان اندازهگیریشده را مینویسد. بازگشت بعدی هم نیاز به تطبیق داده دارد؛ پایان بازیابی صرفاً پیام «سرور روشن شد» نیست.
این مثال آموزشی است، نه پروژهٔ واقعی یا نتیجهٔ عددی ویوان نت؛ روش اجرا و آزمون باید با بستر و اختیار سازمان هماهنگ شوند.
این راهنما از مجموعهٔ پشتیبانگیری و بازیابی اطلاعات ویوان نت است. برای شناخت مجموعه، معرفی ویوان نت را ببینید.
خیر؛ بکاپ نسخهٔ داده است، DR بازگرداندن خدمت، مسئولیتها و وابستگیهای لازم را هم پوشش میدهد.
RPO نقطهٔ دادهٔ قابل بازیابی را هدف میگیرد؛ RTO هدف زمان بازگشت منبع یا خدمت در دامنهٔ مشخص است.
خیر؛ تحقق هدف باید با طراحی، منابع و تمرین معتبر بررسی و محدودیت آن ثبت شود.
بدون بررسی سلامت و هماهنگی پاسخ به حادثه نه؛ آخرین نسخه ممکن است خود مشکل داشته باشد.
بدون مجوز و طرح کنترلشده نه؛ محیط ایزوله و دادهٔ مجاز برای آزمون اولیه مناسبترند.
دامنهٔ سناریو، اهداف، ترتیب اجرا، مسئولان، نتیجهٔ پذیرش برنامه و روش بازگشت به محیط اصلی.
منابع برای مبانی و نمونهٔ روشها هستند؛ انتخاب محصول، ظرفیت و تنظیمات واقعی باید در زمان اجرا و بستر سازمان بررسی شوند.
از نیاز واقعی و محدودیتهای مجموعه شروع میکنیم؛ طراحی و آزمون باید با بستر و اختیار سازمان هماهنگ شوند.
ثبت درخواست مشاوره ←