Problemy i błędy podczas przywracania danych

Wydaje się, że backup to jak parasol w deszczowy dzień: myślisz, że uratuje cię przed wszystkimi problemami. Ale jeśli w tym parasolu jest dziura, i tak zmokniesz. Z backupami i przywracaniem jest podobnie: jeśli coś pójdzie nie tak, możesz stracić dane albo, co gorsza, dostać uszkodzoną bazę danych. Dlatego właśnie zrozumienie błędów i ich zapobieganie jest tak ważne.

Problemy podczas przywracania danych

1. Niekompatybilność wersji PostgreSQL

Jednym z najczęstszych i najbardziej wkurzających problemów jest próba przywrócenia danych utworzonych na jednej wersji PostgreSQL na inną (np. próbujesz przywrócić backup z wersji 11 na 15). PostgreSQL nie gwarantuje wstecznej kompatybilności między wersjami.

Dlaczego tak się dzieje?

• Format danych może się zmienić między wersjami.
• Niektóre funkcje i parametry mogą zostać usunięte lub zmienione.

Jak tego uniknąć?

• Zawsze rób backupy za pomocą pg_dump, a nie kopiując bezpośrednio katalog danych PostgreSQL. pg_dump tworzy uniwersalne skrypty SQL, które można przywrócić na dowolnej kompatybilnej wersji.
• Sprawdzaj kompatybilność wersji przed rozpoczęciem przywracania. Info znajdziesz w oficjalnej dokumentacji PostgreSQL.

Przykład. Zrobiłeś backup na PostgreSQL 14:

pg_dump -U user -d my_database -f backup.sql

Teraz próbujesz przywrócić go na PostgreSQL 15:

psql -U user -d my_database -f backup.sql

I dostajesz błędy typu:

ERROR:  unrecognized configuration parameter "old_function"

Rozwiązanie: zaktualizuj wersję PostgreSQL na serwerze albo użyj narzędzia pg_upgrade do migracji.

2. Brak wymaganych plików WAL

Czasem przywracanie bazy z backupu przyrostowego lub różnicowego może nagle się przerwać — wszystko przez brakujące pliki WAL (Write-Ahead Logging). PostgreSQL polega na nich, żeby „dokręcić” zmiany po ostatniej pełnej kopii. Jeśli tych plików nie ma albo są uszkodzone, baza nie dokończy przywracania.

To się zdarza np. gdy archiwizacja plików WAL nie była włączona, albo ktoś przypadkiem wyczyścił folder, żeby zrobić miejsce. Więc jeśli planujesz używać niepełnych backupów, koniecznie włącz archiwizację w postgresql.conf:

archive_mode = on
archive_command = 'cp %p /path/to/wal_archive/%f'

I nie zapominaj regularnie sprawdzać, czy archiwum faktycznie działa, a pliki są całe i na miejscu. To niewielka cena za pewność, że przywracanie cię nie zawiedzie.

3. Uszkodzony plik backupu

Twój plik backupu może być uszkodzony, co czyni go bezużytecznym do przywracania.

Dlaczego tak się dzieje?

• Naruszenie integralności pliku podczas przesyłania lub przechowywania.
• Niespodziewany błąd podczas tworzenia backupu.

Jak tego uniknąć?

Używaj kompresji i sum kontrolnych do sprawdzania integralności backupu. Na przykład, zrób hash MD5 pliku po jego utworzeniu:

md5sum backup.sql > backup.sql.md5

Przed przywracaniem danych zawsze sprawdzaj plik backupu:

md5sum -c backup.sql.md5

Problem i jego rozwiązanie

Próbujesz przywrócić uszkodzony plik:

pg_restore -U user -d my_database backup.dump

I widzisz:

pg_restore: fatal error: input file appears to be a text file, but you are using the 'pg_restore' command-line tool; try using psql instead

Rozwiązanie: spróbuj otworzyć plik w edytorze tekstu i sprawdź, czy jest cały. Jeśli uszkodzenie jest minimalne, możesz ręcznie poprawić plik SQL.

4. Niewystarczające uprawnienia użytkownika.

Czasem podczas przywracania możesz natknąć się na błędy przez brak uprawnień, szczególnie jeśli próbujesz przywrócić dane z ograniczonego konta.

Dlaczego tak się dzieje?

Użytkownik nie ma wystarczających praw do tworzenia tabel, schematów lub obiektów bazy danych.

Jak tego uniknąć?

Przywracaj dane jako użytkownik z odpowiednimi uprawnieniami:

pg_restore -U postgres -d my_database backup.dump

5. Nadpisanie istniejącej bazy danych

Kolejny częsty błąd — przywracanie bazy z backupu, gdy dane już istnieją. Jeśli przypadkiem „zetrzesz” istniejące rekordy, nie da się ich już odzyskać.

Dlaczego tak się dzieje?

Nie używasz flagi --clean, przez co nowy backup dopisuje się na stare dane.

Jak tego uniknąć?

Podczas przywracania użyj flagi --clean, żeby usunąć istniejącą strukturę:

pg_restore --clean -U user -d my_database backup.dump

6. Błąd niezamkniętej transakcji

Podczas przywracania danych mogą pojawić się problemy z danymi, które utknęły w niezamkniętej transakcji. To szczególnie dotyczy dużych baz danych.

Dlaczego tak się dzieje?

Transakcja została „uszkodzona” przez awarię serwera.

Jak tego uniknąć?

Upewnij się, że serwer PostgreSQL kończy wszystkie czyste transakcje przed przywracaniem. Jeśli pojawią się problemy, zrestartuj serwer za pomocą:

sudo service postgresql restart

Sposoby zapobiegania błędom przywracania

Omówiliśmy, jak unikać konkretnych problemów, ale są też ogólne strategie, które pomogą zapobiec większości z nich:

Regularnie testuj przywracanie. Stwórz osobną testową bazę i spróbuj tam przywrócić dane.

Trzymaj kilka kopii backupów. Używaj chmury, lokalnego dysku i zdalnego serwera.

Automatyzuj tworzenie backupów. Użyj cron lub podobnych narzędzi do ustawienia harmonogramu.

Sprawdzaj integralność plików. Używaj sum kontrolnych, żeby mieć pewność, że backup nie jest uszkodzony.

Dbaj o synchronizację wersji PostgreSQL. Nigdy nie odkładaj aktualizacji PostgreSQL, bo to może prowadzić do niezgodności w przyszłości.

Przykłady prawdziwych case'ów i ich rozwiązania

Case 1: Utrata plików WAL. Twój serwer nagle się wyłączył i odkrywasz, że brakuje wymaganych plików WAL. W takim przypadku przywrócenie jest niemożliwe bez pełnej kopii bazy. Najprostsze rozwiązanie — regularnie sprawdzaj konfigurację archiwizacji WAL.

Case 2: Uszkodzony backup. Wgrałeś backup na serwer, ale przy sprawdzaniu widzisz, że plik jest pusty. W takich sytuacjach użyj backupu z innego miejsca albo sprawdź możliwość przywrócenia z częściowo uszkodzonej kopii.

Case 3: Niekompatybilność wersji. Przy przenoszeniu danych z PostgreSQL 12 na PostgreSQL 14 pojawiły się błędy. Przenoś dane przez pg_dump i przywracaj je na nowej wersji.