Как да архивирате базата данни на приложението си (и наистина да я възстановите)

За да архивирате базата данни на приложението си, я експортирайте във файл по график (за 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 може да прочете, и ви позволява по-късно да възстановите отделни таблици. Използвайте --format=plain, ако предпочитате четим .sql файл.
• --no-owner пропуска командите за собственост, което прави възстановяването в друга база по-просто.
• Датата в името на файла държи архивите отделени.

Версията на pg_dump трябва да е същата или по-нова от версията на Postgres на базата ви. По-стар pg_dump може да откаже да работи.

Ако работите с AI и не искате да докосвате командния ред, можете да попитате:

Направи архив на базата данни на приложението с 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: Архивирайте преди рискови промени

Направете свеж архив точно преди:

• Изпълнение на миграция на базата, която премахва или преименува колони
• Масов импорт на данни
• Оставяне на AI агент да направи големи промени в модела на данните
• Изтриване на стари записи

В приложение, създадено с AI, агентът може да промени структурата на таблиците като част от дадена функция. Контролните точки и контролът на версиите връщат назад кода ви, но не възстановяват изтрити редове. Архивът от тридесет секунди преди голяма промяна е евтина застраховка.

Чести грешки

• Приемането, че Git или експортът на кода е архив. Той съдържа кода, а не данните.
• Никога да не тествате възстановяване. Много архиви се оказват празни, непълни или нечетливи точно когато са ви нужни.
• Пазене на архивите в същия акаунт като базата. Един компрометиран или закрит акаунт губи и двете.
• Забравяне на качените файлове. Базата данни пази пътя до файла; самата снимка е в хранилището.
• Оставяне на тайни данни в скриптове за архивиране. Прочетете низа за връзка от променлива на средата, никога от текста на скрипта. Вижте как да пазите API ключовете си в безопасност.

Архиви и Mythex

Проектите в Mythex могат да имат собствена Postgres база данни, а данните за връзка с нея се инжектират в работното пространство и в публикуваното приложение. Документацията на Mythex не описва функция за архивиране или възстановяване на базата, затова планирайте сами: помолете агента да направи дъмп, изтеглете го и го пазете на сигурно място, особено преди големи промени. Експортът на проект (Pro) съдържа кода ви, като тайните данни и node_modules са изключени; той не съдържа редове от базата данни. Вижте Database и Data ownership в документацията. За повече за самата база данни прочетете какво е Postgres.

Контролен списък за архивиране

• Решено е колко данни можете да си позволите да загубите и колко време можете да сте недостъпни
• Проверено е какви автоматични архиви предоставя хостът на базата
• Вашият собствен дъмп работи по график и провалите ви уведомяват
• Копията се пазят отделно от базата, с ограничен достъп
• Политиката за съхранение е записана
• Качените файлове са архивирани заедно с базата
• Възстановяването е тествано в празна база, с проверен брой редове
• Архив се прави преди всяка рискова промяна

Въпроси