Jak zrobić kopię zapasową bazy danych aplikacji (i naprawdę ją przywrócić)

Aby zrobić kopię zapasową bazy danych aplikacji, wyeksportuj ją do pliku według harmonogramu (dla Postgresa standardowym narzędziem jest pg_dump), przechowuj kopie w miejscu oddzielnym od bazy i regularnie przywracaj jedną z nich do pustej bazy, aby sprawdzić, czy działa. Przed każdą ryzykowną zmianą zrób dodatkową kopię. Kopia zapasowa kodu, czyli repozytorium GitHub albo eksport, nie zawiera Twoich danych.

Ten przewodnik jest dla osób, które prowadzą małą aplikację i chcą przestać martwić się jej utratą. Jako przykład używamy Postgresa, bo większość aplikacji tworzonych przez AI korzysta właśnie z niego, ale zasady dotyczą każdej bazy danych.

Co musi obejmować kopia zapasowa

Aplikacja to więcej niż jej baza danych. Wiedz, którą część chroni każda kopia.

Dane to część, której nie da się odtworzyć. Kod można napisać od nowa, a ustawienia wprowadzić ponownie; zamówień klientów nie da się.

Krok 1: Ustal, ile danych możesz stracić

Dwa pytania określają Twój plan kopii zapasowych:

• Ile ostatnich danych możesz sobie pozwolić stracić? Jeśli kopiujesz raz dziennie, a baza ulegnie awarii wieczorem, stracisz zmiany z całego dnia. Dla aplikacji hobbystycznej to wystarczy. Dla aplikacji przyjmującej zamówienia może być nie do przyjęcia.
• Jak długo aplikacja może być niedostępna podczas przywracania? Mała baza przywraca się w kilka minut. Duża może zajmować znacznie dłużej, a ten czas warto znać, zanim będzie potrzebny.

Dla większości małych aplikacji dobrym początkiem jest automatyczna kopia codzienna oraz ręczna przed ryzykownymi zmianami. Aplikacje, w których pojawiają się pieniądze lub dane zdrowotne, potrzebują częstszych kopii albo zarządzanej bazy z odzyskiwaniem do dowolnego momentu (możliwością przywrócenia stanu z dokładnej chwili, a nie tylko z ostatniej kopii).

Krok 2: Sprawdź, co już robi Twój dostawca

Wiele zarządzanych dostawców baz danych wykonuje automatyczne kopie. Sprawdź:

• Czy kopie są włączone w Twoim planie i jak często się wykonują?
• Jak długo są przechowywane?
• Czy możesz przywrócić stan z dowolnej chwili, czy tylko z dziennego zrzutu?
• Czy możesz pobrać kopię, czy tylko przywrócić ją w ramach ich systemu?

Kopie dostawcy są przydatne, ale mają jeden wspólny punkt awarii z bazą: konto. Jeśli konto zostanie zamknięte, zawieszone albo projekt zostanie usunięty, kopie mogą przepaść razem z nim. Dlatego warto mieć też własną kopię.

Krok 3: Wykonaj zrzut za pomocą pg_dump

pg_dump eksportuje bazę Postgresa do pliku. Odczytuje spójny migawkowy stan bazy, więc aplikacja może działać dalej podczas jego wykonywania.

Typowe polecenie, używające połączenia z bazą, które Twoja aplikacja już ma w zmiennej środowiskowej:

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

Co robią opcje:

• --format=custom zapisuje skompresowany plik, który może odczytać pg_restore, i pozwala później przywrócić pojedyncze tabele. Użyj --format=plain, jeśli chcesz czytelny plik .sql.
• --no-owner pomija polecenia dotyczące właścicieli, co upraszcza przywracanie do innej bazy.
• Data w nazwie pliku oddziela od siebie kolejne kopie.

Wersja pg_dump powinna być taka sama jak wersja Postgresa Twojej bazy albo nowsza. Starsze pg_dump może odmówić uruchomienia.

Jeśli budujesz z pomocą AI i nie chcesz korzystać z wiersza poleceń, możesz poprosić:

Utwórz kopię zapasową bazy danych aplikacji za pomocą pg_dump w formacie custom, z dzisiejszą datą w nazwie pliku. Nie wyświetlaj połączenia do bazy ani żadnego sekretu. Po zakończeniu podaj nazwę pliku i jego rozmiar.

Krok 4: Zautomatyzuj to

Ręczne kopie zapasowe łatwo zapomnieć. Zautomatyzuj je za pomocą tego, co obsługuje Twoja konfiguracja:

• Zaplanowane kopie Twojego dostawcy bazy danych, jeśli je oferuje.
• Zadanie cykliczne na serwerze albo w usłudze CI, które uruchamia pg_dump i wysyła plik do magazynu.
• Hostowaną usługę kopii zapasowych, która łączy się z Twoją bazą.

Niezależnie od wyboru, ustaw powiadomienie o błędzie kopii. Zadanie kopiujące, które po cichu nie działa od trzech miesięcy, to klasyczny scenariusz katastrofy.

Krok 5: Przechowuj kopie w innym miejscu

Zasada kciuka, często nazywana 3-2-1, mówi o trzech kopiach danych, na dwóch różnych rodzajach nośników, z jedną kopią poza siedzibą. Dla małej aplikacji praktyczna wersja to:

• Baza na żywo
• Automatyczne kopie u dostawcy
• Własne zrzuty w oddzielnym magazynie, na przykład w bucketcie magazynu obiektów na innym koncie

Dodatkowo:

• Ogranicz dostęp. Kopia zawiera dane wszystkich użytkowników. Traktuj ją jak bazę na żywo.
• Ustal politykę retencji. Na przykład kopie dzienne przez dwa tygodnie i miesięczne przez rok. Stare kopie usuwaj świadomie, pamiętając, że przepisy o ochronie danych mogą wymagać usunięcia danych osobowych na żądanie.
• Nigdy nie commituj kopii do Gita. Zrzut w repozytorium to wyciek danych, który dopiero czeka, aby się wydarzyć.

Krok 6: Przetestuj przywracanie

Kopia jest tyle warta, ile Twoje ostatnie udane przywrócenie. Przynajmniej co kilka miesięcy, a także po każdej zmianie procesu kopii zapasowych:

1. Utwórz nową, pustą bazę danych. Nigdy nie przywracaj testowo na bazę na żywo.
2. Przywróć najnowszą kopię do niej:

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

Dla zwykłego pliku .sql użyj zamiast tego psql "$TEST_DATABASE_URL" -f backup.sql.

1. Sprawdź, czy istnieją wszystkie tabele, porównaj liczbę wierszy z bazą na żywo i przejrzyj kilka ostatnich rekordów.
2. Jeśli możesz, podłącz do niej kopię aplikacji i zaloguj się.
3. Zapisz, ile trwało przywracanie. To Twój rzeczywisty czas odzyskiwania.

Krok 7: Rób kopię przed ryzykownymi zmianami

Zrób świeżą kopię tuż przed:

• Uruchomieniem migracji bazy, która usuwa lub zmienia nazwy kolumn
• Masowym importem danych
• Pozwoleniem agentowi AI na duże zmiany w modelu danych
• Usuwaniem starych rekordów

W aplikacji zbudowanej przez AI agent może zmienić strukturę tabel jako część nowej funkcji. Punkty kontrolne i kontrola wersji cofają kod, ale nie przywracają usuniętych wierszy. Kopia zapasowa wykonana przez pół minuty przed dużą zmianą to tani sposób na ubezpieczenie.

Częste błędy

• Zakładanie, że Git albo eksport kodu to kopia zapasowa. Mają kod, a nie dane.
• Nigdy nieprzetestowane przywracanie. Wiele kopii okazuje się pustych, niepełnych albo nieczytelnych dopiero wtedy, gdy są potrzebne.
• Trzymanie kopii na tym samym koncie co baza. Jedno przejęte lub zamknięte konto kasuje oba.
• Zapominanie o przesłanych plikach. Baza przechowuje ścieżkę do pliku; sam obraz znajduje się w magazynie.
• Zostawianie sekretów w skryptach kopii zapasowych. Odczytuj ciąg połączenia ze zmiennej środowiskowej, nigdy z treści skryptu. Zobacz jak zabezpieczyć klucze API.

Kopie zapasowe a Mythex

Projekty w Mythex mogą mieć dedykowaną bazę Postgres, a jej dane połączenia są wstrzykiwane do przestrzeni roboczej i opublikowanej aplikacji. Dokumentacja Mythex nie opisuje funkcji tworzenia i przywracania kopii bazy danych, więc zaplanuj własną: poproś agenta o wykonanie zrzutu, pobierz go i przechowuj w bezpiecznym miejscu, zwłaszcza przed dużymi zmianami. Eksport projektu (plan Pro) zawiera Twój kod, z pominiętymi sekretami i node_modules; nie zawiera wierszy z bazy danych. Więcej znajdziesz w dokumentacji: Baza danych oraz Własność danych. Aby dowiedzieć się więcej o samej bazie, przeczytaj czym jest Postgres.

Lista kontrolna kopii zapasowych

• Ustalono, ile danych możesz stracić i jak długo możesz być niedostępny
• Sprawdzono, jakie automatyczne kopie oferuje dostawca bazy
• Własny zrzut działa według harmonogramu, a awarie wysyłają powiadomienie
• Kopie są przechowywane osobno od bazy, z ograniczonym dostępem
• Polityka retencji jest spisana
• Przesłane pliki są objęte kopią zapasową, tak jak baza
• Przywracanie przetestowano do pustej bazy i sprawdzono liczbę wierszy
• Kopia wykonana przed każdą ryzykowną zmianą

Pytania