Як зробити резервну копію бази даних застосунку (і справді її відновити)

Щоб зробити резервну копію бази даних застосунку, експортуйте її у файл за розкладом (для Postgres стандартний інструмент — pg_dump), зберігайте копії окремо від бази даних і регулярно відновлюйте одну з них у порожню базу, щоб переконатися, що вона працює. Зробіть додаткову копію перед будь-якою ризикованою зміною. Резервна копія коду, будь то репозиторій на GitHub чи експорт, не містить ваших даних.

Цей посібник для тих, хто веде невеликий застосунок і хоче перестати боятися його втратити. У прикладах використовується Postgres, адже більшість застосунків, створених за допомогою ШІ, працюють саме з ним, але принципи підходять для будь-якої бази даних.

Що має охоплювати резервна копія

Застосунок — це більше, ніж його база даних. Знайте, яку частину захищає кожна копія.

Дані — це та частина, яку неможливо відтворити. Код можна переписати, а налаштування ввести знову; замовлення клієнтів — ні.

Крок 1: вирішіть, скільки ви можете втратити

Два питання визначають ваш план резервного копіювання:

• Скільки останніх даних ви можете дозволити собі втратити? Якщо копію робити раз на добу і база зламається ввечері, ви втратите зміни за день. Для хобі-проєкту це прийнятно. Для застосунку, який приймає замовлення, може бути неприйнятно.
• Як довго застосунок може бути недоступним, поки ви відновлюєте дані? Невелика база відновлюється за хвилини. Велика може тривати набагато довше, і це варто знати заздалегідь, а не тоді, коли це знадобиться.

Для більшості невеликих застосунків хорошим початком є щоденна автоматична копія плюс ручна перед ризикованими змінами. Застосункам, пов'язаним з грошима або медичними даними, потрібні частіші копії або керована база даних із відновленням на будь-який момент часу (можливість відновити дані на будь-яку мить, а не лише до останньої копії).

Крок 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: три копії даних, на двох різних типах носіїв, і одна з них поза межами основного розташування. Для невеликого застосунку практичний варіант такий:

• Активна база даних
• Автоматичні копії від провайдера
• Ваші власні дампи в окремому сховищі, наприклад у бакеті об'єктного сховища в іншому обліковому записі

Крім того:

• Обмежте доступ. Резервна копія містить дані кожного користувача. Ставтеся до неї так само, як до активної бази.
• Визначте політику зберігання. Наприклад, щоденні копії за два тижні та щомісячні за рік. Старі копії видаляйте свідомо, пам'ятаючи, що закони про конфіденційність можуть вимагати видалити персональні дані на запит.
• Ніколи не додавайте резервні копії до 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: робіть копію перед ризикованими змінами

Зробіть свіжу копію безпосередньо перед тим, як:

• Запускати міграцію бази даних, яка видаляє або перейменовує стовпці
• Масово імпортувати дані
• Дозволяти агенту ШІ великі зміни моделі даних
• Видаляти старі записи

У застосунку, створеному за допомогою ШІ, агент може змінити структуру таблиць як частину нової функції. Контрольні точки й контроль версій відкочують код, але не повертають видалені рядки. Копія за півхвилини перед великою зміною — недорогий захист.

Типові помилки

• Вважати Git або експорт коду резервною копією. Там є код, а не дані.
• Ніколи не перевіряти відновлення. Багато копій виявляються порожніми, неповними або нечитабельними саме тоді, коли вони потрібні.
• Зберігати копії в тому самому обліковому записі, що й база даних. Один зламаний чи закритий обліковий запис втрачає і те, і інше.
• Забувати про завантажені файли. База даних зберігає шлях до файлу, а саме зображення лежить у сховищі.
• Залишати секрети в скриптах резервного копіювання. Читайте рядок підключення зі змінної середовища, а не з тексту скрипта. Див. як безпечно зберігати ключі API.

Резервні копії та Mythex

У проєктів Mythex може бути окрема база даних Postgres, а її параметри підключення передаються в робочий простір і опублікований застосунок. Документація Mythex не описує функцію резервного копіювання або відновлення бази даних, тож плануйте власну: попросіть агента створити дамп, завантажте його й зберігайте в безпечному місці, особливо перед великими змінами. Експорт проєкту (Pro) містить ваш код, без секретів і node_modules; рядків бази даних він не містить. Див. База даних та Володіння даними у документації. Щоб дізнатися більше про саму базу даних, прочитайте що таке Postgres.

Чек-лист резервного копіювання

• Визначено, скільки даних ви можете дозволити собі втратити і як довго можете бути недоступними
• Перевірено, які автоматичні копії надає ваш хостинг бази даних
• Ваш власний дамп працює за розкладом, а збої надсилають сповіщення
• Копії зберігаються окремо від бази даних, з обмеженим доступом
• Політику зберігання записано
• Завантажені файли скопійовано так само, як і базу даних
• Відновлення перевірено в порожній базі, кількість рядків перевірено
• Копію зроблено перед кожною ризикованою зміною

Запитання