Jak odzyskać bazę danych MySQL po usunięciu plików lub partycji w Ubuntu: RAID 6 i LUKS2
-
Autor:
Oksana Volyniuk
-
Redaktor:
Michał Mirosznyczenko
Usuwanie plików lub całej partycji dysku w Ubuntu może prowadzić do krytycznej utraty danych, zwłaszcza jeśli na serwerze działa baza danych MySQL. Sytuacja staje się znacznie bardziej skomplikowana, gdy system pamięci masowej jest oparty na macierzy RAID 6, a dane są dodatkowo chronione szyfrowaniem LUKS2. W takich warunkach standardowe narzędzia odzyskiwania nie zawsze przynoszą oczekiwany rezultat, a nieostrożne działania mogą trwale zniszczyć informacje. W tym artykule omówimy możliwe scenariusze utraty danych, specyfikę pracy z RAID 6 i LUKS2 oraz proces odzyskiwania bazy danych MySQL po przypadkowym usunięciu plików lub partycji dysku.
- Przygotowanie środowiska testowego i bazy danych MySQL
- Podłączanie dysków do analizy
- Jak odzyskać usuniętą bazę danych MySQL z RAID 6 + LUKS2
- KROK 1. Automatyczne wykrywanie RAID 6 i partycji LUKS
- KROK 2. Odblokowanie i odzyskiwanie usuniętych plików
- KROK 3. Odtwarzanie bazy danych z zrzutu SQL
- KROK 4. Odtwarzanie bazy danych z fizycznych plików MySQL
- KROK 5. Odtwarzanie struktury tabel z plików ibd
- KROK 6. Dołączanie odzyskanych plików ibd
- Wnioski
- Najczęściej zadawane pytania
- Komentarze
Pliki bazy danych MySQL i ich kopie zapasowe na serwerze Linux mogą stać się niedostępne z różnych powodów: przypadkowego usunięcia plików, formatowania lub usunięcia partycji, uszkodzenia systemu plików, awarii macierzy RAID, awarii dysku lub awarii kontrolera RAID. Sytuacja staje się jeszcze bardziej złożona, jeśli dane są przechowywane na zaszyfrowanej partycji LUKS2.
Hetman RAID Recovery pomaga odtwarzać strukturę macierzy RAID, odnajdywać utracone partycje, odblokowywać LUKS2, jeśli dostępne jest hasło, oraz odzyskiwać pliki bazy danych i zrzuty SQL.
Pokażemy działanie programu na komputerze z systemem Windows. Jednak Hetman RAID Recovery jest również dostępny dla systemów Linux i macOS.
Jak odzyskać usuniętą bazę MySQL z RAID 6 + LUKS2 (Ubuntu)
Przygotowanie środowiska testowego i bazy danych MySQL
Do testów użyliśmy serwera Dell PowerEdge R710 z kontrolerem PERC H700.
| Parametr | Specyfikacja |
|---|---|
| Model serwera | Dell PowerEdge R710 |
| Format obudowy | Rack 2U |
| Procesor | Do 2 × Intel Xeon serii 5500/5600 |
| RAM | DDR3 ECC, do 288 GB (18 slotów) |
| Kontroler RAID | Dell PERC H700 |
| Typ RAID | Sprzętowy RAID |
| Obsługiwane poziomy RAID | RAID 0, 1, 5, 6, 10, 50, 60 |
| Konfiguracja macierzy | RAID 6 |
| Interfejs dysków | SAS/SATA, do 6 Gbit/s |
| Liczba zatok na dyski | Do 6 × 3,5″ lub 8 × 2,5″ w zależności od konfiguracji |
| Pamięć podręczna kontrolera RAID | 512 MB lub 1 GB (w zależności od modelu) |
| Zabezpieczenie pamięci podręcznej | BBU — ochrona pamięci podręcznej z zasilaniem bateryjnym |
| System operacyjny | Ubuntu Server |
| Szyfrowanie danych | LUKS2 (na poziomie Linux, nie na kontrolerze RAID) |
| System zarządzania bazą danych | MySQL |
| Tolerancja awarii RAID 6 | Pozwala na jednoczesną awarię do dwóch dysków |
| Narzędzia diagnostyczne | Dell OpenManage, MegaCLI, StorCLI (jeśli zgodne) |
Aby zapewnić systemowi operacyjnemu bezpośredni dostęp do każdego fizycznego dysku, na kontrolerze utworzono sześć jednodyskowych macierzy RAID 0 — po jednej dla każdego dysku. Na jednej z nich zainstalowano Ubuntu Server 24.04, a pozostałe cztery połączono w programową macierz MD RAID 6 za pośrednictwem Cockpit.
Na macierzy utworzono tablicę partycji GPT oraz trzy partycje, jako system plików wybrano ext4, a dla każdej z nich włączono szyfrowanie LUKS2.
Katalog mysql-data został umieszczony na trzeciej partycji i zawierał dane testowej bazy company_db, pliki systemowe oraz logi MySQL. Użyto MySQL w wersji 8.0.46.
Sama baza danych zawierała tabele customers, products i orders, a także widok, procedurę składowaną i funkcję.
Kopia zapasowa bazy danych została utworzona w MySQL Workbench jako zrzut SQL i zapisana w katalogu mysql-backups.
Przed testem katalogi mysql-data i mysql-backups zostały skopiowane z trzeciej partycji na drugą. Następnie drugą partycję usunięto za pomocą Cockpit, a pliki bazy danych i zrzut SQL usunięto z trzeciej partycji przy użyciu kombinacji Shift + Delete, z pominięciem Kosza. W ten sposób przygotowano dwa scenariusze: odzyskiwanie plików z usuniętej partycji oraz odzyskiwanie usuniętych plików z zachowanej partycji.
Podłączanie dysków do analizy
W naszym przypadku dyski uczestniczące w macierzy RAID 6 zostały podłączone do komputera z systemem Windows za pośrednictwem stacji dokującej USB, a do analizy uruchomiono Hetman RAID Recovery.
Oprócz pracy z fizycznymi dyskami program obsługuje analizę pełnych obrazów dysków typu bajt po bajcie. Takie obrazy można tworzyć bezpośrednio w Hetman RAID Recovery za pomocą funkcji Save Disk i zapisywać na innym sprawnym dysku.
Jest to szczególnie przydatne, jeśli dysk jest niestabilny, zawiera uszkodzone sektory lub generuje błędy odczytu. Utworzenie obrazu zachowuje czytelne dane i umożliwia późniejsze skanowanie kopii, ograniczając liczbę wielokrotnych odwołań do problematycznego dysku.
Jeśli dyski pozostają na serwerze Linux i są czytelne, można je analizować zdalnie. W tym celu należy połączyć się z serwerem przez SSH w Hetman RAID Recovery i uzyskać dostęp do jego urządzeń blokowych.
Jak odzyskać usuniętą bazę danych MySQL z RAID 6 + LUKS2
KROK 1. Automatyczne wykrywanie RAID 6 i partycji LUKS
Bezpośrednio po uruchomieniu Hetman RAID Recovery automatycznie wykrył konfigurację MD RAID 6 i odtworzył jej strukturę do analizy.
W prawym panelu wyświetlane są główne parametry macierzy: typ i stan RAID, kolejność i rozmiar bloków, a także lista uczestniczących dysków wraz z ich kolejnością, przesunięciami i rozmiarami.
Na złożonej macierzy program wykrył trzy partycje, w tym wcześniej usuniętą drugą, oraz zidentyfikował szyfrowanie LUKS na wszystkich trzech. Przed wprowadzeniem hasła ich systemy plików nie są wyświetlane — partycje muszą zostać odblokowane w celu dalszej analizy.
Druga partycja jest wyświetlana w interfejsie jako nieprzydzielone miejsce oznaczone LUKS. Oznacza to, że program rozpoznał metadane zaszyfrowanego kontenera w lokalizacji usuniętej partycji.
KROK 2. Odblokowanie i odzyskiwanie usuniętych plików
Aby rozpocząć analizę, należy dwukrotnie kliknąć wymaganą partycję. Ponieważ jest ona zaszyfrowana za pomocą LUKS2, program poprosi o podanie hasła lub wskazanie pliku klucza. Wprowadź hasło i kliknij Unlock.
Najpierw wybierz Fast Scan. Poczekaj na zakończenie skanowania, po czym program otworzy strukturę odnalezionych katalogów. W naszym teście szybkie skanowanie odnalazło wymagane pliki na usuniętej partycji.
Jeśli w Twoim przypadku wymagane dane nie zostaną znalezione, wróć do wyboru typu analizy i uruchom Full Analysis, wskazując system plików EXT2/3/4.
Przejrzyj wyniki skanowania. W naszym przypadku program wyświetlił zrzut SQL backup1.sql, katalog company_db oraz pliki tabel MySQL z rozszerzeniem .ibd. Zawartość zrzutu SQL można sprawdzić w oknie podglądu.
Zaznacz pliki i foldery, które chcesz odzyskać, a następnie kliknij Recovery. Wybierz metodę zapisu, wskaż inny dysk fizyczny i pozostaw włączoną opcję przywracania struktury katalogów.
Nie zapisuj znalezionych plików na tym samym dysku, z którego są odzyskiwane, aby nie nadpisać innych utraconych danych.
KROK 3. Odtwarzanie bazy danych z zrzutu SQL
Najprostszym sposobem przywrócenia bazy danych jest użycie odzyskanego zrzutu SQL. Zawiera on polecenia tworzące strukturę bazy danych i przywracające dane według stanu z chwili wykonania kopii zapasowej. Jeśli wybrano odpowiednie opcje eksportu, zrzut będzie również zawierał widoki, procedury i funkcje.
Uruchom MySQL Workbench i połącz się z serwerem MySQL. Otwórz menu Server — Data Import, wybierz Import from Self-Contained File i wskaż odzyskany plik SQL.
Jeśli utracono cały katalog mysql-data z plikami systemowymi MySQL, należy najpierw przywrócić działanie serwera lub przygotować nową instancję MySQL. Dopiero wtedy można zaimportować zrzut przez Workbench.
Wybierz docelowy schemat lub utwórz nową bazę danych company_db, a następnie kliknij Start Import. Poczekaj na zakończenie operacji i sprawdź dziennik pod kątem błędów.
Odśwież listę schematów. Baza danych powinna teraz zawierać tabele customers, products i orders. Otwórz je i zweryfikuj rekordy.
KROK 4. Odtwarzanie bazy danych z fizycznych plików MySQL
Jeśli nie ma odpowiedniego zrzutu SQL, ale Hetman RAID Recovery zdołał odzyskać katalog bazy danych z plikami tabel, można spróbować odzyskiwania fizycznego.
W naszym przypadku katalog company_db zachował pliki customers.ibd, products.ibd i orders.ibd. Każdy z nich zawiera dane i indeksy odpowiedniej tabeli InnoDB.
Samo skopiowanie tych plików do katalogu MySQL nie wystarczy. Nowy serwer nie ma jeszcze definicji odpowiednich tabel w słowniku danych. Dlatego odzyskiwanie przebiega w dwóch etapach: najpierw trzeba odtworzyć strukturę tabel, a następnie dołączyć do niej odzyskane pliki .ibd.
Aby wykonać odzyskiwanie, przygotuj działający serwer z tą samą wersją MySQL. Połącz się z nim przez Workbench i utwórz pustą bazę danych.
Jeśli zachował się oryginalny skrypt SQL ze strukturą, wykonaj z niego polecenia CREATE TABLE. Tabele muszą dokładnie odpowiadać oryginałowi, w tym typom kolumn, kluczom, indeksom, zestawowi znaków i formatowi wiersza. Nie ma potrzeby wykonywania poleceń wstawiania danych — na tym etapie tabele muszą pozostać puste.
KROK 5. Odtwarzanie struktury tabel z plików ibd
Jeśli oryginalny skrypt SQL nie jest dostępny, można spróbować odzyskać strukturę tabel z plików .ibd. W MySQL 8.0 zawierają one SDI — metadane słownika danych. Do ich odczytu służy narzędzie ibd2sdi.
Uruchom je dla każdego odzyskanego pliku i zapisz wyniki w formacie JSON. W naszym przypadku uzyskaliśmy metadane z plików customers.ibd, products.ibd i orders.ibd, a następnie użyliśmy jq, aby sprawdzić definicję tabeli customers.
Metadane mogą zawierać nazwę tabeli, wersję MySQL, silnik magazynowania, zestaw znaków oraz parametry tablespace. Zawierają również definicje kolumn. Informacje o kluczu głównym i kluczach unikalnych, indeksach wtórnych oraz relacjach z innymi tabelami są przechowywane oddzielnie.
Wygenerowany plik JSON można analizować ręcznie w edytorze tekstu. Na podstawie wykrytych parametrów specjalne skrypty i konwertery mogą automatycznie generować wstępne polecenia CREATE TABLE. W przypadku dużej liczby tabel znacząco przyspiesza to odzyskiwanie struktury.
KROK 6. Dołączanie odzyskanych plików ibd
W Workbench tymczasowo wyłącz sprawdzanie kluczy obcych i wykonaj polecenie ALTER TABLE … DISCARD TABLESPACE dla każdej utworzonej tabeli. Spowoduje to odłączenie utworzonej pustej przestrzeni tabeli i przygotuje tabelę do dołączenia odzyskanego pliku.
Następnie skopiuj odpowiednie pliki .ibd do katalogu bazy danych na przygotowanym serwerze. Po skopiowaniu nie zapomnij nadać plikom właściciela mysql i ustawić wymaganych uprawnień dostępu.
Wróć do Workbench i uruchom dla każdej tabeli polecenie ALTER TABLE … IMPORT TABLESPACE. Ostrzeżenia o brakujących plikach .cfg nie są krytyczne: MySQL kontynuuje import bez automatycznej weryfikacji struktury. MySQL zarejestruje odzyskane przestrzenie tabel i dołączy dane oraz indeksy do wcześniej utworzonych definicji tabel.
Po pomyślnym imporcie ponownie włącz sprawdzanie kluczy obcych. Odśwież listę schematów i zweryfikuj liczbę oraz zawartość rekordów za pomocą zapytań SELECT.
Pliki .ibd umożliwiają odtworzenie tabel, ich danych i indeksów. Jednak widoki, procedury i funkcje nie są przechowywane jako oddzielne pliki w katalogu company_db. Jeśli nie zostały uwzględnione w zrzucie SQL, obiekty te należy odtworzyć ręcznie.
Po zweryfikowaniu przywróconej bazy danych zalecamy utworzenie nowej kopii zapasowej w formacie SQL dump.
Wnioski
Za pomocą Hetman RAID Recovery udało się automatycznie odtworzyć strukturę Linux MD RAID 6 oraz wykryć i odblokować kontenery LUKS2 przy użyciu znanego hasła. Szybkie skanowanie odnalazło wymagane pliki zarówno po ich usunięciu, jak i po usunięciu całej partycji.
Odzyskany zrzut SQL można zaimportować przez MySQL Workbench, przywracając strukturę bazy danych i dane do stanu z chwili utworzenia kopii zapasowej. Jeśli odpowiedni zrzut nie jest dostępny, poszczególne tabele InnoDB można odzyskać z plików .ibd, uprzednio odtwarzając ich strukturę.
