1C va CRM zaxira nusxasi: nimani nusxalash va qanday tekshirish

1C va CRM bazasini zaxiralash — toza serverga joylashtirib ochish mumkin bo‘lgan ma’lumotlarning muntazam nusxasi. Buning uchun uch narsa kerak: bazaning o‘zi nusxasi, uning atrofidagi fayllar va sozlamalar nusxasi hamda jadval bo‘yicha tiklashni tekshirish. Bir marta ham tiklanmagan nusxa taxminligicha qoladi.

3-2-1 sxemasi va RTO hamda RPO tushunchalarini biz nosozliklardan keyin IT-tizimlarni tiklash haqidagi maqolada ko‘rib chiqqanmiz. Bu yerda esa ma’lumotlar bazalari amaliyoti: aynan nimani nusxalash, qaysi usulda, qanchalik tez-tez va nusxaning ishlashiga qanday ishonch hosil qilish.

Zaxira nusxaga bazadan tashqari nima kiradi

Zaxira nusxaga bazani yangi serverda ochish uchun kerak bo‘lgan hamma narsa kiradi: faqat baza fayli yoki dump emas, balki uning yonidagi fayllar, konfiguratsiya va muhit sozlamalari ham.

Maslahat «Nimani nusxalaymiz» ro‘yxatini bir sahifada tuzing va serverdan tashqarida saqlang. Avariya kuni aynan u ishga tushirish uchun nima yetishmayotganini ko‘rsatadi.

Ma’lumotlar bazasi uchun qaysi nusxalash usulini tanlash kerak

Usul MBBT, baza hajmi va kompaniya nusxalar oralig‘ida qancha ma’lumotni yo‘qotishga tayyorligiga qarab tanlanadi. Mijoz-server rejimidagi 1C va CRM bazalari MBBT, masalan PostgreSQL yoki Microsoft SQL Server, asosida ishlaydi va ularga shu MBBT qoidalari tatbiq etiladi.

PostgreSQL hujjatlarida uch yondashuv tasvirlangan: SQL-dump, fayl tizimi darajasidagi nusxa va vaqtning istalgan nuqtasiga tiklash bilan uzluksiz arxivlash.

Oxirgi usul haqida PostgreSQL hujjatlarida shunday deyilgan: bazani bazaviy nusxadan keyingi istalgan paytdagi holatga tiklash mumkin, ammo arxivlangan jurnal fayllarining uzluksiz ketma-ketligi kerak. Shuning uchun arxivlash birinchi bazaviy nusxadan oldin sozlanadi va tekshiriladi, jarayonning o‘zi esa nazoratda turadi.

O‘sha hujjatda aniqlashtirilganki, pg_dump fayl tizimi darajasidagi nusxa yaratmaydi va uzluksiz arxivlash uchun yaramaydi: bunday dumplar mantiqiy bo‘lib, jurnalni qayta ijro etish uchun yetarli ma’lumot saqlamaydi. Ikki sxema aralashtirilmaydi, ongli ravishda biri tanlanadi.

Muhim Fayl rejimidagi 1C bazasi bitta fayldan iborat va foydalanuvchilar ishlayotgan paytda uni nusxalash xavfli: nusxa o‘zaro moslashmagan bo‘lib chiqishi mumkin. Faylni seanslar yopiq paytda nusxalang, 1C vositalari bilan bazani yuklashni esa sinov tiklash o‘tkazilguncha qo‘shimcha nusxa deb hisoblang.

1C va CRM bazalarini qanchalik tez-tez nusxalash kerak

Nusxalash chastotasi ma’lumotlarni yo‘qotishning maqbul darajasiga (RPO) teng: biznes bir soatlik ishni yo‘qotishga tayyor bo‘lsa, nusxalar kamida soatiga bir marta, bir kunlik bo‘lsa — kuniga bir marta kerak. Bu raqamni administrator emas, rahbar belgilaydi.

Turli tizimlarda raqam turlicha. Kun bo‘yi hujjatlarni o‘tkazadigan hisob bazasi haftada bir marta o‘zgaradigan kontragentlar ma’lumotnomasiga qaraganda tungi nusxadan ko‘proq yo‘qotadi. Faol yozishmalar va qo‘ng‘iroqlar bo‘lgan CRM ni oyda bir marta ochiladigan bazaga qaraganda tez-tez nusxalash kerak.

• To‘liq nusxa — odatda tunda, yuklama eng kam bo‘lganda.
• Oraliq nusxalar yoki jurnal arxivi — ish kuni davomida, RPO qisqa bo‘lgan tizimlar uchun.
• Foydalanuvchi fayllari va server sozlamalari — ularning o‘zgarishiga bog‘langan jadval bo‘yicha.
• O‘zgarishlardan oldingi nusxa — konfiguratsiya, platforma yoki MBBT yangilanishidan oldin, jadvaldan alohida.

Nusxa tiklanishini qanday tekshirish kerak

Nusxa faqat bitta usul bilan tekshiriladi: uni alohida kompyuterga joylashtirib, bazada ishlab ko‘rish. Jurnaldagi «vazifa bajarildi» yozuvi fayl yaratilganini isbotlaydi, undan ma’lumotlarni qaytarish mumkinligini emas.

1. Nusxani ishchi serverdan emas, saqlash joyidan oling: nusxaning o‘zi bilan birga unga kirish ham tekshiriladi.
2. Uni ishchi bazaga kirish va integratsiyalarsiz sinov kompyuteriga joylashtiring, shunda mijozlarga xat va to‘lovlar yuborilmaydi.
3. Bazani oching va nazorat harakatlarini bajaring: oxirgi hujjat joyida, tanlangan sana uchun hisobot ishchi baza bilan mos tushadi, ilovalar ochiladi.
4. Boshlanishdan ishlaydigan bazagacha bo‘lgan vaqtni o‘lchang va RTO bilan solishtiring.
5. Natijani yozib qo‘ying va topilgan kamchiliklarni to‘g‘rilang: nima yetishmadi va qancha vaqt oldi.

MBBT tekshiruvlari yordam beradi, lekin sinov tiklashni almashtirmaydi. Microsoft SQL Server hujjatlarida aytilishicha, RESTORE VERIFYONLY nusxaning to‘liqligini, tomlarning o‘qilishini va nazorat yig‘indisini tekshiradi, ammo nusxa ichidagi ma’lumotlar tuzilmasini tekshirmaydi.

Kichik va o‘rta biznes uchun CISA tavsiyalarida qo‘shimcha qilingan: to‘liq ham, qisman ham tiklashni tekshiring va ma’lumotlarni kamida yetti kun orqaga qaytarish mumkinligiga ishonch hosil qiling.

Nusxalarni qayerda saqlash: 3-2-1 sxemasi va O‘zbekiston qonuni

Nusxalar shunday saqlanadiki, bitta avariya ham bazani, ham uning barcha nusxalarini yo‘q qila olmasin. CISA 3-2-1 sxemasini o‘sha tavsiyalarda tasvirlaydi.

• 3 ta muhim ma’lumot nusxasi
• 2 xil turdagi tashuvchi
• 1 ta nusxa kompaniya maydonidan tashqarida
• 7 kun CISA tavsiyalariga ko‘ra orqaga qaytishning minimal chuqurligi

Shifrlovchi hujumida yana bir nusxa muhim: ishchi tarmoqdan unga yetib bo‘lmaydigani. CISA ning tovlamachi dasturlarga javob qaytarish qo‘llanmasida ma’lumotlarni oflayn, shifrlangan nusxalardan tiklash tasvirlangan va ogohlantirilgan: tiklash paytida toza tizimlarni qayta zararlamang.

Nusxada ishchi bazadagi ma’lumotlarning o‘zi bor, shuning uchun saqlash joyi ham xuddi shu qoidalar bo‘yicha tekshiriladi. «Shaxsga doir ma’lumotlar to‘g‘risida»gi ZRU-547-sonli Qonunning 26.03.2026 dagi ZRU-1125-sonli qonun tahriridagi 27-1-moddasiga ko‘ra, O‘zbekistonda biometrik va genetik ma’lumotlarni hamda mamlakatda ishlaydigan aloqa operatorlari foydalanuvchilarining ma’lumotlarini saqlash majburiy. 20-moddaga ko‘ra, bunday ma’lumotlar bor bazalar Shaxsga doir ma’lumotlar bazalari davlat reestrida ro‘yxatdan o‘tkazilishi shart.

Boshqa shaxsga doir ma’lumotlarni qonun shartlari bajarilganda xorijda saqlash mumkin. Bulutni qanday tanlash haqida biz O‘zbekistondagi bulut va server haqidagi maqolada yozgan edik. Biometrikali baza uchun nusxa mamlakat ichida saqlanadi, sxema esa yurist bilan kelishiladi.

Nusxalar yo‘q yoki hech qachon tekshirilmagan bo‘lsa, nimadan boshlash kerak

Inventarizatsiya va birinchi sinov tiklashdan boshlanadi, saqlash joyini sotib olishdan emas: aynan nimani himoya qilayotganimiz noma’lum ekan, har qanday qaror taxmin bo‘lib qoladi.

1. Bazalar va xizmatlar ro‘yxatini tuzing: 1C, CRM, sayt, pochta, fayl serveri. Har birining qarshisiga undan kim foydalanishini va usiz nima to‘xtashini yozing.
2. Bo‘lim rahbarlaridan ruxsat etiladigan to‘xtab qolish va ma’lumot yo‘qotishni aytishlarini so‘rang. Shunda har bir tizim uchun RTO va RPO hosil bo‘ladi.
3. Nusxalashni alohida disk yoki serverga sozlang va maydondan tashqarida ikkinchi nusxani qo‘shing.
4. Birinchi sinov tiklashni o‘tkazing va nima noto‘g‘ri ketganini yozib qo‘ying. Natija keyingi oyga mo‘ljallangan takomillashtirishlar rejasini beradi.

Nusxalash reglamentiga nimalarni yozish kerak

Reglament nusxalashni bir martalik sozlash emas, jarayonga aylantiradi: unda kim mas’ulligi, nima nusxalanishi va natija qanday tekshirilishi ko‘rsatiladi. Bir sahifa yetarli.

• RPO va RTO belgilangan tizimlar va bazalar ro‘yxati;
• har bir tizim bo‘yicha nima nusxalanadi: baza, fayllar, konfiguratsiya, sozlamalar, kalitlar;
• nusxalash usuli va jadvali, to‘liq va oraliq nusxalar;
• har bir nusxa qayerda saqlanadi, jumladan maydondan tashqaridagi va ishchi tarmoqdan yetib bo‘lmaydigani;
• nusxalar uchun kim mas’ul va ta’til paytida uning o‘rniga kim ishlaydi;
• oxirgi sinov tiklash sanasi va natijasi hamda keyingisining sanasi;
• nusxalash vazifasi bajarilmasa, kim xabar oladi.

Qanday xatolar nusxani rasmiyatchilikka aylantiradi

Ko‘pincha nusxa murakkab texnik sababdan emas, oldindan ko‘rinib turadigan tashkiliy xato tufayli ish bermay qoladi.

• Nusxa bazaning o‘zi turgan serverda yoki diskda yotadi: u ishdan chiqsa, ikkalasi ham yo‘qoladi.
• Faqat baza nusxalanadi, ilova fayllari, konfiguratsiya va kalitlar esa unutiladi.
• Ishchi bazaning fayli foydalanuvchilar ishlayotgan paytda nusxalanadi va moslashmagan nusxa olinadi.
• «Vazifa bajarildi» xabari tiklashni tekshirish deb qabul qilinadi.
• Nusxalar ishchi tarmoqdan yozish uchun ochiq qoladi: shifrlovchi ularga ham yetib boradi.
• Arxivlangan jurnallar zanjiri kuzatilmaydi: bitta qism yetishmasa, kerakli paytga tiklab bo‘lmaydi.
• Mas’ul tayinlanmaydi: nusxa hammada bor, lekin hech kimniki emas.

Biz zaxiralashni qanday tashkil qilamiz

Syntra Systems da biz hisob-kitobdan boshlaymiz: har bir baza uchun RPO va RTO ni siz bilan birga aniqlaymiz, so‘ng nusxalarni baza, fayllar va sozlamalarga ajratamiz, MBBT ingizga mos usulni tanlaymiz va nusxalarni turli joylarga joylashtiramiz. Syntra Cloud serverlari O‘zbekiston hududidagi ma’lumotlar markazida turadi: sayt yoki CRM uchun server — oyiga 30 $ dan.

Keyin nusxalashni qo‘llab-quvvatlash kerak: vazifalarni kuzatish va sinov tiklashlarni o‘tkazish. Qo‘llab-quvvatlash sahifasida ko‘rsatilishicha, oyiga 250 $ dan tarif yangilanishlar, nusxalar va monitoringni o‘z ichiga oladi, jiddiy nosozlikka javob berish muddati tarifga bog‘liq va shartnomaga ilovada belgilanadi. Qo‘llab-quvvatlash va SLA qanday tuzilgani haqida batafsil — IT-infratuzilmani texnik qo‘llab-quvvatlash haqidagi maqolada.

Ko‘p beriladigan savollar

Muqova surati: David Yu, Pexels