Co robić, gdy backup jest uszkodzony

Sheet happens. Na poprzednim wykładzie ogarnialiśmy też krok po kroku pełne odzyskiwanie bazy po awarii. Ale życie lubi zaskakiwać. Co zrobić, jeśli twój backup jest uszkodzony? No to czas się z tym zmierzyć.

Gdzie najlepiej wrzucić CV?

Żart. Teraz skupimy się na technicznych sprawach. Ale pamiętaj, w każdym żarcie jest trochę żartu :)

Analiza uszkodzenia backupu

Uszkodzony backup — to jak twój plik z pracą dyplomową, który nie chce się otworzyć tuż przed oddaniem. Objawy są podobne:

• Błędy przy próbie przywracania: podczas pg_restore możesz zobaczyć błędy typu:

  pg_restore: [archiver] input file does not appear to be a valid archive

• Część danych zniknęła albo plik ma dziwny rozmiar (np. nagle jest malutki albo ma zero bajtów).
• Rozpakowany plik SQL ma urwane dane, dziwne znaki albo puste sekcje.

Uszkodzenia backupów mogą się zdarzyć z różnych powodów:

• Przerwanie procesu backupu (np. wyłączenie prądu albo pad systemu).
• Zły transfer pliku (błędy przy kopiowaniu na pendrive albo przez sieć).
• Awaria sprzętu (dyski, RAM, padnięty RAID).
• Błędy w konfiguracji systemu albo narzędzia do backupu.
• Wirusy, złośliwe oprogramowanie i oczywiście spontaniczny "klik nie tam gdzie trzeba".

Odzyskiwanie danych z uszkodzonego backupu

Jeśli plik jest uszkodzony, to jeszcze nie koniec świata. Czasem da się coś uratować. Zobaczmy kilka sposobów.

Próba odzyskania przez pg_restore

Jeśli plik był zrobiony przez pg_dump w formacie custom albo directory, spróbuj przywrócić go komendą pg_restore z flagą --ignore-errors. Przykład:

pg_restore --dbname=your_database --ignore-errors backup_file.dump

Ta flaga mówi narzędziu, żeby ignorowało błędy i leciało dalej. Jasne, dane w uszkodzonych miejscach przepadną, ale może coś się uda odzyskać.

Jeśli się uda, dokładnie sprawdź odzyskane dane po zakończeniu procesu i zanotuj, czego brakuje.

Użycie częściowych danych

Załóżmy, że masz backup w formacie tekstowym SQL. Otwórz go w edytorze tekstu (najlepiej czymś sensownym, np. Visual Studio Code albo Notepad++), żeby zobaczyć, gdzie się urywa. Jeśli plik jest czytelny i większość SQL-i jest cała:

1. Wytnij uszkodzoną część pliku.
2. Odpal resztę SQL-i ręcznie albo przez psql:

psql -U username -d database_name -f partial_backup.sql

Czytanie pliku w formacie custom

Jeśli twój backup jest w formacie custom, możesz spróbować wyciągnąć jego zawartość po kawałku:

pg_restore --list backup_file.dump > file_list.txt

Ta komenda zrobi listę wszystkich obiektów w backupie. Potem możesz próbować przywracać pojedyncze elementy (np. tabele albo schematy) tak:

pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump

Edytując file_list.txt, możesz wywalić uszkodzone elementy z procesu przywracania.

Próba odzyskania przez archiwalne logi (WAL)

Jeśli używasz backupów przyrostowych albo różnicowych (np. przez pg_basebackup), pewnie masz archiwalne logi (pliki WAL). Tam są wszystkie zmiany od ostatniego backupu. Żeby odzyskać dane, możesz:

1. Znajdź ostatni cały backup (np. pełny backup).
2. Powiedz PostgreSQL, gdzie są pliki WAL:

   restore_command = 'cp /path/to/wal_directory/%f %p'

3. Odpal odzyskiwanie.

Użycie zewnętrznych narzędzi

Czasem uszkodzenia backupów można ograniczyć narzędziami do odzyskiwania plików. Popularnym narzędziem jest ddrescue. Przykład:

ddrescue --force backup_file.dump recovered_dump.file

To narzędzie spróbuje odzyskać jak najwięcej danych i zrobić nową kopię pliku.

Zapobieganie uszkodzeniom backupów

No tak, praca z uszkodzonymi plikami to stres. Zastanówmy się, jak tego uniknąć.

Trzymanie kopii w kilku miejscach

Jak w projekcie — backup zawsze rządzi się zasadą "nie trzymaj wszystkich jajek w jednym koszyku". Warto dublować backupy:

• Na lokalnym serwerze.
• W chmurze (Amazon S3, Google Cloud Storage albo nawet przez prosty serwis typu Dropbox).
• Na zewnętrznych nośnikach (jeśli chcesz być turbo-bezpieczny).

Regularna kontrola integralności backupów

Jest takie powiedzenie w IT: "Backup, którego nie testowałeś, to nie backup". Regularnie sprawdzaj swoje backupy, robiąc testowe odzyskiwanie danych. Czyli:

1. Wrzuć backup na testowy serwer.
2. Odzyskaj z niego dane.
3. Sprawdź, czy wszystko gra.

Używanie sum kontrolnych

Tworząc backupy, generuj sumy kontrolne plików (np. przez MD5 albo SHA256):

md5sum backup_file.dump > backup_file.md5

Przy odzyskiwaniu porównaj aktualną sumę kontrolną z oryginalną:

md5sum -c backup_file.md5

Dzięki temu od razu dowiesz się o uszkodzeniu pliku.

Przykłady odzyskiwania z uszkodzonych backupów

Zobaczmy parę prawdziwych case'ów.

Case 1. Błąd przy przenoszeniu pliku

Przenosisz backup przez FTP, ale nagle widzisz, że plik jest mniejszy niż powinien. Użyłeś pg_dump w formacie tekstowym, więc:

1. Otworzyłeś plik w edytorze.
2. Wyciąłeś uszkodzoną część danych.
3. Odzyskałeś działającą część pliku przez psql.

Case 2. Częściowa utrata danych w WAL

Twój serwer używał backupów przyrostowych i archiwalnych plików WAL. Nagle część plików zniknęła. Ale udało się odzyskać dane przez pg_basebackup i zachowane pliki WAL, podając ich ścieżkę w ustawieniach odzyskiwania.

Pamiętaj, że backup to nie tylko robienie kopii, ale też ich sprawdzanie. Nie czekaj na koniec świata, żeby się przekonać, że twoje backupy są bezużyteczne. A jeśli kopia jednak się posypała, nie panikuj: PostgreSQL daje sporo sposobów na odzyskanie danych. Najważniejsze — działaj szybko i z głową!

No a jak nic nie pomogło — przeczytaj jeszcze raz pierwszy punkt tego wykładu.