Сақтық көшірме жүйесін таңдау: RTO/RPO және сценарийлер

Мәселе қайдан басталады: нені қорғау керек

Сақтық көшірме туралы әдетте өнім атауларынан бастайды. Бірақ дұрыс бастама — жоғалтқыңыз келмейтін деректерді және олар қайдан пайда болатынын анықтау. Көбінесе «хакерлерден» гөрі күнделікті жағдайлар қателік жібереді: қате файл жойылды, жаңарту сәтсіз өтті, диск бос емес, виртуализация құлады, шифрлаушы желілік қалтаға жетті.

Қорғанысты "серверлер мен ПК" бойынша емес, жүктемелер түрі бойынша жоспарлаған ыңғайлы. Виртуализацияда көп ұқсас машиналар болады және жаппай қалпына келтіру жылдамдығы маңызды. Дерекқорларда бірінші орында консистенттік пен транзакцияларды дұрыс қалпына келтіру тұр. Офис ПК үшін сан бойынша қамту, пайдаланушы үшін қарапайымдылық және жеке файлдарды қалпына келтіру басым.

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

Дұрыс тәсілді таңдау үшін қорғауға жататындардың минималды картасын жасаңыз. Бірнеше сұраққа жауап беру жеткілікті: қай жүйелер маңызды (ВМ, дерекқорлар, файл ресурстар, ПК), деректер қайда орналасқан (ДЦ, филиалдар, бұлт, офистен тыс ноутбуктар), деректердің иесі кім және кім қалпына келтіреді (ИТ немесе бизнес бөлім), қандай инциденттер болған (жоюлар, апаттар, вирустар, әкімші қателері), типтік инцидентте не маңызды — қызметті толығымен жылдам көтеру ме әлде бір құжатты қайтару ма.

Одан кейін ғана RTO мен RPO-ны қалпына келтіру мақсаттары ретінде талқылаңыз, брендтің «функциясы» ретінде емес. Бұл тәртіп жүйені таңдау процесін жеңілдетеді: құралдарды жарнамалық уәделер емес, сіздің сценарийлеріңіз бойынша салыстырасыз. Практикада интеграторлар сияқты GSE.kz осы инвентаризациядан бастайды, сонда «жалпы жақсы» шешімді күнделікті қолдануда қолайсыздықтар туындатпайды.

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

RTO мен RPO жиі араласады, сондықтан кейін күтулер қате болады: ИТ көшірме жасап қойған, ал бизнес басқа нәрсе күтеді. Бұл екі көрсеткішті жазбаша және әрбір қызмет түрі бойынша бөлек бекіткен дұрыс.

RTO (Recovery Time Objective) — қызмет апаттан кейін қайта жұмысқа тұруы қажет уақыт. Қарапайым тілмен: қанша минут немесе сағат күте аласыз.

RPO (Recovery Point Objective) — уақыт бойынша деректердің рұқсат етілген жоғалуы. Қарапайым: сіз қанша уақыттық өзгерісті жоғалтуды қабылдайсыз. Егер RPO = 1 сағат болса, апатта сіз бір сағат бұрынғы күйге ораласыз.

Типтік бағдарлар (уәде емес, сөйлесудің бастапқы нүктесі):

• Крити́калық жүйелер (төлемдер, тапсырыстар қабылдау): RTO 15–60 минут, RPO 5–30 минут.
• Жалпы қызметтердің виртуалдық серверлері (AD, файл ресурстары, типтік қосымшалар): RTO 2–8 сағат, RPO 1–4 сағат.
• Актив жазбасы бар дерекқорлар: RTO 1–4 сағат, RPO 5–60 минут (консистенттілікті ескеріп).
• Пошта және коллаборация: RTO 4–24 сағат, RPO 1–8 сағат.
• Офис ПК мен ноутбуктер: RTO 1–3 күн, RPO 1 күн.

Барлық бөлімшелерге бірдей RTO/RPO қолайлы емес. Бухгалтерияға құжаттардың тұтастығы маңызды, контакт-орталыққа — жұмыс орнын тез қалпына келтіру, қауіпсіздікке — көшірмелердің өзгермейтіндігі. Бәріне ең қатаң талап қою бюджетті сақтау, каналдар, лицензиялар мен қолдауға жұмсайды.

Төрт сұрақ арқылы сандар бойынша дау-дамайсыз келісіңіз:

• Не есептеледі — жүйенің қолжетімсіздігі ме, әлде процестердің тоқтауы ма?
• Осы қызметтің бір сағаты қаншаға түседі?
• Қандай деректер еш жағдайда жоғалмауы тиіс?
• Қалпына келтіруді қаншалықты жиі тексеруге дайынсыз және нәтижені кім растайды?

Сценарий 1: виртуализация (VMware, Hyper-V және т.б.)

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

Негізгі тәсіл — гипервизор деңгейінде сақтық көшірме: ВМ-ды объект ретінде алып, көбінесе жаппай қалпына келтіруді ең жылдам қамтамасыз етеді. Бірақ кейде қонақ агентсіз болмайды. Агент ОС немесе қосымша деңгейінде консистенттілік қажет болса немесе жеке томдар мен деректер үшін нақтылы саясаттар керек болса қолданылады.

Виртуалдық ортаға жүйе таңдаудан бұрын бірнеше практикалық мәселені шешіңіз: апатта не маңызды — «ВМ-ды 15 минутта іске қосу» немесе «файлды 2 минутта қайтару», қонақ ОС ішінде консистенттілік кепілдіктері керек пе (мысалы, белсенді транзакциялары бар сервистер үшін), көшірмелер қайда сақталатын болады және дедупликация мен бірнеше нүктені сақтау үшін орын жеткілікті ме, қай қалпына келтіру сценарийі жиі болады (толық, инкременталдық, backup-тан лезде іске қосу), өндірісті тоқтатпай қалай тексересіз.

Тар жерлер әдетте екі: қалпына келтіру жылдамдығы (сақтау мен желіге байланысты) және көлем. Дедупликация мен сығу көмектеседі, бірақ әсер ВМ-дардың ұқсастығына және өзгеріс жиілігіне тәуелді.

Бөлек критикалық сервистерді бөліп көрсетіңіз: домен контроллері, файл серверлер, лицензиялау және басқару серверлері. Оларға жиі қалпына келтіру нүктелері, жеке сақтау саясаттары және міндетті кезектік тесттер жасалады. Барлық ВМ-ды бірдей «алтынға» айналдырудан артық шығынды болдырмау үшін осылай істеу тиімді.

Сценарий 2: дерекқорлар және консистенттік талаптары

Дерекқорларда маңыздысы тек файлдар емес, қалпына келтіру сәтіндегі деректердің дұрыс күйі. «Дерекқор» контексте түрлі болуы мүмкін: Microsoft SQL Server, PostgreSQL, Oracle, MySQL, 1С SQL-нұсқасы, сондай-ақ CRM, документооборот, биллинг жүйелерінің ішкі дерекқорлары. Әрқайсысының транзакцияларды бекіту және қалпына келтіру талаптары әртүрлі.

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

Логикалық бэкаптар және сақтау/снапшоттар

Логикалық бэкап (dump, экспорт) түсінікті және тасымалданатын, бірақ ірі көлемде қалпына келтіру ұзақ болуы мүмкін. Сонымен қатар, егер экспорттар сирек жасалса, «соңғы минутқа» тез оралуға көмектеспейді.

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

Алдын ала компромиссті бекітіңіз: нақты дерекқор үшін не маңызды — қызметті тез қайтару (RTO) ма немесе деректердің минималды жоғалуы (RPO) ма, және қай механизмдерді пайдалануға дайынсыз.

Қалпына келтіру нүктелері: full, incremental және журналдар

Көптеген өндірістік дерекқорлар үшін бір толық бэкап жеткіліксіз. Әдетте толық бэкап, инкременталдық көшірмелер және транзакция журналдарының бэкаптары қажет, осылайша қалпына келтіруді қажетті уақытқа дейін «докрутасыз». Бұл пайдаланушы қателігінен (кестені жою, қате жаңарту) және жаңарту сәтсіздіктері кезінде әсіресе маңызды.

Енгізбес бұрын келесі негізгі нәрселерді бекітіңіз:

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

Консистенттілікті тексеру міндетті болуы тиіс, «қажет кезде» емес. Жұмыс тәжірибесі — «құмқорапта» тұрақты қалпына келтіру: бөлек стенд немесе оқшауланған орта, онда көшірмені көтеріп, дерекқорды тексеріп, қосымшаның деректерді дұрыс көретініне көз жеткізесіз. Осылай апат күні не алынатынын алдын ала білесіз.

Сценарий 3: офис ПК және ноутбуктар

Офис ПК-ларды жиі қате қорғаудың жалпы тәсілі — дискіні түгелдей сақтық көшірмелеу. Практикада құндылық көбіне басқа жерде: құжаттар папкасы, жұмыс үстелі, қосымша профилдері, жергілікті бухгалтерлік файлдар, сатылым бөлімі файлдары, пошта архивтері, браузер және VPN параметрлері. Кэш, уақытша файлдар және "Жүктеулер" жиі тек сақтау мен көшірме уақытын өсіреді.

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

ПК үшін сақтау саясаттары бизнеске түсінікті болуы керек. Әдетте бірнеше қабат жеткілікті: кездейсоқ жоюлар үшін қысқа нұсқалар және инциденттерді тергеу үшін ұзақ сақтау.

Офис құрылғылары үшін не тиімді

Жиі келесі жиынтық жеткілікті:

• кездейсоқ өзгерістер мен жоюдан қорғау үшін 14–30 күн версиялары;
• маңызды бөлімдерге (қаржы, кадр, заңгерлер) 3–6 ай;
• басшы ноутбуктары үшін жиі нүктелер;
• көшірмелердің шифрлануы және қолжетімділікті бақылау, сонда бэкап дереккөзінен ақпарат ағып кетпес;
• пайдаланушыларға self-service мүмкіндік беріп, файлды ИТ-ға өтінішсіз қайтару.

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

Зрел жоба белгісі — ИТ соңғы файл қалпына келтіру тестінің нақты күнін көрсете алады, тек көшірме «жасалды» галочкаларынан гөрі.

Veeam, Commvault, Rubrik, Acronis-ты сценарийлер бойынша қалай салыстыру

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

Өнім атауларынан гөрі тапсырма арқылы салыстырыңыз

Тапсырмаларды қарапайым сөйлемдермен қойыңыз: "виртуалдық машинаны 30 минут ішінде көтеру", "дерекқорды уақыт нүктесіне қайтару", "шифрлаушыдан кейін қызметкер ноутбукын қалпына келтіру". Әр вендорға немесе интеграторға бірдей сұрақтарды қойыңыз.

Тез лайықсыздарды бөліп тастайтын сұрақтар жиынтығы:

• әр сценарий бойынша типтік қалпына келтіру қанша қадам және қанша уақыт алады (ВМ, ДБ, ПК)?
• оқшауланған сақтау нұсқалары (immutability, бөлек контур, офлайн-көшірме) бар ма және олар қалай басқарылады?
• шешім on-prem, гибрид және филиалдарда қалай жұмыс істейді және лицензияларда не өзгереді?
• дерекқорлар үшін консистенттік талаптары қандай (агенттер, снапшоттар, журналдар, point-in-time) және тестпен қалай тексеріледі?
• каталог (AD), мониторинг, SIEM, тикет жүйелері, аудит есептері сияқты интеграциялар қажет пе?

Күшті жақтар сценарийлер бойынша бөлінеді. Виртуализацияда қалпына келтіру жылдамдығы, снапшоттармен жұмыс және тестті автоматтандыру маңызды. Дерекқорларда консистенттік пен нақты уақыт нүктесіне оралу шешеді. Жұмыс станциялары үшін орнатудың қарапайымдылығы, пайдаланушыға жүктеме аз болуы, self-service және шифрлаушылардан қорғаныс маңызды.

Аралас инфрақұрылымда (бір бөлігі ДЦ-да, бір бөлігі филиалдарда) қай жерде негізгі "шындық көзі" (source of truth) болатынын және саясаттарды кім басқаратанын алдын ала анықтаңыз. GSE.kz сияқты интегратор жобаларында бұл әдетте талаптарда бекітіледі: мониторинг кімде, SIEM-ге инциденттер кімге барады және тикет 24/7 қолдауға қалай жетеді.

Уәделерге сенбеңіз — пилот сұраңыз. Әрқайсынан нақты сіздің кейсті: бір VM, бір критикалық ДБ және бір ноутбук қалпына келтіріп көрсетуін сұраңыз, уақытын өлшеңіз және анық есеп алыңыз.

Шешімді таңдаудың қадамдық алгоритмі

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

Көп ұйымда жұмыс істейтін 5 қадам

1. Қорғауға алынатындарды тізімдеп, критикалықтігін белгілеп шығыңыз. Әрқайсысын кемінде үш топқа бөліңіз: "тоқтатуға болмайды", "бір күнде қалпына келтіріледі", "жоғалтуы өкінішті, бірақ көтеріңізші". Тәуелділіктерді дереу жазып алыңыз: қай дерекқор қай қызметке қажет, негізгі файлдар қайда сақталады.

2. Мақсатты RTO мен RPO және нақты көшірме терезесін бекітіңіз. "Жылдам болсын" емес, нақты: "тоқтауы 2 сағаттан аспауы тиіс" және "деректерден 15 минут жоғалтуға рұқсат" сияқты. Желі мен сақтау тапсырмаларды көтере ме тексеріңіз.

3. Сақтау архитектурасы мен шифрлаушылардан қорғанысты анықтаңыз. Негізгі репозиторий қайда болады (жергілікті немесе бөлек орын), репликация қажет пе, immutable сақтау керек пе және саясат талаптарына сәйкес қанша уақытқа болу керек.

4. 1–2 типтік сценарийде пилот жасаңыз. Мысалы: бір виртуалдық машина, бір дерекқор және 10 офис ПК. Пилотта нақты қалпына келтіру уақыттарын өлшеп, көшірмелердің консистенттігін тексеріңіз.

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

Басқа пайдалы тәжірибе — бір критикалық жүйені таңдап, бэкаптан бастап бөлек жабдыққа (арнайы сервер немесе сақтау) қалпына келтіру жолын толық өту. Бұл RTO/RPO-ға қатысты күтулер мен нақты жағдай қай жерде келіспейтінін тез көрсетеді.

Қалпына келтіру тесттері: бэкаптың жұмыс істейтінін қалай дәлелдеу

Сақтық көшірме құнды тек қалпына келтіру мүмкін болғанда ғана. Сондықтан қалпына келтіру тесттерін процестің міндетті бөлігіне айналдыру керек, «бір реттік тексеру» етіп қалдырмаңыз.

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

• Бір файлды қалпына келтіру (құқықтар мен версияны тексеру).
• Виртуалдық машинаны бөлек ортаға қалпына келтіру (ОS-ты іске қосу және желі баптауларын тексеру).
• Дерекқорды қалпына келтіру және консистенттікті тексеру (контроль сұрақтар).
• Офис ПК-ны немесе ноутбукты "таза" құрылғыға қалпына келтіру.
• Деректерді қайта жазбау үшін альтернативті орынға қайтару.

Тесттер дау-дамайға айналмас үшін алдын ала иелерін анықтаңыз. Әдетте ИТ тест жүргізеді, ал бизнес иесі немесе қауіпсіздік бөлімі қалпына келтірілген қызметтің жұмысқа жарамдылығын растайды.

Жиілік: файлдар мен офис ПК-ларды ай сайын, критикалық ВМ мен дерекқорларды тоқсан сайын тексеру жиі қолдануға ыңғайлы. Ірі өзгерістерден соң (гипервизор жаңартуы, сақтау миграциясы, саясатының өзгерісі) жоспардан тыс тест жүргізіңіз.

Нәтижелер көрініктен гөрі маңызды: протоколда тек процесті жақсартуға көмектесетін заттарды тіркеңіз:

• не қалпына келтірілді және қай нүктеден (күні мен уақыты);
• қанша уақыт кетті (факт vs мақсатты RTO);
• қанша деректер жоғалды (факт vs мақсатты RPO);
• қателер мен ескертулер, себептері және түзетуді кім жауапты;
• жүйенің иесі не дәлелдеді («сәттілік» критерийлері).

Өндірісті тоқтатпай қауіпсіз тест жасау мүмкін: оқшауланған желіге қалпына келтіру, ВМ көшірмесін интеграциясыз көтеру, дерекқорды бөлек инстанцияда қалпына келтіру, ПК үшін қосымша құрылғы пайдалану. Мысалы, банк тоқсан сайын төлем ВМ-ның көшірмесін тест сегментінде көтеріп, кіруді, журналдауды және негізгі операцияларды тексереді, сосын ортаны жояды.

Сақтық көшірме жобаларындағы типтік қателіктер мен тұзақтар

Ең жиі кездесетін проблема — мақсат "бэкап жасау" деп қойылады, ал дұрыс мақсат "осындай күйде және осындай уақытта қалпына келтіру" болуға тиіс. Нәтижесінде көшірмелер бар, бірақ нақты апатқа жауап беретін ешкім жоқ: не бірінші көтеріледі, соңғы "таза" нүкте қайда, кімде қолжетімділік бар, қанша уақыт қажет.

Екінші тұзақ — ұғымдардың ауыстырылуы: snapshot әрдайым резервтік көшірме емес. Снапшот қысқа уақыттық оралуға ыңғайлы, бірақ ол өңдеп тұрған жүйемен бірге өмір сүреді және сол сақтау жүйесіне тәуелді. Егер СХД-де, скрипт қатесінде немесе шифрлаушыда мәселе болса, snapshot көмектеспеуі мүмкін.

Үшінші қателік — "қажет кезде тест жасаймыз" тәсілі. Бір реттік қолмен қалпына келтіру нақты жағдайды көрсетпейді: көбіне нақты RTO өлшенбейді, қосымшалардың тұтастығы тексерілмейді және бірнеше жүйені параллельді қалпына келтіру ескерілмейді. Шешімді таңдағанда сәтті тесттің не екенін және қанша уақыт алатынын алдын ала келісіңіз.

Тәуелділіктерді ескермеу тағы бір классикалық мәселе. Бэкапта сервер бар, бірақ болмауы мүмкін:

• сервис тіркелгілері мен қолжетім құқықтары;
• шифрлау кілттері мен сақтау парольдері;
• лицензиялар мен активация файлдары;
• DNS, AD, желілік маршруттар мен VLAN параметрлері;
• виртуализация консольіне немесе конфигурация базасына қолжетім.

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

Прост мысал: Қазақстандағы бір филиалда виртуалдық машиналар қорғалған, бірақ көшірмелер сол NAS-та сақталады. Шифрлаушылар шабуылдағанда репозиторий де шифрланған болып шығады. Қорғалған жалғыз үміт — ескі snapshot, бірақ ол да бүлінген болып шықты. Мұндай жағдайлар тек тұрақты қалпына келтіру тесттері мен көшірме сақтаудың дұрыс оқшаулауында анықталады.

Сатып алу мен енгізуден бұрынғы қысқа чек-лист

Сақтық көшірме жүйесін таңдауды бастамас бұрын "бэкап керек" ғана емес, ойнау ережелері анық болуын тексеріңіз. Әйтпесе құрал аласыз да, ол нені және қанша уақытта сақтайтыны жөнінде дауласып жүресіз.

Біріншіден, деректер иелерін тағайындаңыз. Бұл ИТ-тың жалпы емес, бизнес тарапынан нақты адамдар: критикалықтікті кім растайды, қалпына келтіруді кім қабылдайды, тест нәтижелерін кім қол қояды.

Содан соң сандар мен шектеулерді бекітіңіз. RTO мен RPO "жылдамырақ" және "жиірақ" емес, жүйе топтары бойынша нақты мәндер болуы керек. Қай уақытта желі мен сақтау жүктелуіне болатындығын да бөлек айтыңыз (мысалы, бухгалтерия жұмыс уақытында ауыр жүктеме беруге болмайды).

Сатып алудан бұрынғы практикалық минимум:

• Критичтілік матрицасы: қай жүйелер Tier-1/Tier-2, иелері кім, тоқтаудан келетін шығын.
• Әр класс бойынша RTO/RPO және көшірме терезесі: виртуализация, дерекқорлар, офис ПК.
• 3-2-1 принципіне сай сақтау схемасы немесе эквиваленті және оқшауланған көшірме: мысалы, immutable-сақтау немесе офлайн-дискі.
• Қалпына келтіру тесттер жоспары: не қалпына келтіру (VM, кесте/дерекқор, пайдаланушы файлы), қаншалықты жиі, кім қатысады, нәтижені қалай тіркейсіз.
• Қауіпсіздік талаптары: тасымалдауда және дискке шифрлау, қолжетімділікті бөлу, әрекеттер журналы, бэкап үшін бөлек тіркелгілер.

Сәттілік метрикаларын алдын ала келісіңіз. Мысалы: "1С-ты T-15 минут нүктесіне 60 минут ішінде қалпына келтіру" немесе "сweтик VM-ды 30 минутта жұмыспен тексеру арқылы көтеру". Олай болмаған жағдайда тесттер формальданып кетеді.

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

Осы тармақтар келісілген соң, сақтық көшірме жүйесін таңдау функциялар мен баға бойынша сабырлы тапсырмаға айналады, брендтер туралы дау емес.

Сценарий мысалы және келесі қадамдар

Орташа ұйым: 40–60 виртуалдық машина (пошта, файл сервисі, 1С), 1–2 дерекқор (мысалы, PostgreSQL және MS SQL), шамамен 200 офис ПК мен ноутбук. "Жалпы бэкап" туралы даудан қашу үшін қорғанысты сыныптарға бөліп, әрқайсысына RTO мен RPO-ны алдын ала келісіңіз.

Жұмысшы нұсқа: критикалық сервистер виртуализацияда жиі нүктелер және апатта жылдам іске қосылуға ие. Дерекқорлар консистенттікті ескере отырып қорғалады (снапшоттар + журналдар, тест ортада тексеру). Офис ПК бөлек контурда: маңызды папкалар мен профильдер, түсінікті сақтау саясаты, файлды қайтару үшін қарапайым self-service.

Пресейлде сұраңыздар, бұл сандар мен бағаға тікелей әсер етеді:

• Біздің дерекқорлар үшін консистенттікті қалай қамтамасыз етесіз және журналдарды қаншалықты жиі қолдануға болады?
• Қай уақытта біз үшін нақты қалпына келтіру уақыты қандай болады: VM іске қосу, темірге қалпына келтіру немесе желі арқылы көшіру ме?
• Көшірмелер қайда сақталады (жергілікті, бөлек орын, immutable сақтау) және аккаунттар қалай қорғалған?
• Қалай жұмыс істейтінін дәлелдейсіз: қандай қалпына келтіру тесттері және олар қаншалықты жиі жүргізіледі?
• Қолдау неге кіреді және түнгі немесе демалыс күнгі инцидентті шешу қанша уақыт алады?

Пилотты нақты RTO/RPO өлшеу үшін жоспарлаңыз. 2–3 типтік VM, бір ДБ және 5–10 ПК таңдаңыз. Сценарийлері: файл жою, ВМ құлауы, ДБ бүліну, жаңа площадкаға қалпына келтіру. Уәде емес, минуттар мен қадамдарды тіркеңіз.

Келесі қадамдар: обследование, жоба, пилот, енгізу, регламенттер (кім жауап береді, қаншалықты жиі тексереміз, қайда сақтаймыз, қалай әрекет етеміз). Қажет болса, GSE.kz сіздің RTO/RPO-ға сәйкес архитектура жинап, инфрақұрылым (серверлер және СХД), интеграция және 24/7 қолдауды қамтамасыз ете алады.