Disaster recovery (DR) — katta uzilishdan keyin axborot tizimi, ma’lumot va biznes xizmatini kelishilgan darajada tiklashga qaratilgan jarayonlar hamda texnik arxitektura. Disaster oddiy process xatosidan kengroq bo‘lib, data center, cloud region, storage, identity yoki muhim operator imkoniyatining uzoq yo‘qolishini qamrab olishi mumkin.
RPO va RTO
Recovery Point Objective (RPO) tiklashda qancha yangi ma’lumot yo‘qolishi mumkinligini vaqt bilan belgilaydi. RPO 15 daqiqa bo‘lsa replication yoki backup intervali shu oynaga mos bo‘ladi. Recovery Time Objective (RTO) xizmat qancha vaqt ichida qaytishi kerakligini ko‘rsatadi.
RPO nolga yaqinlashsa synchronous replication va murakkab koordinatsiya talab qilinishi mumkin. Juda qisqa RTO oldindan ishga tayyor capacity, avtomatlashtirilgan failover va doimiy sinovni talab qiladi. Har xizmat bir xil maqsadga ega bo‘lishi shart emas; biznes ta’sir tahlili ustuvorlikni belgilaydi.
Recovery modellari
Backup and restore eng arzon model bo‘lib, infratuzilma disasterdan keyin yaratiladi. Pilot light’da database va minimal asosiy xizmatlar ikkinchi joyda ishlaydi. Warm standby kichik capacity bilan tayyor turadi. Multi-site active-active normal trafikni bir nechta hududda bajaradi, ammo consistency va operatsion murakkablikni oshiradi.
Model nomi emas, o‘lchangan recovery natijasi muhim. “Backup mavjud” degani uning decrypt qilinishi, schema bilan mosligi va RTO ichida restore bo‘lishini kafolatlamaydi.
Ma’lumotni himoya qilish
Replica hardware failurega yordam beradi, lekin noto‘g‘ri DELETE yoki ransomware o‘zgarishini ham nusxalaydi. Immutable yoki alohida credential bilan himoyalangan backup tarixiy tiklash nuqtasini saqlaydi. Backup boshqa failure domain va kerak bo‘lsa boshqa regionda bo‘ladi, residency talabini buzmaydi.
Database uchun base backup bilan transaction log arxivi point-in-time recovery beradi. Application-consistent snapshot olishda database flush yoki backup mode ishlatiladi. Encryption key, certificate va secret backupi bo‘lmasa data nusxasi mavjud bo‘lsa ham xizmat tiklanmasligi mumkin.
Runbook va bog‘liqliklar
Recovery tartibi identity, network, DNS, database, queue va application ketma-ketligini ko‘rsatadi. Tashqi SaaS, domain registrar va notification kanali ham dependency hisoblanadi. Runbook faqat bitta mutaxassis xotirasiga bog‘lanmaydi; offline yoki disaster hududidan tashqarida mavjud bo‘ladi.
Failover qarorini kim beradi, qaysi dalilga tayanadi va split-brain qanday oldi olinishi aniq belgilanadi. Eski primary’ning write accessi fencing bilan uzilmasdan yangi primary ochilsa ikki mustaqil tarix paydo bo‘lishi mumkin.
Mashq va failback
Tabletop exercise odamlar qaror oqimini tekshiradi, texnik drill esa haqiqiy restore va trafik ko‘chirishni bajaradi. Sinov productionga o‘xshash data hajmi bilan bo‘lmasa RTO noto‘g‘ri baholanadi. Natijada topilgan qo‘lda qadamlar avtomatlashtiriladi.
Primary hudud qaytgach failback rejalashtiriladi. Recovery paytida yozilgan yangi data qayta sinxronlanadi, capacity va health tasdiqlanadi, trafik bosqichma-bosqich qaytariladi. Incident tugagach backup, audit log va timeline saqlanib, maqsad va amaldagi natija taqqoslanadi.
Odamlar va aloqa
Disaster recovery faqat texnik failover emas. Incident commander, xizmat egasi, security, provider va biznes vakilining roli oldindan belgilanadi. Asosiy chat yoki email ishlamasa mustaqil aloqa kanali mavjud bo‘ladi. Mijozga status berish va regulyatorga xabar muddati texnik runbook bilan bir vaqtda ishga tushadi.
Bog‘liq tushunchalar
Business continuity, RPO, RTO, Backup, Failover, Failback, Multi-region architecture, Point-in-time recovery