Резервтік көшіруді көбіне бір рет баптап қою жеткілікті болатын міндет деп қабылдайды. Әкімші тапсырма жасайды, каталогты көрсетеді, кестені белгілейді және бағдарламаның сәтті аяқталғанын хабарлағанына көз жеткізеді.
Осыдан кейін жүйе жылдар бойы қосымша назарсыз жұмыс істей беруі мүмкін. Бірақ дәл апат болған сәтте кейіннен түзету мүмкін емес қателер анықталады.
Көшірмелер ақаулы дискіге сақталуы, бүлінген дерекқорды қамтуы, жұққан серверлермен бір желіде орналасуы немесе компанияның ең маңызды құжаттарын мүлдем қамтымауы мүмкін.
Негізгі деректер қолжетімсіз болып қалған кезде ғана салдары байқалатын резервтік көшірудегі жеті кең таралған қатені қарастырайық.
Резервтік көшіру тапсырмасының сәтті аяқталуы ұйымның деректерді қалпына келтіріп, жұмысын жалғастыра алатынына әлі кепілдік бермейді.
Жүйенің сенімділігі жасалған архивтер санымен емес, олардың өзектілігімен, қорғалуымен және қалпына келтіру мүмкіндігінің нақты тексерілгенімен анықталады.
№1 қате. RAID, синхрондау және снапшоттарды толыққанды резервтік көшіру деп есептеу
Бұл корпоративтік деректерді сақтауды ұйымдастыру кезінде ең жиі кездесетін қателердің бірі.
Компания бірнеше дискісі бар NAS орнатып, RAID баптайды да, енді файлдар қауіпсіз деп ойлайды.
Алайда RAID ең алдымен қолжетімділік міндеттерін және деңгейіне қарай белгілі бір диск саны істен шыққан кездегі тұрақтылықты шешеді. Ол тәуелсіз резервтік көшірмелерді алмастырмайды.
Неліктен RAID backup емес
Файлдық серверде RAID 5 массивіне біріктірілген төрт жинақтауыш бар делік.
Бір диск істен шықса, басқа ақаулар болмаса, массив әдетте жұмысын жалғастыра алады.
Бірақ RAID құжатты кездейсоқ жоюдан, дерекқорды қате өзгертуден, файлдарды зиянды шифрлаудан немесе құрылғының толық жоғалуынан қорғамайды.
Пайдаланушы маңызды каталогты жойса, бұл өзгеріс жұмыс істеп тұрған массивте де бірден орын алады.
Егер шифрлаушы сервердегі файлдарға қол жеткізсе, RAID олардың шифрлануына кедергі болмайды.
Синхрондау да әрдайым көмектеспейді
Тағы бір кең таралған схема — жұмыс қалтасын басқа компьютермен, NAS-пен немесе бұлттық қоймамен синхрондау.
Синхрондау бірнеше құрылғыдағы файлдардың өзекті күйін сақтау үшін ыңғайлы.
Бірақ екіжақты синхрондау бапталған болса, құжатты қате жою немесе оның бүлінуі басқа құрылғыларға да таралуы мүмкін.
Мұндай жағдайда қалпына келтіру мүмкіндігі нұсқалар тарихының, себеттің және басқа қорғау механизмдерінің болуына байланысты.
Ал файлдық жүйе снапшоттары ше?
Снапшоттар, яғни snapshots, кездейсоқ жоюдан немесе деректерді қажетсіз өзгертуден кейін қалпына келтіруді айтарлықтай жылдамдата алады.
Бірақ сол физикалық құрылғыда орналасқан снапшоттар құрылғымен бірге жоғалуы мүмкін.
Сондықтан жергілікті snapshots-ты жалғыз резервтік көшіру тәсілі ретінде емес, қосымша қорғау деңгейі ретінде қолданған дұрыс.
| Технология | Негізгі міндеті | Нені ескеру қажет |
|---|---|---|
| RAID | Дискілердің белгілі бір ақауларында деректердің қолжетімділігін сақтау | Жоюдан, шифрлаудан және бүкіл құрылғының жоғалуынан қорғамайды |
| Синхрондау | Бірнеше құрылғыда файлдардың өзекті күйін сақтау | Қателер мен жою әрекеттері синхрондалатын көшірмелерге таралуы мүмкін |
| Жергілікті snapshots | Сақталған күйге жылдам қайтару | Негізгі құрылғының сақталуына және қол жеткізу баптауларына тәуелді |
| Тәуелсіз резервтік көшірме | Қарастырылған дерек жоғалту сценарийлерінен кейін қалпына келтіру | Бақылауды, қорғауды, сақтауды және қалпына келтіруді тексеруді талап етеді |
Дискілерді айнаға көшіру өзгерістердің тәуелсіз тарихын жасамайды.
Жойылған файлдар, бүлінген деректер және шифрлаушының нәтижелері айнадағы екі жаққа да бірдей әсер етуі мүмкін.
№2 қате. Барлық резервтік көшірмелер бір тәуекел аймағында орналасқан
Шағын ұйымды елестетейік.
Жұмыс құжаттары серверде, ал резервтік көшірмелер автоматты түрде сол серверлік сөреде тұрған NAS-қа сақталады.
Кәдімгі жағдайда мұндай схема ыңғайлы көрінеді: жылдам жергілікті желі, көшіруге аз уақыт және архивтерге оңай қол жеткізу.
Бірақ елеулі инцидент кезінде негізгі сервер де, резервтік қойма да бір уақытта зардап шегуі мүмкін.
Қандай тәуекелдер туындайды
- Үй-жайдағы өрт немесе су басу.
- Жабдықтың ұрлануы.
- Электрмен жабдықтаудағы ірі апат.
- Әкімшілік есептік жазбалардың бұзылуы.
- Қолжетімді желілік ресурстардың шифрлануы.
- Деректер мен резервтік архивтерді қате жою.
Резервтік көшіру сервері, негізгі сервер және NAS кең өкілеттіктері бар бір есептік жазбамен әкімшілендірілсе, жағдай әсіресе қауіпті.
Бұл есептік жазба бұзылса, шабуылдаушы барлық компонентке бірден қол жеткізуі ықтимал.
3-2-1 қағидасы
Кең таралған тәсілдердің бірі — 3-2-1 резервтік көшіру стратегиясы.
Бұл жұмыс данасын қоса алғанда деректердің үш данасын, тасымалдағыштың немесе сақтау ортасының екі түрлі түрін және кемінде бір дананы басқа физикалық жерде орналастыруды көздейді.
Алайда 3-2-1 схемасының өзі шифрлаушылардан қорғануға кепілдік бермейді.
Егер барлық резервтік көшірмеге бірдей әкімшілік өкілеттік арқылы қол жеткізілсе, олар бәрібір осал болуы мүмкін.
Резервтік көшірмелерді оқшаулау
Маңызды деректер үшін қосымша қорғауды қарастырған жөн: ажыратылатын тасымалдағыштар, оқшауланған қойма немесе өзгертілмейтін резервтік көшірмелер.
Өзгертілмейтіндік, немесе immutability, белгіленген мерзім ішінде сақталған резервтік деректерді өзгерту және жою мүмкіндігін шектейді.
Бұл механизмнің тиімділігі нақты іске асыруға, сақтау баптауларына және әкімшілік өкілеттіктердің қорғалуына байланысты.
Бұлттық қойма пайдаланылғанда басқару есептік жазбаларын қосымша қорғап, көпфакторлы аутентификацияны қосып, жою құқықтарын бақылау қажет.
Оқшауланған көшірмелер және шабуылдан кейін қалпына келтіру жөніндегі ұсыныстар CISA-ның шифрлаушыларға қарсы нұсқаулығында берілген.
№3 қате. Компанияға шын мәнінде қажет нәрсенің бәрі көшірілмейді
Кейде резервтік көшіру формалды түрде дұрыс бапталғанымен, тапсырмаларға маңызды деректердің аз ғана бөлігі енгізіледі.
Мысалы, ортақ файлдық сервер сақталады, бірақ резервтік көшірмелерге бухгалтерлік база, корпоративтік пошта, желілік жабдық конфигурациялары немесе жеке қызметкерлердің компьютерлерінде сақталатын жобалар кірмейді.
Апаттан кейін файлдық қалтаны қалпына келтіруге болатыны, ал компанияның толық жұмысын қалпына келтіру мүмкін еместігі анықталады.
Алдымен маңызды жүйелердің тізімін жасаңыз
Backup баптамас бұрын күнделікті қызмет үшін қандай деректер мен қолданбалар қажет екенін анықтау керек.
| Жүйе | Нені қарастыру маңызды |
|---|---|
| 1С | Ақпараттық базалар, сыртқы файлдар, өңдеулер және қажетті баптаулар |
| Файлдық сервер | Жұмыс құжаттары, ортақ каталогтар және қол жеткізу құқықтары туралы қажетті мәліметтер |
| Виртуалды машиналар | Келісілген күйде қалпына келтіру мүмкіндігі бар жүйелер, қолданбалар және тәуелді деректер |
| Корпоративтік пошта | Пошта деректері, сақтау ережелері және қарастырылған қалпына келтіру тәсілі |
| NAS | Жұмыс каталогтары, конфигурация және қажетті резервтік нұсқалар |
| Желілік жабдық | Маршрутизаторлар, коммутаторлар және басқа маңызды құрылғылар конфигурациялары |
| Сайттар және веб-қолданбалар | Файлдар, дерекқорлар, конфигурациялар және қажетті қалпына келтіру кілттері |
Негізгі серверлерден тыс файлдарды ұмытпаңыз
Директор құжаттарды ноутбугінде, жобалаушы ірі жұмыс файлдарын қосымша SSD-де, ал бухгалтер 1С сыртқы өңдеулерін жергілікті каталогта сақтауы мүмкін.
Егер мұндай деректер орталықтандырылған сақтау схемасына енгізілмесе, олар резервтік көшірмеге мүлдем түспеуі мүмкін.
Не орталықтандырылған сақтауды ұйымдастыру, не маңызды жұмыс станцияларын бөлек резервтеуді қарастыру қажет.
Бұлттық деректер де назарды қажет етеді
Бұлттық пошта немесе онлайн-қойма пайдалану ұйымды өзінің қалпына келтіру стратегиясын анықтау қажеттілігінен босатпайды.
Провайдер қандай қалпына келтіру механизмдерін ұсынатынын, жойылған деректер қанша уақыт қолжетімді болатынын және компанияға қандай қосымша көшірмелер қажет екенін зерттеу керек.
Кілттер мен құпиясөздер — бөлек мәселе
Елеулі апаттан кейін файлдарды ғана емес, шифрланған архивтерге, виртуалды машиналарға және әкімшілік жүйелерге қол жеткізуді де қалпына келтіру қажет болуы мүмкін.
Сондықтан қалпына келтіру рәсімдері қажетті шифрлау кілттерін, төтенше қол жеткізу есептік жазбаларын және техникалық құжаттаманы қауіпсіз сақтауды ескеруі тиіс.
Сонымен бірге құпия деректер қарапайым резервтік архивтердің жанындағы жалпыға қолжетімді қалтада сақталмауы керек.
№4 қате. Көшіру жұмыс істеп тұрған дерекқорларды ескермей орындалады
Қарапайым файлдық көшіру белсенді жұмыс істеп тұрған ақпараттық жүйелерге әрдайым жарамайды.
Мысалы, резервтік көшірме жасалып жатқан кезде дерекқор тікелей өзгеруі мүмкін.
Егер көшіру келісілген күйді қамтамасыз етпесе, нәтиже дұрыс қалпына келтіруге жарамсыз болып қалуы мүмкін.
1С үшін әсіресе маңызды
1С-ті резервтеу тәсілі ақпараттық базаның архитектурасына байланысты.
Файлдық нұсқада деректер 1Cv8.1CD файлында сақталады.
База каталогын әдеттегі тәсілмен көшіргенде белсенді қосылымдар мен деректерді өзгерту операциялары болмауын қамтамасыз ету қажет.
Платформада қарастырылған тағы бір тәсіл — тиісті нұсқа талаптарын сақтай отырып, ақпараттық базаны .dt файлына түсіру.
Клиент-сервер нұсқасы үшін қолданылатын дерекқорларды басқару жүйесінің штаттық резервтік көшіру құралдарын пайдалану ұсынылады.
Бұл компания Microsoft SQL Server немесе PostgreSQL қолданса, әсіресе маңызды.
Толығырақ: ақпараттық базаларды резервтік көшіру жөніндегі 1С әдістемелік ұсынымдары.
Егер ақпараттық база көшіру кезінде өзгерсе, алынған архив келісілмеген күйде болуы мүмкін.
Өз архитектураңызға арналған резервтеу тәсілін қолданыңыз және қалпына келтіруді тұрақты түрде тексеріңіз.
Виртуалды машиналарды резервтеу
Ұқсас мәселе жұмыс істеп тұрған виртуалды машиналарды резервтік көшіру кезінде де туындауы мүмкін.
Виртуалды машинада бір уақытта операциялық жүйе, қолданбалар сервері және белсенді жұмыс істейтін дерекқор болуы мүмкін.
Сондықтан виртуалды диск файлдарын жай ғана көшіруді автоматты түрде дұрыс резервтік көшірме деп санауға болмайды.
Гипервизор мен резервтік көшіру бағдарламасы қолдайтын келісілген көшірмелер жасау механизмдерін қолдану қажет.
Деректерді арнайы өңдеуді қажет ететін қолданбалар үшін application-aware backup немесе өндіруші қолдайтын басқа рәсімдерді қарастырған жөн.
Жүйенің іске қосылуын ғана тексермеңіз
Қалпына келтірілгеннен кейін виртуалды машина Windows-ты сәтті жүктеуі мүмкін, бірақ бұл оның ішіндегі базаның жұмыс істейтінін әлі дәлелдемейді.
Негізгі қолданбалы сервистерді, деректердің күйін және бақылау операцияларының орындалуын тексеру қажет.
№5 қате. Резервтік көшірмелер бар, бірақ керекті нұсқа әлдеқашан жойылған
Күнделікті backup болуы бірнеше күн немесе аптадан кейін ғана анықталатын қателерден қорғауға кепілдік бермейді.
Маңызды құжат дүйсенбі күні кездейсоқ өзгертілді делік.
Мәселе келесі айда ғана байқалды.
Егер жүйе соңғы бірнеше күнделікті көшірмені ғана сақтаса, құжаттың бастапқы нұсқасы сол уақытқа дейін жойылып кетуі мүмкін.
Қолданбадағы байқалмай қалған қате деректерді біртіндеп бүлдірсе немесе зиянды БҚ инцидент анықталғанға дейін инфрақұрылымда қалып қойса, дәл осындай жағдай болуы мүмкін.
Сақтау саясаты не үшін қажет
Резервтік көшірмелердің қанша нұсқасы және қандай кезеңге сақталуы керектігін алдын ала анықтау қажет.
Кесте мен сақтау мерзімдерін деректердің маңыздылығына, өзгеру жиілігіне, қойманың қолжетімді көлеміне және компания талаптарына қарай таңдау керек.
Кейбір жүйелер үшін күнделікті, апталық және айлық қалпына келтіру нүктелері қолданылуы мүмкін.
Бірақ барлық ұйымға бірдей жарайтын әмбебап көшірме саны жоқ.
Сақтау мерзімін көшіру жиілігімен шатастырмаңыз
Күнделікті көшіру жаңа қалпына келтіру нүктелерінің қаншалықты жиі жасалатынын анықтайды.
Сақтау саясаты олардың қанша уақыт қолжетімді болып қалатынын анықтайды.
Екі параметрді бірге баптау қажет.
Бос орынды бақылаңыз
Егер резервтік қойма толып қалса, жаңа тапсырмалар қатемен аяқталуы немесе жүйе белгіленген саясатқа сәйкес ескі нұсқаларды жоя бастауы мүмкін.
Сондықтан бастапқы деректердің өсуін, резервтеу жиілігін және нақты сақтау кезеңін ескере отырып, қажетті көлемді алдын ала есептеу маңызды.
Өзгертілмейтін көшірмелер үшін қорғалған нұсқалар белгіленген мерзім аяқталғанша орын алатынын бөлек ескеру керек.
№6 қате. Резервтік көшіруді ешкім бақыламайды
Автоматтандыру қажет, бірақ оның өзі backup-тың жұмыс қабілеттілігіне кепілдік бермейді.
Көбіне тапсырмалар бір рет бапталады да, кейін әкімші олардың нақты орындалуын тұрақты тексеруді тоқтатады.
Бірнеше айдан соң архивтер қойма толып қалғандықтан, есептік деректер өзгергендіктен немесе қосылу қатесінен бұрыннан жасалмай жүргені анықталуы мүмкін.
Қандай оқиғаларды бақылау қажет
- Резервтік көшіру тапсырмасы қатемен аяқталды.
- Жоспарланған тапсырма мүлдем іске қосылмады.
- Соңғы сәтті көшірме тым ескі.
- Жаңа көшірменің көлемі әдеттен тыс өзгерді.
- Орындалу уақыты едәуір артты.
- Қоймадағы бос орын таусылып келеді.
- Екінші көшірмені жеткізу мүмкін емес.
- Баптаулар немесе сақтау мерзімдері өзгерді.
- Архивтерді жоюға күмәнді әрекеттер пайда болды.
Неліктен бір жасыл мәртебе жеткіліксіз
Резервтік көшіру бағдарламасы сәтті аяқталды деп хабарлауы мүмкін, бірақ тапсырма құрамында бұрын қорғалған каталог енді жоқ болуы ықтимал.
Мысалы, әкімші дерекқорды басқа серверге көшірді, бірақ резервтелетін объектілер құрамын өзгертпеді.
Формалды түрде тапсырма жұмысын жалғастыра береді, алайда жаңа база қорғалмайды.
Сондықтан тапсырма нәтижесін ғана емес, резервтелетін ресурстардың ағымдағы тізімі нақты инфрақұрылымға сәйкес келетінін де бақылау қажет.
Хабарламалар жауапты қызметкерге келуі тиіс
Қате туралы хабарламалар бағдарламаның жергілікті журналында ғана қалып қоймауы керек.
Маңызды жүйелер үшін жауапты маманға хабарлау және әрекет ету тәртібін ұйымдастыру қажет.
Егер әкімші демалыста болса, резервтік жауапты адам қарастырылуы тиіс.
Нақты жасалып жатқан көшірмелер тізімін маңызды ақпараттық жүйелер тізімімен тұрақты салыстырып отырыңыз.
Сервер көшірілгеннен, каталог құрылымы өзгергеннен немесе жаңа қолданба орнатылғаннан кейін резервтік көшіру тапсырмаларын өзгерту қажет емес пе екенін тексеріңіз.
№7 қате. Қалпына келтіру ешқашан тексерілмеген
Ең жағымсыз қате әдетте негізгі сервер қолжетімсіз болған сәтте анықталады.
Резервтік архивтер бар, бірақ олардан жұмыс істейтін жүйені қалай қалпына келтіру керектігін ешкім білмейді.
Кейде архив бүлінгені, шифрлау құпиясөзі жоқ екені, қолданба дистрибутиві сақталмағаны немесе қалпына келтіру ұйым көтере алатын уақыттан әлдеқайда ұзаққа созылатыны анықталады.
Қалпына келтіруді тексеру деген не
Бұл резервтік көшірмелер каталогын жай ғана ашу емес.
Белгілі бір қалпына келтіру нүктесін таңдап, деректерді жоспарланған тестілік ортада өрістетіп, олардың пайдалануға жарамды екеніне көз жеткізу қажет.
Файлдық сервер үшін жекелеген құжаттарды күтілетін мазмұнымен қалпына келтіруді тексеруге болады.
1С үшін ақпараттық базаның бақылау көшірмесін қалпына келтіріп, оның ашылатынын және келісілген операцияларды орындайтынын тексеру керек.
Виртуалды инфрақұрылым үшін қалпына келтірілген жүйенің іске қосылуын және тәуелді сервистердің жұмысын тексеру қажет.
Қалпына келтіруді оқшауланған ортада тексеріңіз
Серверлер мен корпоративтік дерекқорларды тестілеу кезінде жұмыс істеп тұрған инфрақұрылыммен қақтығысты болдырмау маңызды.
Мысалы, сервердің тестілік көшірмесі жұмыс интеграцияларын кездейсоқ іске қоспауы, өндірістік жүйе деректерін өзгертпеуі немесе нақты электрондық құжаттарды жібере бастамауы тиіс.
Сондықтан елеулі тексерулер үшін оқшауланған тестілік желі мен алдын ала дайындалған сценарийлерді қолданған дұрыс.
Қалпына келтірудің әртүрлі түрлерін тексеріңіз
- Кездейсоқ жойылған жеке файлды қалпына келтіру.
- Құжаттың алдыңғы нұсқасын қалпына келтіру.
- 1С ақпараттық базасын қалпына келтіру.
- Виртуалды машинаны қалпына келтіру.
- Негізгі NAS қолжетімсіз болғанда деректерді қалпына келтіру.
- Негізгі сервер толық жоғалғаннан кейін қалпына келтіру.
Тексеру жиілігін жүйелердің маңыздылығы мен рұқсат етілетін тоқтап тұру уақытына қарай таңдау керек.
Инфрақұрылымда елеулі өзгерістер болғаннан кейін әсер еткен қалпына келтіру рәсімдерін қайта тексеру қажет.
Жоспарлы сынақтар үшін оқшауланған ортаны, тестілік объектілерді және алдын ала келісілген сценарийлерді пайдаланыңыз.
Резервтік көшірмелерді тексеру үшін жұмыс істеп тұрған бухгалтерлік базаны жою немесе жұмыс жоспарынсыз маңызды серверді өшіру дұрыс емес.
RPO және RTO: компания қанша деректі жоғалта алады және қалпына келтіруді қанша күте алады
Резервтік көшіруді жобалағанда екі негізгі көрсеткішті анықтау пайдалы: RPO және RTO.
RPO — уақыт бойынша рұқсат етілетін дерек жоғалту
Recovery Point Objective апаттан кейін деректерді қай уақыт сәтіне дейін қалпына келтіру мүмкін болуы керектігін көрсетеді.
Мысалы, бухгалтерлік база үшін RPO төрт сағат деп белгіленсе, резервтеу жүйесі қажетті қалпына келтіру нүктесін қамтамасыз ететіндей жобалануы тиіс.
Бірақ төрт сағаттық кестені жай ғана белгілеу RPO орындалатынына кепілдік бермейді: тапсырма қателерін, көшірме жасау уақытын және технологияның басқа ерекшеліктерін ескеру қажет.
RTO — рұқсат етілетін қалпына келтіру уақыты
Recovery Time Objective жүйе қолжетімсіз болғаннан кейін оның жұмысын қандай мерзімде қалпына келтіру қажет екенін анықтайды.
Мысалы, маңызды база үшін RTO сегіз сағат болып келісілсе, резервтік көшіру, жабдық және қалпына келтіру рәсімдері бұл міндетті орындауға мүмкіндік беруі тиіс.
Бұл ретте архивті жүктеу уақытын ғана емес, жабдықты дайындауды, қажетті сервистерді қалпына келтіруді және жұмыс қабілеттілігін тексеруді де ескеру қажет.
| Көрсеткіш | Қандай сұраққа жауап береді |
|---|---|
| RPO | Деректердің соңғы өзгерістерінің қанша бөлігін жоғалтуға болады? |
| RTO | Жүйе қанша уақыт қолжетімсіз болып қала алады? |
RPO және RTO мәндері бизнес-процестер иелерімен бірге анықталады.
Олар компанияның практикалық қажеттіліктерін ескеруі тиіс және әкімші оларды тек қолда бар жабдыққа сүйеніп белгілемеуі керек.
Терминдер мен тәсілдер қалпына келтіруді жоспарлау жөніндегі NIST нұсқаулығында қарастырылған.
Шағын компаниядағы резервтік көшіру қалай көрінуі мүмкін
Windows Server, қызметкерлердің желілік қалтасы, 1С бухгалтерлік базасы және резервтік көшірмелерді сақтауға арналған NAS пайдаланылатын шартты ұйымды қарастырайық.
Мүмкін архитектуралардың бірі бірнеше қорғау деңгейін қамтуы мүмкін.
Бірінші деңгей: жұмыс жүйелерін резервтеу
Файлдарды, виртуалды машиналарды және ақпараттық базаларды резервтік көшіру бапталады.
Әр жүйе үшін деректердің келісілген күйін қамтамасыз ететін қолдау көрсетілетін технология таңдалады.
Екінші деңгей: жергілікті қойма
Резервтік көшірмелер қарапайым қателер мен аппараттық ақаулардан кейін деректерді салыстырмалы түрде жылдам қалпына келтіруге мүмкіндік беретін арнайы қоймада орналасады.
Пайдаланушылардың архивтерге қол жеткізуі шектеледі.
Үшінші деңгей: оқшауланған көшірме
Қосымша дана негізгі тәуекел аймағынан тыс орналастырылып, рұқсатсыз өзгерту мен жоюдан қорғалады.
Бұл бөлек алаң, лайықты бұлттық қойма немесе жоба қарастырған басқа нұсқа болуы мүмкін.
Төртінші деңгей: бақылау және қалпына келтіру
Жауапты маман тапсырмалардың орындалуын, тасымалдағыштардың күйін және көшірмелердің өзектілігін бақылайды.
Келісілген кесте бойынша маңызды жүйелерді қалпына келтіру тексерулері жүргізіледі.
Нақты схема ұйым бюджетіне, деректер көлеміне, қауіпсіздік талаптарына және келісілген RPO/RTO көрсеткіштеріне байланысты.
Резервтік көшірмелер ұзақ уақыт тексерілмесе не істеу керек
Егер backup бұрыннан бапталғанымен, оның жұмыс қабілеттілігіне сенім болмаса, бүкіл жүйені бірден ауыстыру міндетті емес.
Алдымен қолданыстағы инфрақұрылымды тексеріп, нақты тәуекелдерді анықтау қажет.
1-кезең. Түгендеу
Маңызды серверлердің, дерекқорлардың, жұмыс каталогтарының және басқа ақпараттық ресурстардың тізімін жасаңыз.
Бұл тізімді қолданыстағы резервтік көшіру тапсырмаларымен салыстырыңыз.
2-кезең. Қоймаларды тексеру
Көшірмелер физикалық тұрғыда қайда орналасқанын, оларға кім қол жеткізе алатынын және негізгі жабдық жоғалғанда не болатынын анықтаңыз.
3-кезең. Өзектілікті тексеру
Әр маңызды жүйенің соңғы сәтті көшірмесінің күнін анықтаңыз.
Тапсырма қателерін, қолжетімді сақтау көлемін және архивтерді жою саясатын тексеріңіз.
4-кезең. Таңдамалы қалпына келтіру
Бірнеше маңызды файлды және бір немесе бірнеше маңызды жүйені тиісті тестілік ортада қалпына келтіріңіз.
Нәтижелерді және нақты қалпына келтіру уақытын құжаттаңыз.
5-кезең. Анықталған мәселелерді жою
Тексеру нәтижелері бойынша кестені, резервтеу аясын, сақтау саясатын және көшірмелерді оқшаулау схемасын түзетіңіз.
Чек-лист: резервтік көшірудегі жеті қате
RAID резервтік көшірудің орнына қолданылмайды
Синхрондау жалғыз қорғау тәсілі емес
Маңызды деректер үшін нұсқалар тарихы қарастырылған
Файлдық жүйе снапшоттары тәуелсіз көшірмелермен толықтырылған
Маңызды жүйелер мен деректердің тізімі бар
Барлық маңызды жүйелер резервтік көшіруге енгізілген
Жұмыс станцияларында орналасқан құжаттар тексерілген
Дерекқорлардан тыс сақталатын файлдар мен баптаулар ескерілген
1С файлдық базалары үшін келісілген көшіру қамтамасыз етілген
Серверлік базалар үшін ДҚБЖ-ның тиісті механизмдері пайдаланылады
Виртуалды машиналарды резервтеу жұмыс істеп тұрған қолданбаларды ескереді
Негізгі деректер мен барлық көшірмелер бір құрылғыда орналаспаған
Негізгі тәуекел аймағынан тыс бөлек көшірме қарастырылған
Маңызды деректер үшін офлайн немесе өзгертілмейтін көшірмелер бар
Резервтік қоймаларға қол жеткізу шектелген
Резервтік ортаның әкімшілік өкілеттіктері қорғалған
Көшірмелер жасау кестесі бапталған
Бірнеше нұсқаны сақтау саясаты бапталған
Резервтік қойманың бос орны бақыланады
Тапсырма қателері туралы хабарламалар бар
Соңғы сәтті көшірменің күні бақыланады
Инфрақұрылым өзгергенде backup тапсырмалары жаңартылады
Негізгі және резервтік жауапты тұлға тағайындалған
Файлдарды қалпына келтіру тексеріледі
Маңызды дерекқорларды қалпына келтіру тексеріледі
Қажетті кілттер мен қалпына келтіру қолжетімділігі тексерілген
Негізгі инфрақұрылым істен шықса да қалпына келтіру жоспары қолжетімді
RPO және RTO анықталған және келісілген
Нақты қалпына келтіру уақыты сынақтармен тексерілген
Тексеру нәтижелері құжатталады
Бұл бағыттарды интерактивті форматта тексергіңіз келсе, резервтік көшіруге дайындық тексерісін пайдаланыңыз. Нәтижесінде ол жалпы дайындық деңгейін көрсетіп, бірінші кезекте назар аударуды қажет ететін тармақтарды бөлек көрсетеді.
Резервтік көшіру туралы жиі қойылатын сұрақтар
RAID 5 немесе RAID 6 бар бір NAS жеткілікті ме?
Жоқ. RAID қойманың белгілі бір диск ақауларына төзімділігін арттыруы мүмкін, бірақ тәуелсіз тасымалдағыштардағы немесе бөлек ортадағы резервтік көшірмелерді алмастырмайды.
Файлдар бұлтпен синхрондалса, backup қажет пе?
Қолданылатын сервис нақты қандай қорғау ұсынатынын тексеру керек: нұсқалар тарихы, жойылған файлдарды сақтау мерзімі және есептік жазба бұзылғаннан кейін қалпына келтіру мүмкіндігі.
Егер бұл механизмдер компания талаптарына сәйкес келмесе, қосымша резервтік көшіру қажет болады.
Барлық көшірмені бір сыртқы USB-дискіде сақтауға бола ма?
Мұндай жинақтауыш қорғаудың бір элементі болуы мүмкін, бірақ жалғыз құрылғы бәрібір жалғыз істен шығу нүктесі болып қалады.
Маңызды деректер үшін қосымша даналар мен тасымалдағышты жоғалтудан қорғауды қарастыру қажет.
Қалпына келтіруді қаншалықты жиі тексеру керек?
Жиілік жүйенің маңыздылығына, қолжетімділік талаптарына және инфрақұрылым өзгерістерінің жиілігіне байланысты.
Дерек жоғалту немесе ұзақ тоқтап қалу салдары неғұрлым ауыр болса, практикалық сынақтарды тұрақты өткізу соғұрлым маңызды.
Резервтік көшірмелерді шифрлау керек пе?
Құпия және дербес деректерді қамтитын архивтер үшін шифрлау маңызды қорғау механизмі болып табылады.
Бірақ қалпына келтіру кілттерін қауіпсіз сақтауды бөлек ұйымдастыру қажет.
Кілт жоғалса, толық жарамды архивтің өзі пайдасыз болып қалуы мүмкін.
Резервтік көшіру жүйесіне аудит қашан қажет
Ұйым жақында серверлерді көшірсе, сақтау жүйесін өзгертсе, жаңа 1С базасын енгізсе немесе аппараттық ақауларға тап болса, тексеру әсіресе өзекті.
Сондай-ақ маңызды деректер соңғы рет қашан сәтті қалпына келтірілгенін ешкім растай алмаса, аудит қажет.
Резервтік көшірмелердің техникалық күйін ғана емес, ұйымдастырушылық жағын да бағалау пайдалы: бақылауға кім жауап береді, хабарламалар кімге келеді, нұсқаулық қайда сақталады және қалпына келтіру туралы шешімді кім қабылдайды.
WEB-LABS-тың корпоративтік деректерді қорғау тәсілі туралы толығырақ «Деректерді қорғау және резервтік көшіру» бетінде.
Қорытынды
Резервтік көшірудегі ең қауіпті қате — архивтердің бар болуын деректердің қорғалғанына жеткілікті дәлел деп санау.
RAID, синхрондау және жергілікті снапшоттар пайдалы міндеттерді шешеді, бірақ толыққанды backup жүйесін алмастырмайды.
Сенімді қалпына келтіру үшін қандай деректер маңызды екенін алдын ала анықтап, келісілген көшірмелер жасап, бірнеше нұсқаны сақтап, резервтік даналарды жұмыс инфрақұрылымымен ортақ тәуекелдерден қорғау қажет.
Тапсырмалардың орындалуын бақылау және қалпына келтірудің практикалық сынақтарын тұрақты өткізу де кем емес маңызды.
WEB-LABS ұйымдарға қолданыстағы резервтік көшіру жүйелерін тексеруге, серверлерді, жұмыс деректерін және ақпараттық базаларды қорғауды баптауға, сондай-ақ техникалық ақаулар мен ақпараттық қауіпсіздік инциденттерінен кейінгі қалпына келтіру рәсімдерін әзірлеуге және тексеруге көмектеседі.