CodeGym /Kursy /SQL SELF /Odzyskiwanie danych po awarii

Odzyskiwanie danych po awarii

SQL SELF
Poziom 44 , Lekcja 2
Dostępny

Awarii może być wiele: awarie sprzętu, wyłączenia prądu, błędy w kodzie albo, co wcale nie jest rzadkie, przypadkowe usunięcie bazy przez admina, który postanowił wyczyścić "coś starego". W takich sytuacjach backupy i dobrze ogarnięty proces odzyskiwania to twoja "magiczna różdżka".

Lecimy rozkminiać proces odzyskiwania krok po kroku, jakbyśmy składali szafkę z IKEA: bez spiny i zgodnie z instrukcją.

Krok 1. Analiza przyczyny awarii

Zanim rzucisz się na pełnej prędkości do odzyskiwania danych, ważne jest, żeby ogarnąć, co się właściwie stało.

  1. Błąd aplikacji czy bazy danych?
    Sprawdź logi swojej aplikacji i PostgreSQL (zazwyczaj znajdziesz je w /var/log/postgresql/ albo podobnym katalogu, zależnie od twojego systemu). Szukaj wskaźników błędów.

  2. Awaria sprzętu?
    Jeśli serwer jest fizycznie uszkodzony (np. padł dysk), najpierw upewnij się, że sprzęt działa. Jeśli twój dysk jest uszkodzony, podłącz inny i odzyskaj wszystko z niego.

  3. Problemy z siecią lub dostępem?
    Jeśli awaria wynika z sieci — twój serwer raczej na razie nie potrzebuje akcji odzyskiwania.

  4. Czynnik ludzki:
    Przyznaj się... ktoś zrobił DROP DATABASE? Jeśli tak, mamy jeszcze szansę odzyskać dane z backupu.

Pamiętaj, że dokładne zrozumienie przyczyny awarii pomoże ci uniknąć jej w przyszłości.

Krok 2. Sprawdzenie dostępności backupów

Przyszedł czas, żeby upewnić się, że mamy dobry backup. Znajdź najnowsze kopie bazy, które robiłeś za pomocą pg_dump albo pg_basebackup. Sprawdź ich integralność. Jeśli nie wiesz jeszcze, jak to zrobić, tu szybka przypominajka:

  • Użyj komendy ls -l, żeby sprawdzić rozmiar plików. Jeśli plik jest podejrzanie mały, to może być znak problemu.
  • Sprawdź plik komendą file. Na przykład:
    file backup_file.sql
    
    Powinieneś zobaczyć info o pliku, które mówi, że to SQL dump.

Dla archiwum tar sprawdź, czy da się je rozpakować:

tar -tf backup.tar

Brak błędów? Super! Możemy lecieć dalej.

Krok 3. Zatrzymanie PostgreSQL

Przed rozpoczęciem odzyskiwania ważne jest, żeby zatrzymać serwer PostgreSQL, żeby zabezpieczyć proces. Zrobisz to taką komendą (jako admin serwera):

sudo systemctl stop postgresql

Zatrzymanie bazy daje pewność, że żaden proces nie przeszkodzi w odzyskiwaniu.

Krok 4. Przygotowanie nowej bazy do odzyskiwania

Jeśli twoja baza została całkiem usunięta albo uszkodzona, najpierw stwórz ją od nowa. Przykład komendy:

createdb -U postgres new_database

Zamień new_database na nazwę swojej bazy.

Krok 5. Odzyskiwanie z backupu

Rozkminimy dwa główne scenariusze odzyskiwania:

  1. Jeśli używasz backupu SQL (pg_dump): Do odzyskiwania użyj komendy

    psql -U username -d new_database -f backup_file.sql
    
  • username — twój użytkownik PostgreSQL.
  • new_database — baza, do której importujesz dane.
  • backup_file.sql — twój plik backupu.
  1. Jeśli używasz backupu binarnego (pg_basebackup albo pg_dump z custom):
    Do odzyskiwania użyj:
    pg_restore -U username -d new_database backup_file.dump
    
    Pamiętaj, że te backupy nie są w formacie tekstowym, tylko mają "spakowane" dane.

Dodatkowo:

  • Jeśli w backupie są tylko dane, użyj --data-only.
  • Jeśli chcesz odzyskać tylko strukturę, dodaj --schema-only.

Krok 6. Uruchomienie PostgreSQL i testowanie

Po wykonaniu komendy odzyskiwania uruchom serwer:

sudo systemctl start postgresql

Teraz trzeba zrobić testy. Spróbuj połączyć się z odzyskaną bazą przez psql albo pgAdmin. Zrób kilka selectów, żeby sprawdzić poprawność danych:

SELECT * FROM your_table_name LIMIT 10;

Jeśli wszystko wygląda OK, gratulacje: dane odzyskane!

Krok 7. Sprawdzenie integralności danych

Po odzyskaniu ważne jest, żeby sprawdzić, czy dane są spójne. Na przykład:

  1. Porównaj liczbę wierszy w tabelach z backupami:

    SELECT COUNT(*) FROM your_table_name;
    

    Porównaj wynik z zapisami w backupie (jeśli masz).

  2. Użyj sum kontrolnych: Jeśli wcześniej robiłeś sumy kontrolne dla tabel, teraz jest czas, żeby je porównać:

    md5sum backup_file.sql
    
  3. Sprawdź powiązania między tabelami: Upewnij się, że odzyskane powiązania FOREIGN KEY działają poprawnie.

Krok 8. Testowanie aplikacji

Teraz sprawdź, czy twoja aplikacja, która korzysta z tej bazy, działa poprawnie. Przeleć się po głównych scenariuszach. Są jakieś błędy? Wszystko dobrze się wyświetla?

Przykłady realnych błędów przy odzyskiwaniu

Teraz rozkminimy kilka case'ów, żeby pokazać, jak można uniknąć problemów:

  1. Niekompatybilność wersji PostgreSQL.
    Wyobraź sobie, że backup był zrobiony na wersji 12, a serwer już jest na wersji 15. Przy odzyskiwaniu pojawią się błędy.
    Rozwiązanie: użyj tej samej wersji PostgreSQL, co do robienia backupu, albo sprawdź dokumentację o kompatybilności: PostgreSQL Documentation.

  2. Uszkodzony backup . Jeśli twój backup był uszkodzony, część danych może być stracona.
    Rozwiązanie: używaj replikacji backupów (np. trzymaj kilka wersji).

  3. Błąd przy odzyskiwaniu konkretnej tabeli.
    Jeśli odzyskujesz konkretną tabelę, ale brakuje zależności (np. foreign keys), proces może się wywalić.
    Rozwiązanie: zawsze odzyskuj tabele w odpowiedniej kolejności, zaczynając od nadrzędnych.

Komentarze
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION