중복 제거된 백업 저장소가 중단된 정리 작업 후 읽기 전용으로 작동하는 이유
중단된 prune 작업 후 독점 잠금, 스토리지 오류, 변경 불가 백엔드 또는 완료되지 않은 유지 관리 상태로 인해 저장소가 읽기 전용으로 작동할 수 있습니다.
“읽기 전용”은 파일 시스템의 실제 마운트 모드가 아니라 백업 클라이언트의 안전 대응일 수 있습니다. 취소된 prune 작업으로 독점 잠금, 완료되지 않은 pack 또는 index 작업, 부족한 정리 작업 공간이 남거나 읽기는 허용하지만 삭제는 거부하는 백엔드 작업이 발생할 수 있습니다. 이와 별개로 운영 체제는 I/O 또는 일관성 오류 후 저장소 파일 시스템을 읽기 전용으로 다시 마운트할 수 있습니다. 잠금을 제거하거나 prune을 다시 실행하기 전에 어느 계층에서 첫 번째 쓰기 작업을 거부하는지 확인하세요.
읽기 전용을 보고하는 첫 번째 작업을 확인하세요
저장소 목록 명령을 실행한 다음 변경하지 않는 검사를 한 번 실행하고, 클라이언트, 백엔드 및 운영 체제 로그에서 처음 발생한 오류를 저장하세요.
Restic 문서에서는 prune이 저장소 데이터를 다시 작성하며, 참조되지 않는 콘텐츠를 제거하고 일부만 사용된 파일을 재패킹할 수 있으므로 독점 액세스가 필요하다고 설명합니다.
목록 조회는 작동하지만 잠금을 생성하거나 메타데이터를 기록하는 모든 작업이 실패한다면 오래된 잠금, 백엔드 쓰기 권한 및 객체 보존 정책을 구분하세요.
중단된 prune 작업이 남긴 독점 잠금을 확인하세요
백업 도구를 통해 저장소 잠금을 나열하고 각 잠금의 호스트, 프로세스, 생성 시간 및 잠금을 소유한 명령을 확인하세요.
Borg 문서에서는 저장소를 변경하는 명령이 동시 쓰기를 방지하기 위해 저장소 잠금을 사용한다고 설명하며, 활성 잠금을 해제하면 저장소 상태가 손상될 수 있다고 경고합니다.
소유자가 종료되었다는 사실을 확인한 후에만 지원되는 명령을 사용하여 오래된 잠금을 제거하세요.
파일 시스템이 읽기 전용으로 다시 마운트되었는지 확인하세요
마운트 테이블, 커널 로그, 파일 시스템 상태, 스토리지 풀 상태와 최근 USB, SATA, 네트워크 또는 컨트롤러 오류를 확인하세요.
Linux ext4 문서에는 errors=remount-ro가 안전 정책으로 나와 있어 스토리지 장애로 저장소가 실제 읽기 전용이 될 수 있음을 보여 줍니다.
하드웨어 또는 파일 시스템 오류가 계속되는 동안 강제로 읽기-쓰기 재마운트를 수행하지 마세요. 먼저 로그를 보존하고 스토리지를 복구하세요.
부분적으로 진행된 prune, compact 또는 index 상태를 점검하세요
만료된 스냅샷 선택, 참조 삭제, 데이터 재패킹, 인덱스 재구성 또는 메타데이터 커밋 중 어느 단계가 중단되었는지 확인하세요.
Borg prune 참조 문서에서는 prune과 compact가 별도 단계라고 설명하므로, 공간 회수가 완료되지 않은 상태에서도 아카이브는 유효할 수 있습니다.
파괴적인 작업을 다시 실행하기 전에 저장소 검사 명령을 사용하세요. pack, index 또는 segment를 수동으로 삭제하지 마세요.
객체 잠금, 변경 불가 설정 및 백엔드 자격 증명을 확인하세요
클라우드 저장소의 경우 객체 보존, 법적 보류, 버킷 정책, 버전 관리, 삭제 권한 및 자격 증명 교체 상태를 확인하세요.
AWS는 S3 객체 잠금이 보호된 보존 기간 동안 삭제 또는 덮어쓰기를 방지하므로 읽기는 가능하지만 prune은 실패할 수 있다고 설명합니다.
prune을 통과시키기 위해 변경 불가 보존 정책을 약화하지 마세요. 백업 도구가 지원하는 저장소 설계를 사용하세요.
여유 공간, inode 및 prune 작업 공간을 확인하세요
파일 시스템의 바이트와 inode, 할당량, 스냅샷 예약 공간, 임시 디렉터리, 객체 스토리지 한도 및 로컬 캐시 공간을 확인하세요.
GNU Coreutils는 df가 블록과 inode 사용량을 보고하므로, 파일 시스템이 가득 찬 경우와 저장소 수준의 잠금 또는 권한 오류를 구분할 수 있다고 설명합니다.
파일 시스템이 가득 찼다면 저장소 객체를 삭제하는 대신 임시 용량을 추가하거나 검증이 끝난 관련 없는 데이터를 제거하세요.
검사, 잠금 해제 및 통제된 유지 관리 한 번으로 복구하세요
마지막으로 정상 작동이 확인된 복원 지점을 보호하고, 예약 작업을 중지한 뒤, 지원되는 검사를 실행하세요. 확인된 오래된 잠금만 해제하고 로그를 남기면서 유지 관리 작업을 한 번 수행하세요.
ZimaSpace의 가득 찬 백업 대상 복구 가이드는 저장소를 서로 독립적인 파일이 아니라 관리되는 구조로 취급해야 한다는 관련 원칙을 제공합니다.
목록 조회, 검사, 백업, 보존 정책 적용 및 테스트 복원이 강제 잠금 해제나 수동 삭제 없이 모두 성공하면 문제가 해결된 것입니다.
자주 묻는 질문
잠금 파일을 수동으로 삭제해도 되나요?
첫 단계로 수행해서는 안 됩니다. 어떤 프로세스도 잠금을 소유하지 않는지 확인하고 백업 도구가 지원하는 잠금 해제 작업을 사용하세요.
충돌 후 즉시 prune을 다시 실행해야 하나요?
아니요. 파괴적인 유지 관리 작업을 다시 실행하기 전에 저장소, 인덱스, 파일 시스템 및 백엔드 상태를 확인하세요.
읽기 전용 동작은 백업 데이터가 안전하다는 뜻인가요?
반드시 그렇지는 않습니다. 누락된 pack, 스토리지 오류, 변경 불가 객체 또는 완료되지 않은 인덱스로 인해 복원이 여전히 불가능할 수 있습니다.
추천 제품
지원 및 팁
더 읽어보기
Plex가 다른 Docker 컨테이너와 GPU를 공유할 수 있나요?
Plex와 다른 컨테이너가 동일한 GPU에 함께 액세스할 수 있는 경우가 많지만, 드라이버 지원, 디바이스 매핑, 비디오 엔진 부하, 메모리, 복구 동작을 테스트해야 합니다.
Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.
Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.
