최적의 마이그레이션 전략: CasaOS를 호스트 OS, 앱 정의 및 영구 데이터라는 세 개의 계층으로 취급하세요. CasaOS를 다시 설치하는 것은 쉬운 부분입니다. 중요한 작업은 컨테이너가 실제로 사용하는 폴더와 구성을 보존한 다음 새 시스템에서 동일한 경로를 다시 생성하는 것입니다.
복사하기 전에 인벤토리를 작성하세요
- CasaOS 및 기본 Linux 버전;
- 컨테이너 이미지, 포트 및 환경 변수;
- 모든 바인드 마운트 소스 경로;
-
/DATA/AppData사용자 지정 앱 폴더; - 미디어/데이터 디스크 마운트 지점;
- UID/GID 소유권;
- 고정 IP, DNS, 프록시, VPN 및 방화벽 규칙.
CasaOS 스토어 앱은 일반적으로 /DATA/AppData/$AppID 아래에 데이터를 저장합니다. CasaOS AppData 패턴은 Docker 컨테이너만 복사하는 것이 마이그레이션이 아닌 이유를 보여 줍니다.
최종 복사 전에 쓰기 작업이 많은 앱을 중지하세요
복사하는 동안 데이터베이스와 앱 상태가 변경될 수 있습니다. 마지막 백업을 수행하기 전에 관련 컨테이너 또는 최종 동기화 작업을 위해 Docker를 중지하세요.
sudo systemctl stop casaos-app-management
sudo systemctl stop docker그런 다음 메타데이터를 보존하는 도구를 사용해 복사하세요. 예를 들어 rsync -aHAX 파일 시스템에서 이를 지원하는 경우.
이름이 지정된 볼륨도 목록화하세요
일부 앱은 호스트 바인드 마운트 대신 Docker 볼륨을 사용합니다. Docker의 영구 Docker 볼륨은 컨테이너보다 오래 유지되지만, 여전히 의도적으로 마이그레이션해야 합니다.
먼저 스토리지 경로를 다시 생성하세요
새 호스트에서는 앱을 실행하기 전에 디스크를 마운트하세요. Jellyfin이 이전에 사용했다면 /DATA/Media/Movies동일한 경로를 복원하면 라이브러리 손상을 방지할 수 있습니다. 경로가 변경되면 처음 시작하기 전에 컨테이너 매핑을 수정하세요.
숫자 소유권을 유지하세요
컨테이너는 숫자 UID/GID를 기준으로 동작합니다. 기존 시스템과 새 시스템에서 중요한 디렉터리를 비교하세요.
stat -c '%u:%g %a %n' /DATA/AppData/*서비스를 단계적으로 복구하세요
- 지원되는 Linux 기반 시스템을 설치하세요.
- CasaOS를 설치하세요.
- 모든 데이터 디스크를 마운트하세요.
- 영구 데이터를 복원하세요.
- 앱 정의를 다시 생성하거나 가져오세요.
- 상태 저장 앱을 하나씩 시작하세요.
- 데이터베이스, 미디어, 권한 및 예약 작업을 검증하세요.
- 테스트가 통과한 후에만 IP/DNS를 전환하세요.
CasaOS Docker 구조는 앱 데이터와 컨테이너가 별개의 문제인 이유를 설명합니다. 셀프 호스팅 앱 플랫폼은 CasaOS를 재구축하는 대신 ZimaOS로 마이그레이션하려는 경우에 유용합니다.
소규모 배포를 위한 컴팩트한 x86 교체 장치로는 ZimaBoard 2를 사용할 수 있습니다.
각 앱을 상태 유형별로 분류하세요
모든 컨테이너를 같은 방식으로 마이그레이션할 수 있는 것은 아닙니다.
- 상태 비저장: compose/environment에서 구성을 다시 만들 수 있습니다.
- 파일 기반: 바인드 마운트된 폴더를 복사하세요.
- SQLite: 데이터베이스 파일을 복사하기 전에 앱을 중지하세요.
- PostgreSQL/MySQL: 가능하면 라이브 파일 시스템 복사본에만 의존하지 말고 애플리케이션/데이터베이스 백업을 사용하세요.
- 이름 있는 볼륨 앱: Docker 볼륨을 의도적으로 내보내거나 복사하세요.
현재 Docker 구성 캡처하기
각 주요 컨테이너에 대해 다음을 저장하세요.
docker inspect <container> > container-inspect.json바로 가져와 사용할 수 있는 compose 파일은 아니지만, 마운트, 포트, 환경, 네트워크 및 장치를 기록하므로 재구축한 서비스가 기존 서비스와 일치하는지 확인할 수 있습니다.
IP 및 호스트 이름 전환 계획 세우기
클라이언트가 서버 호스트 이름을 사용한다면 마이그레이션이 더 쉽습니다. 검증 후 DNS가 새 IP를 가리키도록 변경하세요. 모든 앱에 기존 IP가 하드코딩되어 있다면 기존 서버의 전원을 끈 후 새 호스트에 기존 고정 주소를 할당하는 방법을 고려할 수 있습니다.
롤백이 불필요해질 때까지 기존 서버를 변경하지 말고 유지하세요
첫 로그인에 성공했다고 즉시 원본을 지우지 마세요. 최소 한 번의 백업 주기와 한 번의 정상 사용 기간 동안 전원을 끄되 온전한 상태로 보관하세요. 이렇게 하면 예약 작업, 데이터베이스 또는 원격 클라이언트를 놓쳤을 때 정상 작동이 확인된 롤백 지점을 확보할 수 있습니다.
컨테이너뿐 아니라 데이터도 확인하세요
초록색 Docker 상태는 프로세스가 실행 중이라는 사실만 증명합니다. 다음을 확인하세요.
- Jellyfin 라이브러리 및 시청 상태;
- Syncthing 폴더 상태;
- 백업 작업 및 복원 테스트;
- 데이터베이스 애플리케이션;
- 외장 드라이브 경로;
- 리버스 프록시 인증서;
- 원격 VPN/터널 액세스.
FAQ
부팅 디스크를 복제해도 되나요?
경우에 따라 가능하지만, 복제하면 하드웨어에 종속된 네트워크, 부팅 및 마운트 설정이 그대로 따라옵니다. 새 호스트를 정리한 후 데이터를 복원하는 편이 검증하기 더 쉬운 경우가 많습니다.
기존 서버는 언제 폐기해도 되나요?
새 호스트에서 앱 로그인, 데이터베이스, 미디어 경로, 권한, 예약 작업, 백업 및 원격 액세스가 모두 작동한 후에만 진행하세요.
