Stateful‑қызметтерге арналған Kubernetes сақтық көшірмесі: таңдау және қалпына келтіру тесттері

Stateful‑қызметтер үшін Kubernetes сақтық көшірмесі не үшін қажет

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

Шынайы инцидентте көбіне бір нәрсе ғана бұзылмайды. Көбінесе бір уақытта зардап шегеді PersistentVolume (немесе диск деректері), манифесттер (Deployment/StatefulSet, Service, Ingress, RBAC), Secrets пен ConfigMap және айналадағы конфигурациялар: StorageClass, рұқсат саясаттары, желі параметрлері. Тек PV‑ды қалпына келтіріп, қосылу үшін қажет секреттер немесе құқықтар жоқ болса, қосымша жүктелмейді, дегенмен деректер физикалық тұрғыда сақталған болады.

Stateful‑қызметтерді қайтару реті мен консистенттілігі себебінен қиынырақ. PostgreSQL репликациямен немесе Kafka сияқты жүйелерде қайтару кезінде қандай түйіндер бірінші жүктелетіні, томдар қалай қосылатыны және split‑brain болмауы маңызды. Сондықтан бэкап — жай файл көшірмесі емес, сенімді, болжамды күйге оралатын әдіс.

Пайдалы түрде екі сценарийді ажыратыңыз:

• Подтың жоғалуы көбінесе қайта жасалады және пайдаланушы байқамауы мүмкін.
• Деректерді немесе кластер метадеректерін жоғалту — ешқандай бэкап болмаса, көбіне қолмен қалпына келтіру мен қайтымсыз жоғалтулар қаупін тудырады.

Kubernetes сақтық көшірмелері типтік проблемаларды жабады: кездейсоқ namespace жою, қате helm upgrade, бұзылған құқықтар, стейт бар нодтың жоғалуы, томның бүлінуі, басқа кластерге миграция. Дегенмен бәрінен сақтап қалмайды: егер қосымша ішінде зиянды бағдарламамен шифрланған деректер бэкапқа түссе немесе бэкаптар қалпына келтірумен тексерілмесе, сенімсіз болады. Сақтық көшірме тек қалпына келтіру жоспары мен регулярлы тексерулермен мағыналы.

Не сақтау керек: деректер, конфигурациялар және тәуелділіктер

Stateful‑қызметтерге арналған Kubernetes бэкапы көбіне тек “том көшірмесін алу” дегенге келмейді. Қалыпты қалпына келтіру үшін деректермен бірге оларды қалай жалғағаны, рұқсаттар және бірнеше байқалмайтын тәуелділіктер де керек.

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

Практикада үш қабатпен ойлану ыңғайлы:

• Namespace ішіндегі ресурстар (Deployments, StatefulSets, Services, Ingress, ConfigMaps).
• CRD және оларға қатысты ресурстар (мысалы, деректер базасының операторларының объектілері).
• Құқықтар мен қолжетімділік (ServiceAccounts, Roles/RoleBindings, кейде ClusterRole/ClusterRoleBinding).

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

PV бойынша бәрі сақтаудың түріне байланысты. Егер CSI‑снапшоттар болса, олар уақыт нүктесіне тез оралуға көмектеседі, бірақ көбіне бірдей storage‑та және жиі бір деректер орталығы шеңберінде шектеледі. Егер снапшоттар болмаса, қолданба деңгейінде бэкап (мысалы, дамптар) немесе сақтау жүйесінің мүмкіндіктеріне сүйену қажет.

Дерекқорлар үшін әдетте тәсілдерді біріктіру тиімді. Том снапшоты жылдам RTO береді, ал логикалық дамп (pg_dump, mysqldump) логикалық қателерден қорғайды. Мысалы: релиз алдында снапшот жасап, түнде логикалық дамп алып, оның шынымен қалпына келетінін тексерген дұрыс.

Сыртқы тәуелділіктерді ұмытпаңыз: сыртқы S3‑бакет, сыртқы БД, LDAP, лицензиялар, DNS жазбалары. Оларды Kubernetes құралы арқылы «бэкаптау» мүмкін емес, бірақ конфигурация мен қолжетімділік нүктелерін тіркеуге және сыртқы жүйелер үшін өз бэкап пен қалпына келтіру тестін ұйымдастыруға болады.

Стратегия талаптары: RPO, RTO және қалпына келтіру моделі

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

RPO (Recovery Point Objective) — қалпына келтіргенде деректер қаншалықты «жаңа» болуы тиіс. Мысалы, RPO 15 минут болса, ең жаман жағдайда соңғы 15 минуттағы өзгерістер жоғалады.

RTO (Recovery Time Objective) — қызмет қанша уақытқа қолжетімсіз бола алады. Мысалы, RTO 1 сағат болса, бір сағат ішінде сервис қайта жұмыс істеуі керек, тіпті шектеулі режимде болса да.

RPO мен RTO‑ны бизнес пен операция командаларымен талқылау керек: не ауыр — деректер жоғалуы ма әлде тоқтап тұру ма. Ішкі Git пен CI үшін көбіне RTO маңызды, ал төлем жүйелері үшін RPO өзекті.

Бэкап жиілігі мен түрі тікелей RPO‑ға байланысты. Толық бэкап белгілі бір нүктеге оралу береді, бірақ уақыт пен орын жағынан ауыр. Инкременталды сақтау орнын үнемдейді және күнделікті жылдамдықты арттырады, бірақ қалпына келтіруді қиындатады және тесттеуді талап етеді.

Құжаттарда минимум: әр критикалық сервис үшін мақсатты RPO/RTO, сақтық көшірме жиілігі мен сақтау мерзімі (retention), тесттер бойынша нақты қалпына келтіру уақыты және кім қандай сигналмен қалпына келтіруді бастайтыны көрсетілгені дұрыс.

Содан кейін қалпына келтіру моделі таңдалады. "Kubernetes деңгейінде бэкап" (ресурстар, манифесттер, Secrets, PVC метадеректері) сервисті тез қайта құруға көмектеседі, бірақ том ішіндегі деректер консистенттігін әрдайым қамтамасыз етпейді. Хранение деңгейінде бэкап (том снапшоттары, репликация) деректер мен кезектер үшін сенімдірек жол береді, бірақ Kubernetes объектілерімен және жүктеу ретін түсінуді талап етеді.

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

Velero, Kasten, Portworx: мәні бойынша айырмашылықтар

Velero, Kasten K10 және Portworx PX‑Backup ұқсас мәселені шешеді (Kubernetes бэкап және қалпына келтіру), бірақ тәсілдері әртүрлі. Әр өнімнің «ядросын» түсінсеңіз, таңдау жеңілдейді.

Velero жиі базалық бастапқы шешім ретінде таңдалады. Ол Kubernetes ресурстарын (манифесттер, namespaces, CRD‑ларды дұрыс бапталған жағдайда) жақсы шығарады, ал томдармен жұмыс сақтау ортасына байланысты. Снапшоттар мен нақты сторадждар үшін плагиндер (CSI, объектілік сақтау провайдері) қажет. Бұл икемді және лицензия жағынан арзан болуы мүмкін, бірақ баптау және қолдау талап етеді.

Kasten K10 enterprise‑бағдарланған: саясаттар, кестелер, есептер, қосымша қарай көрініс, рөлдік модель, ыңғайлы қалпына келтіру сценарийлері. Оны аудит, сәйкестік және командаларға тапсырмаларды делегелеу маңызды жерлерде таңдайды. Лицензия бағасы жоғары болуы мүмкін, бірақ «бөлшектерден жинау» азаяды.

Portworx PX‑Backup сақтау қабатымен тығыз байланысқан кезде ыңғайлы: консистентті снапшоттар, томдарды тасымалдау, кластерлер арасында миграция. Ол әсіресе Portworx қолданған жағдайда логикалық. Егер Portworx жоқ болса, тағы бір платформа қосып, оны басқару қажет болады.

Функционалдан бөлек, меншік құнына назар аударыңыз: лицензия, операциялық шығындар (жаңарту, плагиндер, қалпына келтіру қатесін талдау), интеграциялар мен бақылау талаптары (саясаттар, RBAC, аудит).

On‑prem инфрақұрылымда ашық процесс пен қолдауды бағалаңыз: жүйені таңдаумен қатар тестті қалпына келтіру және бүкіл тізбекті қолдау ресурстарын жоспарлаңыз.

Құралды қалай таңдау: маркетингсіз критерийлер

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

Ең алдымен storage‑қабатпен үйлесімділікті дәлелдеңіз. Егер сіз RTO‑ны тез снапшот арқылы қамтамасыз етуді жоспарласаңыз, сіздің StorageClass‑тарыңыз үшін CSI snapshot қолдау керек (және ол нақты кластерде жұмыс істеуі тиіс, құжатта жазылғандай емес). Снапшот мүмкін болмаса, альтернатива ретінде файл көшіру, sidecar‑агенттер немесе сторадж интеграциясы шешілуі керек. Бұл тікелей RPO және тоқтау уақытына әсер етеді.

Келесіде саясаттар мен қалпына келтіру қалай ұйымдастырылғанын қараңыз. Namespace және меткалар бойынша ережелер қою, артық нәрсені шығаруды болдырмау, томдарды келісімді қалпына келтіру және басқа namespace‑қа (тест үшін) немесе басқа кластерге (DR және миграция) қалпына келтіру мүмкін болуы тиіс. Диагностика да маңызды: не сақталған, не өткідірілген және неге — бәрі анықталуы керек.

Қауіпсіздікті тексеріңіз. Қатаң талаптары бар ұйымдар үшін (мемлекеттік сектор, қаржы, медицина) бэкаптарды шифрлау, рөлдер бойынша шектелу, операцияларды аудиттеу және әрекеттердің тарихы — өте маңызды.

Ақыры, құрал дежур жұмысына сай келуі керек. Қалпына келтіру процедурасы дежур операторға түсінікті және түнгі уақытта болжамды болуы — жақсы белгі: минимум қолмен қадамдар, қалыпты хабарландырулар және оқу‑тәжірибе ретінде үнемі restore жасау мүмкіндігі.

Күмәніңіз болса, бір критикалық stateful‑қызметте қысқа пилот жасаңыз: бірдей сценарий, бірдей метрикалар. Көбінесе осы жеткілікті болып, шешім айқындалады.

Резервті сақтау орнын таңдау: S3‑үйлесімді, NFS, on‑prem және оффсайт

Сақтау орны кейде құралдан да маңызды. Сол бэкап кластерді, адам қатесін немесе алаңша проблемасын өткере ме — сол маңызды. Бірдей бэкап сенімді немесе пайдасыз болуы сақтау орнына байланысты.

Объектілік сақтау (S3‑үйлесімді) тұрақты бэкаптар үшін жиі тиімді: масштабталуы оңай, версиялау және immutable саясаттары үшін ыңғайлы. Файлы сақтау (NFS) жергілікті жылдам қолжетімділік пен қарапайым интеграция үшін ыңғайлы, бірақ ол бір нүктелік ақау болуы мүмкін, әсіресе кластермен жақын орналасса.

3‑2‑1 ережесін Kubernetes контекстінде былай қабылдауға болады: үш көшірме (күнделікті, апталық, айлық), екі түрлі носитель (объект және файл немесе архив) және бір көшірме алаңнан тыс жерде (басқа ЦОД немесе провайдер).

Тіркелгілер бөлек болуы тиіс. Резервтік шотты бойдағы жұмыс шотынан бөліп, оған минималды құқық беріңіз. Dev/stage/prod тіркелгілерін бөлу жақсы тәжірибе, әйтпесе тест скрипті продтың бэкаптарын өшіруі мүмкін.

Сақтау мерзімдері алдын ала келісілген болсын: күнделікті қанша сақтау керек, апталық және жылдық архивтер керек пе. Версиялау мен жоюға тыйым (immutability) қосыңыз, әйтпесе бір қате rm бәрін жояды.

On‑prem жағдайда бэкап репозиторийі кластермен бірдей стендте болмауы тиіс: ол басқа стеллажда, басқа қорек желісінде болуы керек. Егер екінші алаң бар болса, репликация оны ең ауыр сценарийден қорғайды: "кластер мен бэкап бірдей жерде кетті".

Қалай жүріп шығару керек: жұмыс істейтін бэкап стратегиясын жинау

Инвентардан бастаңыз. Критикалық namespace‑тар мен стейт бар сервисдерді тізіп шығыңыз: деректер базалары, кезектер, файлдық сақтау және оларға бекітілген PV‑лар. Қайсы деректер сыртқы жүйелерден қалпына келетінін және қайсысы тек кластерде екенін белгілеп алыңыз.

Содан кейін ережелерді бекітіңіз. Политика үш сұраққа жауап беруі керек: қаншалықты жиі бэкап жасаймыз, қанша уақыт сақтаймыз, не шығарылған. Конфигурацияларды жиі сақтап, ауыр томдарды сирек, бірақ ұзақ сақтау тәсілін қабылдауға болады. Кэштер, уақытша директориялар және тесттік namespace‑тарды шығару тізімін жасаңыз.

Көп жағдайда қарапайым схема жеткілікті: критикалық namespace‑тардағы PV мен ресурстардың күнделікті бэкапы, конфигурацияларды жиірек (томдарсыз) сақтау, анық ретенция (мысалы, 7 күндік күнделікті, 4 апталық, 6 айлық) және нақты шығарулар.

Осыдан кейін қолжетімділікті орнатыңыз. Бэкап үшін жеке service account жасаңыз, оған тек қажетті рұқсаттарды беріңіз және сақтау құпиялары пайплайндарда ашық тұрмауын қадағалаңыз.

Шифрлауды өткізіп алмаңыз. Бэкаптарды сақтау орнында шифрлауды қосып, қалпына келтіру үшін кілттердің бар-жоғын тексеріңіз: команда restore жасағаннан кейін қолмен кілттер іздейтін жағдайлар болуы жиі кездеседі. Көп жағдайда деректер орнына келгенімен, қосымша секреттер жоқ болғандықтан жүктелмейді.

Барлығын қысқа құжатпен бекітіңіз: не сақталатыны, көшірмелер қайда, бэкап пен қалпына келтіруді қалай бастау және кім жауапты. Қысқа командалар жиынтығын қосыңыз (backup, list, restore, verify), дежур контактілер, тесттік restore уақыттары және сәттілік критерийлері.

Қалпына келтіруді қалай тексеру керек: сценарийлер мен метрикалар

Бэкаптың құны оның қалпына келтіруді қалай білетініңізге тең. Restore тесттері үнемі, бірдей қадамдармен және нақты цифрлармен жүргізілуі тиіс.

Ең қауіпсіз бастама — бөлек namespace‑қа қалпына келтіру. Осылайша PVC/PV жасалатынын, StatefulSet/Deployment жүктелетінін, Secrets пен ConfigMap тартылатынын тексересіз және продқа әсер етпейсіз. Ресурстарға суффикс қосып, уақытша ingress өшіріп қою тесттің кездейсоқ релизге айналуына жол бермейді.

Келесі деңгей — басқа кластерде тест. Бұл DR‑сценарий, мұнда DNS, CSI‑драйвер нұсқалары, сақтауға қол жеткізу және сыртқы тәуелділіктер шығады. Мұндай тестті тоқсан сайын немесе кластерге ірі өзгеріс енгізгеннен кейін жасаған дұрыс.

Қалпына келтіргеннен кейін нені тексеру керек

Падтардың Running болғанын көру жеткіліксіз. Қосымшалық деңгейде консистенттілікті тексеріңіз: Postgres үшін бақылау сұраулары мен жолдар санының сәйкестігін, Kafka үшін соңғы хабарларды оқу, файлдық сервисте эталон файлдардың хэшін тексеру. Қолданба үшін маңызды нәрселерді валидтеу — инженерге ыңғайлы нәрселерден маңыздырақ.

Метрикалар мен автоматтандыру

Шынайы RTO‑ны есептеу үшін restore басқышынан бастап сервис қарапайым тексеруге жауап берген кездегі уақытына (health + бір «нақты» сұрау) дейінгі аралықты белгілеңіз.

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

Тесттерді кестеге салып автоматтандырыңыз: түнгі restore тесті тестті namespace‑қа, ай сайынғы резервтік кластерге қалпына келтіру, логтар мен уақыттарды ортақ журналға сақтау.

Stateful‑тың бэкапында жиі кездесетін қателіктер және тұзақтар

Ең жиі не бұзылады

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

Типтік мәселе — PV көтерілмейді, себебі мақсатты кластерде басқа StorageClass немесе қажет CSI‑драйвер жоқ. Манифесттер қалпына келтіріледі, бірақ сақтау параметрлеріне (диск түрі, зона, шифрлау параметрлері) сай том бөліну мүмкін емес. Нәтижесінде Pod Pending күйінде қалады.

Екінші тұзақ — жоғалған секреттер мен кілттер. Қосымша развернут болғанымен, деректерді дешифрлей алмайды немесе TLS сертификатты аша алмайды. Stateful сервистер үшін бұл өте ауыр: деректер бар, бірақ кілттер басқа, сондықтан сервис жұмыс істемейді.

Үшінші қателік — жазылымды «тоқтатпай» жасалған снапшоттар. PostgreSQL, MySQL, Elasticsearch тәрізді жүйелер үшін консистенттілік маңызды. Жазу жүріп жатқан кезде алынған снапшот логикалық бұзылуларға әкелуі мүмкін.

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

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

Қалай алдын алыңыз

Қысқа жиынтық тексерістер көмектеседі:

• Қалпына келтіру жоспарын StorageClass пен CSI‑ге сәйкестендіріңіз: жаңа кластерде томдар қалай мэпталады.
• Секреттерді бірге қалпына келтіруге болатындай сақтау және шифр кілттерін бөлек тексеру.
• Дерекқорлар үшін келісімді режим пайдалану: не встроенный бэкап, не quiesce‑сы бар снапшоттар мен олардың тұтастығын тексеру.
• Рөлдерді бөлу: кім бэкап жасайды, кім жоя алады, кім restore бастайды.
• Қалпына келтіруді кестемен тестілеңіз және нақты RTO мен RPO‑ны тіркеңіз.

Жай сценарий: екі апта сайын тесттік namespace‑қа Postgres пен қосымшаны қалпына келтіріп, бір‑екі бақылау операциясын (кіру, жазу, оқу) орындаңыз. Бұл апат күніндегі ұзақ және қымбат талдаудан арзанырақ.

Продқа жібермес бұрын қысқа чеклист

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

Алдымен не деректер жоғалту болып саналады және қандай тоқтау шектеледі — келісіңіз. Әр түрлі stateful‑қызметтер үшін бұл әртүрлі болуы мүмкін: дерекқор, кезек және файл сақтау бірдей емес.

Содан соң мына тармақтарды тексеріңіз:

• Критикалық сервистер тізімі бар, әрқайсысы үшін RPO мен RTO және қалпына келтіру моделі (сол кластерде не жаңа кластерде) анықталған.
• Бэкап тек томдарды ғана емес, сонымен бірге манифесттерді, конфигурацияларды және тәуелділіктерді қамтиды: Namespace, CRD, ConfigMap, Secrets және қажет болса Ingress пен рұқсат саясаттары.
• Бэкап сақтау орны оқшауланған: жеке қолжетімділік, жаппай жоюдан қорғау, версиялау немесе immutable қосылған, және тіркелгі компрометациясына жоспар бар.
• Қалпына келтіру тесті бар және соңғы табысты орындау күні белгілі, нақты RTO: Pod‑тың іске қосылуы, қосымшаның дайын болуы және деректер тексерісі өлшенген.
• Процестің иесі бар: кестені қадағалайтын, қателерге жауап беретін, қысқа қалпына келтіру нұсқаулығы қай жерде екенін білетін адам анықталған.

Чеклистті тірек мысалға байлаңыз. Мысалы: "Billing үшін PostgreSQL: RPO 15 минут, RTO 1 сағат, қалпына келтіру жаңа namespace‑та, тексеріс: жазбалар саны мен соңғы транзакциялар". Егер бір сөйлемде жазылмаса, жоспар дайын емес.

Продқа бергеннен кейін сақтау жүйесі, қолжетімділік саясаты немесе Kubernetes нұсқасы өзгергенде чеклистті қайта қарауды ескерткішпен байлаңыз — дәл осындай өзгерістер қалпына келтіруді жиі бұзады.

Келесі қадамдар: пилот, регламент және бэкап инфрақұрылымы

Келесіде құрал атауы маңызды маңдайша емес — маңыздысы бэкапты қайталанатын процесске айналдыру. Практикалық жол — қысқа пилот, онда нақты уақыт, көлем, жүктеме және қалпына келтіру сапасы көрінеді.

1–2 типтік қосымшадан бастаңыз: PVC бар PostgreSQL және критикалық Secrets пен ConfigMap бар шағын сервис. Толық цикл жасаңыз: резервтік көшіру, тесттік ортада деректерді жою және қалпына келтіру, содан соң қосымшалық тексерістер (кіру, сұрау, фондық тапсырмалар).

2–3 аптаға арналған жоспар қарапайым болуы тиіс: пилоттық қосымшалар мен RPO/RTO таңдау, кесте мен сақтау мерзімдерін орнату, бірнеше restore‑сценарий өткізу (сол кластерде, бөлек namespace, басқа кластерде), метрикаларды тіркеу (уақыт, көлем, сәттілік) және 1–2 беттен тұратын регламент жазу.

Параллельде инфрақұрылымды бағалаңыз. Таяқшалық тартым — көбіне бағдарламалық емес, диск пен желінің шектеулерінде: түнгі уақытта пропусктілігі жетеді ме, IOPS‑та запас бар ма, ретенцияны ескере отырып, қанша орын қажет, оффсайт бар ма.

Егер кластер on‑prem болса, резервтік репозиторийге арналған серверлік базаны, резервтеу (RAID/репликация), қуат және мониторингті алдын ала ойластырыңыз. Мұндай жұмыстарда кейде жүйелік интеграторлар көмектеседі — мысалы, GSE.kz серверлерді жеткізіп, Kubernetes пен резервтік процесс талаптарына сай инфрақұрылым жинауға көмектеседі.