CRM/ERP деректерінің резервтік көшірмелері: жиілік пен сақтау тәртібі

Неліктен CRM/ERP үшін бэкап регламенті қажет

CRM/ERP бизнестің жұмысын тоқтататын маңызды деректерді сақтайды: сатулар, қаржы операциялары, отгрузкалар, шарттар, рұқсаттар. Айқын регламент болғанда резервтік көшірме — әкімшінің бір реттік міндеті емес, нақты процесске айналады: не көшіріледі, қаншалықты жиі, көшірмелер қайда сақталады және кім жауап береді.

Маңызды тек тапсырыстар мен бухбаланстар емес, жүйенің сенімді жұмысын қамтамасыз ететін барлық нәрсе:

• дерекқор (сатып алулар, шоттар, төлемдер, қалдықтар)
• анықтамалар мен баптаулар (номенклатура, контрагенттер, бағалар, салық ережелері)
• құжаттар мен тіркемелер (акттер, шарттар, сканерлер)
• интеграциялар мен алмасу кезектілігі (касса, қойма, банк‑клиент, EDI)
• аккаунттар мен ролдер (кім не көреді және не өзгерте алады)

Екі тәуекелді бөліп алу пайдалы: деректерді жоғалту және жүйенің тоқтауы. Деректер жоғалту — белгілі бір уақытша үзінді жоғалу (мысалы соңғы 6 сағаттағы тапсырыстар жоқ). Тоқтау — деректер бар, бірақ жұмыс істеу мүмкін емес (қолданба істен шықты, диск толды, желі бұзылды). Регламент қай жағдайдың сізге қауіпті екенін және әрбір жағдайда қандай әрекет басталатынын анықтайды.

Бэкаптың өзі қалпына келтірусіз қорғаныс саналмайды. Көбінесе көшірмелер жасалады, бірақ олар ашылатындығын, шифрлау кілттері жеткілікті ме, және қалпына келтіру мақсатты уақытта орындалатынын ешкім тексермеген болады.

Көбіне толық жүйе емес, жекелеген түйіндер бұзылады: дерекқор, диск және сақтау, қосымша, аккаунттар (құқықтар өшірілген, пароль өзгерді, сервис‑пайдаланушы жабылды). Регламент апат кезінде шекті ойдан шығуға емес, алдын ала тексерілген жоспарға жүруге көмектеседі.

Мақсаттар мен көрсеткіштер: RPO, RTO және деректердің критичтілігі

Регламент құралды таңдаудан басталмай, екі сұраққа жауаптан басталады: қанша деректі жоғалтуды көтере аласыз және жүйе қанша уақыт ішінде жұмысқа қайтуы керек. Бұларсыз CRM/ERP резервтік көшіру бизнес күтуімен сәйкес келмейтін бірнеше көшірмелер жинағына айналуы мүмкін.

RPO (Recovery Point Objective) — уақыт бойынша рұқсат етілген дерек жоғалту. Егер RPO = 15 минут болса, ең нашар жағдайда сіз соңғы 15 минуттағы өзгерістерді жоғалтасыз: тапсырыстар, төлемдер, статус‑өзгерістер, хабарламалар. RTO (Recovery Time Objective) — жүйені жұмыс күйіне қайта келтіруге қажетті уақыт. Егер RTO = 2 сағат болса, 2 сағат ішінде пайдаланушылар қайтадан жұмыс істей алады, тіпті кейбір есептер немесе интеграциялар уақытша қолжетімсіз болса да.

RPO мен RTO‑ны шынайы ету үшін деректерді критичтілігі бойынша бөліп, әр деңгейге мақсат қойыңыз:

• Қатты критично: сатулар, қойма, төлемдер, аккаунттар, рұқсаттар
• Маңызды: аналитика, деректер витриналары, өзгерістер тарихы
• Күтсе болады: архивтер, ескі тіркемелер, тесттік орта

Мысалы: сату бөлімі RPO 30 минут және RTO 1 сағат талап етсе, бухгалтерия RPO 24 сағатқа келіссе, айлық жабылу зардап шекпесе, онда критикалық деректерге жиі және жылдам қалпына келтіру сценарийлері, ал екіншілік деректерге сирек архивтік көшірмелер жасайсыз.

Содан кейін қызмет көрсету терезелері мен жүктеме шектеулерін тексеріңіз. ауыр операцияларды (толық көшірме, үлкен дерекқордың консистентті снэпшоты, файл экспорттары) түні бойы немесе аз жүктелген уақытта жоспарлау жақсы. Егер «тыныш» терезелері жоқ болса, регламентке бұл туралы жазып, техникалық шараларды енгізіңіз: жиі инкрементальды көшірмелер, репликация немесе тапсырмаларды уақыт бойынша бөліп орындау.

Көшіріп алу жиілігі: жүйеңізге сәйкес режимді қалай таңдау керек

CRM/ERP‑дегі бэкап жиілігі тәуелді емес «күнделікті жасау дәстүрінен», ол сіз қанша деректі жоғалтуды көтере аласыз және жүйені қаншалықты тез қалпына келтіргіңіз келетініне байланысты. Бірдей жүйе болғанымен сатулар мен бухгалтерияда жүктеме шыңы мен тәуекелдер әртүрлі болады.

Толық көшірме (full) қалпына келтіру үшін опор нүктесі ретінде пайдалы, бірақ күнделікті жасау әрдайым қажет емес. Ол ұзаққа созылады, орны көп алады және белсенді жұмыс терезесіне түсуі мүмкін. Практикада толық көшірме сирек, ал аралықтарда өзгерістер алынған болады.

Инкрементальды көшірмелер тек соңғы көшірмеден кейін өзгергендерді сақтайды және әдетте аз орын алады. Дифференциалды көшірмелер соңғы толық көшірмеден бері өзгерістерді сақтайды. Дифференциалды қалпына келтіру жеңілірек (шілтемелік тізбек қысқа), инкрементальды үнемді, бірақ тәртіпті қажет етеді: бір фрагменттің жоғалуы қалпына келтіруді бұзуы мүмкін.

Егер дерекқор транзакциялық журналдарды (transaction logs) қолдаса, олардың көшірмесін жасау арқылы RPO‑ны минуттық деңгейге түсіруге болады. Бұл әрбір сұраныс немесе төлем маңызды жерде өте маңызды.

Практикалық схема, регламенттің негізіне алу оңай:

• толық көшірме: аптасына 1 рет ең тыныш терезеде
• күнделікті: дифференциалды немесе күні ішінде бірнеше инкрементальды
• транзакция журналдары: негізгі дерекқорлар үшін әр 5–15 минут
• жаңарту, интеграция немесе жаппай жүктеу алдында бөлек бэкап

Мысалы: бөлшек сауда компаниясында сатулар шыңы 12:00‑ден 21:00‑ге дейін, айдың жабылуы соңғы күні өтеді. Сол кезде жиі инкрементальды көшірмелер күндіз қойылады, айдың жабылу алдында жоспардан тыс толық көшірме жасалып, журналдар жиі сақталады, соңғы жүргізілген операциялар жоғалмауы үшін.

CRM/ERP‑да нақты не сақтау керек

Шынайы қалпына келтіру үшін тек дерекқорды ғана сақтау жеткіліксіз. Апатта жиі не бұзылады — деректер кестесі емес, байланыс: файлдар, баптаулар, интеграциялар, лицензиялар, доработкалар.

Міндетті минимум — бұлсыз қалпына келтіру толық болмайды

Компоненттерді топтастырып, олардың қайда сақталатынын және қалай қалпына келетінін білу ыңғайлы:

• Операциялық дерекқорлар (негізгі DB, транзакция журналдары, егер бар болса қызметтік DB)
• CRM/ERP файлдық сақтау (қосымшалар, сканерлер, құжаттар, экспорттар, сыртқы жүйелермен алмасу)
• Қосымша конфигурациясы және орта (конфигурация файлдары, қосылу параметрлері, тапсырма кестелері, кезектер)
• Интеграциялар және құпиялар (API‑токендер, парольдер, шифрлау кілттері, сертификаттар, 1С, пошта, телефония параметрлері және т. б.)
• Пайдаланушыға арналған доработкалар (скрипттер, плагиндер, басып шығару формалары, есептер, шаблондар, сақталған процедуралар)

Тек дерекқорды көшірсеңіз, жүйені көтеруге болады, бірақ пайдаланушылар тіркемелерді көрмей қалуы, бухгалтериямен алмасу жұмыс істемеуі және есептердің бұзылуы мүмкін.

Инвентаризация: не, қайда сақталады және иесі кім

Регламентке тізімді бекітпес бұрын қысқа инвентаризация жасаңыз. Бұл аз уақыт алады, бірақ қалпына келтіру кезінде күндер үнемдейді:

• не сақталатынын және физикалық қайда жатқанын анықтаңыз (сервер, виртуалдық машина, бұлт, NAS)
• дерек иесін тағайындаңыз (IT, бизнес бөлім, мердігер) және кім қолжетімділік береді
• әр компонентті қалай қалпына келтіруді сипаттаңыз (қадамдар, аккаунттар, лицензиялар, тәуелділіктер)
• нәтиженің қай жерден тексерілетінін белгілеңіз (жүйенің жұмыс белгісі: жүйеге кіру, іздеу, мәміле жасау, тіркемені ашу)

Мысалы: бір компанияда ERP серверде, ал файлдық сақтау желілік дискте жатыр. Апаттан кейін дерекқорды бір сағат ішінде қалпына келтіреді, бірақ интеграция үшін мемлекет порталы сертификатын және архивтерді ашатын кілтті табу үшін екі күн іздейді. Осындай ұсақ, бірақ маңызды элементтерді де бэкап пакетінен тыс қалдырмау керек, бірақ оларға қолжетімділік ережелерін бөлек бекітіңіз.

Сақтау және ротация: мерзімдер, жерлер, өзгермейтін көшірмелер

Көшіру жиілігі идеалды болса да, көшірмелер бір жерде жатса және тез қайта жазылса көмегі аз. Регламент үш сұраққа жауап беруі тиіс: қанша уақыт сақталатыны, қайда сақталатыны және өзгерістерден қалай қорғалатыны.

CRM/ERP резервтік көшірмелері үшін келесі түсінікті мерзім схемасы қолайлы:

• күнделікті көшірмелер: 7 күн сақтау
• апталық көшірмелер: 30 күн сақтау
• айлық көшірмелер: 90 күн сақтау
• ай архиві: 12 ай сақтау
• жылдық архив: 3–7 жыл (саясат пен заң талаптарына байланысты)

Мерзімдерді нақты тапсырмаларға байлаңыз: инцидентті тергеу, айдың жабылуы, аудит және салық кезеңдері. Егер бухгалтерияға өткен жылдың деректері керек болса, бұл жалпы айтылмай, нақты мерзімдермен көрсетілуі тиіс.

Ротация мен тазалауды нақты рольге бекітіңіз, абстрактті IT емес. Регламентте: кім сақтау орнын бақылайды, кім ескі көшірмелерді жоюды растау керек және сақтау толып қалса не істеу керектігі (мысалы, қосымша тапсырмаларды тоқтату, сақтау орнын кеңейту, кейбір архивтерді арзан тасымалдағышқа көшіру).

Площадкалар бойынша 3‑2‑1 қағидасын ұстануға кеңес беріледі: үш көшірме, екі түрлі сақтау түрінде, бір көшірме негізгі орнынан тыс. Бұл бөлек сервер, бөлек сақтау және қашықтағы площадка немесе дата‑орталық болуы мүмкін.

Өзгереді алмайтын (immutable) көшірмелер туралы бөлек тармақ — олар шифрлаушылардан және әкімшінің қателерінен қорғайды: тіпті қолжетімділігі бар адамның өзі тарихты жойып тастай алмайды. Регламентте қандай көшірмелер immutable болатынын (мысалы апталық пен айлық), қанша уақыт және кім осы баптаманы өзгерте алатынын көрсетіңіз. Егер инфрақұрылымды жүйелік интегратор жинаса, алдын ала сіздің жабдықтарыңызда және қашықтағы площадкада immutable репозиторийлерді қолдауды талқылаңыз.

Шифрлау және кілттер: бэкаптарға қолжетімдікті жоғалтпау жолдары

CRM/ERP бэкаптарының шифрлауы формальды қадам емес. Көшірмелерде жиі прод дерекқордан да көп дерек болады: ЖСН/ЖҚ, қаржылық құжаттар, тіркемелер және логтар. Егер архив ашылып кетсе, зиян прод жүйенің бұзылуымен тең болады.

Шифрлауды екі жерде қосыңыз: тасымалдау кезінде және сақтау кезінде. Тасымалдауда — CRM/ERP сервері, сақтау және репликация площадкасы арасындағы канал қорғалсын. Сақтауда — файл немесе томның өзін шифрлау және объектілік сақтау пайдаланса онда оның ішіндегі шифрлауды қосу. Регламентте «шифрланбаған көшірмелер жарамсыз» екенін анық жазу пайдалы.

Кілттерді басқару

Кілттер архивтерден маңыздырақ. Кілт жоғалған немесе бұғатталған жағдайда, көшірмелер мінсіз болса да қалпына келтіру мүмкін болмайды.

Минималды ережелер:

• кілттерді көшірмелерден бөлек сақтаңыз (басқа жүйе, басқа қолжетімділік)
• кілттердің иесін тағайындаңыз (әдетте ақпараттық қауіпсіздік) және төтенше қолжетімділік тәртібін реттеңіз
• кілттерді жоспарлы түрде ауыстырыңыз және қызметкер кеткенде дереу әрекет етіңіз
• кілттің резерв нұсқасын қорғалған түрде ұстаңыз және оның оқылатынын үнемі тексеріңіз

Құқықтарды бөлу

Типтік қате: бір әкімші CRM/ERP‑ны, бэкаптарды және кілттерді бірден басқарады. Бір компрометацияланған аккаунт бүкіл жүйеге қолжетімділік береді. Жақсырақ бөлу:

• жүйе әкімшісі көшірмелерді жасайды және статусын көреді
• ақпараттық қауіпсіздік кілттер мен қолжетімділікті басқарады
• қалпына келтіру операциясын растау үшін бөлек адам немесе топ

Ішкі саясаттар мен регулятор талаптарына сәйкестігін тексеріңіз: кім деректерге қол жеткізе алады, көшірмелер қайда физикалық сақталады, кілт берулер қалай тіркеледі және кім ерекшеліктерді бекітеді.

Жауапкершілік пен бақылау: кім жасайды және кім тексереді

Көп жағдайда регламент технологиядан емес, «ешкім жауап бермейді» жағдайынан құлайды. Егер рөлдер бөлінбесе, бэкап айлар бойы жасалғанымен апатта соңғы көшірменің қай жерде екенін немесе кілттердің кімде екенін ешкім білмеуі ықтимал.

Міндеттерді екі адам жүйесі бойынша бөліңіз: біреу орындаса, басқа тексерсін. Көбінесе төрт роль жеткілікті:

• жүйе иесі (бизнес): приоритеттерді анықтайды, RPO/RTO және сақтау мерзімдерін бекітеді, тәуекелдерді қабылдайды
• әкімші (IT): кестені, сақтау мен ротацияны орнатады, қалпына келтірулерді тапсырыс бойынша орындайды
• ақпараттық қауіпсіздік: шифрлау, қолжетімділік ережелерін бекітеді және сақталуын бақылайды
• бақылау жауаптысы (IT не ішкі аудит): есептерді жүйелі түрде тексереді, тесттік қалпына келтірулерді ұйымдастырады

Бақылау нақты болу үшін әрекеттер журналы жүргізіңіз. Логтарда міндетті түрде көрінуі тиіс: тапсырма басталды, нәтижесі (сәтті/қате), көлемі мен құрамын, сақтау орны, және кез келген қолмен жасалған операциялар (көшірмені жою, саясат өзгерту, қалпына келтіру бастау). Қай әрекетті кім жасағанын жазып отыру маңызды.

Оповещения нақты адамдарға және анық шекті мәндерге жіберілсін. Міндетті оқиғалар: бэкап сәтсіз болғанда, терезені жіберіп алғанда, сақтау толғанда, тұтастық тексерісі қателік бергенде, рұқсатсыз жою болғанда.

Минималды құжаттар қысқа және өзекті болуы тиіс:

• бэкап схемасы (не және қайда көшіріледі)
• кесте және сақтау мерзімдері
• сақтау орындарының тізімі және қолжетімділік ережелері
• жауаптылардың байланыстары және эскалация тәртібі
• қалпына келтіру және тексеру бойынша қысқа нұсқаулық

Мысал: түнде CRM бэкапы дисктің толуы себебінен өтпеді. Әкімші хабарламаны алып, орынды босатады, ал бақылау жауаптысы таңертең жаңа бэкаптың сәтті өткенін тексереді. Егер қолдау 24/7 болса және сыртқы партнерге сенім артылса, алдын ала кімнің инцидентті қабылдайтыны және қанша минут ішінде жауап беретіні регламентте көрсетілсін.

Қадамдық: регламентті қалай рәсімдеп, енгізу керек

CRM/ERP резервтік көшірмелер апатта жұмыс істеуі үшін регламент қағазда емес, нақты нұсқаулық болуы керек: не істейміз, қашан істейміз, көшірмелер қайда, кім жауапты және нәтижені қалай тексереміз.

5 қадам, реттілікпен орындағаны дұрыс

1. Қорғалатын нәрсені анықтаңыз: дерекқорлар, тіркемелер, интеграциялар, негізгі есептер. Жанына әр топ үшін RPO/RTO мақсаттарын жазыңыз (мысалы, тапсырыстар — жоғалту 1 сағаттан аспауы керек, қалпына келтіру 4 сағат ішінде).

2. Көшірме түрлері мен кестесін нақты жұмыстың уақытын және жүктемесін ескере отырып таңдаңыз. Әдетте толық пен инкрементальды комбинациясы, және критикалық анықтамалардың бөлек экспорты қолданылады. Регламентте нақты терезелерді көрсетіңіз: аптаның күндері, сағаттары, ұзақтығы, трафик шектеулері.

3. Сақтау және ротацияны сипаттаңыз, сонда нақты болады: қай жерде соңғы көшірме, қай жерде ұзақ мерзім, және не автоматты түрде өшіріледі. Площадкаларды бөліңіз: кем дегенде бір көшірме негізгі инфрақұрылымнан тыс сақталсын. Мүмкін жерде immutable көшірмелерді пайдаланыңыз.

4. Шифрлау және қолжетімділік ережелерін енгізіңіз: кім бэкапты іске қоса алады, кім оқи алады, кім өшіру құқығына ие. Кілттер қайда сақталады, кім оларды ауыстырады және қызметкер ауысқанда не істеу керек — барлығы регламентте болсын.

5. Сәттілікті мониторингтеңіз: қателер туралы оповещения, күнделікті қысқа есеп, айлық қорытынды. Қайталанған қателер саны бойынша шектік мәндер қойыңыз және қашан инцидент көтерілетінін анықтаңыз.

Содан кейін регламентті жұмысқа арналған артефакттер жиыны ретінде рәсімдеңіз: деректер схемасы, кесте, жауапкершілік матрицасы, қалпына келтіру нұсқаулығы және тексеру журналы. Егер ішкі IT және интегратор бірге енгізсе, біреу операцияларды орындайды, басқасы есеп бойынша нәтиже растасын деген ережені бірден бекітіңіз.

Егер серіктес‑интегратор тартылады, тек баптауды ғана емес, процесс бойынша тұрақты қолдауды: мониторинг, тесттік қалпына келтірулер және кілттерге қолжетімділік тәртібін алдын ала келісуді ұсыныңыз. GSE.kz жобаларында дәл осындай формат жиі апатты жағдайлардан сақтайды.

Тесттік қалпына келтірулер: міндетті минимум және өткізудің тәртібі

Бэкап тексерілмесе, ол тек файл сияқты болады: бар, бірақ қалпына келмейді. Сондықтан тесттік қалпына келтіру регламентте бэкап сияқты қатаң болуы керек.

Көп компания үшін минимум — тоқсан сайын. Егер CRM/ERP сатуға, өндіріс немесе қаржыға критикалық болса, ай сайын немесе әр ірі жаңартудан кейін тестілеу қажет.

Қандай тесттер өткізу керек

Оңайдан бастап, Қалпына келтірудің толық жолын ақырындап тексеріңіз:

• нүктелік қалпына келтіру: бір файл, есеп, тіркелген клиент жазбасы
• дерекқорды бөлек серверге қалпына келтіру
• бэкаптан толық тесттік стендті көтеру
• апат жағдайы сияқты режимде қалпына келтіру (шектеулі қолжетіммен, ескерту жоқ)

Әр тесттен кейін уақытты ғана емес, нәтиженің сапасын да өлшеу маңызды.

Не өлшеу және тест протоколын қалай толтыру

Өлшенетін көрсеткіштер:

• қалпына келтіру уақыты (факті) және оны RTO‑мен салыстыру
• қалпына келтіру нүктесі (қанша дерек жоғалғаны) және оны RPO‑мен салыстыру
• деректер бүтіндігі: таңдамалы тексеру — құжаттар, анықтамалар, құқықтар
• интеграциялардың жұмыс істеуі: пошта, телефония, 1С, ESB, API, файл алмасу

Тест протоколы қысқа, бірақ анық болуы керек: күн, жүйе нұсқасы, пайдаланылған бэкап, орындаушылар, қадамдар, нақты уақыттар, шыққан қателер және шешімдер.

Мысал: түнгі көшірмеден стенд көтергенде дерекқор 40 минутта қалпына келді, бірақ почта серверімен интеграция сертификаты мерзімі өткен еді. Әрекет: сертификатты жаңарту, мерзімді мониторингке қосу, апта ішінде қайта тест жүргізіп, тек табыс болған соң ғана тармақты жабу.

Бэкапты құтқармайтын типтік қателіктер

Көбіне мәселе бэкаптардың болмауында емес, олардың қалпына келтіруге жарамсыз болуында.

Ең ауыр жағдай — тек дерекқорды көшіріп қою. Қалпына келтіру кезінде баптаулар, файлды сақтау, шаблондар, тіркемелер, интеграциялық модульдер, сертификаттар және тапсырма кестелері жоқ болып шығады. Нәтижесінде жүйе әдеттегідей жұмыс істемейді: хаттар шықпайды, бухгалтериямен алмасу сәтсіз болады, тәркелерде тіркемелер жоғалады.

Жиі кездесетін тағы бір қате — архив бар, бірақ оған қолжетім жоқ. Шифрлау кілттері бір адамда, админ кеткенде кілт жоғалған, хранилище құқықтары өзгертілді. Формальды бэкап бар, бірақ қалпына келтіру мүмкін емес.

Бэкаптарды продпен бірге сақтау қауіпті: бір серверде, бір виртуализацияда немесе бір доменде. Шифрлаушы немесе аккаунттардың компрометациясы кезінде прод пен бэкаптар бірге бұзылуы мүмкін, өйткені қолжетімділіктер бірдей.

Тағы бір ж silently жоюшы — қателерді бақылаудың болмауы. Көшіру тапсырмасы жүріп жатқан сияқты, бірақ есептерге қарамайды, диск орын жетпей қалады және ай бойы көшірме жасалмайды. Бұл туралы апат күні ғана белгілі болады.

Сондай‑ақ, көшірмелерді қолмен жою қаупі бар. Егер ротация автоматтандырылмаған болса, біреу орын босату үшін дәл қажетті кезеңді өшіріп жіберуі мүмкін (мысалы, деректердің жаппай жойылуына дейінгі период).

Процестің сау белгісі: сіз алдын ала нақты не көшірілетінін, қайда жататынын, кілттер кімде екенін және резервтеу сәтсіздігін қаншалықты тез байқайтыныңызды білесіз.

Мысал сценарий: апат және регламент бойынша қалпына келтіру

Филиал компаниясы сатуды CRM‑да жүргізеді, ал ERP‑де қойма және отгрузкалар бар. Күндіз менеджерлер мәмілелерді тіркейді, кешке қойма қалдықтарды жауып, накладные басып алады. Бір күндік деректі жоғалту жағынан жағымсыз болса, апта бойы жоғалтушылық критикалық.

Апат дүйсенбі таңертең болады: жоспарлы жаңарту кейін ERP дерекқоры іске қосылмайды, журнал файл зақымданғанын көрсетеді. CRM жұмыс істейді, бірақ ERP‑мен интеграция тоқтап, қойма отгрузка жасай алмайды. Регламент бойынша RPO 4 сағат, RTO 2 сағат белгіленген.

Дежурный әкімші қалпына келтіру процедурасын бастайды. Регламентте көшірмелер қайда және қалай шифрланғаны, кілттер кімде екені алдын ала жазылғандықтан іздеуге уақыт кетпейді.

Чеклист бойынша әрекеттер:

• ақаудың уақытын тіркеу және қалпына келтіру нүктесін таңдау: соңғы сәтті толық көшірме + соңғы инкрементальды
• қалпына келтіруді бөлек серверде немесе виртуалды ортада іске қосу (көбінесе оны жөндеуден тезірек)
• дерекқор бүтіндігін және ERP қызметтерін тексеру, содан кейін CRM‑пен алмасуды тексеру
• бизнес‑тексерулер өткізу: 5–10 типтік құжатты ашу (тапсырыс, шот, келу, жазылым), бақылау позицияларымен қалдықтарды салыстыру
• пайдаланушыларды қайта қосу және нақты RTO мен жоғалған деректер (фактикалық RPO) тіркеу

Коммуникация регламенттің бөлігі. IT алғашқы 10–15 минутта бизнесті хабарлайды: не істен шықты, не істеп жатырмыз, келесі статус қашан болады. IT жетекшісі уақыт болжамын растайды, ал процессте иесі (сату директор немесе қойма басшысы) нәтижені қабылдайды: жүйе жұмыс істейді, тексерулер өткен және айырмашылықтар түсінікті әрі тіркелген.

Жылдам чеклист және келесі қадамдар

CRM/ERP резервтік көшірмелері апатта жұмыс істеуі үшін тек баптау жеткіліксіз — үнемі тексеру керек.

• CRM/ERP үшін RPO және RTO бекітілген және деректер приоритеті анықталған (не бірінші қалпына келтіріледі)
• бэкап кестесі мен ротация орнатылған: күнделікті, апталық, айлық көшірмелер қанша сақталатыны
• сақтау орындары анықталған: ең болмағанда екі, өшіруден қорғаныс (immutable көшірмелер) бар
• шифрлау қосылған, кілттер қайда, кімде және қызметкер ауысқанда не істеу керегі жазылған
• ролдер бекітілген: кім орындайды, кім тексереді, кім нәтижені қабылдайды; қателер туралы оповещения бар және тұрақты бақылау

Келесі қадамдар: қағазда емес тәжірибе болуы үшін тесттік қалпына келтіру протоколтары болуы керек: күн, не қалпына келтірілді (дерекқор, файлдар, интеграциялар), қанша уақыт кетті, қандай проблемалар тіркелді және не өзгертілді.

Егер тезірек тәртіпке келтіру керек болса, үш қадамнан бастаңыз:

1. Қолдағы бэкаптарды қысқа аудитпен тексеріңіз: қайда сақталған, қандай мерзімге бар, не шифрланады, оповещения шынымен келе ме.

2. Бөлек ортада сынақтық қалпына келтіру өткізіңіз. Мысалы, жүйені кеше 18:00 күйіне қалпына келтіріп, пайдаланушы кірісі, есептер, 1С, пошта және телефониямен алмасуды тексеріңіз.

3. Жақсартуды және мерзімдерді бекітіңіз: кестеде, сақтауда, қолжетімділікте не өзгертіледі және қай уақытта қайта тест өткізілетіні жазылсын.

Егер сенімді инфрақұрылым мен толық енгізу қажет болса, отандық жабдық пен 24/7 қолдауымен жүйелік интеграция опциясын қараңыз. Мысалы, GSE.kz (gse.kz) серверлер шығарады және резервтік көшіру мен қалпына келтіру инфрақұрылымын, оның ішінде S200 Series стойкаларын жинауға көмектеседі.