소스의 UrBackup 설치는 정상 작동하기 전까지 몇 가지 독립적인 이유로 실패했습니다. 이미지 가져오기가 중국 본토 전용 미러를 통해 다시 작성되었고, 첫 번째 바인드 경로가 ZimaOS 호스트에 존재하지 않았으며, 백업 디렉터리 권한이 잘못되었고, 앱 런처 URL/포트가 혼동을 일으켰습니다.
핵심 교훈은 UrBackup을 일반적인 상태 저장 Docker 애플리케이션으로 취급하는 것입니다. 실제 호스트 저장소 경로를 사용하고, 백업 데이터와 UrBackup 데이터베이스/상태를 모두 영구 저장하며, 런타임 사용자 권한을 확인하고, 클라이언트 백업에 의존하기 전에 WebUI/네트워크 리스너를 확인해야 합니다.
첫 번째 이미지 가져오기는 사용할 수 없는 미러로 다시 작성되었습니다
데몬이 다음 이미지 가져오기 거부 메시지를 반환했습니다 docker.1panel.live/uroni/urbackup-server. 공식 UrBackup 다운로드 페이지에서도 여전히 다음을 식별합니다 uroni/urbackup-server 공식 Docker 이미지로 사용됩니다.
현재 공식 UrBackup Docker 이미지를 참조하세요.
바인드 마운트는 실제 ZimaOS 호스트 폴더를 가리켜야 합니다
작동한 요약에서는 다음과 같은 실제 저장소 경로를 사용했습니다 /media/Safe-Storage/UrBackup/backups 및 /media/Safe-Storage/UrBackup/data에 매핑되었습니다 /backups 및 /var/urbackup소스의 저장소 이름을 그대로 복사하지 말고 실제 호스트 경로를 확인하세요.
권한 거부는 컨테이너 사용자가 쓸 수 없다는 의미입니다
소스에서는 다음 문제가 발생했습니다 "/backups/urbackup_tmp_files"에 액세스할 권한이 없습니다. 수정 과정에서는 특정 UID/GID와 일치하는 호스트 소유권을 사용했습니다. 다음 값을 고정하지 마세요 1000:100 범용 사용자 ID로서 사용합니다. 현재 런타임 사용자를 확인하세요.
두 백업과 UrBackup 상태를 모두 영구 저장하세요
리포지토리에는 클라이언트 백업 데이터가 포함되어 있으며 /var/urbackup 서버 데이터베이스/상태가 포함됩니다. 사용 가능한 복구 계획에서는 필요에 따라 두 항목을 모두 보존해야 합니다.
소스에서는 호스트 네트워킹을 사용했습니다
유지 관리되는 uroni/urbackup-server image는 현재 지원되는 Docker 패턴 중 하나로 호스트 네트워킹을 문서화하고 있으며, 일반적인 UrBackup 서비스 포트를 노출합니다. 호스트 네트워킹은 검색을 간소화하지만 Docker 네트워크 격리를 제거합니다.
WebUI에는 올바른 포트가 필요합니다
소스에서는 ZimaOS 런처의 포트를 55414로 수정했습니다. 런처는 편의를 위한 URL일 뿐이며, 실제 서비스 상태는 로그와 리스너에서 확인해야 합니다.
재현 가능한 Compose 정의를 우선하세요
현재 ZimaOS App Store 2.0 및 사용자 지정 앱 워크플로에서는 표준 Docker Compose를 지원합니다. 이미지, 영구 경로, 시간대, 재시작 정책 및 네트워킹을 하나의 Compose 정의에 포함하세요.
현재 ZimaOS Compose 모델을 사용하세요.
실행 중인 대시보드는 최종 테스트가 아닙니다
클라이언트 하나를 등록하고 소규모 백업을 완료한 다음 컨테이너/호스트를 다시 시작하고 파일을 복원하세요. 이렇게 하면 네트워킹, 권한, 데이터베이스 영구 저장 및 백업 스토리지를 함께 검증할 수 있습니다.
백업 저장소는 시스템 디스크가 아닌 데이터 스토리지에 배치하세요
UrBackup은 수백 기가바이트 이상을 사용할 수 있습니다. 저장소 경로는 용량과 상태를 파악할 수 있는 실제 ZimaOS 스토리지 공간을 가리켜야 하며, 작은 운영 체제 드라이브를 가리켜서는 안 됩니다.
클라이언트를 추가하기 전에 ZimaOS의 호스트 경로를 확인하고 첫 전체 백업 중 여유 공간을 확인하세요.
UrBackup 데이터베이스는 복원 시스템의 일부입니다
다음 위치의 파일은 /backups 사용 가능한 서버를 구성하는 요소는 그 절반에 불과합니다. 다음 위치의 UrBackup 상태/데이터베이스는 /var/urbackup 클라이언트, 백업 메타데이터, 보존 정책 및 서버 구성을 추적합니다.
두 영구 매핑을 모두 문서화하고 보호하여 컨테이너를 재생성해도 예상되는 서버 상태 없이 백업 파일만 쌓이지 않도록 하세요.
최소 권한의 쓰기 액세스 사용
소스에 지정된 UID/GID 조정으로 한 배포 문제는 해결되었지만, 전체 스토리지 풀에 재귀적으로 소유권을 변경하는 것은 위험합니다. 전용 UrBackup 디렉터리를 만들고, 관련 없는 NAS 데이터에 광범위한 쓰기 권한을 부여하는 대신 컨테이너 ID에 해당 디렉터리へのアクセス 권한을 부여하세요.
호스트 네트워킹은 UrBackup 서비스를 ZimaOS에 직접 노출합니다
호스트 네트워킹을 사용하면 UrBackup 리스너가 호스트 리스너가 됩니다. ZFW 또는 다른 방화벽이 NAS를 보호하는 경우 백업 및 검색에 필요한 포트와 클라이언트 네트워크만 허용하세요. UrBackup 서비스 포트를 공용 인터넷에 직접 공개하지 마세요.
백업 서버 완료를 선언하기 전에 복원을 테스트하세요
클라이언트 백업을 한 번 완료하고 ZimaOS를 다시 시작하거나 컨테이너를 재생성한 다음, 클라이언트 기록이 유지되는지 확인하고 별도의 위치에 여러 파일을 복원하세요. 이렇게 하면 대시보드가 녹색으로 표시되는지만 확인하는 것이 아니라 이미지 사용 가능 여부, 권한, 영구 상태, 네트워킹 및 실제 복구 가능성을 검증할 수 있습니다.
ZimaOS의 UrBackup FAQ
소스 사용자가 결국 UrBackup을 작동시켰나요?
예.
모든 ZimaOS 시스템에서 PUID 1000과 PGID 100을 사용해야 하나요?
아니요. 해당 값은 소스에만 해당하는 값입니다.
호스트 네트워킹이 필수인가요?
보편적으로 그런 것은 아닙니다. 문서화된 이미지 옵션이며 원본에서는 성공적으로 사용했지만, 네트워크 격리 수준이 낮아집니다.
