Блог | ONELAB веб-студиясы
+7 (700) 700 71 77 info@oneit.kz

Резервтік көшіру жүйесі қандай болуы керек

25.02.2017

Парашютшылар әртүрлі болады.

Біреулері парашют спорты мектебіне барып, желге қарсы қарап, екі аяғымен дұрыс қонады.

Басқалары да солай секіреді, бірақ олардың парашюті жыртық. Ал үшіншілері тіпті парашютсіз секіреді. Олар неге үміттенеді? Мүмкін, ұшу кезінде арқаларынан қанат өсіп шығады немесе оларды айдаһар не алып бүркіт қағып алады деп ойлайтын шығар.

Қызығы, сайттың резервтік көшіру жүйесі (ол да парашют сияқты) туралы әңгіме болғанда, сайт иелері сол үшінші топқа айналады: резервтік көшіру жүйесі не «бірдеңе бар сияқты», не мүлде жоқ. Ал статистика мейірімсіз: компаниялардың 25–45%-ы деректердің ірі көлемде жоғалуынан кейін жабылады (cmitsolutions.com).

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

Біздің ойымызша, резервтік көшіру ережелері екеу-ақ. Өте қарапайым.

Ереже №1. Резервтік көшіру жүйесі көпдеңгейлі болуы керек.

Ереже №2. Жоба неғұрлым күрделі болса, резервтік көшіру жүйесі де соғұрлым күрделі болуы қажет.

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

Неліктен бұлай жасауға болмайды? Үш өмірлік оқиға айтып өтейік.

Бірінші оқиға — қайғылы

Біздің клиенттердің бірі – құрылыс компаниясы – сайт пен хостинг тіркелген поштаға кіру паролін жоғалтқан. Жаңа пошта ашып, сайттағы баптауларды өзгертті, бірақ хостингті ұмытып кетті. Бір күні сайт істен шықты. Мәселені тек бір айдан кейін байқады. Белгілі болғандай, ескі поштаға хостингтен қызметті төлеу туралы ескертулер келіп тұрған, бірақ еш реакция болмағандықтан, сайт өшіріліп, 30 күннен кейін резервтік көшірмелерімен бірге жойылған. Басқа көшірмелер болмағандықтан, сайтты қалпына келтіру мүмкін болмады.

Екінші оқиға — сабақ боларлық

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

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

Үшінші оқиға — мұңды

2014 жылы белгілі бір ресейлік деректер орталығында апат болды. Серверлерді қалпына келтірген соң, файл қоймасы мен резервтік көшірмелердің бәрі жоғалып кеткені анықталды. Шағымданудың мәні болмады.

Құтқарған – 1С-Битрикс бұлтында сақталған деректер. Онда ескі дерекқор, әзірлеушінің файлдары мен dev-сервер коды болған. Сайтты сөзбе-сөз бөліктерден жинап, 2–3 күнде қалпына келтірді. Осы уақыт ішінде интернет-дүкен жұмыс істемей, табыс пен клиенттердің сенімін жоғалтты.

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

Резервтік көшіру жүйесі қандай болуы керек? Бұл сіздің жобаңызға байланысты. «Аспро» компаниясында біз әдетте мынадай ұсыныстар береміз.

Егер сізде корпоративтік сайт болса

Қос деңгейлі резервтік жүйе қолданылады: 2–3 резервтік көшірме серверде, тағы 2–3 — 1С-Битрикс бұлтында сақталады.

Бэкап жасау жиілігі: сайтты қаншалықты жиі жаңартатыныңызға қарай күн сайын немесе 2–3 күнде бір рет.

Егер сізде интернет-дүкен болса

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

Ұсыныстар:

  1. 1С-Битрикс құралдары арқылы күнделікті резервтік көшіруді баптап, архивті бұлтқа жіберу.

  2. Хостинг платформасы арқылы резервтік көшіруді баптау және оны бөлек сақтау қоймасына (мысалы, қашықтағы FTP-серверге) жазу.

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

  4. Апат жағдайында қалпына келтіру жоспарын және нұсқаулық дайындау. Бұл нұсқаулықтың жұмысын ай сайын тексеру өте маңызды. Ол үшін тестілік платформада көшірмені қалпына келтіру жеткілікті.

Ірі жобалар үшін

«Ірі» деп біз күніне 50–100 тапсырыс қабылдайтын және айына 1 миллион рубльден астам айналымы бар интернет-дүкендерді айтамыз. Жалпы ережелер — алдыңғы бөлімдегідей. Бірақ қосымша шаралар қажет.

Қосымша не қажет:

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

  2. Дереққор серверінің таралған жүйесі және бір сәттік репликациясы.

  3. Дайын резервтік сервер — әзірлеуші жағында немесе тапсырыс берушінің аумағында. Бұл шұғыл жағдайда трафикті қайта бағыттап, сайттың істен шығуын болдырмайды. Резервтік кластер қолдануды ұсынамыз.

Emergency kit

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

Кестені мына форматта жүктей аласыз: .docx немесе .pdf.

Возврат к списку