중복 제거된 백업 저장소가 중단된 정리 작업 후 읽기 전용으로 작동하는 이유
중단된 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, 스토리지 오류, 변경 불가 객체 또는 완료되지 않은 인덱스로 인해 복원이 여전히 불가능할 수 있습니다.
추천 제품
지원 및 팁
더 읽어보기
라이브 TV 녹화 저장 공간, 보존 기간 및 정리 가이드
실제 녹화 데이터를 측정하고, 헤드룸을 확보하며, 보관 기간과 용량 제한을 함께 적용하고, 저장 공간이 가득 차기 전에 가장 오래된 조건 충족 프로그램이 삭제되는지 확인하세요.
데이터베이스 복원 후 홈 미디어 메타데이터 복구 워크플로우
복원된 상태를 보호하고 미디어 식별 정보와 경로를 확인한 다음, 메타데이터를 광범위하게 변경하기 전에 파일럿 라이브러리에서 누락된 아트워크나 일치 항목을 복구하세요.
오디오, 비디오 및 자막용 Jellyfin 클라이언트 호환성 체크리스트
대표 파일을 한 번에 하나의 변수만 테스트하고, 모든 클라이언트에 대해 Direct Play, 리먹스, 오디오 변환, 비디오 트랜스코딩 또는 실패를 기록하세요.
