LLM контурының резервтік көшірмелерін ел ішінде қалай сақтауға болады?

LLM контурының резервтік көшірмесі тек қолданбаны рұқсат етілген аумақта іске қосып, деректерді штаттық тәсілмен шифрдан шығарып, бұрынғы мінез-құлықты сол қалпында ала алғанда ғана жұмыс істейді деп саналады. Объектілік қоймадағы бірнеше қалтасы бар архив бұл үшін жеткіліксіз. Оның ішінде терабайттаған дерек болуы мүмкін, бірақ іздеуді, қолжетімділік құқықтарын, бапталған модельді немесе аудитті қалпына келтіру мүмкін болмайды.

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

Сервистерді емес, жауапқа әсер ететін күйді көшіріңіз

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

Артефактілерді оларды қалай қайтаруға болатынына қарай бөліңіз:

• бастапқы деректер: бастапқы құжаттар, құрылымдалған жазбалар, медиа, қолжетімділік баптаулары және келісімдер;
• туынды деректер: чанктер, эмбеддингтер, векторлық индекстер, кештер, шығарып алу нәтижелері және қайта оқытылған сөздіктер;
• орындалатын күй: checkpoints, токенизаторлар, LoRA адаптерлері, инференс конфигурациясы, образдар және промпт шаблондары;
• дәлелдік күй: аудит журналдары, қолжетімділік оқиғалары, саясат нұсқалары, конвейер журналдары және бағалау нәтижелері;
• криптографиялық күй: кілттер, кілт нұсқалары, қолжетімділік саясаттары, сертификаттар тізбегі және KMS немесе HSM параметрлері.

Бұл топтардың RPO және RTO мәндері әртүрлі. Кэштің алты сағат жоғалуы жағымсыз, бірақ көтеруге болады. Келісімдер журналының, ACL соңғы нұсқасының немесе жұмыс істеп тұрған архив кілтінің жоғалуы сервисті толық тоқтатуы мүмкін. Бүкіл LLM үшін бір ғана «резервтеу кезеңін» белгілемеңіз. Ол кейін қалпына келтіруді бұзатын тәуелділіктерді жасырады.

Пайдалы ең аз тізілім мынадай болуы мүмкін:

artifact: knowledge-search-prod
owner: ml-platform
classification: confidential
territory: KZ
source_of_truth: postgres-documents
rebuildable: true
rpo: 30m
rto: 4h
backup:
  primary_copy: kz-dc-a
  recovery_copy: kz-dc-b
  encryption_key: kms://kz-hsm/keys/rag-prod-backup-v7
restore_dependencies:
  - document-store
  - embedding-model-qwen3-embedding-8b@sha256:...
  - chunker-config@2026-07-01
  - acl-schema@v4
validation:
  - checksum
  - filtered-search-smoke-test
  - access-denial-test

Бұл кесте үшін жасалған бюрократия емес. rebuildable: true жолы иесін ыңғайсыз сұраққа жауап беруге мәжбүрлейді: индексті нақты қандай деректерден және эмбеддингтердің қай нұсқасымен қайта құрады? Нақты жауап болмаса, индексті жеке артефакт ретінде сақтау керек.

Корпус пен эмбеддинг нұсқасы жоқ векторлық база іздеуді қалпына келтірмейді

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

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

Әр production индексі үшін манифестте кемінде мыналарды бекітіңіз:

{
  "collection": "support-kz-ru",
  "snapshot_time": "2026-07-23T02:30:00Z",
  "embedding_model": "approved-embedding-model",
  "embedding_revision": "sha256:9d4...",
  "dimension": 3072,
  "distance": "cosine",
  "chunking": {
    "parser": "[email protected]",
    "max_tokens": 700,
    "overlap_tokens": 100
  },
  "payload_schema": "acl-payload@v4",
  "source_cursor": "documents:842771",
  "checksum": "sha256:..."
}

Бақылау суммасын «коллекция ашылды» деген тексеріспен алмастырмаңыз. Индекс ашылғанымен, сегменттердің, сүзгілердің немесе метадеректердің бір бөлігі жоғалуы мүмкін. Қалпына келтіргеннен кейін бекітілген сұраулар жиынтығын орындаңыз: қарапайым іздеу, бөлім бойынша сүзгісі бар іздеу, құжатқа құқығы жоқ пайдаланушының сұрауы және жойылған құжатқа сұрау. Соңғы тесттің күтілетін нәтижесі көбіне бос жауап болуы керек. Ол деректермен бірге ақпараттың таралып кетуін қалпына келтірмегеніңізді көрсетеді.

Векторлық базаның снапшоты бастапқы корпустың көшірмесін алмастырмайды. Индексте бастапқы құжат заңды түрде выгрузка жасауға, қайта парсингтеуге және модельді ауыстыруға жарайтын түрде сақталмайды. Ал конвейер нұсқасы жоқ корпус, егер RTO бірнеше күн бойы миллиардтаған векторды қайта есептеуге мүмкіндік бермесе, индекс снапшотын алмастырмайды. Іздеу маңызды процеске қатысса, екі қабатты да сақтаңыз.

Checkpoint-ті файлдар тобынан бөліп қарамаңыз

Ондаған гигабайт көлеміндегі final-v3 деп аталған файл дерлік ешқашан қалпына келтірілетін модель болмайды. Checkpoint-ті алдын ала болжанатын түрде іске қосу үшін базалық модельдің нақты ревизиясы, токенизатор, архитектура конфигурациясы, chat template, квантизация параметрлері және инференс қозғалтқышының нұсқасы қажет. Адаптерлер үшін адаптер түрі, мақсатты қабаттар және базалық модельмен үйлесімділік те қосылады.

Команда көбіне салмақтардың өзін жоғалтпайды. Салмақтар қоймада жатады, ал конфигурация файлы, рантайм образы немесе базалық checkpoint-тің нақты идентификаторы жоғалады. Алты айдан кейін біреу «дерлік сол» модельді қосып, нұсқауларды орындауда, құралдарды шақыруда, контекст ұзындығында немесе жауап тілінде айырмашылық алады. Мұндай апатты байқау қиын: сервис жауап береді, бірақ бизнес-процесс өзгеріп кеткен.

Модель пакетін өзгермейтін нысан ретінде жинаңыз:

models/
  legal-assistant-2026-06/
    manifest.json
    base-model-ref.txt
    adapter.safetensors
    adapter_config.json
    tokenizer/
    generation-policy.yaml
    evaluation-baseline.jsonl
    signatures.sha256

manifest.json файл идентификаторлары мен хештерін қамтуы керек, бірақ құпияларды сақтамауы тиіс. generation-policy.yaml ішінде бақыланатын мінез-құлықты өзгертетін параметрлерді көрсетіңіз: temperature, top_p, ұзындық шектеуі, жүйелік промпт, хабарлама шаблоны, рұқсат етілген құралдар тізімі және құралды міндетті таңдаудың ережелері.

Қалпына келтірілген пакетті модельді жүктеумен ғана тексермеңіз. Жауап форматы, қазақ және орыс тілдері, жабық деректерге қолжетімділіктен бас тарту, құралды шақыру және ұзын контекст маңызды болатын өзгермейтін шағын сұраулар жиынтығын орындаңыз. Бұл толық модель бағалауын алмастырмайды, бірақ ең қымбат қатені ұстайды: «адаптер қосылды, демек бәрі дұрыс».

Логтарды аудитке, диагностикаға және шикі мәтінге бөліңіз

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

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

Аудиттің тұрақты резервтік көшірмесіне әдетте мыналарды қосқан жөн:

• субъект идентификаторы немесе оның қайтарымсыз псевдонимі;
• уақыт, сұрау маршруты, саясат нұсқасы және шешім нәтижесі;
• контекст көздерінің идентификаторлары, олардың мәтінін автоматты көшірмей;
• модель, шақыру параметрлері, нәтиже коды және трассировка идентификаторы;
• толық промптты бөлек сақтауға рұқсат болса, қорғалған тергеу нысанына сілтеме.

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

Журналдар үшін схеманы сақтау маңызды. Өрістердің сипаттамасы мен саясат нұсқасы жоқ пайдалы JSON болжамдар жиынына айналады. Жанына JSON Schema немесе миграцияларды, шешім кодтарының анықтамалығын және оқиғаны қалыптастырған конфигурация хешін қойыңыз.

Шифрлау кілттері бөлек жоспар болғанда ғана бэкаптан аман қалады

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

NIST SP 800-34 шифрланған деректерді резервтеуді криптографиялық кілттерді басқарумен тікелей байланыстырады: жаңа немесе ауыстырылған жүйеде көшірмені оқу үшін қажет бағдарламалық жасақтама да, кілт материалы да болуы тиіс. LLM контуры үшін мұны кеңірек түсінген жөн. Қалпына келтіруге құпия мән ғана емес, саясат, кілт нұсқасы, апаттық рөл құқықтары, сервис сертификаттары және HSM немесе KMS-ке қол жеткізу тәртібі де қажет.

Жұмыс істейтін схема көбіне мынадай болады:

1. Сервис әр архивке немесе архивтер жиынына бөлек DEK жасайды.
2. Сервис деректерді DEK арқылы шифрлайды, содан кейін DEK-тің өзін жергілікті KMS немесе HSM-дегі KEK кілтімен шифрлайды.
3. Архивке шифрмәтін, шифрланған DEK, KEK нұсқасының идентификаторы және бүтіндік манифесті кіреді.
4. KMS саясаты, операциялар журналы және апаттық рөл рұқсат етілген аумақта бөлек резервтеледі.
5. Шифрдан шығару үшін кемінде екі бақыланатын әрекет қажет: архивке қол жеткізу және KEK-ті пайдалану рұқсаты.

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

Ротация да архивтерді бұзады. Әр көшірменің манифестінде кілт нұсқасының идентификаторы көрсетілуі керек, ал кілттерді жою саясаты әлі сақталып тұрған ең ескі архивті ескеруі тиіс. Жоспарлы ротациядан кейін ескі KEK нұсқасын жою оңай. Одан кейін деректерді қалпына келтіру мүмкін емес, нысандардың бәрі бүтін болса да.

Көшірме жүретін бүкіл жолда аумақ сақталуы керек

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

Әр компонентке мына бес сұрақты қойыңыз:

• нысандар мен олардың репликалары физикалық тұрғыда қайда орналасқан;
• уақытша файлдар, multipart-жүктеулер және кезектер қайда түседі;
• KMS пен HSM қай аумақта жұмыс істейді және кілт операцияларының журналы қайда сақталады;
• метадеректер, каталогтар және техникалық қолдау көшірмелері қай аумақта орналасқан;
• апаттық қалпына келтіру саясаты басқа елде көшірмені автоматты түрде жасай ала ма.

Шифрлау аумақ талабын жоймайды, егер талап деректердің өзіне немесе оларды өңдеуге қатысты болса. «Елден тек шифрланған нысан шықты» деген уәжді ұйымның және заңнаманың қолданылатын ережелері растаған жағдайда ғана қабылдауға болады. Мұндай шешімді әзірлеу тобының деңгейінде қабылдамаңыз. Оны деректер иесі, қауіпсіздік қызметі және нақты ақпарат санатына жауапты заңгерлер жазбаша бекітуі тиіс.

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

AI Router жергілікті деректерді сақтау, аудит журналдары және PII маскировкасы қажет командалар үшін осындай контурдың бөлігі бола алады. Бірақ қолданбалық деректерді, индекстерді және кілттерді резервтеу бәрібір жүйе иесінің міндеті болып қалады. Шлюз қандай құжаттарды бастапқы шындық көзі деп санайтыныңызды және бизнеске қандай RTO уәде еткеніңізді білмейді.

RPO мен RTO-ны әр қабатқа бөлек белгілеңіз

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

Жолдары командалардың атауларына емес, нақты тәуелділіктерге сәйкес келетін қалпына келтіру кестесін жасаңыз:

Бұл сандарды басқа біреудің презентациясынан көшірмеңіз. Егер байланыс орталығының операторы білім базасымен жұмыс істесе, ал іздеу сегіз сағат қолжетімсіз болса, бизнес қолмен жұмыс істеуге көшеді. Егер RAG төлемді тексеруге немесе пациент өтінішін өңдеуге қатысса, қол режимі мүмкін болмауы ықтимал. RTO туралы әңгімені процестің иесімен жүргізу керек, оны SRE дискілерді қалпына келтіру жылдамдығын атағаннан кейін аяқтамаңыз.

PostgreSQL үшін RPO аз болуы қажет болса, түнгі дамппен шектелмеңіз. PostgreSQL ресми құжаттамасы PITR-ді базалық көшірме мен үздіксіз архивтелетін WAL үйлесімі ретінде сипаттайды. Базалық көшірме бастапқы нүкте береді, ал WAL өзгерістерді қажетті уақытқа дейін ойнатуға мүмкіндік береді. Бірақ құжаттама практикалық тұзақ туралы да ескертеді: архивтеу баптауы артта қалуы немесе жұмысын тоқтатуы мүмкін, ал pg_wal каталогы диск толғанша өсе береді, соның салдарынан база тоқтайды.

Мониторинг кемінде мыналарды көрсетуі керек: сәтті архивтелген соңғы WAL жасы, сегменттің жасалуы мен жеткізілуі арасындағы лаг, pg_wal бос орны, соңғы базалық көшірменің сәттілігі және қалпына келтірілген архивті оқу мүмкіндігі. «Резервтік көшіру тапсырмасы аяқталды» деген белгі бұл тәуекелдердің ешқайсысын толық қамтымайды.

Қалпына келтіруді оқшауланған ортада жаттықтырыңыз

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

Оқу-жаттығу қалпына келтіруін сол рұқсат етілген аумақтың ішіндегі оқшауланған желіде өткізіңіз. Оған production трафигін бағыттамаңыз, нақты сыртқы интеграцияларды қоспаңыз және тест ортасына пайдаланушыларға хабарлама жіберу құқығын бермеңіз. Уақытша есептік жазбаларды, бөлек ресурс атауларын және шығыс трафигіне анық шектеулерді пайдаланыңыз.

Қалпына келтіру реті көбіне жекелеген операциялардың жылдамдығынан маңызды:

1. Идентификацияны басқаруды, рөлдерді, саясаттарды және KMS немесе HSM-ге қолжетімділікті іске қосыңыз.
2. Бастапқы деректер мен метадеректер базасын қалпына келтіріп, бақылау суммалары мен схема миграцияларын тексеріңіз.
3. Құжаттар мен векторлық индексті қайтарыңыз немесе бекітілген манифест бойынша қайта құруды іске қосыңыз.
4. Модель пакетін жүктеп, генерация саясаттарын қосыңыз және бақылау сұраулары жиынын орындаңыз.
5. Аудитті оқиғалардың үздіксіздігін және қолжетімділік тыйымдарын тексеріп қалпына келтіріңіз, содан кейін қолданбаны пайдаланушыларға ашыңыз.

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

Әр кезеңнің нақты уақытын, қолмен жасалған әрекеттерді, күтпеген құқықтарды және берілген деректер көлемін тіркеңіз. Екі-үш жаттығудан кейін RTO-ны тағы бір қойма сатып алмай-ақ, ұсақ мәселелерді жою арқылы қысқартатыныңыз анық: жетіспейтін рұқсат, DNS ауыстыруының ұзақтығы, токенизатор нұсқасын қолмен іздеу немесе сипатталмаған миграция реті.

Қателер көбіне тәуелділік тізбегінде жасырынады

Ең танымал кеңес мынадай: 3-2-1 ережесін қолданыңыз, сонда мәселе шешілді. Әртүрлі тасымалдағыштардағы бірнеше көшірме расында пайдалы, бірақ бұл ереже көшірмелердің бірін елден тыс жерде заңды түрде сақтауға бола ма, оның қолжетімді кілті бар ма және одан бұрынғы ACL-мен векторлық іздеуді іске қосуға бола ма деген сұрақтарға жауап бермейді. LLM контурында көшірме саны күй сипаттамасын алмастырмайды.

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

Үшінші қате, объект нұсқасы өзгермейтіндікке тең деп санау. Нұсқалау кездейсоқ қайта жазудан кейін көмектеседі, бірақ өкілетті пайдаланушы немесе бұзылған есептік жазба нұсқаларды жойып, сақтау мерзімін қысқартып немесе ережені өшіре алады. Критикалық көшірмелер үшін бөлек есептік жазба, сақтау мерзімі аяқталғанша жоюды шектеу және сол құқықтармен үнсіз өзгертіле алмайтын журнал қажет.

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

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