마운트 경로를 변경하지 않고 컨테이너 데이터를 SSD 풀로 옮기는 방법

각 컨테이너 내부의 대상 경로는 그대로 유지하면서 호스트 측 데이터 소스를 SSD로 이동합니다.

안전한 마이그레이션에서는 현재 마운트 매핑을 인터페이스 계약으로 간주합니다. 컨테이너, 데이터베이스, 미디어 앱은 어떤 디스크가 제공하는지와 관계없이 /config, /data, /media와 같은 경로를 사용합니다. 이 작업에서는 쓰기를 중지하고, SSD를 예측 가능한 방식으로 마운트하며, 소유권과 메타데이터를 복사하고, 호스트 소스만 변경한 뒤, 시작 전에 새 마운트를 확인해야 합니다. 또한 전체 복원 테스트가 통과할 때까지 원본 데이터를 보존해야 합니다.

현재의 모든 소스와 컨테이너 대상 경로 파악하기

Compose 파일 또는 컨테이너 검사 데이터를 내보내고 모든 바인드 마운트, 이름이 지정된 볼륨, tmpfs 마운트, 데이터베이스 디렉터리, 캐시, 트랜스코딩 경로, 미디어 위치를 목록으로 만드세요. 호스트 소스와 컨테이너 대상 경로를 별도로 기록합니다.

실용적인 볼륨 마이그레이션 가이드는 현재 데이터를 찾고, 복사하기 전에 컨테이너를 중지한 뒤 새 디스크 위치로 데이터를 복사하는 것에서 시작합니다. 이러한 목록화 작업을 통해 구성 데이터가 시스템 디스크에 남는 것을 방지할 수 있습니다.

어떤 경로에 기준 상태 데이터가 있고, 어떤 경로에 다시 생성할 수 있는 캐시와 대용량 미디어가 있는지 표시하세요. data라는 이름의 폴더에 모든 영구 애플리케이션 상태가 들어 있다고 가정하지 마세요.

Docker가 시작되기 전에 SSD 풀을 예측 가능한 방식으로 마운트하기

SSD 파일 시스템 또는 풀을 생성하고, 안정적인 UUID나 풀 이름으로 식별한 다음 최종 호스트 경로에 마운트합니다. 재부팅 후 여유 공간, 예상되는 파일 시스템 기능, 쓰기 권한을 확인하세요.

디스크가 없거나 시작 시 다른 경로에 마운트되면 Docker 데이터를 외부 저장소로 이동하는 작업이 실패할 수 있습니다. 최근 외장 SSD 사례에서는 Docker 저장소를 옮길 때 대상 마운트 경로에 대한 의존성이 어떻게 바뀌는지 보여 줍니다.

Docker가 시스템 디스크에 비어 있는 대체 디렉터리를 생성하지 않도록 서비스 순서 또는 자동 마운트 동작을 구성하세요. SSD가 정확히 예상한 경로에 마운트되지 않았다면 중단합니다.

쓰기 작업을 중지하고 메타데이터를 보존한 채 데이터 복사하기

데이터에 쓸 수 있는 애플리케이션과 모든 종속 서비스를 중지하세요. 여기에는 데이터베이스, 인덱서, 다운로드 프로그램, 백그라운드 작업이 포함됩니다. 데이터베이스의 경우 원시 파일을 복사하기 전에 애플리케이션과 일관된 덤프를 생성하거나 정상적으로 종료하세요.

Synology 컨테이너 관련 논의에서는 Docker가 관리하는 볼륨을 바인드 마운트로 이동하기 전에 볼륨 데이터를 식별하고, 새 바인드 마운트 소스에 콘텐츠를 보존할 것을 권장합니다.

소유권, 권한, 타임스탬프, 링크, ACL, 지원되는 경우 확장 속성까지 보존하면서 재귀적으로 복사하세요. Compose를 변경하기 전에 복사 후 드라이런 비교 또는 샘플 체크섬 검사를 실행합니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

호스트 소스 경로만 변경하기

컨테이너 대상 경로는 동일하게 유지하세요. 예를 들어 /oldpool/app:/config를 /ssdpool/app:/config로 변경하고, 애플리케이션이 새로운 내부 경로를 사용하도록 변경하지 않습니다.

바인드 마운트는 정확한 호스트 위치를 컨테이너 내부의 안정적인 경로에 노출합니다. 한 스토리지 개요에서는 관리자가 호스트 측 경로를 제어해야 할 때 이러한 직접 매핑이 유용하다고 설명합니다.

대상 경로를 유지하면 컨테이너 내부 경로를 저장하는 애플리케이션 데이터베이스, 라이브러리 참조, 스크립트, 권한, 구성 값이 손상되는 것을 방지할 수 있습니다.

소유권, 레이블, 데이터베이스 일관성 복원하기

이미지가 요구하는 숫자형 UID 및 GID 값과 SSD에 설정된 소유권을 비교하세요. 또한 잠금 또는 메모리 매핑 파일에 필요한 ACL, SELinux 레이블, AppArmor 허용 규칙, 마운트 옵션도 복원합니다.

macOS Docker 저장소 마이그레이션 가이드에서는 Docker 데이터를 이동하려면 전체 저장소 이미지를 복사한 다음 런타임이 새 저장소 위치를 사용하는지 확인해야 한다고 설명합니다. Linux NAS 시스템에서는 구성된 모든 소스가 마운트된 SSD로 확인되는지 점검하는 것이 이에 해당합니다.

데이터베이스만 먼저 시작하고 종속 앱을 시작하기 전에 복구 로그를 확인하세요. 손상되었거나 파일이 누락되었다는 보고가 있으면 중단하고 원본 복사본으로 돌아가세요. 애플리케이션이 빈 데이터베이스를 초기화하도록 두지 마세요.

롤백 경로를 확보하고 전체 워크플로를 테스트한 뒤 전환하기

종속성 순서에 따라 스택을 시작하고 구성, 데이터베이스 레코드, 권한, 미디어 라이브러리, 업로드, 다운로드, 업데이트, 컨테이너 재생성을 확인하세요. 새로 작성되는 데이터가 SSD에 저장되고 시스템 디스크의 사용량이 더 이상 증가하지 않는지 점검합니다.

ZimaSpace의 Docker 바인드 마운트가 갑자기 읽기 전용이 되는 문제 문서에서는 마이그레이션된 경로가 마운트되지만 쓰기를 거부할 때 수행할 다음 진단 단계를 다룹니다.

백업과 SSD 경로를 사용한 두 번째 컨테이너 재구성이 성공할 때까지 기존 데이터를 오프라인 상태로 변경하지 말고 보존하세요. 롤백 훈련을 통해 Compose 파일, 마운트, 데이터베이스, 애플리케이션 상태를 복원할 수 있음이 입증된 후에만 기존 소스를 삭제합니다.