Кәдімгі жағдайды елестетейік: компания серверінде күн сайын 1С деректер базасының резервтік көшірмесі жасалады. Файл қажетті бумада пайда болады, көлемі қалыпты көрінеді, ал тапсырма сәтті аяқталғанын хабарлайды.
Бір қарағанда бәрі дұрыс. Бірақ ертең негізгі база қолжетімсіз болып қалса, деректерді дәл осы файлдан қалпына келтіре аламыз ба?
Бұл сұраққа жауап беру үшін бөлек тексеру қажет. Резервтік көшірменің болуы мен жүйені толық қалпына келтіру мүмкіндігі — екі бөлек нәрсе.
Резервтік көшірудің мақсаты — .bak файлдарын жинау емес, деректерді қалпына келтіріп, ақпараттық жүйені қайта іске қосу мүмкіндігін қамтамасыз ету.
Неліктен сәтті жасалған бэкап барлық мәселені шешпейді?
Дұрыс жасалған резервтік көшірменің өзі апат кезінде пайдасыз болуы мүмкін: ол негізгі деректермен бірге істен шыққан дискіде сақталса, файлға қол жеткізу мүмкін болмаса немесе қалпына келтіру тәртібін ешкім білмесе.
Басқа жағдай да кездеседі: резервтік көшірме техникалық жағынан оқылады, бірақ бастапқы деректердің өзінде қателер болған немесе қолданбаның жұмыс істеуі үшін қосымша файлдар, баптаулар мен компоненттер қажет.
Сондықтан файлдың жасалғанын ғана емес, ақпараттық жүйені қалпына келтірудің бүкіл тізбегін тексеру маңызды.
SQL Server жүйесінде нені тексеру керек?
Егер 1С ақпараттық базасы Microsoft SQL Server жүйесінде жұмыс істесе, әкімші резервтік көшіру және нәтижесін бақылау үшін SQL Server-дің кірістірілген құралдарын пайдалана алады.
Резервтік көшіру тапсырмасы сәтті аяқталады
Файл күтілген каталогта жасалады
Көшірме көлемінде түсініксіз ауытқулар жоқ
Сақтау орнында жеткілікті бос орын бар
Көшірме файлын оқуға болады
SQL Server тексеруі резервтік көшірме пішімінде қате таппайды
Мерзімді түрде тестілік қалпына келтіру жүргізіледі
RESTORE VERIFYONLY командасы резервтік көшірменің кейбір қасиеттерін, соның ішінде оның оқылуын және толықтығын тексеруге мүмкіндік береді. Көшірме бақылау қосындыларымен жасалса, қосымша WITH CHECKSUM параметрін қолдануға болады.
Алайда VERIFYONLY нақты қалпына келтіруді алмастырмайды. Бұл — маңызды шектеу: тексерудің сәтті аяқталуы 1С жүйесінің апаттан кейін дұрыс жұмыс істейтінін әлі растамайды.
Тестілік қалпына келтіру не үшін қажет?
Резервтік көшірмені жұмыс істеп тұрған ақпараттық жүйеге тиіспей, бөлек тестілік базаға мерзімді түрде қалпына келтіріп отырған пайдалы.
Қалпына келтірілгеннен кейін базаның күйін ДББЖ құралдарымен, оған қосылу мүмкіндігін, 1С-тің іске қосылуын және қажетті операциялардың орындалуын тексереді. Тексерулердің нақты тізімі конфигурацияға, интеграцияларға және ұйым талаптарына байланысты.
Осылайша, тәжірибе жасауға уақыт қалмайтын нақты апат басталмай тұрып-ақ ақауларды анықтауға болады.
Неліктен көрші дискідегі көшірме әрқашан құтқармайды?
Егер негізгі база сервердің D: дискісінде, ал резервтік көшірмелер сол сервердің F: дискісінде болса, бір жинақтауыштың істен шығуы екі көшірмені бірден жоймауы мүмкін. Бірақ басқа тәуекелдер сақталады: сервердің толық істен шығуы, зиянды бағдарламалар, әкімші қателері, жабдықтың ұрлануы немесе жүйеге қолжетімділіктің жоғалуы.
Сондықтан маңызды көшірмелерді негізгі серверден бөлек жерде де сақтау керек. Көптеген ұйым үшін 3-2-1 қағидасы пайдалы бағдар бола алады: деректердің үш данасы, тасымалдағыштың екі түрі және негізгі алаңнан тыс бір көшірме.
Бұл ретте көшірмелер сақталатын орын файлдарды рұқсатсыз өзгерту мен жоюдан қорғалуы тиіс.
Резервтік көшірмені қаншалықты жиі жасау керек?
Барлығына бірдей жарайтын кесте жоқ. Компания күн сайын ондаған операция жүргізсе, тіпті бірнеше сағаттық ақпараттың жоғалуы елеулі шығын әкелуі мүмкін. Ал деректері сирек өзгеретін база үшін ұзағырақ аралық қолайлы болуы ықтимал.
Екі көрсеткішті анықтау керек: ақау кезінде ұйым қанша деректі жоғалтуға дайын және жүйені қалпына келтіруге қанша уақыт жұмсай алады. Резервтік көшіру жиілігі, SQL Server сұлбасы мен қажетті ресурстар осы талаптарға байланысты таңдалады.
Резервтік көшіруді артық күрделендірмей қалай ұйымдастыруға болады?
WEB-LABS компанияларға резервтік көшіру тапсырмаларын баптауға, олардың орындалуын бақылауға, көшірмелерді сақтауды ұйымдастыруға және қалпына келтіруді техникалық тексеруге көмектеседі.
Бір реттік баптаудан гөрі жүйелі бақылау маңызды: бірнеше ай дұрыс жұмыс істеген тапсырма да қолжетімділік құқықтары өзгергеннен, диск толғаннан немесе инфрақұрылымға басқа өзгерістер енгізілгеннен кейін орындалмай қалуы мүмкін.
Қолданыстағы көшіру тәртібін тексеруден бастаңыз: файлдар қайда сақталады, қанша уақыт сақталады және қалпына келтіру сынағы жүргізілді ме? Инфрақұрылымыңызды талқылау үшін WEB-LABS компаниясына хабарласыңыз.