Jak zapobiec tworzeniu kopii zapasowych Immich w niespójnym stanie

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 Prevent Immich Backups From Capturing Inconsistent State - Zima Store Online

Zapobiegaj niespójnym kopiom zapasowym Immich, traktując bazę danych i multimedia jako jeden moduł odtwarzania, którego kolejność przechwytywania oraz aktywność zapisu są celowo kontrolowane.

Kopia zapasowa może zawierać każdy plik, który miała skopiować, a mimo to nie odtworzyć się prawidłowo, jeśli baza danych odwołuje się do zasobów, których nie uwzględniono w kopii, lub jeśli kopia multimediów przedstawia inny moment niż katalog. Najpierw określ granicę spójności, wybierz metodę zatrzymaną albo skoordynowaną na żywo i zweryfikuj wynik w izolacji.

Określ moduł odtwarzania przed zaplanowaniem kopii zapasowej

Wymień bazę danych PostgreSQL, przesłane multimedia, dane profilu, konfigurację wdrożenia, wartości środowiskowe, sekrety oraz wszystkie niestandardowe ścieżki przechowywania wymagane do odtworzenia usługi. Osobno oznacz wygenerowane miniatury, zakodowane filmy i pliki modeli, zależnie od tego, czy zgodnie z zasadami odtwarzania mają być chronione, czy regenerowane.

Porównanie kopii zapasowych Immich wykonywanych na żywo i po zatrzymaniu usługi przygotowane przez ZimaSpace wyjaśnia podstawowy wybór dotyczący spójności. Ten proces zapobiegania idzie o krok dalej: niezależnie od wybranej metody musi ona utworzyć udokumentowany punkt, który można odtworzyć bez zgadywania, która baza danych odpowiada której kopii multimediów.

Zapisz kolejność odtwarzania obok zakresu kopii zapasowej. Jeśli plan mówi „odtwórz zdjęcia”, ale nie określa, który zrzut bazy danych, konfiguracja, dane uwierzytelniające i mapowania pamięci masowej ponownie połączą te zdjęcia z użytkownikami i albumami, definicja kopii zapasowej jest niekompletna jeszcze przed rozpoczęciem pierwszego zaplanowanego uruchomienia.

Wybierz przechwytywanie po zatrzymaniu, gdy wystarcza najprostsza granica

W przypadku małego gospodarstwa domowego, które może zaakceptować krótkie okno serwisowe, wstrzymaj przesyłanie plików i zatrzymaj usługi aplikacji zapisujące stan biblioteki. Utwórz kopię bazy danych, przechwyć multimedia i konfigurację, a następnie uruchom usługi ponownie dopiero po tym, jak migawka lub kopiowanie otrzyma wyraźny znacznik czasu i wynik zakończenia.

Zatrzymanie aplikacji nie sprawia automatycznie, że nieprawidłowa ścieżka staje się poprawna. Sprawdź, czy eksport bazy danych zakończył się powodzeniem, czy uwzględniono zamierzone katalogi główne multimediów oraz czy miejsce docelowe kopii zapasowej jest niezależne od aktywnych danych, które ma zabezpieczać. Zapisz godziny rozpoczęcia i zakończenia, aby późniejsze odtwarzanie mogło zidentyfikować dokładną generację.

Metoda jest poprawna, gdy podczas przechwytywania nie zachodzą żadne zapisy aplikacji, a testowe odtworzenie zwraca oczekiwanych użytkowników, liczbę zasobów, albumy i sprawdzone oryginały. Jeśli przestój regularnie przekracza akceptowalny czas dla gospodarstwa domowego, przejdź na skoordynowaną metodę na żywo, zamiast po cichu pozwalać na wznowienie przesyłania w połowie kopiowania pliku.

W przypadku kopii na żywo przechwytuj bazę danych i pliki w określonej kolejności

Gdy Immich musi pozostać dostępny, utwórz spójny zrzut natywny dla bazy danych, zamiast kopiować aktywny katalog danych PostgreSQL jako zwykłe pliki. Następnie przechwyć lub utwórz migawkę drzewa multimediów w udokumentowanej kolejności, śledząc przesłane pliki, które pojawią się w trakcie okna tworzenia kopii.

Praktyczny proces tworzenia kopii zapasowej bazy danych Immich pokazuje podejście uwzględniające bazę danych. Polecenia i nazwy kontenerów mogą różnić się w zależności od wdrożenia, dlatego uniwersalna zasada polega na poproszeniu PostgreSQL o spójną kopię zapasową, zamiast ufania aktywnemu rekurencyjnemu kopiowaniu plików bazy danych.

Preferuj kolejność, która nie dopuści do sytuacji, w której odtworzona baza danych wskazuje multimedia, które nigdy nie trafiły do kopii zapasowej. Jeśli kopia systemu plików zawiera dodatkowe pliki, o których baza danych jeszcze nie wie, można je bezpieczniej uzgodnić niż brakujące oryginały, do których odwołują się rekordy bazy danych. Udokumentuj wszystkie przesłane pliki przekraczające ustaloną granicę.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Koordynuj migawki systemu plików z mechanizmami bazy danych zamiast zakładać atomowość

Migawki systemu plików są wartościowe, ponieważ szybko przechwytują wolumin, ale same z siebie nie zapewniają transakcyjnej spójności dwóch niezależnie zmieniających się systemów. Jeśli baza danych i multimedia znajdują się w różnych zbiorach danych lub na różnych urządzeniach, określ działania przed utworzeniem migawki i po nim oraz zadbaj o widoczność ich harmonogramu w dzienniku kopii zapasowej.

Przykład z 2026 roku, łączący oprogramowanie do tworzenia kopii zapasowych z mechanizmami migawek Btrfs, pokazuje, dlaczego orkiestracja migawek wymaga jawnie określonych granic aplikacji lub bazy danych. Wykorzystaj tę koncepcję do koordynowania przechwytywania, ale nie kopiuj bezkrytycznie poleceń systemu plików do układu o innej strukturze.

Jeśli narzędzie do tworzenia migawek nie może skoordynować granicy czasowej bazy danych i multimediów, wróć do logicznego zrzutu bazy danych oraz kopii multimediów, zamiast twierdzić, że odzyskiwanie jest atomowe. Złożoność jest uzasadniona tylko wtedy, gdy próba odtworzenia dowodzi, że szybsze przechwytywanie nadal zwraca spójny stan aplikacji.

Uczyń testowanie odtwarzania częścią harmonogramu kopii zapasowych

Pomyślnie zakończone zadanie tworzenia kopii zapasowej jest jedynie dowodem, że przechwytywanie zostało ukończone. Okresowo wybieraj najnowszą generację, odtwarzaj ją pod izolowaną nazwą hosta, podłącz oczekiwaną pamięć masową i weryfikuj użytkowników, reprezentatywne oryginały, albumy, uprawnienia, działanie wyszukiwania oraz nową kopię bazy danych utworzoną z odtworzonej instancji.

Przegląd odtwarzania PostgreSQL dotyczący planowania tworzenia kopii zapasowych i odtwarzania podkreśla znaczenie weryfikacji odtwarzania oraz celów odtwarzania, zamiast traktować utworzenie zrzutu jako koniec procesu. Zastosuj tę samą dyscyplinę do połączonego modułu odtwarzania Immich.

Uznaj zasady tworzenia kopii zapasowych za niespełnione, jeśli odtworzenie bazy danych powiedzie się, ale brakuje plików, jeśli multimedia otwierają się bez użytkowników lub powiązań albo jeśli odtwarzanie zależy od sekretu przechowywanego wyłącznie na uszkodzonym hoście. Popraw zakres, kolejność, przechowywanie lub niezależność kopii, zanim zwiększysz częstotliwość tworzenia kopii; większa liczba niespójnych kopii nie tworzy niezawodnego punktu odtwarzania.