Како да направите резервна копија на базата на апликацијата (и навистина да ја вратите)

За да направите бекап на базата на апликацијата, извезете ја во датотека по распоред (за Postgres, стандардната алатка е pg_dump), чувајте ги копиите на место одделено од базата и редовно вратете една во празна база за да докажете дека работи. Направете дополнителен бекап веднаш пред секоја ризична промена. Бекапот на кодот, било да е GitHub репозиториум или извоз, не ги содржи вашите податоци.

Овој водич е за луѓе што водат мала апликација и сакаат да престанат да се грижат дека ќе ја изгубат. Во примерите се користи Postgres, бидејќи повеќето апликации направени со вештачка интелигенција го користат, но начелата важат за која било база.

Што треба да покрие бекапот

Апликацијата е повеќе од нејзината база. Знајте кој дел го штити секој бекап.

Податоците се делот што не може да се создаде повторно. Кодот може да се напише пак, а поставките може повторно да се внесат; нарачките на вашите клиенти не можат.

Чекор 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 и овозможува подоцна да се враќаат поединечни табели. Користете --format=plain ако сакате читлива .sql датотека.
• --no-owner ги испушта командите за сопственост, што го олеснува враќањето во друга база.
• Датумот во името на датотеката ги држи бекапите одделни.

Верзијата на pg_dump треба да биде иста или понова од верзијата на Postgres на базата. Постара pg_dump може да одбие да се изврши.

Ако градите со вештачка интелигенција и не сакате да работите со командната линија, можете да побарате:

Направи бекап на базата на апликацијата со pg_dump во прилагоден формат, со денешниот датум во името на датотеката. Не ја печати врската до базата ниту некоја тајна. Кажи ми го името на датотеката и нејзината големина кога ќе заврши.

Чекор 4: Автоматизирајте го

Рачните бекапи често се заборават. Автоматизирајте ги со она што го поддржува вашето поставување:

• Заказаните бекапи на провајдерот на базата, ако ги нуди.
• Заказана задача на сервер или CI сервис што го извршува pg_dump и ја прикачува датотеката во складиште.
• Хостирана услуга за бекап што се поврзува со вашата база.

Што и да изберете, нека ве известува кога бекапот ќе падне. Задача за бекап што тивко не работи три месеци е класичната страшна приказна.

Чекор 5: Чувајте копии на друго место

Правилото на палец често се нарекува 3-2-1: три копии од податоците, на два различни типа складиште, а една копија надвор од локацијата. За мала апликација, практична верзија е:

• Живата база
• Автоматските бекапи на провајдерот
• Ваши сопствени дампови во одделно складиште, како bucket за складиште на објекти во друга сметка

Исто така:

• Ограничете го пристапот. Бекапот ги содржи податоците на секој корисник. Третирајте го како жива база.
• Имајте политика за чување. На пример, дневни бекапи две недели и месечни една година. Старите бекапи бришете намерно, и имајте предвид дека законите за приватност може да бараат да ги избришете личните податоци кога ќе ги побара корисникот.
• Никогаш не ги ставајте бекапите во 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: Направете бекап пред ризични промени

Направете свеж бекап непосредно пред:

• Извршување на миграција на база што брише или преименува колони
• Масовен увоз на податоци
• Дозволување на агент со вештачка интелигенција да прави големи промени во моделот на податоци
• Бришење стари записи

Во апликација направена со вештачка интелигенција, агентот може да ја промени структурата на табелите како дел од една функција. Checkpoints и контролата на верзии ги враќаат назад вашиот код, но не ги враќаат избришаните редови. Бекап од триесет секунди пред голема промена е евтино осигурување.

Чести грешки

• Претпоставка дека Git или извозот на кодот е бекап. Тие го содржат кодот, а не податоците.
• Никогаш не тестирање на враќањето. Многу бекапи се испаѓаат празни, нецелосни или нечитливи токму кога ќе ви требаат.
• Чување бекапи во истата сметка како базата. Една компромитирана или затворена сметка губи и двете.
• Заборавање на прикачените датотеки. Базата ја чува патеката до датотеката; самата слика е во складиштето.
• Тајни во скриптите за бекап. Читајте ја врската до базата од променлива на околината, никогаш од текстот на скриптата. Видете како да ги чувате API клучевите безбедни.

Бекапи и Mythex

Проектите во Mythex можат да имаат посветена Postgres база, а нејзините податоци за врска се вметнуваат во работниот простор и објавената апликација. Документацијата на Mythex не опишува функција за бекап или враќање на база, па планирајте свој: побарајте од агентот да направи дамп, преземете го и чувајте го на безбедно место, особено пред големи промени. Извозот на проект (Pro) го содржи вашиот код, без тајни и node_modules; не содржи редови од базата. Видете Database и Data ownership во документацијата. За повеќе за самата база, прочитајте што е Postgres.

Листа за проверка на бекап

• Одлучено колку податоци можете да изгубите и колку долго можете да бидете недостапни
• Проверено што автоматски бекапи нуди вашиот хост на базата
• Вашиот дамп се извршува по распоред, а падовите ве известуваат
• Копиите се чуваат одделно од базата, со ограничен пристап
• Запишана политика за чување
• Прикачените датотеки се бекапирани исто како и базата
• Враќањето е тестирано во празна база, со проверен број на редови
• Бекап е направен пред секоја ризична промена

Прашања