Jak zweryfikować przywrócenie Immich przed wycofaniem starego serwera

Nie wyłączaj starego serwera Immich tylko dlatego, że nowy panel się ładuje, a zdjęcia są widoczne. Zakończ jego użytkowanie dopiero wtedy, gdy przywrócony system potwierdzi działanie użytkowników, albumów, osób, wyszukiwania, wybranych oryginałów, nowych przesyłanych plików, zadań w tle, ponownych uruchomień oraz świeżej kopii zapasowej, a stary host pozostanie dostępny jako cel wycofania zmian.

Podczas walidacji pozostaw stary serwer wyłączony, ale niezmieniony, aby dwie instancje nie przyjmowały przesyłanych plików przy rozbieżnym stanie. Najpierw nadaj przywróconemu hostowi kontrolowany adres testowy, zapisz stan bazowy starego systemu i porównuj te same przepływy pracy w gospodarstwie domowym, zamiast polegać na wizualnym wrażeniu, że oś czasu wygląda na kompletną.

Zachowaj stary serwer w niezmienionym stanie podczas ustalania punktu odniesienia przywracania

Przed przełączeniem zapisz liczbę użytkowników i zasobów, kilka reprezentatywnych albumów, nazwane osoby, ulubione, udostępnione elementy, ścieżki bibliotek zewnętrznych oraz kilka przykładowych oryginałów z różnych dat i kont użytkowników. Zapisz również wersje Immich i PostgreSQL na starym serwerze oraz artefakty kopii zapasowej użyte do przywrócenia. Kontrole integralności folderów lub pamięci masowej są przydatnymi bramkami, ale nie zastępują weryfikacji na poziomie relacji.

Model odzyskiwania ZimaSpace dla przywracania przeszukiwalnej biblioteki zdjęć traktuje oryginały, stan katalogu/bazy danych oraz konfigurację definiującą ścieżki jako jedną jednostkę odzyskiwania. To właściwy punkt odniesienia, ponieważ same luźne pliki obrazów nie potwierdzają przetrwania członkostwa w albumach, własności, osób ani relacji wyszukiwania.

Nie czyść starych dysków, nie używaj ponownie jego adresu IP na stałe i nie usuwaj jeszcze ostatniej sprawdzonej kopii zapasowej. Cel weryfikacji powinien być odwracalny: jeśli brakuje jednej krytycznej relacji, musisz mieć stary stan, aby ustalić, czy problem wynika z kopii zapasowej, metody przywracania, mapowania ścieżek czy nowego środowiska uruchomieniowego.

Weryfikuj relacje, a nie tylko widoczność zdjęć

Zaloguj się jako więcej niż jeden oczekiwany użytkownik i sprawdź, czy każde konto widzi właściwe zasoby i udostępnienia. Otwórz znane albumy, nazwane osoby, ulubione, wspomnienia lub inne relacje charakterystyczne dla danego gospodarstwa domowego, które trudno byłoby odtworzyć na podstawie samych plików. Porównaj niewielki zestaw z zapisanym stanem bazowym starego serwera.

Dyskusja dotycząca migracji Immich o brakujących albumach po przywróceniu PostgreSQL pokazuje, dlaczego ma to znaczenie: zdjęcia mogły pozostać, podczas gdy stan albumów zniknął, a późniejsze ponowne zrzucenie bazy danych zmieniło wynik. Potraktuj to jako dowód, że pomyślne logowanie lub widoczna oś czasu nie stanowią pełnego testu przywracania.

Wyszukaj kilka znanych zasobów na podstawie metadanych oraz wszystkich włączonych funkcji wizualnych lub funkcji rozpoznawania osób. Jeśli oryginały są obecne, ale brakuje relacji lub wyników wyszukiwania, ustal, czy odpowiedni stan powinien zostać przywrócony, czy też jest celowo odtwarzany. Nie wyłączaj starego serwera, dopóki ta różnica nie zostanie wyjaśniona.

Przetestuj ścieżki odczytu, zapisu, zależności i ponownego uruchamiania

Otwórz stare zdjęcia i filmy bezpośrednio z przywróconej pamięci masowej, a następnie prześlij testowy nowy plik z klienta mobilnego lub internetowego. Potwierdź, że jego oryginał jest zapisywany we właściwej ścieżce, pojawia się u odpowiedniego użytkownika, a zadania w tle są przetwarzane. Biblioteki zewnętrzne i dostęp zdalny testuj dopiero po ustabilizowaniu lokalnej ścieżki odczytu i zapisu.

Testowanie przywracania powinno sprawdzać aplikację po skopiowaniu danych. Aktualny przewodnik po testowaniu odtwarzania po awarii zaleca walidację na poziomie aplikacji, obejmującą bazy danych, uprawnienia, połączenia sieciowe i usługi, zamiast kończyć na ukończonym zadaniu tworzenia lub przywracania kopii zapasowej. Uruchom stos Immich ponownie dwa razy i raz uruchom ponownie nowego hosta. Po każdym cyklu potwierdź powrót tych samych punktów montowania, użytkowników, przykładowych zasobów, bazy danych, serwera proxy lub lokalnego punktu końcowego oraz działania zadań. Usługa, która działa tylko do pierwszego ponownego uruchomienia hosta, nie przeszła migracji.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Utwórz świeżą kopię zapasową przed zamknięciem okna wycofania zmian

Utwórz nową kopię zapasową spójną z bazą danych i zabezpiecz zakres multimediów oraz konfiguracji wymagany przez projekt odzyskiwania. Przywróć co najmniej niewielki cel walidacyjny lub sprawdź kopię zapasową przy użyciu tego samego procesu, który był stosowany przed przełączeniem. Przywrócony serwer, który nie potrafi utworzyć własnej kopii możliwej do odzyskania, nie powinien stać się jedyną kopią produkcyjną.

Przez określony czas obserwacji przeprowadź na nowym hoście zwykłe przesyłanie zdjęć z telefonu, przeglądanie, wyszukiwanie, przetwarzanie w tle, zaplanowane tworzenie kopii zapasowej oraz co najmniej jeden cykl nocny. Pozostaw stary host wyłączony, aby nie rozdzielał stanu, ale zachowaj go bez zmian do czasu, aż nowy system przejdzie te zdarzenia bez niewyjaśnionych różnic.

Decyzja o przełączeniu wymaga zgodności krytycznych relacji, czytelnych oryginałów, pomyślnych nowych zapisów, stabilnych ponownych uruchomień oraz świeżej, zweryfikowanej kopii zapasowej.

Jeśli użytkownicy znikają, liczby znacząco się różnią, ponownie pojawiają się błędy ścieżek lub baza danych zgłasza problemy ze spójnością, wyłącz nową instancję i zachowaj oba stany przed rozpoczęciem analizy. Dopiero wtedy należy wyczyścić stary serwer lub przeznaczyć go do innego celu.