Lista kontrolna bezpiecznej migracji Immich na nowy serwer domowy

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.

A Safe Immich Migration Checklist for a New Home Server - Zima Store Online

Bezpieczna migracja Immich zaczyna się od potwierdzenia, co musi zostać zachowane, zanim cokolwiek skopiujesz: pliki zdjęć, baza danych oraz ustawienia wdrożenia, które ponownie połączą je na nowym hoście.

Na serwerze domowym ryzyko migracji zwykle wynika z przenoszenia tych elementów w różnym czasie albo uruchomienia miejsca docelowego z nieprawidłowymi ścieżkami. Potraktuj stary serwer jako kopię awaryjną, wstrzymaj możliwe do uniknięcia operacje zapisu, zanotuj bieżącą wersję i mapowania magazynu, a następnie przenieś na nową maszynę jeden zweryfikowany zestaw danych. Poniższa lista kontrolna pozwala zachować możliwość wycofania zmian aż do chwili, gdy nowa instancja będzie mogła się zalogować, znaleźć oryginalną bibliotekę, przetwarzać zadania i przetrwać ponowne uruchomienie bez powrotu do pustego stanu.

Zamroź źródło i zapisz sprawdzony stan

Rozpocznij na działającym serwerze, nie na nowym. Zapisz wersję Immich, definicję Compose lub sklepu aplikacji, wartości środowiskowe sterujące ścieżkami bazy danych i magazynu, lokalizację biblioteki zdjęć, lokalizację bazy danych oraz wszelkie punkty montowania bibliotek zewnętrznych. Zanotuj także bieżący adres URL serwera i konto użytkownika, którego użyjesz do weryfikacji.

Celem tego spisu jest zapobieżenie sytuacji, w której migracja po cichu staje się jednocześnie aktualizacją, przeprojektowaniem ścieżek i zmianą sieci. Do czasu potwierdzenia działania przywrócenia utrzymuj wersję aplikacji i logiczny układ magazynu w możliwie niezmienionej formie; zmiany wersji można wprowadzić po sprawdzeniu miejsca docelowego.

Przed kopiowaniem wstrzymaj lub zatrzymaj nowe przesyłanie plików, jeśli domownicy mogą to zaakceptować. Jeśli nie jest to praktyczne, wyznacz okno przełączenia i zaplanuj krótką końcową synchronizację. Zakończeniem tego etapu powinien być zapisany schemat źródła, który pozwala odpowiedzieć, gdzie znajdują się oryginały, gdzie jest stan bazy danych oraz jaka konfiguracja odtworzy te same zależności.

Utwórz bazę danych, zasoby i konfigurację jako jeden zestaw migracyjny

Traktuj bazę danych i pliki multimedialne jako jeden zestaw odzyskiwania, a nie dwie niezależne kopie zapasowe. Bieżące kopie zapasowe bazy danych Immich zawierają metadane i odwołania do plików, ale nie same zdjęcia ani filmy, dlatego kopia bazy danych musi być przeniesiona wraz z odpowiadającą jej zawartością UPLOAD_LOCATION oraz danymi bibliotek zewnętrznych, którymi zarządzasz osobno.

Użyteczny zestaw migracyjny wymaga zasobów, stanu PostgreSQL oraz konfiguracji, która ponownie je połączy. kompletny zestaw kopii zapasowej Immich obejmuje przesłane zasoby, obsługiwaną kopię bazy danych i konfigurację wdrożenia, a test przywracania służy do potwierdzenia, że zestaw działa. Przechowuj te elementy razem, aby można było dopasować miejsce docelowe do jednego punktu odzyskiwania.

Zweryfikuj zestaw migracyjny przed rozpoczęciem pracy na miejscu docelowym. Potwierdź, że zrzut bazy danych nie jest pusty, wybierz kilka oryginalnych plików ze skopiowanej biblioteki i sprawdź je, a pliki Compose i środowiskowe przechowuj w tym samym folderze migracji lub zestawie dokumentacji. Jeśli nie można zweryfikować któregokolwiek elementu, zatrzymaj się tutaj i utwórz świeżą kopię zamiast próbować kompensować braki na nowym serwerze.

Przygotuj nowy host bez tworzenia konkurencyjnego stanu

Najpierw utwórz katalogi i punkty montowania miejsca docelowego, a następnie potwierdź, że nowy host widzi właściwe dyski lub udziały sieciowe dokładnie pod planowanymi ścieżkami. Brak montowania NAS może pozostawić zwykły pusty katalog, a kontener może bez problemu zainicjalizować się przy użyciu tej zastępczej ścieżki.

Zainstaluj środowisko uruchomieniowe i odtwórz definicję wdrożenia, ale nie pozwól, aby pusta instancja Immich gromadziła przesłane pliki ani konfigurację przed przywróceniem starego stanu. Zachowaj zgodność danych uwierzytelniających, nazwy bazy danych, zmiennych magazynu i miejsc docelowych montowania bibliotek zewnętrznych ze źródłem, chyba że plan migracji wyraźnie obejmuje kontrolowaną zmianę ścieżek.

Jeśli nowy serwer wymaga innych ścieżek po stronie hosta, mapuj je świadomie, zachowując spójność ścieżek widocznych w kontenerze i oczekiwań bazy danych. Miejsce docelowe jest gotowe dopiero wtedy, gdy jego rzeczywiste punkty montowania wskazują skopiowane lokalizacje danych i potrafisz wyjaśnić każde tłumaczenie ścieżki przed pełnym uruchomieniem aplikacji.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Przywróć stan i ponownie połącz wszystkie ścieżki magazynu

Przywróć bazę danych, korzystając ze ścieżki odzyskiwania odpowiedniej dla wersji Immich, która utworzyła kopię zapasową, a następnie uruchom pozostałe usługi dopiero po przygotowaniu bazy danych. Nie improwizuj destrukcyjnych poleceń dotyczących bazy danych na podstawie starszego poradnika, jeśli nowsza instalacja korzysta z innego procesu przywracania.

Podczas przełączenia zachowaj spójność relacji między bazą danych a magazynem, zanim wznowisz normalne użytkowanie. sprawdzona sekwencja migracji Immich opiera się na tej samej zasadzie: aplikacja powinna otworzyć się ze stanem przywróconym z bazy danych i przy użyciu właściwych ścieżek multimediów, a nie zainicjalizować pustą bibliotekę i wymusić ponowne tworzenie wszystkiego od podstaw.

Po uruchomieniu sprawdź dostęp do magazynu przed rozpoczęciem intensywnych zadań w tle. Otwórz kilka starszych zasobów z różnych dat, sprawdź ładowanie miniatur, potwierdź album oraz osobę lub wynik wyszukiwania istniejące przed migracją i upewnij się, że biblioteki zewnętrzne są dostępne, jeśli ich używasz. Ekran rozpoczęcia konfiguracji lub pusta oś czasu to sygnał do zatrzymania: przed zapisaniem nowego stanu ponownie sprawdź mapowania bazy danych i punktów montowania.

Zweryfikuj pierwotne obciążenie przed wyłączeniem starego serwera

Pomyślne pierwsze logowanie nie oznacza końca migracji. Prześlij jedno testowe zdjęcie, którego można się pozbyć, używając zwykłego klienta, potwierdź, że pojawiło się w oczekiwanym magazynie hosta, a następnie usuń je w Immich i sprawdź, czy biblioteka nadal działa prawidłowo. Weryfikuje to pełną ścieżkę zapisu, a nie tylko możliwość odczytu starych danych.

Uruchom ponownie nowy serwer domowy i powtórz kontrole istotne dla domowników: logowanie w przeglądarce, połączenie kopii zapasowej urządzenia mobilnego, kilka starych zdjęć, wyszukiwanie, przykładowy film, kolejki zadań oraz zdalny dostęp, jeśli należy do standardowej konfiguracji. Migrację można uznać za zakończoną dopiero wtedy, gdy ten sam stan przetrwa ponowne uruchomienie hosta, a punkty montowania magazynu będą dostępne przed uruchomieniem Immich.

Na czas wyznaczonego okna wycofania zmian pozostaw stary serwer wyłączony, ale niezmieniony, zamiast od razu go wymazywać. Jeśli nowa instancja zacznie zapisywać dane do nieoczekiwanego pustego folderu, po ponownym uruchomieniu nie odtworzy starej biblioteki albo pokaże niewyjaśnione błędy bazy danych, zatrzymaj nowe przesyłanie i wróć do sprawdzonego źródła, porównując zestaw migracyjny. Wycofaj stary host dopiero po pomyślnym przejściu przez miejsce docelowe normalnego użytkowania i testu świeżej kopii zapasowej.