Қолданба деректер қорын қалай сақтық көшіруге болады (және оны шынымен қалпына келтіру)

Қолданба дерекқорын сақтық көшіру үшін оны жоспар бойынша файлға экспорттаңыз (Postgres үшін стандартты құрал — pg_dump), көшірмелерді дерекқордан бөлек жерде сақтаңыз және бос дерекқорға үнемі қалпына келтіріп, жұмыс істейтінін дәлелдеңіз. Қауіпті өзгеріс алдында қосымша сақтық көшірме жасаңыз. Код көшірмесі — GitHub репозиторийі ме, экспорт па — деректеріңізді қамтымайды.

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

Сақтық көшірме нені қамтуы керек

Қолданба тек дерекқордан тұрмайды. Әр сақтық көшірме нені қорғайтынын білу керек.

Қалпына келтіре алмайтын бөлік — деректер. Кодты қайта жазуға, баптауларды қайта енгізуге болады; ал клиенттеріңіздің тапсырыстарын қайтара алмайсыз.

1-қадам: қанша деректі жоғалтуға болатынын шешіңіз

Жоспарды екі сұрақ анықтайды:

• Соңғы қанша деректі жоғалтуға болады? Егер күніне бір рет сақтық көшірме жасасаңыз, ал дерекқор кешке бұзылса, сол күнгі өзгерістерді жоғалтасыз. Хобби қолданба үшін бұл қалыпты. Тапсырыс қабылдайтын қолданба үшін ол қолайсыз болуы мүмкін.
• Қалпына келтіру кезінде қолданба қанша уақыт өшіп тұрады? Шағын дерекқор бірнеше минутта қалпына келеді. Үлкен дерекқор едәуір ұзақ уақыт алуы мүмкін, оны қажет болмай тұрып білгеніңіз дұрыс.

Көптеген шағын қолданба үшін күн сайынғы автоматты сақтық көшірме және қауіпті өзгерістерден бұрын қолмен сақтық көшірме — жақсы бастама. Ақша немесе денсаулық деректері бар қолданбаларға жиірек сақтық көшірме немесе point-in-time recovery (кез келген сәтке қайтару мүмкіндігі, тек соңғы сақтық көшірме емес) бар басқарылатын дерекқор керек.

2-қадам: хостингіңіз не істейтінін тексеріңіз

Көптеген басқарылатын дерекқор провайдерлері автоматты сақтық көшірме жасайды. Мыналарды анықтаңыз:

• Тарифіңізде сақтық көшірме қосулы ма және ол қанша жиі жасалады?
• Олар қанша уақыт сақталады?
• Бір сәтке қайтаруға бола ма, әлде тек күнделікті суреттен ба?
• Сақтық көшірмені жүктеп алуға бола ма, әлде тек өз жүйелерінде қалпына келтіруге бола ма?

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

3-қадам: pg_dump арқылы дамп жасаңыз

pg_dump Postgres дерекқорын файлға экспорттайды. Ол дерекқордың тұрақты суретін оқиды, сондықтан қолданба жұмысын тоқтатпай-ақ істей береді.

Қолданбаңызда бұрыннан бар қосылым жолын орта айнымалысынан пайдаланатын типтік команда:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Опциялардың қызметі:

• --format=custom — pg_restore оқи алатын сығылған файл жазады, әрі кестелерді кейін жеке қалпына келтіруге мүмкіндік береді. Оқуға ыңғайлы .sql файлы керек болса, --format=plain пайдаланыңыз.
• --no-owner — иелік командаларын алып тастайды, бұл дерекқорға басқа жерде қалпына келтіруді жеңілдетеді.
• Файл атындағы күн сақтық көшірмелерді бір-бірінен ажыратады.

pg_dump нұсқасы дерекқорыңыздың Postgres нұсқасымен бірдей немесе одан жаңа болуы керек. Ескі pg_dump іске қосудан бас тартуы мүмкін.

Командалық жолмен жұмыс істегіңіз келмесе, сұрай аласыз:

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

4-қадам: автоматтандырыңыз

Қолмен жасалған сақтық көшірмелерді ұмытып кетуге болады. Қолдау көрсететін құралдарыңызбен автоматтандырыңыз:

• Дерекқор провайдерінің жоспарлы сақтық көшірмелері, егер ол ұсынса.
• Жоспарланған тапсырма сервер немесе CI қызметінде, ол pg_dump іске қосып, файлды қоймаға жүктейді.
• Хостингтік сақтық көшіру қызметі, ол дерекқорыңызға қосылады.

Қандай таңдасаңыз да, сақтық көшірме сәтсіз болғанда сізге хабарлайтын етіңіз. Үш ай бойы үнсіз сәтсіз аяқталған сақтық көшіру тапсырмасы — классикалық апат.

5-қадам: көшірмелерді басқа жерде сақтаңыз

Ереже көбінесе 3-2-1 деп аталады: деректердің үш көшірмесі, екі түрлі сақтау орнында, біреуі басқа жерде. Шағын қолданба үшін практикалық нұсқа:

• Тірі дерекқор
• Провайдердің өз автоматты сақтық көшірмелері
• Өз дампыңыз басқа аккаунттағы объектілерді сақтау бакетінде

Сонымен қатар:

• Қолжетімділікті шектеңіз. Сақтық көшірмеде барлық пайдаланушының деректері бар. Оны тірі дерекқор сияқты қараңыз.
• Сақтау ережесін жазып қойыңыз. Мысалы, күнделікті көшірмелер екі апта, айлық көшірмелер бір жыл. Ескі көшірмелерді әдейі жойыңыз, сондай-ақ құпиялық заңдары жеке деректерді сұрау бойынша жоюды талап етуі мүмкін екенін есте сақтаңыз.
• Сақтық көшірмені Git-ке ешқашан коммит жасамаңыз. Репозиторийдегі дамп — деректер ағып кетуін күтіп тұрған жағдай.

6-қадам: қалпына келтіруді сынаңыз

Сақтық көшірме тек соңғы сәтті қалпына келтіру кезіндегідей жақсы. Кем дегенде бірнеше айда бір рет және сақтық көшіру процесі өзгерген сайын:

1. Жаңа, бос дерекқор жасаңыз. Тестілеу үшін ешқашан тірі дерекқорды үстінен жазбаңыз.
2. Соңғы сақтық көшірмені соған қалпына келтіріңіз:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Таза .sql файлы үшін psql "$TEST_DATABASE_URL" -f backup.sql пайдаланыңыз.

1. Барлық кестенің бар екенін тексеріңіз, жолдар санын тірі дерекқормен салыстырыңыз және соңғы бірнеше жазбаға қараңыз.
2. Мүмкін болса, қолданбаның көшірмесін соған бағыттап, кіріп көріңіз.
3. Қалпына келтіру қанша уақыт алғанын жазып қойыңыз. Бұл — сіздің нақты қалпына келтіру уақытыңыз.

7-қадам: қауіпті өзгерістерден бұрын сақтық көшіріңіз

Жаңа сақтық көшірмені мына жағдайлардан бұрын жасаңыз:

• Бағандарды жоятын немесе атын өзгертетін дерекқор миграциясын іске қосу
• Деректерді жаппай импорттау
• AI агентіне деректер моделіне үлкен өзгеріс жасауға рұқсат беру
• Ескі жазбаларды жою

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

Жиі кездесетін қателер

• Git немесе код экспорты сақтық көшірме деп ойлау. Онда код бар, деректер жоқ.
• Қалпына келтіруді ешқашан сынамау. Көптеген сақтық көшірме қажет болған кезде ғана бос, толық емес немесе оқылмайтын болып шығады.
• Сақтық көшірмелерді дерекқормен бір аккаунтта ұстау. Бір скомпрометацияланған немесе жабылған аккаунт екеуін де жояды.
• Жүктелген файлдарды ұмыту. Дерекқор файлдың жолын сақтайды, ал сурет өзі объектілерді сақтауда тұрады.
• Сақтық көшіру скрипттерінде құпияларды қалдыру. Қосылым жолын скрипт мәтінінен емес, орта айнымалысынан оқыңыз. Қараңыз: API кілттерін қалай қауіпсіз ұстау керек.

Сақтық көшірме және Mythex

Mythex жобаларында бөлек Postgres дерекқоры болуы мүмкін, оның байланыс деректері жұмыс кеңістігіне және жарияланған қолданбаға енгізіледі. Mythex құжаттарында дерекқорды сақтық көшіру немесе қалпына келтіру мүмкіндігі сипатталмаған, сондықтан өз жоспарыңызды жасаңыз: агенттен дамп жасауды сұраңыз, оны жүктеп алып, қауіпсіз жерде сақтаңыз, әсіресе үлкен өзгерістерден бұрын. Жоба экспорты (Pro) кодты қамтиды, құпиялар мен node_modules алынып тасталған; ол дерекқор жолдарын қамтымайды. Толығырақ құжаттарда Дерекқор және Деректерге иелік ету бөлімдерін оқыңыз. Дерекқордың өзі туралы көбірек білгіңіз келсе, Postgres деген не мақаласын оқыңыз.

Сақтық көшірме тексеру парағы

• Қанша деректі жоғалтуға болатыны және қанша уақыт өшіп тұруға болатыны анықталды
• Дерекқор хостингі қандай автоматты сақтық көшірме беретіні тексерілді
• Өз дампыңыз жоспар бойынша іске қосылады, сәтсіздіктер туралы хабар келеді
• Көшірмелер дерекқордан бөлек, қолжетімділігі шектелген жерде сақталады
• Сақтау ережесі жазылып қойылған
• Жүктелген файлдар да сақтық көшіріледі
• Қалпына келтіру бос дерекқорда сыналды, жолдар саны тексерілді
• Әр қауіпті өзгерістен бұрын сақтық көшірме жасалады

Сұрақтар