Point-in-time recovery (PITR) — database’ni backup olingan paytga emas, undan keyingi tanlangan vaqt, transaction yoki log pozitsiyasigacha tiklash usuli. U base backup bilan uzluksiz archived transaction loglarini birga replay qilishga tayanadi.
Kerakli tarkib
Base backup data file’larning boshlang‘ich nusxasini beradi. Write-Ahead Log yoki transaction log undan keyin sodir bo‘lgan o‘zgarishlarni ketma-ket saqlaydi. Recovery base backupni ochadi, kerakli log segmentlarini qo‘llaydi va target nuqtada replayni to‘xtatadi.
Faqat kundalik full backup bo‘lsa, xato kechqurun sodir bo‘lganda bir kunlik ma’lumot yo‘qolishi mumkin. PITR loglar mavjud bo‘lsa xatodan bir oz oldingi nuqtaga qaytish imkonini beradi. Bu recovery point objective’ni kamaytiradi.
Target tanlash
Target timestamp, transaction ID, named restore point yoki LSN bo‘lishi mumkin. Timestamp timezone bilan aniq yoziladi. NTP xatosi yoki application logidagi boshqa timezone noto‘g‘ri nuqtani tanlatishi mumkin.
“Xatodan bir soniya oldin” har doim yetarli emas: katta transaction bir necha daqiqa ishlasa commit vaqti muhim. Named restore point xavfli migrationdan oldin logga ma’noli marker qo‘yadi. Target inclusive yoki exclusive semantikasi mahsulot hujjatidan tekshiriladi.
Recovery jarayoni
Restore odatda alohida server yoki clusterga bajariladi. Original production ustiga yozishdan oldin natija tekshiriladi. Database targetga yetgach yangi timeline/branch yaratishi mumkin. Keyin eski timeline loglari bilan yangi loglarni aralashtirmaslik kerak.
Selective bitta jadvalni PITR qilish ko‘p physical backup tizimlarida bevosita mumkin emas. Butun cluster alohida joyga tiklanib, kerakli qator yoki jadval logical export orqali productionga qaytariladi. Foreign key va keyingi o‘zgarishlar bilan conflict tahlil qilinadi.
Log arxivi
Archived log segmentlari tartibli, to‘liq va o‘zgarmas saqlanadi. Bitta yetishmagan segment targetgacha replayni uzadi. Archive command muvaffaqiyatini faqat exit code bilan emas, remote obyekt mavjudligi, checksum va restore testi bilan nazorat qilish kerak.
Retention eng eski kerakli base backupdan target oynasi oxirigacha bo‘lgan loglarni qamraydi. Log generation birdan oshsa archive storage va bandwidth to‘lishi mumkin. Encryption keylar va access policy ham backup lifecycle bilan saqlanadi.
RPO va RTO
PITR kichik RPO beradi, lekin RTO base backup hajmi, download tezligi va replay qilinadigan log miqdoriga bog‘liq. Juda eski base backup ko‘p log replay talab qiladi. Tez-tez base backup restore vaqtini kamaytirishi, evaziga storage va backup IOni oshirishi mumkin.
Parallel restore va incremental backup platformaga bog‘liq. Recovery capacity productiondan kichik bo‘lsa replay sekinlashadi. RTO real drill orqali o‘lchanadi.
Tekshirish va qayta ishga tushirish
Targetga yetgach row count, schema version, muhim biznes invariantlari va application smoke test tekshiriladi. External side effectlar — to‘lov, email yoki message queue — database vaqtini orqaga qaytarish bilan avtomatik bekor bo‘lmaydi. Consumer offset va idempotency alohida muvofiqlashtiriladi.
Promote qilingan instance uchun replica, backup schedule, monitoring va connection endpoint qayta sozlanadi. Recovery dalillari, tanlangan target va yo‘qotilgan transaction oralig‘i incident hisobotida saqlanadi.
Amaliy mashqda tiklash alohida muhitda bajarilib, tanlangan vaqt atrofidagi muhim tranzaksiyalar tekshiriladi. Ishlab turgan bazaning ustiga darhol yozish xato vaqt yoki noto‘liq jurnal sababli dalillarni yo‘qotishi mumkin.
Bog‘liq tushunchalar
Base backup, Write-Ahead Log, Recovery Point Objective, Recovery Time Objective, Restore point, Timeline, Log archiving, Crash recovery