이 스레드는 재시작 문제로 시작해, ZimaOS가 시스템 디스크 전체 용량, AppData 마이그레이션, 앱 재설치 및 저장 공간 복구를 처리하는 방식을 알아보는 상세한 커뮤니티 실험으로 끝났습니다. 원래 사용자는 USB 백업 드라이브를 연결하지 않은 상태로 ZimaOS를 부팅한 뒤, 일반 로그인 화면 대신 최초 부팅 시와 같은 계정 생성 화면이 나타나는 것을 확인했습니다. NFS 데이터에는 계속 접근할 수 있었지만, 프런트엔드와 파일 관련 서비스는 정상적으로 작동하지 않았습니다.
가장 중요한 발견은 ZimaOS-HD의 사용량이 100%에 도달했다는 점입니다. 이후 사용자는 시스템을 ZimaOS 1.5.2로 업데이트했지만, 시스템 볼륨이 가득 찬 상태가 핵심 문제로 남았습니다. 따라서 이는 유용한 역사적 문제 해결 사례이지만, 보편적으로 적용할 수 있는 재설치 절차는 아닙니다.
ZimaOS-HD가 100% 가득 차면 파일 앱 외에도 여러 기능이 중단될 수 있습니다
원본 사례에서 사용자는 NFS를 통해 저장된 데이터에는 계속 접근할 수 있었지만, 대시보드, Files 서비스, 앱 인덱싱 및 계정 관련 UI가 불안정해졌습니다. 커뮤니티 참여자는 이러한 증상을 시스템 파티션이 완전히 가득 찬 상태와 연결했습니다.
이 스레드에는 용량이 100% 찬 시스템 디스크를 안전하게 복구하기 위한 IceWhale 공식 정리 명령이 제공되지 않았습니다. 사용자는 이미 컨테이너를 삭제하고 로그를 정리했지만 충분한 공간을 확보하지 못했습니다. 중요한 점은 커뮤니티 스레드의 추측성 셸 정리 방법을 공식 복구 절차로 간주해서는 안 된다는 것입니다.
최신 시스템 및 저장 공간 지침은 현재 ZimaOS가 저장 공간과 복구를 처리하는 방식을 참고하세요.
IceWhale은 기본 구성이 재설치에 안전하지 않다고 경고했습니다
Zima-Giorgio는 논의에 중요한 정정을 추가했습니다. 대부분의 사용자가 운영 체제와 사용자 데이터를 같은 디스크에 저장하는 기본 구성을 사용하며, 이러한 구성에서는 재설치한다고 해서 모든 항목이 자동으로 다시 인덱싱되고 복원되는 것은 아니라고 설명했습니다. 또한 3-2-1 백업 규칙도 강조했습니다.
이 공식적인 주의사항은 중요합니다. 이전 커뮤니티 답변에서는 재설치 후 복구가 실제보다 더 자동으로 진행되는 것처럼 설명했기 때문입니다. 재설치 후 데이터가 보존되는지는 장애 발생 전에 저장 공간이 어떻게 구성되어 있었는지에 따라 달라집니다.
사용자의 마이그레이션 테스트에서 실제로 확인된 내용
스레드의 두 번째 페이지에는 전용 OS 디스크와 별도의 NVMe 데이터 디스크를 사용한 반복적인 재설치 테스트가 담겨 있습니다. 사용자의 결과에서 확인된 몇 가지 실질적인 동작은 다음과 같습니다.
- 새로 설치한 후, 이전에 사용하던 단일 NVMe 저장 디스크를 다시 활성화해야 할 수 있습니다.
- 기존 AppData 폴더가 있다는 이유만으로 앱이 대시보드에 자동으로 다시 나타나지는 않습니다.
- 앱 컨테이너 또는 이미지를 App Store에서 다시 설치해야 합니다.
- 재설치 전에 영구 애플리케이션 데이터를 별도의 저장 공간으로 마이그레이션했다면 해당 데이터가 유지될 수 있습니다.
- 사용자 지정 포트, 컨테이너 이름, 네트워크 설정, 권한 및 대시보드 표시 방식과 같은 ZimaOS 수준의 메타데이터는 유지된다고 가정해서는 안 됩니다.
이는 ZimaOS 1.5.2에서 수행된 커뮤니티 테스트이며, IceWhale의 복구 보장이 아닙니다. 해당 시기의 관찰된 동작으로만 받아들이세요.
마이그레이션은 완전한 컨테이너 백업이 아닙니다
이 스레드에서 얻을 수 있는 가장 유용한 교훈 중 하나는 애플리케이션 데이터와 ZimaOS 앱 메타데이터의 차이입니다. 사용자는 마이그레이션된 데이터가 앱을 이전과 완전히 동일하게 복원할 것으로 예상했습니다. 그러나 테스트 결과는 그렇지 않았습니다.
마이그레이션을 통해 파일과 애플리케이션이 소유한 데이터는 보존할 수 있었지만, ZimaOS 앱 편집기에서 입력했던 모든 설정이 복원되지는 않았습니다. 예를 들어 사용자 지정 포트 매핑이나 기타 컨테이너 수준 설정은 재설치 후 다시 구성해야 할 수 있습니다.
이 차이를 이해하면 재설치 후 애플리케이션이 기존 데이터베이스나 미디어에 다시 연결되면서도 ZimaOS 대시보드 구성은 새로 표시될 수 있는 이유를 알 수 있습니다.
단일 디스크 복구를 RAID에 일반화하지 마세요
스레드에서는 RAID 5 어레이가 새로 설치한 후 자동으로 인식되는지도 주요하게 논의되었습니다. 사용자는 시스템이 기존 RAID를 즉시 앱 데이터 대상으로 인식하는 대신 저장 공간을 생성하거나 포맷하려고 한다는 것을 확인했습니다.
이에 따라 모든 데이터 볼륨이 자동으로 보존되고 다시 연결된다는 앞선 주장은 철회되었습니다. 이 스레드에서 내릴 수 있는 가장 안전한 결론은 테스트한 ZimaOS 1.5.2 워크플로에서 별도의 단일 저장 디스크와 RAID 어레이가 동일하게 동작하지 않았다는 정도입니다.
현재 ZimaOS의 저장 공간 동작은 이 2025년 스레드 이후 변경되었습니다. 이러한 RAID 관찰 결과를 현재 제품 동작으로 사용하지 말고 최신 저장 공간 문서를 확인하세요.
이 스레드에서 얻을 수 있는 더 안전한 재설치 원칙
- ZimaOS 저장 공간을 변경하거나 재설치하기 전에 중요한 데이터를 백업하세요.
- 어떤 물리 디스크에 운영 체제가 있고 어떤 디스크에 사용자 데이터가 있는지 확인하세요.
- 마이그레이션이 컨테이너 구성 전체의 백업과 같다고 가정하지 마세요.
- 재설치 후 앱을 다시 설치하기 전에 저장 공간이 활성화되어 마운트되었는지 확인하세요.
- 영구 데이터가 유지되더라도 애플리케이션 컨테이너나 이미지는 다시 설치해야 할 수 있습니다.
- 별도의 내보내기 또는 백업이 없다면 ZimaOS 수준의 앱 설정은 수동으로 다시 적용해야 합니다.
ZimaOS 재설치 및 마이그레이션 FAQ
프런트엔드는 작동하지 않았는데 NFS 데이터에는 계속 접근할 수 있었던 이유는 무엇인가요?
이 사례에서는 시스템 볼륨이 100% 가득 찼습니다. 스레드에서는 일부 데이터 접근은 계속 가능했지만 이러한 상태가 프런트엔드 및 서비스 장애와 관련 있다고 설명했습니다.
AppData를 마이그레이션하면 재설치 후 설치된 앱이 자동으로 다시 나타나나요?
아니요. 사용자의 테스트에서는 대시보드가 비어 있었고 앱을 다시 설치해야 했습니다. 이후 기존 영구 데이터를 다시 사용할 수 있었습니다.
마이그레이션을 하면 사용자 지정 포트와 ZimaOS 앱 설정도 보존되나요?
스레드의 후속 테스트에 따르면 그렇게 가정해서는 안 됩니다. 마이그레이션은 각 컨테이너를 설명하는 ZimaOS 메타데이터보다 애플리케이션 데이터를 더 잘 보존했습니다.
이 스레드를 근거로 RAID 구성에 안전하게 재설치할 수 있나요?
보편적인 보장은 확인되지 않았습니다. RAID 테스트는 단일 디스크 마이그레이션 테스트와 다르게 동작했으며, 공식 답변도 자동 복구를 약속하기보다 백업을 강조했습니다.
