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

Журналдарды бір жыл сақтау қымбат дискілерге 365 тәуліктік көлемді орналастыру деген сөз емес. Баға қанша дерек келетінін, индекстеуден кейін оның көлемі қалай өзгеретінін, платформа неше көшірме жасайтынын және тарихтың қай бөлігі сұрауға бірнеше секунд ішінде жауап беруі керегін ескереді.
Сметаға тек бастапқы ағынды қосып, бірнеше айдан кейін кластерде орын қалмаған жобаларды көрдім. Керісінше жағдай да болады: ұйым жылына бір рет қарайтын оқиғалар үшін жылдам массив сатып алады. Дұрыс есеп қолжетімділікті, сақталуды және іздеу жылдамдығын бөлек қарайды. Сонда тарихтың әр бөлігіне лайық тасымалдағыш таңдалып, бюджет тексеруге болатын формулаға сүйенеді.
Алдымен қазіргі қалтаны емес, тәуліктік ағынды өлшеңіз
Есеп коллекторлар толық бір тәулікте нақты қабылдайтын оқиғалар көлемінен басталады. Бір сервердегі каталогтың өлшемі көбіне қате түсінік береді: ротация файлдардың бір бөлігін жойып үлгеруі мүмкін, агенттер кей жазбаларды сүзеді, ал индекс байттарды қосуы да, азайтуы да ықтимал. Конвейердің бір нүктесінде және бірдей өлшем бірліктерімен өлшеңіз.
Кемінде екі қалыпты аптаны, сондай-ақ ай жабылатын, инфрақұрылым жаңартылатын немесе жаппай операция өтетін күнді алыңыз. Әр дереккөз үшін қабылданған байт пен оқиға санын жазыңыз. Орташа көрсеткіш негізгі сыйымдылықты береді, ал ең жоғары тұрақты күн жүйенің дерек жоғалтпай жүктеме шарықтауын көтере алатынын көрсетеді. Бір реттік апаттық шарықтауды бүкіл жылға көбейткеннен гөрі, қабылдау буферімен жабу дұрыс.
Файл шлюзінде шамалап болжаудың орнына мына қайталанатын өлшемді қолдануға болады:
du -cb /var/log/export/2026-06-15/* | tail -1
Нәтиже 318472901224 total түрінде шығады: бұл таңдалған тәуліктегі файлдардың байты. Дерек объектілік қоймада жатса, күн префиксі бойынша объектілер өлшемін қосыңыз. Платформа қабылданған гигабайт үшін ақы алса, оның метрикасынан тәуліктік мәнді шығарып, коллектордағы кемінде бір тәуелсіз өлшеммен салыстырыңыз.
GB мен GiB бір өлшем емес. Диск өндірушілері ондық бірлікті қолданады: 1 TB дегеніміз 1 000 000 000 000 байт. Операциялық жүйе кейде екілік TiB көрсетеді, онда 1 TiB 1 099 511 627 776 байтқа тең. 100 TB диск пішімдеуге дейін шамамен 90,95 TiB береді. Он пайызға жуық айырма қордың едәуір бөлігін алып қояды.
Соңында дереккөздерді бөліңіз. Желіаралық экран ағыны, дерекқордың толық аудиті, қолданба журналдары және жүйелік оқиғалар әртүрлі себеппен өседі. Бір жалпы сан диск сатып алуға жеткілікті, бірақ сақтау мерзімдерін басқаруға жарамайды.
Жұмыс формуласы көшірмені, өсімді және бос орынды есептейді
Барлық коэффициент өз жүйеңізден алынса, алғашқы бағалауға бір формула жеткілікті:
Требуемая емкость = D × R × K × C × G / U
Мұнда D бастапқы тәуліктік көлем, R күн саны, K талдау, индекстеу және сығудан кейін дискідегі көлемнің бастапқы көлемге қатынасы, C деректің толық көшірмелер саны, G өсу қоры, ал U дискті толтыруға рұқсат етілген үлес. Мысалы, 20% өсу қоры G = 1,20, ал 80% толтыру шегі U = 0,80 деп жазылады.
C коэффициентін жиі қате санайды. Бір негізгі және бір реплика екі көшірме дегенді білдіреді, сондықтан C = 2, бір емес. RAID іздеу кластерінің репликасын да, резервтік көшірмені де алмастырмайды. RAID түйін ішіндегі тасымалдағыш істен шыққанда көмектеседі, реплика түйін жоғалғанда жұмысты жалғастырады, ал резервтік көшірме логикалық жоюдан, бүлінуден немесе әкімші қатесінен қорғайды. Бұлар әртүрлі ақаулар және сметаның бөлек жолдары.
Бос орын артық сән емес. Elasticsearch құжаттамасы дисктің қалыпты шектерін белгілейді: 85% толғанда кластер жаңа шардтарды орналастыруды шектейді, 90% кезінде оларды жылжыта бастайды, ал 95% болғанда тиісті индекстерге жазуды бұғаттайды. Басқа платформада тетік өзгеше болуы мүмкін, бірақ оған да біріктіру, уақытша файлдар, қалпына келтіру және қайта теңгеру үшін орын керек. Қалыпты жұмысты 95% толуға жоспарлау апаттық режимді алдын ала қабылдаумен тең.
Формулаға көлеммен тура өспейтін шығындарды қосыңыз: жүйелік индекстер, метадерек, платформаның өз журналдары, қосалқы дискілер, суретті қалпына келтіруге арналған орын және көшіру кезінде ескі әрі жаңа деректің уақытша қатар тұруы. Шағын кластерде бұл баптар ірі кластерге қарағанда көбірек сезіледі. Сондықтан формула нәтижесін бірден жабдық тапсырысына айналдырмай, сынақтық жүктемемен тексеріңіз.
Сығуды өз оқиғаларыңызда өлшеңіз
«Логтар бес есе сығылады» деген сөз бюджетке негіз бола алмайды. Қайталанатын мәтін жолдары жақсы сығылады, бірақ UUID, хеш, шифрланған өріс, трассировка және бұрыннан сығылған пайдалы жүктеме басқаша әрекет етеді. Индекс сөздіктерді, іздеу құрылымдарын және өріс мәндерін қосады. Кейде индекстелген жиын бастапқы JSON-нан кіші, кейде үлкен болады.
Үш-жеті күндік өкілді бөлікті алып, оны өндірістегі өріс үлгісімен жүктеңіз және фондық біріктіру біткенше күтіңіз. Негізгі шардтардың нақты өлшемін бастапқы кіріс көлеміне бөліңіз. Ірі оқиғалар кластары үшін сынақты бөлек қайталаңыз. Орташа өлшенген мән K болады, ал мәндер аралығы тәуекелді көрсетеді.
Elasticsearch жүйесінде негізгі шардтардың өлшемін былай тексеруге болады:
GET _cat/indices/logs-*?h=index,pri,rep,docs.count,pri.store.size,store.size&s=index
Сол кезеңдегі бастапқы кіріс 1,00 TB, pri.store.size 0,62 TB, ал бір репликасы бар store.size 1,24 TB болса, K = 0,62, C = 2. Формулаға 1,24 мәнін коэффициент ретінде қойып, кейін екі көшірмеге тағы көбейтпеңіз. Ондай есеп репликаны екі рет санайды.
Elastic құжаттамасы logsdb режимінде сақталатын өрістерге ZSTD негізіндегі best_compression қолданылатынын және сандық мәндер үшін арнаулы кодектер барын жазады. Бұл пайдалы оңтайландыру, бірақ нақты пайызға кепілдік емес. Тығыз сығу жазу және оқу кезінде процессор жүктемесін де өсіруі мүмкін. Нұсқаларды бірдей сұраулармен, бірдей жабдықта және сегменттер біріктірілгеннен кейін салыстырыңыз.
Мұрағатқа бөлек тексеріс қажет. Тәуліктік файлдарды таңдалған пішіммен сығып, мұрағат көлемінің бастапқы көлемге қатынасын және ашуға кететін уақытты өлшеңіз. Миллиондаған ұсақ объектіні сақтау тиімсіз: каталог пен API ауыр жұмыс істейді, ал кей мұрағат кластары объектінің ең аз көлеміне немесе әр объектінің метадерегіне ақы алады. Мысалы, Amazon S3 құжаттамасы Glacier Flexible Retrieval және Deep Archive ішіндегі әр объектіге 40 KB қосымша метадерек қажет екенін көрсетеді. Әр оқиғаға бір файл жасағаннан гөрі, сағаттық немесе тәуліктік пакет ыңғайлы.
Бір жылдық жедел іздеу сирек қажет
«Бір жыл сақтау» талабы көбіне кез келген сұрауға жауап беру уақытын емес, деректі жоғалтпай ұстау мерзімін сипаттайды. Аудитор көшірмені бірнеше сағат күте алса, бүкіл жылды іздеу кластерінде ұстаудың мәні жоқ. Сарапшы тоғыз ай бұрынғы оқиғаны дереу зерттеп, байланыстар құруы керек болса, іздеу қабаты жоқ суық мұрағат бұл міндетті орындамайды.
Мерзімді үш уәдеге бөліңіз. Ыстық деңгей жазбаны қабылдап, жиі сұрауларға жауап береді. Жылы деңгей ескі индекстерді сыйымдылығы жоғары тасымалдағышта сақтайды, бірақ олар іздеуге қолжетімді қалады. Мұрағат бастапқы немесе қалыпқа келтірілген оқиғаларды сақтайды, ал талдау алдында оларды қайтару, қосу немесе басқа қозғалтқышпен өңдеу керек.
Шекараны дөңгелек күн санымен емес, пайдалану дерегімен белгілеңіз. Бір тоқсан ішінде әр сұрау мен тергеудегі уақыт аралығының жасын жинаңыз. Интерактивті сұраулардың 96% соңғы 30 күнге қатысты болса, бір айды ыстық деңгейде ұстауға бұл салмақты дәлел. Қалған төрт пайыз бүкіл ескі тарихты мұрағатқа жіберу керек дегенді әлі білдірмейді: кей кестелерге 90 күндік жылы деңгей қажет болуы мүмкін.
Microsoft компаниясының Azure Monitor құжаттамасы analytics retention мен long-term retention режимдерін анық бөледі. Ұзақ мерзімді режимдегі деректе кәдімгі кестенің барлық мүмкіндігі жоқ, оны алу үшін іздеу тапсырмасы іске қосылады. Басқа жүйеде де осы қағида пайдалы: сақтау бағасының төмендеуі қолжеткізудің басқа тәсілімен өтеледі. Өз архитектураңызда бұл шектеуді SLA құжатына түсінікті тілмен жазыңыз.
Қалпына келтіру тізбегін тексермей тұрып жалғыз көшірмені мұрағатқа көшірмеңіз. Каталогы, бақылау сомасы, өрістер сызбасы және жұмыс істейтін импорт құралы жоқ мұрағат қағаз жүзінде бар, бірақ одан тергеу жасау мүмкін емес.
Суық сақтау бағаны өзгертеді, шығынды жоймайды
Мұрағат тасымалдағыш құнын төмендетіп, ескі деректі іздеу деңгейінде лицензиялау шығынын жиі алып тастайды. Оның орнына объект жазу операциялары, ең аз сақтау мерзімі, оқу ақысы, API сұраулары, желі арқылы шығару, қалпына келтіруге уақытша алаң және әкімші еңбегі пайда болады. Айына бір GB бағасын ғана санау қауіпті.
Мұрағат кластарының нақты салдары бар: дерек бірден қайтпайды. Amazon S3 құжаттамасы Glacier Flexible Retrieval үшін режимге қарай бірнеше минуттан 12 сағатқа дейін, ал Deep Archive үшін 9-48 сағат қайтару уақытын көрсетеді. Ең аз сақтау мерзімі тиісінше 90 және 180 күн. Объектіні ерте жою немесе басқа класқа ауыстыру төлемді сол сәтте тоқтатпауы мүмкін. Аймақтық тарифтер өзгеріп тұрады, сондықтан модельде оларды жобаға мәңгі бекітілген сан емес, параметр ретінде ұстаңыз.
Бұлттық мұрағаттың жылдық құны былай есептеледі:
Хранение = сумма(средний GB за месяц × цена GB-месяца)
Извлечение = восстановленный GB × цена чтения
Операции = число запросов по типам × цена запроса
Передача = выведенный GB × цена передачи
Бірінші жылы көлем біртіндеп өседі. Мұрағат бос басталып, күн сайын бірдей порция алса, сол жылғы орташа көлем жыл соңындағы көлемнің жартысына жуық болады. «Соңғы 365 күнді сақтаймыз» саясаты бар екінші толық жылда мұрағат шекті көлемге жақын тұрады. Соңғы 30 TB көлемді бірінші жылда он екі айға көбейтетін смета сақтау шығынын асырады. Кейінгі әр жылда көлемнің жартысын ғана алатын смета оны кемітеді.
Жергілікті мұрағат үшін RAID немесе erasure coding қолданғаннан кейінгі пайдалы сыйымдылықты, қосалқы тасымалдағышты, серверді, сөрені, желі портын, электр қуатын, салқындатуды, кепілдік ауыстыруды және еңбекті есептеңіз. Бір ғимарат жоғалғанда журналдар жойылмауы керек болса, екінші алаңды қосыңыз. Бағалар тізіміндегі арзан диск деректі арзан сақтау деген сөз емес.
Мерзімді бүкіл ағынға емес, оқиға класына тағайындаңыз
Бәріне бірдей сақтау тереңдігі көп жағдайда артық шығын туғызады. Қолданбаның жөндеу журналы, әкімшінің құқық өзгертуі, желілік ағын және денсаулық тексеруінің сәтті нәтижесі әртүрлі операциялық әрі дәлелдік мәнге ие. Алдымен дерек иесі, қауіпсіздік, пайдалану және заң бөлімі әр кластың не үшін сақталатынын келіседі. Содан кейін инженер сақтау деңгейін таңдайды.
Жұмыс жіктемесі мынадай болуы мүмкін:
- Тіркелгі және құқық өзгерістері: жедел іздеу 90 күн, саясат бойынша толық мерзім 1-3 жыл; жедел деңгейден кейін толық қалыпқа келтірілген оқиға мен түпнұсқа сақталады.
- Қорғаныс құралдарының оқиғалары: жедел іздеу 30-90 күн, толық мерзім бір жыл; мұрағатта тергеу өрістері мен бастапқы жазба қалады.
- Info деңгейіндегі қолданба журналдары: жедел іздеу 14-30 күн, толық мерзім 90 күн; тек қажет сервистер немесе агрегаттар сақталады.
- Толық жөндеу журналдары: жедел іздеу 3-7 күн, толық мерзім 7-30 күн; ақау түзелгеннен кейін мұрағат көбіне қажет емес.
- Жүйе күйінің метрикалары: жедел іздеу 30 күн, толық мерзім бір жыл; одан кейін сағаттық немесе тәуліктік агрегат жеткілікті.
Бұл дайын саясат емес, жобалау үлгісі. Заң, шарт, салалық ереже немесе ішкі тергеу басқа мерзім мен өзгермейтіндікті талап етуі мүмкін. NIST SP 800-92 ұйымға журналдарды сақтау талаптарын сервер баптауының жанама нәтижесі етіп қалдырмай, саясатта анықтауға кеңес береді. Мен оған тағы үш тармақ қосар едім: мерзім қай сәттен басталады, қалпына келтіруге қанша уақыт беріледі және жоюға кім рұқсат етеді.
Сақтауға дейінгі сүзу ең көп үнем береді, бірақ оған сақтық керек. Пайдасыз екені дәлелденген шуды, мысалы жиі келетін сәтті денсаулық тексерулерін, олардың болмауы қолжетімділік бақылауын бұзбайтын кезде ғана алып тастаңыз. Бүгін ешкім сұрамайды деп өрістерді жоймаңыз. Субъект идентификаторы, нақты уақыт, дереккөз, әрекет, нәтиже және корреляция идентификаторы кейінгі тергеуде оқиғаларды байланыстыруы мүмкін.
Агрегация метрика мен қайталанатын техникалық оқиғаға жарайды, бірақ аудитті алмастырмайды. Сәтсіз кірулердің тәуліктік саны қай тіркелгі, қай мекенжай және қай уақытта тексерілгенін айтпайды. Тренд үшін агрегатты, ал тергеуге қажет мерзімге бастапқы оқиғаларды сақтаңыз.
Тәулігіне 300 GB ағынды есептеу үлгісі
Коллекторлар тәулігіне 300 GB бастапқы оқиға қабылдайды делік. Сынақ іздеу индексі үшін K = 0,65, ал мұрағат файлы үшін K = 0,22 екенін көрсетті. Іздеу деңгейінде бір реплика бар, демек C = 2. Жоспар 20% өсімді ескереді, дисктер 80%-дан артық толмауы керек.
Бүкіл жылды бір іздеу деңгейінде ұстасақ, есеп мынадай:
300 × 365 × 0,65 × 2 × 1,20 / 0,80 = 213 525 GB
Жүйелік дерек, қалпына келтіруге уақытша орын және резервтік көшірме есептелмей тұрып шамамен 213,5 TB берілген пайдалы сыйымдылыққа тапсырыс беру қажет. TB бірлігімен сатылатын дисктер үшін бұл ірі массив. Кластер суретін бөлек есептеңіз: ол басқаша сығылып, қайталанған деректі азайтуы мүмкін, бірақ тегін емес.
Енді жедел деңгейде 30 күн қалдырып, алдыңғы 335 күнді мұрағатқа жіберейік. Іздеу үшін мынандай көлем қажет:
300 × 30 × 0,65 × 2 × 1,20 / 0,80 = 17 550 GB
Қосымша қолданбалық көшірмесіз жыл соңындағы мұрағат көлемі:
300 × 335 × 0,22 × 1,20 = 26 532 GB
Шыққан 17,55 TB жедел деңгей мен 26,53 TB мұрағат объектісін бірдей дисктер секілді қосуға болмайды: олардың бағасы, ақауға төзімділігі және қолжеткізу жылдамдығы басқа. Бірақ салыстыру деңгейлерге бөлу жобаны қалай өзгертетінін көрсетеді. Іздеу кластеріне бастапқы 213,5 TB көлемнің оннан бірінен азы қажет, ал ескі тарих тығыз пішімде сақталады.
90 күндік жедел іздеу нұсқасына 52,65 TB берілген сыйымдылық керек. Қалған 275 күннің мұрағаты сол коэффициенттермен шамамен 21,78 TB алады. Қосымша 60 күндік жедел қолжеткізу іздеу деңгейінде шамамен 35,1 TB тұрады. Енді тергеу иесі бұл айырма нақты сұраулармен ақтала ма деген сұраққа жауап бере алады, ал сатып алу бөлімі жалпылама «көбірек диск керек» деген өтініш емес, нақты SLA бағасын көреді.
Модельді тағы екі сценариймен тексеріңіз: ағынның 50% өсуі және K мәнінің сынақтағы жоғарғы шекке дейін нашарлауы. Журналдың бір жаңа дереккөзі жобаны бұзса, қор тым аз алынған. Қолайсыз сценарийдің өзінде массивтің жартысы бос қалса, сыйымдылықты кезеңмен сатып алуға болады.
Диск бағасы TCO-ның бір бөлігі ғана
Сақтаудың толық құнына жабдық немесе бұлт шоты, көлемге не түйінге негізделген лицензия, индекстеу мен сұрауға арналған есептеу ресурсы, желі, тіреу, қуат, салқындату, резервтік көшірме және адамдардың еңбегі кіреді. Мерзімді ұзарту тек диск қосуды талап етпеуі мүмкін. Шард пен объект саны өседі, каталог үлкейеді, тексеру мен қалпына келтіру ұзарады.
Іздеу платформасының лицензия өлшемін тексеріңіз. Өнім қабылданған GB үшін ақы алса, қабылдаудан кейін мұрағаттау ingestion төлемін азайтпауы мүмкін. Лицензия түйінге немесе ресурсқа тәуелді болса, ескі деректі арзан деңгейге ауыстыру қымбат түйіндер санын қысқартады. Сұрау сканерлеген көлемге ақы алынатын болса, мұрағат бойынша сирек кең іздеулер бөлек айнымалы болады.
Жергілікті нұсқаларды бірдей мерзімде, әдетте үш-бес жылда салыстырыңыз. Диск ауыстыруды, сөре кеңейтуді, қолдауды және капитал құнын қосыңыз. Сатып алынған массивті бірінші жылдан кейін тегін деп санамаңыз: ол бүкіл қызмет мерзімінде ресурс жұмсап, орын алады. Бұлттық нұсқа бастапқы сатып алуды қажет етпейді, бірақ төлем жалғасып, өсуге, оқуға және тасымалдауға байланысты өзгереді.
Инфрақұрылым жобасында GSE.kz сақтау тереңдігінің есебін сервер, дата-орталық және бағдарламалық деңгей конфигурациясымен байланыстырып, архитектураны бір өндірушіге байламай құра алады. Интеграторға жүгінбей тұрып D, K, көшірме талаптарын және сұраулар жасының статистикасын жинаңыз. Бұлар болмаса, кез келген жеткізуші қымбат қор қосады немесе болжаммен жұмыс істейді.
Тексеру құнын бөлек бағалаңыз. Ешкім қалпына келтіріп көрмеген мұрағат жалған үнем береді. Таңдалған бір күнді тоқсан сайын сынақ ретінде қайтару тексерілетін файлдар жиынын жасап, бақылау сомаларын растауы, сызбаны жүктеуі және алдын ала жазылған бірнеше сұрауды орындауы керек. Сметаға уақытша сыйымдылық пен осы сынаққа кететін жұмыс сағатын қосыңыз.
Өзгермейтін сақтау бөлек есепті талап етеді
Ұзақ сақтау көбіне іздеумен қатар жазбаның өзгермегенін дәлелдеу үшін керек. Репликация мен кәдімгі резервтік көшірме мұны өздігінен растамайды. Құқығы жеткілікті әкімші екі көшірмені де жоя алады, ал автоматты саясат жоюды барлық түйінде дәл қайталайды. Журнал аудитке қажет болса, архитектураға мерзімі шектелген және қолжетімділігі бөлек басқарылатын өзгермейтін деңгей қосылады.
Өзгермейтіндік сыйымдылыққа әсер етеді. Қате шығарылған пакетті кейін тығыз нұсқамен жай ғана ауыстыру мүмкін емес, ал тым ұзақ таңдалған мерзім қажетсіз деректі жоюға тыйым салуы ықтимал. Алдымен саясатты бөлек контейнерде және қысқа аралықта тексеріңіз. Сақтауды кім қоса алатынын, кім ұзарта алатынын, заңдық бұғаттау мүмкіндігін және мерзім біткенде объектіге не болатынын жазыңыз. Бұл жауаптар жеткізуші функциясының атауынан маңыздырақ.
Microsoft компаниясының Azure Monitor экспорттау құжаттамасы Log Analytics жүйесіндегі жазбаларды қабылдаудан кейін өзгертуге болмайтынын, бірақ purge рәсімімен жоюға болатынын айтады. Өзгертуден қорғалған сақтау үшін өзгермейтіндік саясаты бар қойма тіркелгісіне экспорттау ұсынылады. Осыдан іздеу платформасындағы жазба мазмұнын қорғау мен жазбаның өзін жоюдан қорғау арасындағы айырма анық көрінеді. Өз жүйеңізде екі операцияны бөлек тексеріңіз.
Әр мұрағат пакетіне шағын манифест қажет: дереккөз, аралықтың басы мен соңы, жазба саны, көлем, сызба нұсқасы және бақылау сомасы. Бақылау сомасын соңғы сығудан кейін, мұрағатқа жібермей тұрып жасаңыз. Қарапайым тексеріс мынадай:
sha256sum events-2026-06-15.json.zst > events-2026-06-15.sha256
sha256sum -c events-2026-06-15.sha256
Сәтті нәтиже events-2026-06-15.json.zst: OK түрінде шығады. Бақылау сомасының файлын пакетпен қатар сақтап, қорғалған каталогқа қосыңыз. Әйтпесе қаскүнем деректі оның сомасымен бірге ауыстыра алады. Қатаң дәлелдік рәсімге цифрлық қолтаңба, сенімді уақыт белгісі және қолжеткізу журналы да қажет болуы мүмкін, бірақ талапты диск массивінің әкімшісі емес, бақылау иесі анықтауы керек.
Мұрағатты шифрлау тағы бір тәуелділік қосады. Дерек, кілт және қалпына келтіру нұсқаулығы бірдей мерзім сақталуы керек, бірақ оларды бір жерде бірдей құқықпен ұстауға болмайды. Кілттерді ауыстырғанда ескі объектілердің оқылатынын тексеріп, пішім нұсқасын сақтаңыз. Бірнеше жыл бойы физикалық тұрғыда бүтін жатқан, бірақ қызмет тіркелгісі жойылғаннан немесе кілт басқару жүйесі ауысқаннан кейін жарамсыз болған мұрағаттарды көрдім.
Пішім де сақтау мерзімінің бір бөлігі. Ашық жолдық JSON-ды әртүрлі құралмен қалпына келтіру оңай, бірақ ол көбірек орын алады және баяу оқылады. Parquet типтелген бағандарды тығыз сақтап, таңдап талдауға қолайлы, алайда сызба мен үйлесімді оқу құралын қажет етеді. Болашақ іздеу тәсіліне қарай таңдаңыз. Дұрыс тексерісте басқа команда таза алаңда пакетті тек манифест пен нұсқаулық арқылы, мұрағат авторының ауызша көмегінсіз оқиды.
Сақтық үшін әр техникалық логқа өзгермейтіндік қоспаңыз. Ол шотты өсіріп, жіктеу қатесін түзетуді қиындатады, ал жеке немесе құпия деректің жою мерзімі бұған қайшы келуі мүмкін. Өзгертуден қорғау шынымен қажет кластарды таңдап, оларды бөлек есептеңіз. Сонда өзгермейтін мұрағат ешкім тазалай алмайтын қымбат қоймаға емес, нақты бақылау құралына айналады.
Орынды шекараны қалпына келтіру уақыты белгілейді
Ұйым төрт сұраққа жазбаша жауап бергенде орынды шекара пайда болады: қай кезең бірнеше секундта ізделуі керек, ескі деректі неше сағат күтуге болады, әдеттегі қалпына келтіру көлемі қандай және мұрағат қолжетімсіз болса не болады. Содан кейін ыстық және жылы деңгей мерзімі әдеттен емес, нақты жұмыстан шығады.
Көптеген ағын үшін бастапқы нұсқаны тексеруге болады: 30 күн жедел іздеу, ең қажет кестелерге жылы деңгейде 90 күн және міндетті мерзімнің қалған бөлігін мұрағатта сақтау. Бұл бәріне ортақ норма емес. Артықшылықты әрекеттер аудитіне ұзақ интерактивті терезе қажет болуы мүмкін, ал толық жөндеу журналына әлдеқайда қысқа мерзім жеткілікті.
Шешімді қабылдау сынағымен бекітіңіз. Жедел деңгейден ескі кездейсоқ күнді таңдап, оқиғаның бір класын оқшауланған алаңға қалпына келтіріңіз, жазба саны мен бақылау сомасын тексеріңіз, тергеу сұрауын орындаңыз, содан кейін уақытша көшірмені қауіпсіз жойыңыз. Уақыт пен еңбекті өлшеңіз. Нәтиже SLA талабына жетпесе, шекараны жылжытыңыз немесе мұрағаттау тәсілін өзгертіңіз. Тағы бір жылға жылдам диск сатып алу осы сынақтан қашудың ең қымбат жолы болып қалады.
Ірі дереккөз қосылғанда, сызба, репликация коэффициенті немесе саясат өзгергенде модельді қайта есептеңіз. Тәуліктік көлем мен K мәнін айлық уақыт қатары ретінде сақтаған ыңғайлы. Сонда сыйымдылық жазу бұғатталғаннан кейін емес, толу шегіне жетпей сатып алынады. Орынды шекара бюджет жолы біткен жерде емес, қалпына келтіру жұмыс талабына әлі сыятын жерде өтеді.
FAQ
Журналдардың бір жылдық көлемін қалай есептеуге болады?
Бастапқы тәуліктік ағынды 365 күнге, өлшенген сақтау коэффициентіне, толық көшірме санына және өсу қорына көбейтіп, рұқсат етілген толу үлесіне бөліңіз. Резервтік көшірмені, қалпына келтірудің уақытша орнын және жүйелік деректі бөлек жолмен есептеңіз.
Логтар қоймасында қанша бос орын қалуы керек?
Платформа құжаттамасы көбірек қор талап етпесе, алғашқы жобада жұмыс толуын 80%-дан асырмаймын. Бос орын біріктіру, қайта теңгеру, қалпына келтіру және қабылдау шарықтауы үшін керек, сондықтан соңғы 5%-ды қалыпты сыйымдылық деп санауға болмайды.
Барлық оқиғалар журналын толық бір жыл сақтау керек пе?
Жоқ. Әр оқиға класына мерзімді оның операциялық, дәлелдік және нормативтік рөліне қарай тағайындаңыз. Толық жөндеу дерегі тез жойылуы мүмкін, ал құқық өзгерістері мен әкімші әрекеттері әлдеқайда ұзақ сақталады.
Бір жылдық логтарды тек суық мұрағатта ұстауға бола ма?
Саясат қалпына келтіру кідірісіне рұқсат берсе және мұрағат жеткілікті өрістерді, бақылау сомаларын және сызбаны сақтаса, болады. Жедел тергеу үшін жаңа бөлікті іздеу деңгейінде қалдырып, ескі деректі қайтаруды тұрақты тексеріңіз.
Есептеуге қандай сығу коэффициентін қолдану керек?
Өндірістегі сызбамен өз оқиғаларыңызда өлшенген коэффициентті ғана қолданыңыз. Бірнеше өкілді күнді жүктеп, фондық біріктіруді күтіңіз және негізгі дерек көлемін бастапқы кіріске бөліңіз. Мұрағат пішімін бөлек өлшеңіз.
Журнал репликасы резервтік көшірме болып санала ма?
Жоқ. Реплика түйін істен шыққанда қолжетімділікті сақтайды, бірақ қате жоюды немесе бүлінуді негізгі көшірмемен бірге қайталайды. Резервтік көшірменің өз өмірлік циклі және тексерілген қалпына келтіру рәсімі болуы керек.
Ескі логтарға HDD әлде объектілік қойма арзан ба?
Жауап көлемге, оқу жиілігіне, екінші алаңға, лицензияға, желіге және еңбекке тәуелді. Тек TB немесе GB-ай бағасын емес, қайтару мен уақытша сыйымдылықты қосып, үш-бес жылдық TCO-ны салыстырыңыз.
Индекс неге бастапқы файлдардан үлкен болуы мүмкін?
Платформа іздеу құрылымдарын, сөздіктерді, өріс мәндерін және метадеректі қосады, ал кездейсоқ мәндер нашар сығылады. Нәтиже сызба мен баптауға тәуелді, сондықтан бастапқы JSON көлемі индекс көлемін өздігінен болжай алмайды.
Мұрағат журналдарын қалпына келтіруді қаншалықты жиі тексеру керек?
Көп ортаға тоқсан сайынғы тексеріс жеткілікті, ал маңызды талаптар жиірек сынауды міндеттеуі мүмкін. Ескі кездейсоқ күнді таңдап, файлды жүктеумен шектелмей, бақылау сомаларын тексеріп, нақты тергеу сұрауын орындаңыз.
Жедел іздеу мерзімін 30 күннен 90 күнге қашан ұзарту керек?
Сұрау статистикасы бір айдан ескі тұрақты тергеулерді көрсетіп, мұрағатты күту келісілген жауап уақытын бұзғанда ұзартыңыз. Шешімді дөңгелек санға емес, нақты сұраулардың жасына және қосымша 60 күннің бағасына сүйеніп қабылдаңыз.