3-2-1 резервтік көшірме: енгізу, қателер және тестілеу

Неліктен 3-2-1 схемасы қажет

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

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

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

3-2-1 схемасы практикалық және шынайылықты ескереді. Ол «бір нүктелік қателік» тәуекелін азайтады: бір тасымалдағыш істен шықса, басқа бар; офис қолжетімсіз болса, сыртқы көшірме сақталған; егер вирустар барлық жерді шифрласа, оқшауланған нұсқа қалады.

Қысқаша айтқанда, 3-2-1 үш нәрсе береді: әртүрлі апаттарға дайындық жоспары, сақтау құрылымы және тәртіп. Бэкапта тәртіп «тамаша» технологиядан маңыздырақ: дағдарыс кезінде алдын ала дайындалған сценарий бойынша әрекет етесіз, ә rather емес, соңғы жұмыс көшірмесі қайда екенін есіңізге түсіруге тырысуға.

3-2-1 схемасы қарапайым тілмен

3-2-1 ережесі — диск істен шыққанда, сервер шифрланғанда немесе біреу маңызды папканы кездейсоқ өшіргенде деректеріңізді жоғалтпау әдісі. Мағынасы — әрқашан бірнеше тәуелсіз қалпына келтіру нұсқалары болуы.

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

«Үш көшірме» нақты қайсысы

Бірінші көшірме — жұмыс деректері (күнделікті пайдаланатын нәрсе). Олардың кемінде екі резервтік көшірмесі болуы қажет.

Маңызды: «бізде серверде көшірме бар» — көбінесе тек бір резервтік көшірме ғана. 3-2-1 үшін тағы бір бөлек көшірме керек.

«Әртүрлі тасымалдағыштар» және «сыртта» нені білдіреді

«Әртүрлі тасымалдағыштар» — бір сервердегі екі бөлім немесе бір RAID-массивіндегі екі диск емес. Бұл бірдей уақытта істен шықпайтын, тәуелсіз сақтау орындары.

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

Практикалық мысал:

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

Бір қабат ақау берсе, қалпына келу үшін кем дегенде тағы бір мүмкіндік қалады.

Қайдан бастау: инвентаризация және мақсаттар (RPO/RTO)

Кез келген 3-2-1 схемасы дискілер мен бұлтты таңдауынан емес, қорғалатын нәрселердің тізімінен басталады: не қорғалатынын және оны жоғалтудың қаншалықты ауыр екенін анықтаңыз. Инвентаризациясыз «әртүрлі нәрселердің» сақтық көшірмесін жасайсыз, бірақ нақты маңызды нәрселер сақталмауы мүмкін.

Маңызды деректер мен жүйелер тізімін жасаңыз. Әдетте бухгалтерия мен қаржылық базалар, CRM/ERP және басқа жұмыс базалар, корпоративтік пошта мен архивтер, жалпы құжаттар мен келісім-шарттар папкалары, сондай-ақ серверлер мен желі құралдарының конфигурациялары мен маңызды қолданбалар кіреді.

Келесі екі сұрақ — бүкіл бэкап жоспары үшін шекара белгілейді.

RPO (қанша деректі жоғалтуды қабылдайсыз). Бұл «қаңша уақытқа дейін артқа оралсақ болады» деген сұрақ. Мысалы, RPO = 4 сағат болса, көшірмелер апатта 4 сағаттан көп өзгерісті жоғалтпау үшін жеткілікті жиі жасалуы тиіс.

RTO (қанша уақытта қалпына келу керек). Бұл тоқтап қалуға қатысты. Егер RTO = 2 сағат болса, апаттан кейін 2 сағат ішінде жұмыс мінсіз болмаса да, ең аз қабылданатын режимде қалпына келтіру керек.

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

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

Тағы бір практикалық қадам: деректерге жауапты иелерді тағайындаңыз. Кім қай жүйе үшін жауапты және апатта кім шешім қабылдайтынын (мысалы, «алғашқыда сату базасын қалпына келтіреміз, содан кейін поштаны») жазып қойыңыз. Бұл уақыт тығыз болғанда сағаттарды үнемдейді.

3-2-1 үшін тасымалдағыштар мен сақтау орындарын таңдау

3-2-1 схемасының мәні — бір құрылғының немесе алаңның істен шығуы барлық көшірмелерді бірден жоймауы. Сондықтан алдымен қандай ақаулар жиі болатындығын анықтаңыз: диск бұзылуы, шифрлаушы, әкімші қатесі, өрт, доменге қолжетімсіздік.

Бірінші резерв әдетте жұмыс жүйесіне жақын орналасады, тез қалпына келтіру үшін. Бұл бөлек репозиторий сервері, NAS немесе диск сақтау болуы мүмкін. Бірақ бұл жұмыс сервис орналасқан кәдімгі машина болмауы керек және сақтау үшін бөлек учёт жазбалары мен құқықтары болуы шарт.

Екінші көшірме «басқа типтегі тасымалдағыш» ретінде бірдей ақаулардан қорғауы тиіс. Егер негізгі бэкап дискілерде болса, екіншісін лентаға, ротациялы сыртқы дискілерге немесе басқа класс сақтау орнына (басқа контроллер, басқа микробағдарлама немесе басқа диск пул) жасауға болады. Идея — бір қате немесе ақау екі көшірмеде бірдей қайталанбауы.

Үшінші көшірме алаңнан тыс болуы керек. Бұл бұлт немесе екінші алаң болуы мүмкін. Мұндағы маңыздысы — қолжетімділік жағдайы: бөлек логиндер, минималды құқықтар, мүмкіндігінше өзгермейтін сақтау (қалпына келтіріп алу үшін жою немесе қайта жазуды шектейтін режим). Егер екінші алаң қолданылса, оның бірдей желіге, доменге және админ-учёттерге тәуелді еместігін тексеріңіз.

Көбінесе таңдау келесідей көрінеді:

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

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

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

Дұрыс құрылған 3-2-1 схема да, егер зиянкестер сақтау орнына қол жеткізсе немесе администратор кездейсоқ көшірмелер тізбегін өшірсе көмектеспейді. Бэкап қауіпсіздігі — бұл тек антивирус емес. Бұл қолжетімділікті басқару, кілттер және жоюдан қорғау.

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

• Бэкап оператор тапсырмаларды іске қосады және есептерді қарайды, бірақ сақтауды жоя алмайды.
• Сақтау администратор дискілік пулдарды басқарады, бірақ бэкап саясаттарын өзгертпейді.
• Аудитор немесе қауіпсіздік маманы журналдар мен есептерді оқиды, өзгерістер жасау құқығы жоқ.
• Жүйе иесі RPO/RTO және деректердің маңыздылығын растайды.
• Төтенше қолжетімділік бөлек процедурамен және бөлек учёт жазбасымен рәсімделеді.

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

Жоюдан қорғау үшін өзгермейтін көшірмелер (immutable) немесе WORM режимі қолданылсын: апталық және айлық нүктелерге, сондай-ақ екінші алаңға жіберілетін көшірмелерге. Бұл маңызды сервис үшін аса қажет: шифрлаушы әдетте ең бірінші резервтік көшірмелерді жоюға тырысады.

Бэкап үшін бөлек учёт жазбалары және көпфакторлы аутентификация міндетті. Күнделікті бэкап тапсырмалары үшін домендік администраторды пайдаланбаңыз.

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

3-2-1 енгізудің кезеңдері

3-2-1 схема тек қана деректердің маңыздылығы, көшірмелердің физикалық орналасуы және ақау қажеттілігін алдын ала білу арқылы жұмыс істейді.

Деректерді кластарға бөлуден бастаңыз. Мысалы: критикалық (бухгалтерия, 1С базасы, пошта), маңызды (өнім бөлімінің ортақ файлдары), екінші дәрежелі (архивтер, ескі жобалар). Әр класс үшін жиілік пен рұқсат етілген дерек жоғалту мөлшерін анықтаңыз: базалар үшін — әр сағат сайын, ортақ папкалар үшін — тәулігіне бір рет болуы мүмкін.

Содан кейін жоспарды анық қадамдарға бөліңіз:

• Қай бұрында қандай деректер көшірілетінін және жиілігін анықтаңыз (БД, виртуалды машиналар, файлдық шарлар, басшылардың ноутбуктері) және әр класқа қанша рет жасалатынын.
• Кестені және көшірме түрлерін орнатыңыз: күнделікті инкременталдар, апталық толықтар, айлық архивтер (қажет болса бөлек ережелермен).
• 3-2-1-ді сақтау орындары бойынша енгізіңіз: бірінші көшірме жүйеге жақын, екінші — басқа тасымалдағышта, үшінші — сыртта.
• Сапаны бақылауды енгізіңіз: бүтіндікті тексеру, автоматты есептер және қателер туралы хабарламалар, сонда бэкап бірнеше апта бойы байқалмай қалмайды.
• Retention пен жауапкершілікті бекітіңіз: сақтау мерзімі, ротация (не қайсысы қашан жойылады), және қысқа қалпына келтіру нұсқаулығы (кім істейді, қай жерде көшірме, қандай парольдер немесе кілттер қажет, әрекет тәртібі).

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

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

Сақтау саясаттары: жиілік, тереңдік, ротация

Сақтау саясаты үш сұраққа жауап береді: қанша жиі көшірмелер жасалатындығы, қанша уақытқа дейін артқа оралуға болатыны және ескі көшірмелер қашан жойылатыны. Олай болмаған жағдайда 3-2-1 «бэкап папкасына» айналып, орын таусылып немесе қажетті нұсқа табылмай қалады.

Маңыздылықтан бастаңыз. Жұмысқа тікелей әсер ететін жүйелер (пошта, 1С, науқастар базасы, сатылым файлы) үшін көшірмелер жиі жасалып, ұзағырақ сақталуы тиіс. Архивтер үшін сирек көшірме және ұзақ сақтау жеткілікті.

Қанша қалпына келтіру нүктесі керек

Дерек типіне қарай құрамды таңдаңыз. Құжаттар үшін бір файлды қалпына келтіру қажет болуы мүмкін. Виртуалды машиналар үшін — тез толық оралу. Мәліметтер қорын сенімді қалпына келтіру үшін толық бэкап пен журналдар немесе инкремент қолданған дұрыс.

Жоба жетекшілеріне оңай түсіндіретін негізгі схема:

• күнделікті: жұмыс деректері үшін жылдам инкременталдар/дифф;
• апталық: негізгі жүйелер үшін толық бэкап;
• айлық: «айлық шоты» ұзақ сақтау үшін.

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

Ротация: не жойылады, не ұзақ сақталады

Ротацияның мақсаты — бірнеше айдан кейін орынға жетіп қалмау. Қарапайым қағида: соңғы 14–30 күнге көп нүктелер, 8–12 аптаға орташа нүктелер, және тек заң немесе есеп үшін қажет болған жағдайда 12–36 айға ұзақ нүктелер.

Деректер өсімін алдын ала жоспарлаңыз. Төрт айда бір рет қараңыз: қанша терабайт қосылды, бэкап терезелері ұлғайды ма, локалдық сақтау және екінші алаңда орын жеткілікті ме. Серверлер мен СХД алғанда бэкап үшін бос орындарды «науқанмен» емес, өсімді ескеріп алыңыз.

Қате жиі кездесетін себептер және неге бэкаптар қалпына келмейді

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

Көбіне қалпына келтіруді бұзатын қателіктер:

• Көшірме бастапқы деректерге жақын сақталады: сол серверде, сол СХД-де немесе сол виртуалды инфрақұрылымда. Өрт немесе шифрлаушы жұмыс деректерді де, бэкапты да бірден жоя алады.
• Сырттағы көшірме тек қағазда бар: шын мәнінде жоқ немесе аптасына бір рет ғана шығарылады, ал бизнес бір күн ішінде қалпына келтіруді күтеді. Репликацияның кешігуі RPO талаптарына сай келмейді.
• Бэкап қателері ешкім бақыламайды: тапсырмалар «жұмыста» көрсетіледі, бірақ логтар қызыл, хабарламалар өшірілген, хаттар оқылмайды.
• Қайта қалпына келтіру үшін қажетті нәрселер сақталмаған: файлдар сақталған, бірақ мәліметтер қорлары, қолданба конфигурациялары, сервис учёттары, лицензиялар, сертификаттар және шифрлау кілттері ұмытылған. Деректер қалпына келтірілгенімен, жүйе жұмысқа тұрмайды.
• Шифрлау қосылған, бірақ кілттер басқарылмайды: кілттер барлыққа қолжетімді жерде немесе бір адамның ғана «басында». Кілт жоғалса — файлдар пайдасыз болады.

Тағы бір мәселе — ешкім нақты қалпына келтіру тәртібін немесе шығын уақытын білмейді. Қалпына келтіру кезінде команда ең соңғы көшірмені тауып, не бірінші алатынын (AD, базалар, файл ресурстары), парольдер қайда екенін және орын жеткілікті ме екенін білмейді.

Зрелдік белгісі — қысқа қалпына келтіру нұсқаулығы бар және «сервер қазір іске қосылмаса, алғашқы 30 минутта не істейміз?» деген сұраққа анық жауап бар.

Қалпына келтіру тесттерін жүйелі өткізу: қалай жасау және не жазу

Резервтік көшірмелер тек сол кезде ғана мәнге ие — егер олардан шын мәнінде қалпына келтіре алсаңыз. Сондықтан қалпына келтіру тесті жүйелі және алдын ала жоспарлы болуы тиіс, кездейсоқ «апат болғанда» емес. 3-2-1 болғанмен, ақылға сай минимум — айына бір рет маңызды сервистің тесті (мысалы, бухгалтерия, пошта немесе файл хранилище).

Екі деңгейлі тест: жылдам және толық

Алғашқыда жеңілінен бастаңыз, бірақ тұрақты түрде жасаңыз. Содан кейін күрделі тексерістер қосыңыз.

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

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

Сәттілік өлшемі және не жазу керек

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

Нәтижелерді келесі түрде тіркеңіз:

• қадамдар тізімі және нақты өткен уақыт (RTO-пен салыстыру);
• қолданылған қалпына келтіру нүктесі және деректер көлемі (RPO тексеру);
• бэкап жүйесінің логтары және шыққан қателер;
• қорытынды және тапсырмалар: не түзетілуі керек, жауапты кім және мерзім.

Практикалық мысал: шағын ұйымда 3-2-1 қалай көрінеді

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

Мақсаттар ережені анықтайды. Құжаттар үшін RPO 24 сағат (күн ішіндегі өзгерістерді жоғалту қабылданатын). Есеп жүйесінің базасы үшін RPO 4 сағат (бұдан артық болса қабылдау және төлемдерді қолмен қалпына келтіру керек болады). Қалпына келтіру уақыты ретінде құжаттарды 2–3 сағат ішінде, базаны 1–2 сағат ішінде көтеру деп белгілейді.

Содан кейін 3-2-1-ді геройлық емес түрде жинайды:

• Көшірме 1 (жұмыс): деректер серверде.
• Көшірме 2 (локал): файлдар үшін күнделікті бэкап бөлек сақтау орнында, базалар — әр 4 сағат сайын.
• Көшірме 3 (сыртта): тәулігіне бір рет көшірме жіберу (екінші офис немесе қорғалған бұлт). Сонымен қатар аптасына бір рет — бөлек тасымалдағышқа архив.

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

Әрекеттер:

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

Нәтиже: базаны 1,5 сағатта, құжаттарды 3 сағатта қалпына келтірді, құжаттар бойынша жоғалту бір күнге сыяды. Апаттан кейін жетілдірулер енгізілді: бэкап үшін бөлек учёт жазбалары, ай сайынғы қалпына келтіру тесттері және сыртқы көшірме өзгермейтін режимде сақталатыны туралы ереже.

Чек-лист және келесі қадамдар

Жылдам тест: әр тармаққа «иә» деп жауап беріңіз.

1. Деректердің кемінде 3 көшірмесі бар (жұмыс көшірмесі қоса).
2. Көшірмелер кемінде 2 түрлі типтегі тасымалдағышта не платформаларда жатыр.
3. Бір көшірме алаңнан тыс сақталған.
4. Тек файлдар ғана емес, маңызды базалар, конфигурациялар, кілттер және лицензиялар да сақталады.
5. Әр жүйеге RPO және RTO анықталған.
6. Қателер туралы хабарламалар қосылған және оларды шынымен қарайды.
7. Бэкапқа қолжетімділіктер шектелген және күнделікті учет жазбалардан бөлек.
8. Көшірмелер шифрланған, кілттер бөлек сақталады.
9. Жоюға қарсы қорғау бар (өзгермейтіндік немесе кем дегенде бөлек құқықтар).
10. Соңғы айда қалпына келтіру тесттері жүргізілді және нәтижелері тіркелді.

Егер көп нәрсе «жоқ» болса — кішкентайдан бастап жоспар бойынша жүріңіз.

Не істеуге болады 1 күнде: жүйелер мен деректер тізімін жасаңыз (алдын ала не құтқарылатынын), бэкап иесін және оның ауыстырушы адамын тағайындаңыз, тапсырма сәтсіздігі туралы хабарламаларды қосыңыз және сақтау толған кезде ескерту орнатыңыз, 3–5 ең маңызды сервистің минималды RPO/RTO-ларын анықтаңыз, және бір файл мен бір папканың пробалық қалпына келтіруін оқшауланған машинада орындаңыз.

1–2 аптада не істеуге болады: бөлек сыртқы көшірме орнатып, жеке қолжетімділіктерді енгізу; қалпына келтіру тесттерін кестелеу (аптасына бір сервис); «1 беттік нұсқауды» жазу (қайда көшірмелер, кім бастайды қалпына келтіруді, қайда қоңырау шалуға болады); бүтіндік бақылауды және есептерді қосу; «бәрі бұзылса» сценарийін тексеру: домен жоғалту, шифрлаушы, диск массивінің істен шығуы.

Интегратор қажет болуы мүмкін, егер жүйелер мен филиалдар көп болса, сәйкестік пен аудит талаптары болса немесе IT уақыты жетпесе.

Егер инфрақұрылым бойынша көмек керек болса, GSE.kz (gse.kz) репозиторий серверін, қалпына келтіру алаңын, сақтау таңдауын және қолдауды ұйымдастыруда көмектесе алады, сонда бэкап бір адамға тәуелді болмайды.