Бэкап-репозиторий сервері: CPU, RAM, дискілер және қалпына келтіру (restore)

Неліктен тек backup емес, restore есептеу керек

Backup пен restore жылдамдығы әртүрлі. Backup — «қоқысты қаптарға жинау» сияқты: деректерді біртіндеп, кезектермен, түнде және қайталаулармен жазуға болады. Restore — «барлығын дәл қазір орнына қайтару», көбіне қысым астында: жүйе түсті, пайдаланушылар күтіп отыр, бизнес тоқтады.

Дедупликация мен қысу арқылы орын үнемдеу жақсы, бірақ қалпына келтіру баяу болса ол пайдасы аз. Сіз жай ғана бэкап сақтау орнын сатып алмайсыз — сіз ақаудан кейін сервисті жылдам жандандыру мүмкіндігін сатып аласыз.

Жоспарлау нақты болуы үшін «терабайттар» мен «бэкап терезесі» ғана емес, өлшенетін мақсаттар талқыланады:

• RTO: сервис қанша минут немесе сағат ішінде жұмысқа келуі тиіс.
• Бір тапсырма бойынша restore жылдамдығы (МБ/с, ГБ/мин) және жалпы.\n- Параллель түрде қанша қалпына келтіру жүргізілуі керек (мысалы, 1, 5 немесе 20).\n- Ең маңызды түйіннің (мәліметтер базасы, домен контроллері) қалпына келтіру қанша уақыт алады.

Практикада restore дербір уақытта бірнеше себептер бойынша бәсеңдейді: дискілерге IOPS жетпейді, CPU деректерді ашуға үлгермейді, RAM кэшті ұстамайды, желі тар шеме болады, ал сақтау форматы қосымша шығындар қосады (ұзын инкремент шеңберлері, шифрлау, тұтастық тексерулері).

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

Дедупликация мен қысу серверге қалай жүктеме салады

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

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

Есептеулер нақты қай жерде жүргізіледі

Алдын ала түсіну маңызды: өңдеу қайда жүретінін және ресурстар кімге салмақ түсіретінін:

• Дереккөзде (агент/клиент). Жүк қорғалатын серверге түседі, желі арқылы аз дерек ұшады.
• Проксиде. Дереккөздер «тыныс алады», бірақ проксиге күшті CPU мен жеткілікті RAM керек.
• Репозиторийде. Инфрақұрылым қарапайымрақ, бірақ сервер қабылдау, өңдеу және қалпына келтіру кезінде деректерді беру жүгін көтеруі тиіс.

Неліктен backup жылдамдап, restore баяулауы мүмкін

Дедуп және қысу көбінесе backup-ты жылдамдатады: желіге және дискке аз жазылады. Бірақ restore баяулауы ықтимал, себебі деректер фрагменттерден «жинақты» түрде ашылып, тексерілулері тиіс. Егер CPU, RAM (метадеректер кэші) немесе дискілердің кездейсоқ оқу қабілеті шектеулі болса, қалпына келтіру үзілістермен жүретін болады.

Мысал: 200 ПК офисі күнделікті ұқсас профильдер мен құжаттарды сақтайды. Бэкап ықшам болады. Бірақ апатта ондаған жұмыс орнын сағат ішінде қалпына келтіру қажет болса, репозиторийге бір уақытта көп ағынды ашып, жинау керек болады. Әлсіз процессор немесе баяу массив дәл сол кезде restore-ты тежейді.

Деректер түрі де маңызды. Мәліметтер базалары мен офис файлдары жиі жақсы қысылады. Виртуал дискылар әртүрлі. Бейне мен суреттер әдетте алдын ала сығылған күйде: пайда аз, ал есептеу жүктемесі қалады.

Дедупликация, қысу және қалпына келтіруге CPU таңдау

Репозиторийдегі CPU тек «қабылдап жазу» үшін ғана жауапты емес. Ол дедупликация үшін хэштер есептейді, деректерді сығады, кейде шифрлайды, ал қалпына келтіруде керісінше жұмыс істейді: блоктарды табады, ашып, ағымды жинап, желіге жібереді. Әлсіз процессорда дискілер мен желі жеткілікті жүктелмегендей көрінгенмен, restore баяу болады.

Бір ядро частотасы ойдағыдан маңызды

Бірнеше жағдайларда бір ядро өнімділігі шешуші болады. Бір үлкен ВМ немесе база бойынша қалпына келтіру жиі тізбекті операцияларға ұшырайды (іздеу, жинау, ашу). Осы кезде жоғары сағаттық жиілік пен заманауи архитектура көп ядродан да артық әсер береді.

Көп ядро бірнеше тапсырма бірдей уақытта жүріп жатқанда пайдалы: бірнеше restore, түнгі backup, синтетикалық full, тұтастық тексерістері. Сонда жүктеме параллельденіп, қосымша ядролар нақты жылдамдық қосады.

Практикалық ереже: егер RTO апаттан кейінгі көпжақты қалпына келтірілуге бағытталса, CPU-ға запас қалдырыңыз, тек «түнгі терезеге» ғана есептемеңіз. Әйтпесе апат күнінде сіз процессорға тірелесіз, дискілер жақсы болса да.

Шифрлау және қалпына келтіру шың уақыты

Шифрлау CPU талаптарын айтарлықтай жоғарылатады, әсіресе дедупликация мен қысумен бірге қолданса. Аппараттық үдетуді және ашу плюс расшифровка кезінде нақты өнімділікті тексеріңіз.

Күнделікті бір файлды қалпына келтіру жылдам болады. Ал апат күнінде 20 ВМ-ды көтеру керек болса, әрқайсысы параллель оқуды, ашуды және жинауды талап етеді. Егер CPU 90–100% шамасында болса, жылдамдық «пила тәрізді» болады және RTO бұзылады.

Сатып алудан бұрын қысқа жүгізу пайдалы: 3–5 restore тапсырмасын бір уақытта қосып, фондық операциялармен бірге жүргізіңіз. Графиктер бойынша CPU қай жерде есептегіштің таусылғанын көрсетеді.

Репозиторийге қанша RAM қажет және неге ол restore-қа әсер етеді

RAM репозиторийге жай ғана қосымша емес. Оларда файл жүйесінің кэштері, дедупликация кестелері мен индекстері, параллель ағындар үшін оқу буферлері сақталады. Қалпына келтіру кезінде дәл осы кэш сервердің деректерді беруді тұғызуын немесе дискіден үнемі кішкене оқулар жасауын анықтайды.

RAM жетпесе, restore «қосқыштай» болады: метадеректер мен блоктар кэштелмейді, жүйе оларды қайта-қайта дискіден оқиды. Дедупликацияланған репозиторийлерде бұл айқын байқалады: бір виртуалды диск көптеген кішкене бөліктерден жиналуы мүмкін, және кэш болмаса әр бөлік жеке I/O операциясына айналады.

Жадты бағалау барысында белсенді жиынтық пен параллельділікті ескеріңіз:

• Белсенді жиынтық: қай қалпына келтіру нүктелерін жиі оқисыз (мысалы, соңғы 7–14 күн).\n- Параллельдік: шипалы уақытта қанша бір уақытта restore керек.\n- Дедупликация деңгейі: блок деңгейінде неғұрлым «жұқа» болса, RAM талаптары жоғары болады.\n- ОС пен сервистерге арналған запас: жадыны нөлге дейін жоспарламаңыз, әйтпесе кэш үнемі шығарылады.

SSD-кеш кездейсоқ оқуларда көмектеседі, бірақ RAM-ды алмастырмайды. Ол кэш «сызықтық тыс» болғанда үдеу береді, бірақ индекстер мен метадеректер жадыға сыймаса мәселені шешпейді. Көп жағдайда RAM қосу дискілерге тағы HDD қосудан гөрі restore-ты тегістейді.

Памятьпен шектелгендігінің белгілері: қалпына келтіру жылдамдығының күрт құлауы, оқу кешігулерінің өсуі және белсенді своп қолдану, тіпті CPU бос болса да. Мысалы, екі ВМ қалпына келтіріп жатқанда жылдамдық тербеледі, үшіншісін қосқанда почти нөлге түседі.

Дискілер, RAID және контроллер: тез репозиторийді қалай жинау керек

Бэкап үшін сақтау таңдауында негізгі қате — тек жазу жылдамдығын есептеу. Backup жиі үлкен тізбекті блоктармен өтеді және үлкен HDD-ларда жақсы жұмыс істейді. Ал restore көбінесе кіші операциялар мен кідірістерге тіреледі, әсіресе дедупликация, көптеген файлдар немесе бірнеше ВМ параллель қалпына келтіріліп жатқанда.

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

HDD vs SSD: қай жерде үнемдеуге болады, қай жерде болмайды

Латенттік пен IOPS-қа назар аударыңыз, тек ГБ/с-ке емес. Тізбекті backup үшін HDD «қалыпты» болуы мүмкін, бірақ дедупликацияланған репозиторийден restore кезінде оқу кездейсоқ сипатта болады.

Жұмысшы компромисс: метадеректер мен активті жиын үшін SSD, көлем үшін HDD.

RAID, контроллер және предсказуемті restore

RAID-ты оқу және тұрақты кешігуге қарай таңдаңыз:

• RAID10 әдетте ең предсказуемті қалпына келтіруді береді, бірақ сыйымдылық бойынша қымбат.\n- RAID6 HDD-лар үшін көлем жағынан ыңғайлы, бірақ қалпына келтіру мен ребилд кезінде жылдамдық айтарлықтай төмендеуі мүмкін.

Контроллер бойынша маңыздысы — «ең қымбат емес», керісінше сәйкес режим. Бағдарламалық сақтау үшін көбіне HBA (IT режимі) және сенімді дискілер жақсырақ. Аппараттық RAID қолдансаңыз, қорғалған кэш жазуда көмектеседі, бірақ restore көбіне оқу мен кешігулерге тіреледі.

Мысал: RAID6 HDD массивіндегі репозиторий және күтпеген 10 ВМ-ды бірден көтеру керек болуы. Түнгі backup тез болғанымен, күндізгі restore кездейсоқ оқулар мен массив деградациясы салдарынан «тысықшалықпен» жүреді. Метадеректер мен «ыстық» бэкаптар үшін кішкене SSD-слой көбіне қосымша HDD шкафын қосудан гөрі үлкен әсер береді.

Практикада нақты не қалпына келтіруді баяулатады

Restore көбіне backup-тан күрделірек. Жазу кезінде деректер ұзын ағыммен келеді және дискілерге жақсы орналаса береді. Қалпына келтіруде оқу хаотикалық сипатқа ие: жүйе көптеген кішкентай блоктарды тартады, уақыт кешігулерге кетеді.

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

Дедупликация мен қысу да схеманы өзгертеді: деректер «уникалды» үзінділерге бөлінеді. Restore кезінде бұл көптеген кішкентай оқулар мен CPU-ның қосымша ашу және жинау жұмысын білдіреді.

Параллель қалпына келтірулер мәселені күшейтеді: бірнеше тапсырма бірдей дискілерді, кэш пен CPU ядроларын бөліседі. Уақыт сызықтық емес, секірістермен өседі, әсіресе баяу диск массивтерінде.

Егер сізге прогнозделетін RTO маңызды және restore жиі болса, кейде рөлдерді бөлу көмектеседі: бір түйін деректерді сақтайды, екіншісі «ауыр» өңдеуді (дедупликация, қысу, жинау) орындайды.

Желінің әсері: каналға тірелмейтіндей қалай жасау керек

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

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

10/25/40/100G таңдау қанша терабайтты қандай уақытта қайтару керектігіне байланысты. Мысалы, 8 ТБ-ты 4 сағатта қалпына келтіру ≈ 4,4 Гбит/с таза деректер. Шығындарды ескере отырып, запаспен 10G немесе 25G қарастыру дұрыс, 1G-ға сенбеу ұсынылады.

Егер апат терезесінде көп ВМ мен базаны көтерсеңіз, бэкап және өндірістік трафик үшін бөлек желілер бір-біріне әсер етпеуіне көмектеседі.

RTO-дан CPU, RAM және дискілерге дейінгі қадамдық есеп

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

Алдымен 2–3 нақты restore сценарийін сипаттаңыз. Әдетте: бір критикалық ВМ, мәліметтер базасын қалпына келтіру және массовый инцидент (мысалы, бірнеше ВМ-ды шифрлаушыдан кейін). Әрбір сценарий үшін RTO белгілеңіз және оны қажет жылдамдыққа аударыңыз. Мысалы, 2 ТБ-ты 4 сағатта қайтару ≈ 140 МБ/с пайдалы деректер. Шығындарды ескеріп 200+ МБ/с нысана қойыңыз.

Кейін параллельділікті бағалаңыз. Егер 4 ВМ бірден қалпына келтірілетін болса, жылдамдық пен IOPS талаптары жиынтық болып есептеледі, бір тапсырмаға емес.

Одан кейін логика қарапайым: дедупликация, қысу, шифрлау және ашуға CPU есептеп шығыңыз (запаспен), дискілерді өткізу қабілеті мен IOPS-қа сай таңдаңыз, контроллер мен массив параметрлерін тексеріңіз.

Финалдық қадам — пробный restore. Типтік ВМ мен ауыр файлдар жинағын қалпына келтіріп, нақты МБ/с, CPU жүктемесін және диск кезегін өлшеңіз. Егер CPU шекті көрсеткіште немесе диск кезегі үнемі үлкен болса, запас кеткен.

Мысал сценарий: сыйымдылық vs жылдам restore

Мысал: ұйымда 60 ВМ және 10 физикалық сервер бар. Күнделікті өсім ≈ 2 ТБ, толық бэкаптар аптасына бір рет, бэкап терезесі — 10 сағат түнде. Мақсат: 2 критикалық жүйені (мысалы AD мен есеп жүйесінің базасы) 2 сағатта қалпына келтіру, қалғанын тәулікте көтеру.

Тек backup-қа қарап жиі көп HDD таңдап, тыныштанады. Бірақ restore жазудан гөрі «қолайсыз» түрде оқылады: кішкентай блоктармен, параллельді, жұмыс уақытында. Сондықтан репозиторийді таңдау оқуға бағытталуы тиіс.

Қысу орын үнемдейді, бірақ жазуда және қалпына келтіруде CPU-ға жүк қосады. Шифрлау одан да көп CPU талап етеді және сіздің 2 сағаттық мақсатты тезірек «жеп қоюы» мүмкін.

Егер сыйымдылық басты мақсат болса, үлкен HDD массивін (көбіне RAID6) алады және массовый қалпына келтірудің баяу болуын қабылдайды. Ал restore-қа баса назар қажет болса, гибрид таңдау тиімді: көлем үшін HDD + метадеректер мен актив үшін SSD, кеш үшін көбірек RAM және күшті CPU.

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

Репозиторий серверін таңдаудағы жиі қателіктер

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

Тағы бір тұзақ — «көбірек диск = жылдам». Үлкен HDD массиві IOPS пен кешігулер есептелмесе, әсіресе дедупликация мен параллель restore кезінде кездейсоқ оқуларға тіреледі.

CPU да жиі төмен бағаланады. Дедупликация, қысу және шифрлау бір уақытта процессорды «жеп» қоя алады, және диск массиві жақсы болса да қалпына келтіру баяулайды.

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

Сатып алудан және restore тестінен бұрын қысқа чеклист

Сатып алуға дейін маңыздыны белгілеңіз:

• RTO және приоритеттер: не бірінші көтерілуі тиіс, не күте алады.\n- Ш worst күнде бір уақытта қанша restore жүруі тиіс.\n- Бір тапсырмаға және жиынтыққа қажетті қалпына келтіру жылдамдығы.

Одан кейін пилотта «тар шектерді» тексеріңіз (дедупликация, қысу, шифрлауды қосыңыз): CPU, RAM (swap жоқ па), оқу кешігулері мен диск кезегі, жұмыс уақытындағы желінің нақты өткізу қабілеті.

Ең пайдалы тест — жұмыс жағдайына ұқсас уақытта жүктеменің астында пробный restore жүргізу.

Келесі қадамдар: пилот, өлшемдер және провайдер таңдау

Бастапқы деректерден бастаңыз. Бір сервер backup-та жақсы нәтиже көрсетіп, егер RTO белгіленбесе және нақты restore өлшенбесе қалпына келтіруде сәтсіз болуы мүмкін.

Барлық енгізу деректерін бір бетке жинаңыз: қорғалатын деректер көлемі мен өсімі, жүктеме түрлері (VM, базалар, файлдар), мақсатты RTO және критикалық сервистер тізімі, бэкап терезесі, сайт шектеулері және 1–3 жылдық өсу жоспары. Содан кейін пилот жоспарлаңыз: жазуды ғана емес, әр түрлі қалпына келтіру нұсқаларын (бір үлкен ВМ, көп шағын файлдар, басқа сайтқа қалпына келтіру) тестілеңіз.

Жергілікті өндірушіден және интегратордан аппараттық шешім таңдасаңыз, RTO және параллельдік сандарыңызға сәйкес конфигурация сұраңыз. Мысалы, GSE.kz (gse.kz) өндірісші және жүйелік интегратор ретінде қалпына келтіру сценарийлеріне сай сервер конфигурациясын жинап, 24/7 қолдау көрсете алады.

Пилот нәтижелерін цифрлармен бекітіңіз (restore жылдамдығы, сервис дайын болу уақыты, ресурстардың жүктемесі) және осыға сүйене отырып конфигурацияны бекітіңіз: серверлер, диск подсистема, желі және бэкап ПО-мен интеграция.