Jak odzyskać bazę danych Immich ze sprawdzonej kopii zapasowej

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How to Recover an Immich Database From a Known-Good Backup - Zima Store Online

Znana jako poprawna kopia zapasowa bazy danych Immich jest przydatna tylko wtedy, gdy przywrócisz ją w kontrolowanym środowisku i potwierdzisz, że odzyskana baza nadal wskazuje multimedia, które serwer rzeczywiście może zobaczyć.

Traktuj odzyskiwanie jako sekwencję działań, a nie pojedyncze polecenie importu. Najpierw zachowaj uszkodzoną instancję, ustal wersję Immich i czas utworzenia kopii zapasowej, uruchom czysty, zgodny docelowy system bazodanowy, przywróć bazę bez pozwalania aplikacji na zapis do pustego schematu, a następnie sprawdź konta, dane osi czasu, ścieżki multimediów i jeden nowy zapis. Jeśli którykolwiek krok jest niejasny, zatrzymaj się przed zastąpieniem ostatniej możliwej do odzyskania kopii.

Zamroź uszkodzony stan, zanim cokolwiek przywrócisz

Przed rozpoczęciem odzyskiwania zatrzymaj nowe przesyłanie plików i operacje wykonywane w tle przez dotkniętą problemem instancję Immich. Zapisz bieżący plik Compose, wartości zmiennych środowiskowych, zamontowane ścieżki, wersje obrazów, ostatnie logi oraz stan uszkodzonej bazy danych, jeśli pozwala na to miejsce na dysku. Uszkodzona baza może nadal zawierać informacje wyjaśniające przyczynę problemu, a jej nadpisanie usunie te dane.

Dokładnie ustal, której kopii zapasowej zamierzasz zaufać. Zapisz jej czas utworzenia, sposób utworzenia, rozmiar pliku oraz informację, czy kiedykolwiek została przetestowana przez przywrócenie. Zrzut SQL utworzony przez bazę danych jest innym zasobem do odzyskiwania niż surowa kopia katalogu danych działającego PostgreSQL — nie traktuj ich jako zamienników.

Jeśli to możliwe, utwórz środowisko docelowe odzyskiwania w osobnym katalogu lub odizolowanym stosie. Warunek zakończenia tego etapu jest prosty: pierwotny uszkodzony stan jest zachowany, wybrana kopia zapasowa jest tylko do odczytu, a Ty wiesz, z jaką wersją wdrożenia i jakimi ścieżkami przechowywania ma zostać ponownie połączone przywracane środowisko.

Sprawdź, czy kopię zapasową rzeczywiście można przywrócić

Przed jej odtworzeniem sprawdź kopię zapasową. Skompresowany zrzut SQL powinien poprawnie się rozpakować i zawierać rozpoznawalną zawartość zrzutu PostgreSQL, a nie pustą paczkę utworzoną przez nieudaną procedurę. Jeśli masz sumy kontrolne lub wyniki weryfikacji repozytorium, porównaj je teraz, zamiast odkrywać uszkodzenie w połowie odzyskiwania.

Zrzut PostgreSQL jest bezpieczniejszym zasobem do odzyskiwania niż przypadkowa kopia działającego katalogu danych bazy, ponieważ jest tworzony za pomocą narzędzi uwzględniających specyfikę bazy danych i można go odtworzyć w czystym środowisku docelowym. Wzorzec kopii zapasowej w postaci zrzutu bazy danych oddziela również bazę danych od kopii multimediów, ułatwiając sprawdzenie obu elementów przed odzyskiwaniem.

Potwierdź także, że multimedia i konfiguracja odpowiadające okresowi utworzenia kopii nadal istnieją. Samo przywrócenie bazy danych może odzyskać użytkowników, albumy, metadane i odwołania do plików, ale pozostawić każdy zasób niedostępny, jeśli brakuje wskazanych ścieżek biblioteki. Kontynuuj tylko wtedy, gdy zrzut oraz zestaw multimediów i konfiguracji należą do znanego punktu odzyskiwania.

Najpierw uruchom zgodny, czysty docelowy system bazodanowy

Dopasuj metodę przywracania do wersji, w której utworzono kopię zapasową. Aktualne wydania Immich umożliwiają przywracanie bazy danych z poziomu Administracja > Konserwacja oraz podczas procesu wdrażania nowej instalacji, natomiast starsze kopie zapasowe mogą wymagać instrukcji ręcznych właściwych dla danej wersji; procedura przywracania zmieniła się w wersji v2.5.0.

W przypadku nowego środowiska docelowego nie pozwól, aby Immich wykonał standardowe migracje na pustym schemacie, zanim baza danych będzie gotowa do przywrócenia. Jeśli używana metoda wdrożenia uruchamia aplikację razem z PostgreSQL, skorzystaj z mechanizmów przywracania odpowiednich dla danej wersji, aby serwer nie utworzył konkurencyjnego stanu przed importem.

Jeśli baza danych nie stanie się sprawna samodzielnie, zatrzymaj się i najpierw rozwiąż ten problem. Nie powtarzaj w kółko odtwarzania tej samej kopii do środowiska, które się restartuje, ma za mało miejsca na dysku lub korzysta z niezgodnego układu pamięci masowej. Czyste i stabilne środowisko docelowe jest warunkiem wstępnym, a nie pobocznym zadaniem diagnostycznym.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Przywróć zrzut raz i zatrzymaj się przy pierwszym błędzie

Przywróć wybrany zrzut do przygotowanej bazy danych i przechwyć pełny wynik operacji. Użyj narzędzi bazodanowych oraz przełączników odpowiednich dla formatu zrzutu, aby błąd wyraźnie przerwał przywracanie, zamiast pozostawić częściowo zaimportowany schemat, który nadal się uruchamia.

Użyteczny zestaw migracyjny musi obejmować zasoby, stan PostgreSQL oraz konfigurację ponownie łączącą te elementy. Kompletny zestaw kopii zapasowej Immich obejmuje przesłane zasoby, obsługiwaną kopię bazy danych oraz konfigurację wdrożenia, a testy przywracania służą do potwierdzenia, że zestaw działa. Przechowuj te elementy razem, aby można było dopasować miejsce docelowe do jednego punktu odzyskiwania.

Po pomyślnym imporcie uruchom aplikację Immich i uważnie obserwuj jej pierwsze uruchomienie. Jeśli interfejs poprosi o utworzenie nowego pierwszego administratora zamiast zaakceptować istniejące konta, zatrzymaj się: to silna wskazówka, że przywrócona baza nie jest bazą używaną przez Immich. Nie zaczynaj ponownie przesyłać zdjęć do tego pustego stanu.

Sprawdź stan bazy, ścieżki multimediów i nowy zapis

Zaloguj się na istniejące konto i przejrzyj oś czasu, uwzględniając zarówno starsze, jak i nowsze daty. Otwórz kilka oryginalnych plików, sprawdź albumy lub ulubione elementy, o których wiesz, że istniały, i potwierdź, że aplikacja może odnaleźć podstawowe pliki, a nie tylko wyświetlać rekordy z bazy danych.

Stan bazy danych, pliki aplikacji, konfiguracja i przesłane pliki muszą być ze sobą zgodne w momencie przywracania. Wykorzystaj spójną kopię zapasową kontenera bazy danych jako model akceptacji, a nie samo sprawdzenie, czy PostgreSQL się uruchamia.

Na koniec prześlij jedno zdjęcie przeznaczone do usunięcia, zaczekaj na jego standardowe przetworzenie, potwierdź, że przetrwa restart Immich oraz ponowne uruchomienie hosta, a następnie usuń je za pośrednictwem aplikacji. Jeśli konta, starsze zasoby i nowy zapis działają prawidłowo, utwórz świeżą kopię zapasową odzyskanego stanu przed aktualizacją wersji. Jeśli nie, wróć do zachowanych dowodów dotyczących awarii lub starszej, znanej jako poprawna kopii zapasowej, zamiast pogłębiać uszkodzenia.