Rozwiązanie Discordu

Jak przenieść serwer CasaOS na nowy sprzęt

A user asked for a practical way to transfer an existing CasaOS server from one physical device to another.

Najlepsza strategia migracji: traktuj CasaOS jako trzy warstwy — system operacyjny hosta, definicje aplikacji i dane trwałe. Ponowna instalacja CasaOS jest łatwą częścią. Najważniejsze jest zachowanie folderów i konfiguracji faktycznie używanych przez kontenery, a następnie odtworzenie tych samych ścieżek na nowej maszynie.

Zainwentaryzuj wszystko przed kopiowaniem

  • wersje CasaOS i bazowego Linuksa;
  • obrazy kontenerów, porty i zmienne środowiskowe;
  • wszystkie źródłowe ścieżki montowań wiążących;
  • /DATA/AppData oraz niestandardowe foldery aplikacji;
  • punkty montowania dysków z multimediami/danymi;
  • właścicielstwo UID/GID;
  • statyczny adres IP, DNS, proxy, VPN i reguły zapory sieciowej.

Aplikacje ze sklepu CasaOS zwykle przechowują dane w ścieżce /DATA/AppData/$AppID. Wzorzec AppData CasaOS pokazuje, dlaczego samo skopiowanie kontenera Dockera nie jest migracją.

Zatrzymaj aplikacje intensywnie zapisujące dane przed końcowym kopiowaniem

Bazy danych i stan aplikacji mogą zmienić się podczas kopiowania. Zatrzymaj odpowiednie kontenery — lub Dockera w celu wykonania końcowej synchronizacji — przed utworzeniem ostatniej kopii zapasowej.

sudo systemctl stop casaos-app-management
sudo systemctl stop docker

Następnie skopiuj dane za pomocą narzędzia zachowującego metadane, takiego jak rsync -aHAX jeśli obsługują je używane systemy plików.

Zainwentaryzuj także woluminy nazwane

Niektóre aplikacje korzystają z woluminów Dockera zamiast montowań wiążących hosta. trwałe woluminy Dockera przetrwają usunięcie kontenerów, ale nadal trzeba je celowo przenieść.

Najpierw odtwórz ścieżki magazynu

W nowym hoście zamontuj dyski przed uruchomieniem aplikacji. Jeśli Jellyfin wcześniej korzystał z /DATA/Media/Movies, przywrócenie tej samej ścieżki pozwala uniknąć uszkodzenia bibliotek. Jeśli ścieżki się zmienią, edytuj mapowania kontenerów przed pierwszym uruchomieniem.

Zachowaj numeryczne właścicielstwo

Kontenery korzystają z numerycznych identyfikatorów UID/GID. Porównaj ważne katalogi w starym i nowym systemie:

stat -c '%u:%g %a %n' /DATA/AppData/*

Przywracaj usługi etapami

  1. Zainstaluj obsługiwaną bazową dystrybucję Linuksa.
  2. Zainstaluj CasaOS.
  3. Zamontuj wszystkie dyski z danymi.
  4. Przywróć dane trwałe.
  5. Odtwórz/zaimportuj definicje aplikacji.
  6. Uruchamiaj aplikacje przechowujące stan pojedynczo.
  7. Zweryfikuj bazy danych, multimedia, uprawnienia i harmonogramy.
  8. Przełącz adres IP/DNS dopiero po pomyślnym zakończeniu testów.

Struktura Dockera w CasaOS wyjaśnia, dlaczego dane aplikacji i kontenery to odrębne kwestie. Platforma aplikacji hostowanych samodzielnie jest istotna, jeśli migrujesz do ZimaOS zamiast odbudowywać CasaOS.

W przypadku kompaktowego zamiennika x86 ZimaBoard 2 może sprawdzić się w mniejszych wdrożeniach.

Sklasyfikuj każdą aplikację według typu stanu

Nie wszystkie kontenery migruje się w ten sam sposób:

  • Bezstanowe: konfigurację można odtworzyć z pliku Compose i zmiennych środowiskowych.
  • Oparte na plikach: skopiuj foldery montowane przez bind mount.
  • SQLite: zatrzymaj aplikację przed skopiowaniem pliku bazy danych.
  • PostgreSQL/MySQL: w miarę możliwości użyj kopii zapasowej aplikacji/bazy danych zamiast polegać wyłącznie na kopii działającego systemu plików.
  • Aplikacje korzystające z nazwanych woluminów: celowo wyeksportuj lub skopiuj wolumin Dockera.

Zapisz bieżącą konfigurację Dockera

Dla każdego ważnego kontenera zapisz:

docker inspect <container> > container-inspect.json

Nie jest to gotowy do zaimportowania plik Compose, ale zapisuje punkty montowania, porty, zmienne środowiskowe, sieci i urządzenia, dzięki czemu możesz sprawdzić, czy odbudowana usługa odpowiada starej.

Zaplanuj przełączenie adresu IP i nazwy hosta

Jeśli klienci korzystają z nazwy hosta serwera, migracja jest łatwiejsza: po weryfikacji skieruj DNS na nowy adres IP. Jeśli każda aplikacja ma na stałe wpisany stary adres IP, możesz przypisać stary statyczny adres nowemu hostowi po wyłączeniu starego.

Nie zmieniaj niczego na starym serwerze, dopóki wycofanie migracji nie będzie już potrzebne

Nie usuwaj natychmiast źródła po pierwszym pomyślnym logowaniu. Pozostaw je wyłączone, ale nienaruszone, co najmniej przez jeden cykl tworzenia kopii zapasowej i jeden okres normalnego użytkowania. Zapewni to sprawny punkt powrotu na wypadek pominięcia zaplanowanego zadania, bazy danych lub klienta zdalnego.

Sprawdź dane, nie tylko kontenery

Zielony status Dockera potwierdza tylko, że proces działa. Sprawdź:

  • biblioteka Jellyfin i stan oglądania;
  • stan folderów Syncthing;
  • zadania tworzenia kopii zapasowych i testy przywracania;
  • aplikacje bazodanowe;
  • ścieżki dysków zewnętrznych;
  • certyfikaty odwrotnego proxy;
  • zdalny dostęp przez VPN/tunel.

FAQ

Czy mogę sklonować dysk rozruchowy?

Czasami, ale klon zawiera założenia dotyczące sprzętowej konfiguracji sieci, uruchamiania i montowania. Czysty host wraz z przywróconymi danymi często jest łatwiejszy do zweryfikowania.

Kiedy mogę wyłączyć stary serwer?

Dopiero gdy logowanie do aplikacji, bazy danych, ścieżki multimediów, uprawnienia, zaplanowane zadania, kopie zapasowe i zdalny dostęp działają na nowym hoście.