마운트 지점을 변경한 후 Restic 또는 Borg에서 저장소가 없거나 위치가 변경되었다고 보고하는 이유는 무엇인가요?

Restic 또는 Borg는 구성된 경로가 이제 빈 디렉터리, 다른 파일 시스템 또는 위치가 변경된 저장소 ID를 가리키면 저장소를 잊어버린 것처럼 보일 수 있습니다.

저장소 데이터는 백업 디스크에 그대로 남아 있을 수 있지만, 디스크가 연결되기 전에 작업이 비어 있는 마운트 디렉터리를 열거나, 변경된 컨테이너 경로를 사용하거나, 오래된 환경 변수를 읽거나, 새 위치에 나타난 ID가 있는 Borg 저장소의 사용을 거부할 수 있습니다. 무엇이 마운트되어 있는지와 저장소 ID를 확인한 후 초기화 작업을 진행하세요. 잘못된 빈 경로에서 init 명령을 실행하면 두 번째 저장소가 생성되어 원래 문제를 파악하기 어려워질 수 있습니다.

구성된 저장소 경로에 무엇이 마운트되어 있는지 확인

예약된 작업에서 사용하는 저장소 경로를 기록한 다음, 백업 디스크가 마운트되기 전과 후의 경로를 비교하세요. 파일 시스템 소스, UUID, 마운트 지점 및 사용 가능한 용량을 확인합니다.

Linux의 findmnt 유틸리티는 대상 경로 뒤의 활성 마운트를 확인하므로, 익숙한 디렉터리가 실제로는 마운트되지 않은 호스트 폴더일 수 있을 때 가장 먼저 확인해야 합니다.

경로가 백업 디스크가 아닌 루트 파일 시스템에 속한다면, 해당 빈 디렉터리에 새 저장소나 백업 세트를 기록하기 전에 백업 서비스를 중지하세요.

Restic 저장소의 정확한 위치 확인

-r, --repository-file 또는 RESTIC_REPOSITORY에 전달된 경로를 현재 마운트 지점과 비교하세요. 래퍼 스크립트, NAS 설정 필드, 자격 증명 파일 및 예약 작업 환경도 확인합니다.

Restic은 로컬 저장소를 config, data, index, keys, locks 및 snapshots가 포함된 특정 디렉터리로 정의하므로, 마운트 지점을 변경하면 명령이 열려고 하는 위치도 변경됩니다.

새 경로에서 저장소가 없다고 보고한다는 이유만으로 restic init을 실행하지 마세요. 먼저 마운트된 디스크에서 원래 저장소의 config 및 data 디렉터리를 찾으세요.

Borg의 위치 변경 저장소 경고를 신중하게 처리

Borg 저장소 URL, 저장소 ID, 이전 위치, 현재 위치, 캐시 경로 및 보안 디렉터리를 기록하세요. 동일한 저장소를 의도적으로 이동한 것인지 확인합니다.

Borg FAQ에서는 저장소가 이동된 후 승인을 요청한다고 설명합니다. 동일한 저장소 ID가 새 경로에 나타나는 것은 안전하지 않은 대체를 의미할 수도 있기 때문입니다.

저장소 ID와 저장 장치의 내용을 비교한 후에만 위치 변경을 승인하세요. 경로가 변경되는 여러 이동식 저장소가 연결될 수 있다면 경고를 전역적으로 억제하지 마세요.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

장치 순서 기반 경로를 영구적인 저장소 ID로 교체

마운트 구성이 /dev/sdX, 중복된 레이블, 파일 시스템 UUID, 파티션 UUID 또는 장치 ID를 참조하는지 확인하세요. 교체해 사용하는 모든 디스크에서 식별자가 중복되지 않는지 비교합니다.

ArchWiki에서는 레이블 및 검색 순서에 따라 변경될 수 있는 커널 할당 장치 이름보다 UUID가 이름 충돌을 줄여 준다고 설명합니다.

안정적인 식별자라도 의도한 고정 마운트 디렉터리에 연결되어야 합니다. UUID는 디스크 순서 변경을 방지하지만, 이전 경로가 여전히 포함된 백업 작업을 자동으로 업데이트하지는 않습니다.

컨테이너 및 바인드 마운트 경로 변환 확인

컨테이너에서 Restic, Borg 또는 백업 UI를 실행하는 경우 호스트 마운트 지점, 바인드 마운트 소스 및 컨테이너 내부의 저장소 경로를 비교하세요. 저장된 compose 파일만 확인하지 말고 실행 중인 컨테이너를 검사합니다.

Docker 문서에서는 바인드 마운트가 정확한 호스트 경로에 의존한다고 설명합니다. 따라서 디스크를 /mnt/backup-a에서 /media/backup-a로 이동하면 컨테이너가 빈 디렉터리를 계속 가리킬 수 있습니다.

호스트에서는 안정적인 하드웨어 경로를 유지하고, 컨테이너에는 하나의 안정적인 경로를 노출하세요. 고정된 매핑을 사용할 수 있다면 호스트에 종속된 이동식 미디어 경로를 저장소 구성에 직접 저장하지 마세요.

백업 서비스가 마운트를 기다리도록 설정

부팅 및 서비스 시작 시간을 비교하세요. 백업 스케줄러, 컨테이너, 저장소 UI 또는 유지 관리 작업이 접근하기 전에 마운트가 완료되었는지 확인합니다.

Red Hat의 영구 마운트 지침에서는 fstab에 고정 마운트를 정의할 것을 권장하며, 이후 서비스 종속성과 시작 전 검증을 연결할 수 있습니다.

이동식 백업 디스크에는 nofail 부팅 옵션이 적절할 수 있지만, 필요한 파일 시스템이 없을 때 백업 서비스가 시작되지 않도록 해야 합니다.

백업을 실행하기 전에 기존 저장소 다시 연결

예약 작업을 중지하고, 의도한 파일 시스템을 고정 경로에 마운트한 다음, 저장소 구조를 확인하세요. 읽기 전용으로 열거나 스냅샷 목록을 확인하고, 쓰기를 활성화하기 전에 작은 규모의 저장소 검사를 수행합니다.

ZimaSpace의 안정적인 UUID 기반 앱 경로 문서에서는 전반적인 마운트 체인을 다룹니다. 이 문서는 경로가 변경된 후 저장소 ID와 백업 도구의 안전성에 초점을 맞춥니다.

반복적인 재부팅 및 디스크 교체 테스트 후에도 동일한 저장소 ID와 스냅샷 기록이 의도한 경로에서 열리고, 비어 있는 마운트 디렉터리에 새 저장소가 생성되지 않는다면 문제가 해결된 것입니다.

자주 묻는 질문

Restic 저장소를 다른 마운트 지점으로 이동할 수 있나요?

예. 전체 저장소를 손상 없이 이동하고 모든 작업이 새 위치를 참조하도록 변경하면 됩니다. Restic은 명령에 전달된 경로 또는 백엔드에서 저장소를 식별합니다.

저장소 데이터가 변경되지 않았는데 Borg가 경고하는 이유는 무엇인가요?

Borg는 보안 조치로 저장소 ID와 이전 위치를 기록합니다. 동일한 ID가 다른 경로에 나타나면 의도적인 승인이 필요합니다.

새 경로에서 저장소를 초기화해야 하나요?

아니요. 기존 저장소가 실제로 존재하지 않는다는 것을 확인하기 전에는 초기화하지 마세요. 빈 마운트 지점을 초기화하면 원래 저장소에 다시 연결되는 것이 아니라 별도의 저장소가 생성됩니다.