전원 장애 후 ZimaOS 볼륨이 읽기 전용으로 전환되었다면 권한 문제가 아니라 파일 시스템 보호 이벤트로 봐야 합니다. 이 1.4.0 사례에서 Windows는 I/O 오류를 보고했고 ZimaOS 파일 브라우저에는 “읽기 전용 파일 시스템”이 표시되었습니다. 사용자는 결국 fsck로 접근 권한을 복구했습니다.
이 성공적인 복구는 유용한 근거이지만, 먼저 파일 시스템과 마운트 해제 상태를 확인하지 않고 정확한 명령을 그대로 복사해 실행하는 것은 안전하지 않습니다. 파일 시스템마다 필요한 복구 도구가 다르며, 마운트된 볼륨을 대상으로 무작정 복구를 시도해서는 안 됩니다.
어떤 장애가 발생했나
서버에는 2TB RAID1 어레이가 사용되었습니다. 전원 장애 후 Windows SMB를 통해 파일을 안정적으로 열 수 없었고, ZimaOS 파일 브라우저에서 직접 폴더를 만들 수도 없었습니다. RAID 마운트가 읽기 전용으로 전환되었기 때문입니다.
이 조합은 중요합니다. 클라이언트 측 접근 오류와 호스트 측 읽기 전용 파일 시스템 메시지가 함께 나타난다면 Samba 권한보다 더 하위 계층의 문제일 가능성이 높습니다. 사용자를 변경하거나 ACL 및 공유 설정을 수정하기 전에 스토리지 또는 파일 시스템 무결성을 확인해야 한다는 의미입니다.
포럼의 복구 방법은 사용자에 의해 검증됨
사용자는 모니터와 키보드를 연결하고 높은 권한으로 로그인한 뒤 fdisk -l로 Linux 파일 시스템 장치를 확인했습니다. 그런 다음 RAID 장치에 fsck -f를 실행하고, 오류가 남아 있자 검사를 반복한 후 재부팅했습니다. 사용자는 이를 통해 정상적인 읽기/쓰기 동작이 복구되었다고 보고했습니다.
이는 실제로 사용자가 검증한 결과이지만 IceWhale이 작성한 공식 복구 절차는 아닙니다. 더 안전한 원칙은 먼저 정확한 파일 시스템을 확인하는 것입니다. e2fsck 매뉴얼은 제한적으로 정의된 읽기 전용 사례를 제외하고 마운트된 ext 파일 시스템을 검사하지 말라고 경고합니다.
위험을 줄이는 복구 순서 사용
복구를 시작하기 전에 해당 볼륨에 쓰기 작업을 수행하는 앱과 동기화 작업을 중지하세요. 중요한 데이터를 아직 읽을 수 있다면 가장 중요한 파일부터 별도의 정상 스토리지로 복사하세요. 어레이를 재부팅하거나 변경하기 전에 풀 구성과 현재 오류를 기록하세요.
읽기 전용 볼륨 체크리스트에서는 ext4, XFS, Btrfs 및 ZFS에 대한 이 과정을 자세히 설명합니다. 모든 ZimaOS 어레이에 동일한 fsck 명령을 실행한다고 가정하는 것보다 더 나은 출발점입니다.
현재 ZimaOS 터미널에 액세스하는 방법
현재 ZimaOS는 개발자 모드에서 SSH와 내장 웹 터미널을 제공합니다. 현재 SSH 설정 안내에서 이러한 액세스 방법을 설명합니다.
터미널에 액세스한 후 먼저 장치와 파일 시스템 유형을 확인하세요. 정상적으로 시스템을 실행하는 동안 영향을 받은 볼륨을 깨끗하게 마운트 해제할 수 없다면, 현재 위치에서 강제로 복구하지 말고 적절한 유지 관리 또는 복구 환경을 사용하세요.
같은 장애가 데이터 손실로 이어지지 않도록 방지
UPS는 갑작스러운 종료를 줄일 수 있지만 백업을 대신할 수는 없습니다. RAID 복구의 한계에서는 미러링된 어레이에도 독립적으로 복구 가능한 사본이 필요한 이유를 설명합니다.
결론
이 포럼 사례는 실제로 파일 시스템 복구를 통해 해결되었지만, 교훈은 “전원 장애가 발생할 때마다 fsck -f를 실행하라”는 것이 아닙니다. 올바른 원칙은 읽을 수 있는 데이터를 보존하고, 파일 시스템과 장치를 확인하며, 필요한 경우 마운트를 해제하고, 해당 파일 시스템에 맞는 기본 복구 도구를 사용한 다음에야 쓰기 작업을 복원하는 것입니다.
