전체 앱 스택을 교체하지 않고 컨테이너 하나만 복원할 수 있나요?

구성, 영구 데이터, 종속성 경계를 스택의 나머지 부분과 명확히 분리할 수 있다면 컨테이너 하나만 독립적으로 복원할 수 있습니다.

홈 NAS에서는 눈에 보이는 컨테이너가 대개 일회용이지만, 앱 상태는 바인드 마운트, 이름이 지정된 볼륨, 별도 데이터베이스, 시크릿, 프록시 라우트, 공유 네트워크에 걸쳐 있을 수 있습니다. 따라서 안전한 단일 서비스 복원은 컨테이너 ID 하나를 원래 위치에 복사하는 것이 아닙니다. 영향을 받은 서비스를 중지하고, 해당 서비스가 소유한 상태만 복원한 뒤, 알려진 정의에서 서비스를 다시 생성하고, 공유 종속성과 정상적으로 작동하는 인접 컨테이너가 변경되지 않았음을 확인하는 과정입니다.

무엇이 복원 단위인지 먼저 정의하세요

장애가 발생한 정확한 서비스를 식별하고, 해당 서비스가 소유한 모든 객체를 나열하세요. 여기에는 Compose 서비스 이름, 이미지 태그 또는 다이제스트, 환경 파일, 시크릿, 바인드 마운트, 이름이 지정된 볼륨, 공개 포트, 네트워크 별칭, 예약 작업, 역방향 프록시 레이블이 포함됩니다.

Docker 볼륨 복원 가이드는 컨테이너 런타임과 영구 스토리지를 분리합니다. 데이터 볼륨은 독립적으로 백업하고 복원할 수 있기 때문입니다. 실용적인 안내에서는 실행 중인 컨테이너만을 유일한 복구 대상으로 취급하지 않고, 컨테이너와 볼륨을 별도로 복원하는 방법을 보여 줍니다.

앱이 공유 데이터베이스나 볼륨에 기록한다면 복원 단위에는 해당 공유 종속성도 포함되므로 안전하게 격리하지 못할 수 있습니다. 소유권이 명확해질 때까지 어떤 것도 덮어쓰지 말고 중지하세요.

정상 스택과 장애 서비스의 상태를 캡처하세요

현재 Compose 파일, 확인된 환경 변수, 이미지 다이제스트, 마운트 목록, 네트워크 소속, 상태 점검 결과, 최근 로그를 내보내거나 저장하세요. 복원 시 영향 범위를 명확히 판단할 수 있도록 인접 서비스 중 정상적으로 작동하는 서비스도 기록하세요.

서비스 수준의 Compose 작업을 사용하면 전체를 재시작하지 않고 이름이 지정된 서비스 하나만 대상으로 지정할 수 있습니다. Linux Handbook의 단일 서비스 워크플로는 하나의 Compose 서비스와 스택 전체 작업을 구분하지만, 구성 변경에는 단순한 재시작이 아니라 다시 생성하는 작업이 필요하다는 점도 설명합니다.

장애가 발생한 서비스에 대해서만 자동 업데이트와 재시작 루프를 비활성화하세요. 일관성 유지를 위해 함께 중지해야 하는 경우가 아니라면 데이터베이스와 공유 인프라는 계속 실행 상태로 두세요.

먼저 격리된 위치에 데이터를 복원하세요

선택한 백업을 라이브 경로에 직접 덮어쓰지 말고 임시 디렉터리나 새 볼륨에 복원하세요. 파일 수, 소유권, 타임스탬프, 데이터베이스 덤프 메타데이터, 애플리케이션 버전을 손상된 상태와 비교하세요.

볼륨 백업 프로젝트에서는 임시 일회성 컨테이너를 사용해 대상 볼륨을 마운트하고 다시 채우는 방법을 설명합니다. 이를 통해 프로덕션 서비스가 해당 볼륨에 기록하기 전에 격리된 볼륨 복원 경로를 만들 수 있습니다.

데이터베이스는 가능한 경우 애플리케이션 인식형 덤프 또는 복원 방법을 사용하세요. 실행 중인 데이터베이스의 파일 시스템 복사본은 기껏해야 충돌 일관성만 보장할 수 있으며, 이전 컨테이너가 사라진 뒤 오류가 발생할 수 있습니다.

마운트를 전환하기 전에 격리된 복사본을 확인하세요. 백업을 읽을 수 없거나 스키마가 사용하려는 이미지와 일치하지 않는다면 현재 상태를 보존하고 다른 복구 지점을 선택하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

원래 식별 정보를 유지한 채 장애 서비스만 다시 생성하세요

저장해 둔 Compose 정의에서 이름이 지정된 서비스만 다시 생성하세요. 이때 동일한 프로젝트 이름, 외부 네트워크, 서비스 별칭, 포트, 시크릿, UID/GID 매핑, 확인된 영구 경로를 유지해야 합니다.

데이터를 올바르게 복원한 뒤에도 소유권이나 보안 레이블이 런타임 사용자와 일치하지 않으면 마운트 접근이 실패할 수 있습니다. Rocky Linux 컨테이너 사례에서는 데이터를 다시 복사하는 대신 소유권과 보안 컨텍스트를 확인해 누락된 볼륨 접근 문제를 해결했습니다.

볼륨을 삭제하거나 스택 전체에 영향을 주는 정리 명령을 실행하지 말고 서비스를 시작하세요. 마이그레이션, 스캔 또는 백그라운드 작업이 복원된 데이터를 수정하도록 허용하기 전에 실제 적용된 마운트를 확인하세요.

종속성은 복원하지 말고 다시 연결하세요

복원된 컨테이너에서 데이터베이스, 캐시, ID 공급자, 오브젝트 스토리지, 프록시 네트워크로의 DNS 확인과 TCP 접근을 테스트하세요. 복구된 구성에 정의된 동일한 서비스 이름과 자격 증명을 사용하세요.

공유 종속성이 정상 상태로 유지되었다면 애플리케이션이 연결되지 않는다는 이유만으로 해당 종속성을 복원하거나 교체하지 마세요. 누락된 네트워크 별칭, 변경된 시크릿, 스키마 불일치 또는 잘못된 데이터베이스 이름 때문에 정상적인 종속성이 사용할 수 없는 것처럼 보일 수 있습니다.

복원된 앱 버전과 데이터베이스 백업에 마이그레이션이 필요한 경우에만 마이그레이션을 실행하세요. 되돌릴 수 없는 마이그레이션을 시작하기 전에 종속성을 백업하고, 앱이 빈 데이터베이스를 초기화하려고 하면 중지하세요.

트래픽을 다시 전달하기 전에 단일 서비스 경계를 확인하세요

로그인, 읽기, 쓰기, 업로드, 예약 작업, API 호출, 프록시 접근, 통제된 재시작 한 번을 테스트하세요. 복원 전 캡처 내용과 인접 컨테이너의 재시작 횟수, 로그, 포트, 데이터 체크섬을 비교하세요.

ZimaSpace의 영구 컨테이너 상태 매핑 가이드도 동일한 복구 원칙을 제시합니다. 가정한 컨테이너 셸이 아니라 상태의 소유자를 복원해야 한다는 것입니다.

복구된 서비스가 의도한 데이터와 종속성을 사용하고, 정상적인 스택 구성원이 영향을 받지 않았으며, 다시 생성해도 동일한 결과가 나올 때 복원이 완료됩니다. 공유 상태를 격리할 수 없다면 부분 롤백을 강행하지 말고 스택 전체를 조정하는 복원으로 전환하세요.