충돌 후 Restic 저장소가 잠겼을 때: 원인, 점검 및 해결 방법

Restic 저장소는 다른 프로세스가 아직 실행 중이거나, 충돌로 인해 오래된 상태가 남았거나, 백엔드의 업데이트가 지연되었거나, 유지 관리 작업이 아직 배타적 잠금을 보유하고 있어 잠긴 상태로 남을 수 있습니다.

여러 호스트로 구성된 홈 서버에서 주의해야 할 점은 마지막으로 확인된 충돌이 유일한 잠금을 만들었다고 단정하는 것입니다. 다른 곳에서 prune 작업이 여전히 실행 중일 수 있고, 컨테이너가 동일한 일정으로 다시 시작되었을 수도 있으며, 오브젝트 스토리지가 최신 상태를 즉시 표시하지 않을 수도 있습니다. 먼저 새 일정 실행을 중지하고 잠금 식별 정보를 확인하세요. 호스트, 프로세스, 시간, 저장소 활동을 모두 검토한 결과 작업이 종료된 것이 확실할 때만 잠금을 제거해야 합니다.

조치를 취하기 전에 잠금 식별 정보 확인하기

저장소에 접근할 수 있는 모든 컴퓨터에서 새 백업, forget, check, prune 일정 실행을 일시 중지하세요. 잠금 목록을 확인하고 호스트, 프로세스 ID, 사용자, 생성 시간, 갱신 시간, 배타적 또는 비배타적 역할을 저장하세요. 그런 다음 나이만 보고 추측하지 말고, 표시된 호스트에서 해당 프로세스와 서비스 로그를 점검하세요.

Restic 프로세스가 중단되면 오래된 잠금이 흔히 남지만, 중단된 파이프라인은 가능한 원인 중 하나일 뿐입니다. 비정상적인 신호를 받은 프로세스가 원격 작업이 여전히 실행 중인 경우와 비슷해 보이는 상태를 남길 수도 있습니다.

PID가 살아 있고 로그가 계속 진행 중이라면 기다리거나 서비스 관리자를 통해 작업을 중지하세요. 작업이 실행 중인 상태에서 잠금을 해제하지 마세요. 프로세스가 없고 호스트가 동일한 작업을 다시 시작하지 않았다면 해당 잠금은 오래된 잠금 후보가 됩니다. 호스트에 연결할 수 없거나 백엔드의 상태가 일치하지 않는다면 상태는 확인되지 않은 것이므로 파괴적인 조치를 취해서는 안 됩니다.

네 가지 잠금 패턴 구분하기

실행 중인 쓰기 작업에는 일치하는 프로세스와 최신 로그 활동이 있으며 잠금이 갱신됩니다. 비정상 종료의 경우 실행 중인 프로세스가 없고 호스트 또는 컨테이너가 중지된 이후 잠금 타임스탬프가 고정됩니다. 클라이언트마다 잠금 목록이나 타임스탬프가 다르게 보이거나, 알려진 저장소 활동보다 타임스탬프가 늦게 반영된다면 백엔드 지연일 수 있습니다. 완료되지 않은 유지 관리 작업은 배타적 잠금이 유지되고 check 또는 prune 로그가 계속 변경되는 형태로 나타납니다.

포괄적인 Restic 문제 해결 순서에서는 저장소 잠금, prune 실패, 손상 가능성을 별도의 분기로 다룹니다. 따라서 오래된 잠금에 대한 해결 방법을 스토리지 문제에 잘못 적용하지 않게 됩니다.

한 번에 하나의 패턴만 테스트하세요. 먼저 실행 여부를 확인한 다음 타임스탬프와 로그를 비교하고, 백엔드 연결 가능성과 시계를 확인한 뒤, 마지막으로 유지 관리 작업을 점검하세요. 두 가지 패턴이 여전히 가능하다면 잠금을 유지하고 더 안전한 분기를 조사하세요. 잠금 해제는 이해하려는 보호 기능 자체를 변경하므로 진단 테스트로 사용할 수 없습니다.

오래된 것으로 입증된 잠금만 제거하기

잠금을 해제하기 전에 모든 클라이언트, 자동화 컨트롤러, 컨테이너 호스트, 저장소 측 서비스를 다시 한 번 확인하세요. 현재 잠금 목록과 최근 로그를 저장하세요. remove-all 또는 no-lock 옵션이 아니라 일반적인 오래된 잠금 제거 명령을 사용하세요. 표준 경로는 활성 잠금을 그대로 유지하도록 설계되어 있기 때문입니다.

실제 환경의 오래된 잠금 오류는 정상적으로 구축된 백업 일정도 중단시킬 수 있지만, 특정 사례의 경과 시간만으로 모든 상황에 적용되는 안전한 삭제 기준을 정할 수는 없습니다.

표준 명령으로 오래된 기록이 제거되고 잠금이 즉시 다시 생성되지 않는다면 읽기 전용 저장소 목록 조회를 진행하세요. 잠금이 활성 상태라는 이유로 명령이 거부되면 중지하고 소유자를 찾으세요. 잠금이 즉시 새로 나타난다면 스케줄러나 다시 시작된 컨테이너가 여전히 실행 중인 것입니다. 다른 복구를 시도하기 전에 해당 원인을 비활성화하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

원래 작업을 다시 테스트하고 재발 여부 확인하기

실패했던 것과 동일한 작업을 실행하면서 진행 상황과 종료 상태를 기록하세요. 작업이 활성 상태일 때 잠금이 생성되고 갱신되는지, 정상적으로 종료된 후 사라지는지 확인하세요. 그런 다음 정상적인 일정 주기 하나를 실행하게 두세요. 이렇게 해야 원래의 트리거를 재현할 수 있으며, 저장소 목록 조회가 성공한 것보다 더 확실하게 검증할 수 있습니다.

잠금이 해제된 후 저장소가 읽기 전용이 되거나 유지 관리 작업이 실패한다면 잠금을 반복해서 해제하지 말고 별도의 중단된 prune 복구 절차를 따르세요.

두 번의 원래 작업 주기가 완료되고, 각 잠금이 작업 중에 갱신되며 종료 시 제거되고, 저장소 검사 또는 샘플 복원이 정상적으로 수행되면 복구가 완료된 것입니다. 정상 종료 후에도 잠금이 반복되거나, 클라이언트마다 백엔드 상태가 다르게 표시되거나, 검사에서 저장소 객체의 누락 또는 손상이 보고되면 문제를 상위 단계로 이관하세요. 조사하는 동안에는 잠금 기능을 계속 활성화해 두세요.