Restic пен Borg арқылы S3-та сақтық-көшірме: орнату, шифрлау, тесттер

«Коммерциялық агенттерсіз» не дегені және неге керек

«Коммерциялық агенттерсіз» дейді: әр серверге немесе жұмыс станциясына жабық вендор агентін орнатпай, оның лицензиясына, жабық форматына және бөлек консольға тәуелді болмай жұмыс істеу. Одан гөрі restic немесе borg сияқты қарапайым құралдарды қолданады да, деректерді S3-үйлесімді сақтау орнына жібереді.

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

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

Шекараларды түсіну маңызды. Restic пен borg S3-қа файлдық деректерді (каталогтар, конфигурациялар, дерекқор дамптары, сервер мен виртуалдардағы маңызды папкалардың «снапшоттары») жақсы қорғайды. Дегенмен күрделі қосымшалардың консистентті бэкаптары үшін әлі де сценарийлер керек: сервисті дұрыс тоқтату немесе дамп жасау, қалпына келтіруді тексеру, қосымшаның шынымен іске қосылатынына көз жеткізу.

Бұл тәсіл бір сервері бар офис, бірнеше филиалдар, шағын виртуал орта немесе типтік ПК мен реңжерлердегі серверлер паркі үшін жақсы келеді — ашықтық, бақылау және вендордан тәуелсіздік маңызды болса.

Негізгі схема: нені көшірген дұрыс, қайда және қалай қорғаныш жасаймыз

restic пен borg үшін S3-қа бэкаптың минималды жұмыс схемасы үш бөліктен тұрады: дерек көздері (сервер немесе жұмыс станциясы), бэкап репозиториясы (снапшоттардың жазылатын орны) және S3-үйлесімді сақтау ретінде қашық мақсат. Бұдан тыс әрқашан тағы екі қабат болады: шифрлау кілттері және рұқсат ережелері.

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

Restic-та шифрлау әдетте міндетті: репозиторий парольмен шифрланады, S3-те тек шифрланған блоктар қалады. Borg-та шифрлау репозиторийді инициализациялау режиміне байланысты, сондықтан бір рет саналы түрде шифрлауды таңдап, репозиторийді ашық күйде қалдырмау маңызды.

Негізгі сұрақ: парольдер мен кілттерді қайда сақтау керек. Практикалық варианттар:

• қоршаған орта айнымалылары және тек root-қа рұқсатталған файл
• егер бар болса жүйелік құпия сақтау орны
• апаттық қол жеткізу үшін офлайн тасымалдағыш (сервер жоғалған жағдайда)

S3-ке қолжетімдікті екі бағыттан тарылту дұрыс: желі және құқықтар. Желі бойынша тек бэкап жасайтын машиналарға ғана қосылуға рұқсат беріңіз және мүмкіндігінше қалғандарын фаервол немесе саясатпен жабық етіңіз. Құқықтар бойынша бэкап үшін бөлек тіркелгіні құрыңыз және операцияларды бөліңіз:

• күнделікті жұмыс үшін жазу (append)
• тек оқу — тексерістер мен қалпына келтіру тесттері үшін
• бөлек админ-доступ, кестеде қолданылмайтын

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

Restic немесе Borg: артық теориясыз қалай таңдау

Restic пен Borg бір мақсатты шешеді: деректердің «снапшоттарын» жасап, қайталанатын бэкаптарды аз орын алатындай ету. Екеуі де дедупликация, сығымдау (әртүрлі тәсілдермен) және клиент жағында шифрлауды қолдайды, яғни сақтау орнына барғанда деректер уже шифрланған блоктар түрінде жатады.

Айырмашылық әдетте «қайсысы жақсы» емес, сіз күнделікті қалай жұмыс жасайтындығыңызға байланысты болады: репозиторий қайда орналасады, тапсырмаларды қалай іске қосасыз, күйді қалай тексересіз және қаншалықты тез қалпына келесіз.

Қай кезде restic таңдау оңайырақ

Restic көбінесе S3-қа қосылуды «қораптан» істейтін жағдайларда ұнайды: машина -> S3 схемасы қарапайым және тікелей болады.

Restic мына жағдайда жарайды:

• S3-репозиторий негізгі нұсқа (облако немесе өз ЦОД-ыңызда)
• көп бірдей узелдер бар және бірдей командалар мен логтар керек
• окружениеда тәуелділіктер минималды, орнату қарапайым
• cron/systemd арқылы автоматтандыру түсінікті және күрделі орама қажет емес
• шаблон арқылы жаңа серверлерді тез қосу керек

Қай кезде borg логичнее

Borg репозиторийді бөлек серверде ұстап, SSH арқылы мәлімет жинау қажет кезде ыңғайлы. Бұл «орталық бэкап-сервер + көп көздер» сценарийі үшін жақсы, әсіресе егер S3 тек сыртқы көшірме ретінде пайдаланылса.

Borg келесі жағдайларға сай келеді:

• репозиторий файлдық жүйеде және кіру SSH арқылы
• қатты бақылаулы желі, жұмысшылардан тікелей S3-қа шықпайды
• «бір бэкап-хост бәріне қызмет етеді» моделі

Егер команда кішкентай болса, әдетте бір құралды стандарттау тиімді: дежуршыларды оқыту оңай, қалпына келтіру нұсқаулықтары бірдей болады және репозиторий форматтары, кілттер мен тексеру командаларында шатасу азаяды.

S3-үйлесімді сақтау мен қолжетімділікті дайындау

Бэкапты баптамас бұрын таңдаған сақтау шынымен үйлесімді ме екенін тексеріңіз. «S3-үйлесімді» кейде «S3-қа ұқсайды» дегенді білдіреді, бірақ түн ортасында, бэкап терезесі жабылып жатқанда кейбір нюанстар шығады.

Провайдерден көбіне әсер ететін жайттарды тексеріңіз: AWS Signature v4 қолдауы, үлкен объектілермен жұмыс (multipart upload), сұраулар мен объект өлшемдеріне шектеулер, және бакет адресациясының түрі. Егер аймаққа арналған жеке endpoint бар болса, оны алдын ала нақтылап, баптаңыз.

Ресурстарды бөліңіз: бэкап үшін бөлек бакет және бөлек пайдаланушы/кілт жасаңыз. Бұл кездейсоқ жою қаупін азайтады және аудитті жеңілдетеді.

Бэкап пайдаланушысына құқықтар чек-листі:

• тек бір бакетке қолжетімділік
• оқу, жазу, объектілер тізімін алу (есептік жазба бойынша әкімшілік операцияларсыз)
• мүмкін болса жоюға тыйым
• тест/өндірістік орта үшін бөлек кілттер

Егер сақтау нұсқалықты (versioning) ұсынса, бэкап бакетіне қосыңыз — объектілер жойылғанда немесе қайта жазылғанда пайдалы. Lifecycle ережелері қосып, нұсқалар шексіз өспесін қадағалаңыз: жиі қалпына келтіру нүктелерін қысқа ұстаңыз, сирек нүктелерді ұзағырақ сақтаңыз.

Құпия кілттерді пароль сияқты сақтаңыз: жалпы чаттарда немесе «заметкада» емес. Минимум — 600 құқықтарымен сервис-пайдаланушыға арналған файл. Жақсырақ — жүйелік құпия сақтау немесе systemd credentials.

Желіде тест жасаңыз: бэкап жүретін серверден 1–5 ГБ тест файл жүктеп — жүктеп көріңіз және нақты жылдамдық пен латентті фикс жасау, осылайша көшірме терезесіне сыйатынын бағалайсыз.

Restic баптауы: бастауға арналған қадамдар

restic пен borg S3-қа тұрақты бэкап үшін алдымен деректер тізімінен бастаңыз: не шынымен қалпына келтіргіңіз келетінін белгілеңіз (базалар, құжаттар, конфигтер) және не қайта құруға болатындығын көрсетіңіз (кэштер, уақытша файлдар). Бұл көшірме уақытын қысқартады және бэкап терезесін кемітеді.

Содан кейін S3-қа қолжетімділікті дайындап (ключ/секрет, бакет атауы, жол) және репозиторий паролін қайда сақтайтыныңызды таңдаңыз. Пароль әрқашан керек: restic клиент жағында шифрлайды және парольсіз репозиторий «қалпына келмейтін мұрағатқа» айналады.

Репозиторийді инициализациялау және алғашқы тексеріс мысалы (өз мәндеріңізді қойыңыз):

export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export RESTIC_REPOSITORY="s3:s3.example.local/backup-prod"
export RESTIC_PASSWORD="сильный_пароль"

restic -o s3.endpoint=s3.example.local init
restic snapshots

init-тен кейін бірінші толық бэкап жасаңыз. Бұл кезеңде идеалды исключения емес, жұмыс істейтін снимок алу маңызды:

restic -o s3.endpoint=s3.example.local backup /etc /home /var/lib/app
restic snapshots

Содан кейін артық нәрсені жібермеу үшін исключения қосыңыз. Әдетте келесілерді қояды:

• кэш каталогтары (мысалы, */cache*)
• уақытша файлдар (/tmp, */tmp*)
• қажет емес үлкен сборка және жүктемелер катологтары
• логтар, егер логтарды бөлек сақтау саясаты болса

Және міндетті қадам — «сынақтық қалпына келтіру» бөлек папкаға. Бұл бірнеше минут алады, бірақ пароль, S3 қолжетімдігі және деректер құрылымы дұрыс па соны көрсетеді.

mkdir -p /restore-test
restic restore latest --target /restore-test
ls -la /restore-test

Егер тест қалпына келтіру сәтті болса, сізде минималды жұмыс схема бар. Одан әрі исключенияларды файлға бекітіп, парольді ортадан шығарып, кестелеу мен бэкап терезесін бақылауға өтіңіз.

Borg баптауы: күтпеген жайттарсыз жұмыс схемасы

Borg файл деңгейінде жылдам инкрементал бэкапқа және ыңғайлы қалпына келтіруге жақсы. Borg репозиторийді өзіне файлдық жүйе ретінде жазатындықтан, S3-қа әдетте арадағы қабат арқылы жетеді.

Ең сенімді екі нұсқа бар. Біріншісі — репозиторийді бөлек SSH-шлюзда (немесе бэкап-серверде) ұстау, кейін репозиторий каталогын S3-қа жеке тапсырма арқылы көшіру. Екіншісі — S3-ты файлдық жүйе ретінде монтировать ету; ыңғайлы болғанымен кешігулер, блокировкалар және толық POSIX сәйкес еместік проблемалар тудыруы мүмкін. Borg үшін әдетте «алдымен локалды, сосын жүктеу» қауіпсізрек.

Инициализация және шифрлау

Кілт режимін таңдаңыз: ең оңайы repokey (кілт репозиторийде сақталады, парольмен қорғалған) немесе keyfile (кілт бөлек файлда, оны да резервте сақтау керек). Инициализация мысалы:

export BORG_REPO=ssh://backup@backup-gw/./repos/app1
export BORG_PASSPHRASE='СильныйПароль'

borg init --encryption=repokey-blake2 "$BORG_REPO"

Архив атауларын түсінікті етіп келісіңіз: тәжірибеде хост аты + рөлі + дата қойылады, іздеу мен салыстыру оңай болу үшін:

borg create --stats --compression lz4 \\
  "$BORG_REPO"::"srv1-app-{now:%Y-%m-%d_%H%M}" \\
  /etc /var/lib/app

Жоспар бойынша іске қосуды cron немесе systemd timer арқылы жасаңыз. «restic/borg + S3» схемасында Borg көбіне локалды инкременттер үшін жауап береді, ал S3-қа жүктеу сәтті архивтен кейін бөлек тапсырма ретінде жүреді.

Тексеру және тесттік қалпына келтіру

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

borg check --verify-data "$BORG_REPO"

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

mkdir -p /tmp/restore-test
borg extract "$BORG_REPO"::srv1-app-2026-01-11_0200 etc/app.conf
borg extract "$BORG_REPO"::srv1-app-2026-01-11_0200 --target /tmp/restore-test var/lib/app

Кестелеу және бэкап терезесін бақылау

Жақсы бэкап кестеге байланған және жұмыс сервистеріне кедергі жасамауы керек. restic/borg үшін жиі cron немесе systemd-timer жеткілікті. Маңыздысы — тапсырмаларды қалай іске қосқаныңыз емес, іске қосылғаннан кейін нәтижені қалай тексеретініңіз.

Кестені қалай жасау

Қарапайым нүктелерден бастап, нақты қажеттілік шықса күрделендіріңіз. Негізгі схема:

• әр түн: инкременталдық бэкап деректер мен конфигурацияларға
• аптасына бір рет: «тексеру» көшірмесі + репозиторий тұтастығын тексеру
• ай сайын: өте маңызды нүкте, оны мерзімінен бұрын жоюға болмайды
• өзгерістерден кейін: жаңарту немесе миграция алдындағы шұғыл бэкап

Осылай күнделікті қателіктер мен сирек кездесетін проблемаларды жабасыз.

Бэкап терезесін бақылау

Бэкап терезесі — көшірме дискіге, желіге және S3-қа әсер ететін уақыт. Оның өлшемін бір рет есептеп, деректер өсімінен кейін қайта қараңыз: тәуліктік өзгерістер мөлшерін алып, 2 есеге көбейтіп, нақты жүктеу жылдамдығымен салыстырыңыз.

Егер бэкап кедергі жасаса, жүктемені шектеңіз, кейбір тәжірибелер:

• жылдамдықты шектеу: restic-та upload/download шектеулері бар, borg-та remote-ratelimit
• параллелизмді азайту: аз ағын көбіне тұрақты жүктемені береді
• тапсырмаларды бөлу: деректер базасы мен үлкен каталогтарды әр түрлі уақытта көшіру
• артықтарды шығарған жөн: кэштер, уақытша файлдар және логтар

Табыстың белгісі — процесс логқа бір нәрсе жазып қана қоймай, дұрыс аяқталуы: restic — 0 қайтару коды, borg — 0 (borg-та код 1 әдетте «ескертулер бар» дегенді білдіреді, оны бөлу керек).

Қате туралы сигнал өзінен-өзі келуі тиіс. Минимум: дежур поштаға хат, жұмыс мессенджерге хабар немесе автоматты тикет. Мысалы, егер түнгі бэкап бухгалтерлік серверге терезеге сыймаса, хабар таңертең жұмыс басталғанға дейін келуі керек.

Сақтау, ротация және тұтастық тексерістері

Сақтау орнын ережесіз қалдырсаңыз, тез толып кетеді. «restic және borg S3-қа» үшін бұл маңызды, себебі S3-та сақтау және операциялар бойынша төлем жүргізіледі.

Сақтау ережелері: қанша ұстау және неге

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

• Күнделікті: 7–14 күн — кездейсоқ жойылғандарды қайтару үшін
• Апталық: 4–8 апта — кеш байқалған мәселелер үшін
• Айлық: 6–12 ай — есептер, аудит немесе маусымдық деректер үшін
• «Өзгерістер алдында»: жаңарту, миграция және патч алдында жеке снимок

Restic пен borg-та retention механизмдері бар. Бір маңызды нәрсе: ережелер бір типтегі барлық серверлерде бірдей болуы керек, әйтпесе көлемді болжау қиын.

Жою және қателіктерден қорғау

Жоюды тек құралдың өз қауіпсіз командаларымен жасаңыз, бакеттегі файлдарды қолмен өшірмеңіз. Автоматты prune/compact қосудан бұрын 1–2 апта «тек есеп» режимінде өткізіп, нені өшіретініңіз туралы есеп алыңыз.

Тұтастық тексерісін кестеге енгізіңіз:

• апта сайын метадеректерді тез тексеру
• ай сайын толық тексеріс, ұзақ және бөлек терезеде

S3 құны және дедупликация рөлі

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

Параметрлер тәңбесі

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

• дата және себеп (мысалы, каталог исключениясын қостық)
• кім мақұлдады
• кесте/retention-те не өзгерді
• бэкап терезесіне және көлемге күтілетін әсер

Осы жазбалар инциденттерді талдауды жеңілдетеді: «неліктен ескі көшірмелер жойылды» немесе «неліктен тұтастық тексерісі ұзап кетті».

Жүйелі қалпына келтіру тесттері: қалай ұйымдастыру керек

Резервтік көшірме жоқ жерде қалпына келтіру жоқ. Деректер қайда жазылғанын тексеріп қана қойып, қосымшаны іске қосу мен қызметтердің жұмысын тексермесеңіз, бұл тек «бірдеме жазылды» тексерісі.

Тесттер формальды болуы үшін күнтізбе жасаңыз: айына бір рет бір файл немесе кішкене папка қалпына келтіріп тексеріңіз, тоқсан сайын толық сценарийді іске қосыңыз. Бұл restic, borg және S3-қа арналған сценарийлер үшін бірдей маңызды.

Қайда және қалай қалпына келтіру

Тікелей жұмыс істеп тұрған деректерге қалпына келтірмеген дұрыс. Бөлек VM, тесттік диск каталогы немесе кішкене стенд жарайды. Офис инфрақұрылымында бұл тесттік виртуалка болуы мүмкін, пайдаланушылардан оқшауланған.

Тесттің бір жұмыс циклі мысалы:

• «эталон» файлын/папканы және қалпына келтіру күнін таңдау
• тесттік орынға қалпына келтіру, өлшем мен файлдар санын тексеру, таңдап хэшттерді салыстыру
• құқықтарды тексеру (владелецтар, топтар, режимдер) — қосымшалар оқи алатын болуы керек
• қосымшаны тест режимінде іске қосып негізгі сценарийді (логин, есеп, іздеу) тексеру
• тест деректерін жою немесе тексеріс нәтижесін архивтеу

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

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

Орнатуда жиі кездесетін қателіктер мен тұзақтар

Шифрлаудағы ең ауыр қате — пароль немесе кілтті жоғалтып, оны апат күнінде ғана байқап қалу. Restic пен borg үшін бұл деректер бар, бірақ оқылмайды дегенді білдіреді. Құпия менеджерінде кілттерді сақтау, қосымша офлайн-резерв және жауапты адамды алдын ала анықтау — қажет минимум.

Тағы бір қауіп бар: бэкапты «сол жерде» жасау — бір серверде, сол RAID-та немесе сол аккаунтта сақтау. Шабуыл, әкімші қатесі немесе сақтау ақауы кезінде жұмыс және резервтік көшірме бірдей жоғалуы мүмкін. restic пен borg S3-қа жасағанда, кем дегенде қолжетімділік деңгейлерін және мүмкін болса аккаунттарды бөліңіз.

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

Исключенияларды қате қою да кең таралған мәселе: уақытша файлдарды шығарғандай көрсеңіз де, дерекқор немесе қосымша кілттері шығарып салынып қалуы мүмкін. Исключенияларды өзгертсеңіз дереу сынақ жүргізіңіз және не түскенін қараңыз.

Соңында бэкаптар «тыныш түрде» бұзылуы мүмкін: түн сайын тапсырмалар құлап, ешкім байқамайды. Өзіңізді төмендегі тізім бойынша тексеріңіз:

• сәтсіз іске қосу және уақытты асу туралы хабарландыру бар ма
• соңғы сәтті бэкап пен оның көлемі көрініп тұра ма («0 МБ» пайда болса байқалсын)
• S3 кілттерінің мерзімі бар ма және ротация процедурасы анықталған ба
• репозиторий тұтастығы кезеңді тексеріледі ме
• айына бір рет тест қалпына келтіру орындалады ма

Мысал: қосымша жаңартылғаннан кейін деректер каталоги /var/lib-тен /srv-қа көшірілді, ал исключениялар өзгеріссіз қалды. Бэкап «сәтті» өтіп жатқандай көрінеді, бірақ қалпына келтіруге ештеңе жоқ. Мұндай жағдайларды көлем мониторингі мен жүйелі тесттер ғана ұстайды.

Мысал сценарий: офис инфрақұрылымы және S3 сыртқы көшірме ретінде

15–30 пайдаланушысы бар офис жағдайын елестетейік. Файлдық серверде ортақ папкалар (шарттар, сканерлер, жобалар), бөлек 1С машинасы мен дерекқор, және қосымша серверлерде маңызды каталогтар (конфигтер, есептер) бар. Мақсат — диск бұзылғанда, сервер істен шыққанда немесе біреу папканы өшіргенде деректерді тез әрі тәртіппен қайтару.

RPO және RTO-ны қарапайым тілде қойыңыз. RPO — қанша уақытқа дейін жоғалтуды қабылдайсыз: мысалы, бухгалтерлік жұмыс үшін максимум 1 сағат, жалпы папкалар үшін 4 сағат. RTO — қаншалықты тез қалпына келтіру керек: файлдарға 2 сағат ішінде қолжетімділік, 1С үшін 4–6 сағат (кемінде уақытша стенд).

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

Кесте үлгісі:

• түнде: толық прогон (немесе дедупликация логикасы бойынша) жүктеме аз кезде
• күндіз: маңызды деректер үшін 1–2 сағат сайын қысқа дельталар
• күн аяқталмас бұрын: 1С деректерінің дампы және оны сыртқы репозиторийге жіберу

Тест қалпына келтіруді апта сайын енгізіңіз: бірнеше папканы және бір файлды таңдап қалпына келтіріңіз. Ай сайын толық стендті көтеріп, серверді (бөлек машина немесе виртуалка) қалпына келтіріп, 1С ашылады ма тексеріңіз.

Жүйенің «барлығы қалыпты» екенін көрсететін метрикалар:

• соңғы сәтті бэкап жасының сағаттағы көрсеткіші (файл бойынша және база бойынша)
• бэкаптың ұзақтығы және ол түнгі терезеге сыя ма
• соңғы 7 күндегі тапсырмалардың сәттілік пайызы (қолмен қайта іске қосуларсыз)
• нақты тест қалпына келтіру уақыты (файл/базаны ашуға кеткен минуттар)

Келесі қадамдар: нәтижені бекіту және масштабтау

restic пен borg S3-қа продқа шығар алдында ұсақ мәселелерді реттеп алу пайдалы — дәл олар апат күнінде көбіне проблемалар тудырады.

Іске қосар алдында чек-лист

Қысқа тізім бойынша тексеріп барып кестені қосыңыз:

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

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

Қалай аралықтан масштабтау

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

• бір серверге бір репозиторий (жеке іздеу және қалпына келтіру оңай)
• рөл бойынша репозиторий (мысалы, біреулері — базалар, біреулері — файлдық деректер)
• қолжетім деңгейі бойынша репозиторийлер бөлінуі (қосымша админдері критикалы репозиториге қолжетімсіз болуы үшін)

Кейін бәрі ресурстарға келіп тіреледі. Түнгі терезелер сыймаса немесе жүктеме өссе, бөлек бэкап-сервер қосу керек. Желіні, CPU-ды дедупликация/сығымдау жеңбеуі үшін жабдық жаңарту ақталады.

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

Егер инфрақұрылым бойынша көмек керек болса, GSE.kz жүйелік интеграция тәжірибесі бар. Бэкап-сервер немесе сақтау түйіні үшін GSE S200 стойкалы серверлері жарамды болуы мүмкін, ал одан да маңыздысы — қалпына келтіру бойынша нақты SLO және жүйелі тексерістерге келісу.