Bosh sahifa Wiki Point-in-time copy

Point-in-time copy

Point-in-time copy — ma’lumotlar to‘plamining muayyan vaqt lahzasidagi holatini keyin o‘qish yoki tiklash uchun saqlaydigan nusxa mexanizmidir. U to‘liq fizik copy, snapshot, clone yoki database recovery orqali yaratilishi mumkin. Asosiy xususiyat nusxadagi obyektlar bitta belgilangan vaqt kontekstiga tegishli bo‘lishidir.

Fizik va mantiqiy usullar

Full physical copy barcha block yoki fayllarni boshqa joyga ko‘chiradi. U source’dan mustaqil, ammo yaratish va storage narxi katta. Snapshot metadata va copy-on-write orqali tez tasvir yaratadi; uning mustaqilligi storage implementatsiyasiga bog‘liq.

Database point-in-time recovery base backup va transaction loglarni birlashtiradi. Recovery logni kerakli timestamp yoki log sequence numbergacha replay qiladi. Bu oldindan aynan o‘sha daqiqada snapshot bo‘lmagan bo‘lsa ham oraliq holatni tiklash imkonini beradi.

Consistency group

Application data bir nechta volume’da bo‘lsa ularni alohida snapshot qilish vaqt oralig‘i yaratadi. Bir volume’dagi database data file va boshqasidagi log turli transaction holatiga tegishli bo‘lishi mumkin. Consistency group barcha volume uchun koordinatsiyalangan point-in-time marker yaratadi.

Bu ham application bufferlarini avtomatik flush qilmaydi. Storage-level atomiklik bilan application-level transaction bir tushuncha emas. Guest freeze, database backup mode yoki application API zarur bo‘lishi mumkin.

Yaratish jarayoni

Koordinatsiyalangan copy odatda quyidagicha bajariladi:

  1. application yangi write’larni qisqa muddat to‘xtatadi yoki checkpoint qiladi;
  2. filesystem cache kerakli darajada flush qilinadi;
  3. storage snapshot yoki copy marker yaratadi;
  4. application normal ishni davom ettiradi;
  5. nusxa background rejimda boshqa storagega ko‘chirilishi mumkin.

Har bosqich timeout va rollbackga ega. Snapshot muvaffaqiyatsiz bo‘lsa application freeze holatida qolmasligi kerak.

Clone va test muhiti

Point-in-time copy’dan writable clone yaratilib, production data bilan test yoki analytics bajarilishi mumkin. Thin clone base bloklarni ulashadi va faqat o‘zgargan bloklarni saqlaydi. Base snapshot o‘chirilishidan oldin clone dependencylari tekshiriladi.

Production nusxasida shaxsiy va maxfiy ma’lumot bor. Test muhitiga berishdan oldin masking yoki tokenization bajariladi, access control productiondan kam bo‘lmaydi. Clone tez yaratilishi data governance talabini chetlab o‘tmaydi.

Replikatsiya bilan ishlashi

Snapshot remote sitega incremental blocklar bilan replicate qilinishi mumkin. Remote copy source snapshotning consistency nuqtasini saqlaydi. Network uzilsa keyingi urinish changed-block trackingdan davom etadi.

Asynchronous replicationda eng yangi remote point source’dan ortda qoladi. RPO snapshot intervali va transfer lagga bog‘liq. Synchronous replication yaqin RPO beradi, ammo latency va ikki site o‘rtasidagi failure semantikasi murakkab.

Restore tanlovi

Operator timestampni biznes hodisasi bilan bog‘laydi. Zararli delete 14:05 da aniqlansa, 14:04 nusxa ham zarar boshlanganidan keyingi bo‘lishi mumkin. Audit log va transaction timeline xavfsiz recovery pointni tanlashga yordam beradi.

Restore original joyga overwrite, yangi volume yoki alohida database sifatida bajariladi. Avval isolated restore qilib integrity va application tekshirilsa noto‘g‘ri nusxa bilan productionni almashtirish xavfi kamayadi.

Cheklovlar

Timestamplar soat sinxronizatsiyasiga tayanadi. Database log va storage snapshot turli timezone yoki clock drift bilan qayd etilsa mos nuqtani topish qiyin. LSN, snapshot ID va application marker timestampdan aniqroq bog‘lanish beradi.

Point-in-time copy retention tugagach yoki dependency chain buzilsa mavjud bo‘lmasligi mumkin. Catalog nusxaning joyi, checksum, encryption key va restore talablari bilan birga saqlanadi.

Bog‘liq tushunchalar

Snapshot, Point-in-time recovery, Consistency group, Clone, Transaction log, Recovery Point Objective, Replication