부팅 드라이브 교체를 위한 복구 가능한 개발자 홈랩 설정

복구 가능한 개발자 홈랩은 부트 드라이브를 Git 서비스, 레지스트리, 데이터베이스, 러너, 프리뷰 앱의 작동 방식을 기록한 유일한 매체가 아니라 교체 가능한 매체로 취급합니다.

실질적인 목표는 설치 미디어, 버전 관리되는 정의 파일, 보호된 시크릿, 외부에 백업된 애플리케이션 상태, 간결한 복구 런북만으로도 정상 작동하는 호스트가 될 수 있는 빈 디스크입니다.

교체 가능한 호스트와 영구 상태를 분리하세요

운영 체제, 패키지 캐시, 컨테이너 이미지, 일회성 빌드 결과물은 부트 드라이브에 보관하세요. 데이터베이스 파일, 레지스트리 객체, Git 저장소, 업로드 파일, 대체할 수 없는 구성은 명시적인 앱 데이터 또는 스토리지 마운트에 두세요.

`/srv/appdata`, `/srv/projects`, `/srv/registry`와 같은 안정적인 경로를 UUID 또는 다른 영구 식별자로 마운트하세요. 필수 마운트가 없을 때 서비스가 이를 명확히 표시하며 실패하도록 구성하여, 교체용 부트 디스크의 빈 디렉터리에 절대 기록하지 않도록 하세요.

모든 상태 저장 구성 요소와 그 일관성 유지 방법을 목록으로 작성하세요. 데이터베이스 네이티브 덤프, 저장소 백업, 객체 스토어 복사본은 모두 하나의 애플리케이션에 속하더라도 서로 다른 일정이 필요할 수 있습니다.

실수를 그대로 복제하지 않고 호스트를 재현 가능하게 만드세요

Compose 파일, 인프라 코드, 패키지 목록, 방화벽 규칙, DNS 레코드, systemd 유닛, 시크릿이 아닌 구성을 버전 관리에 저장하세요. 재구축 시 모든 서비스가 한 번에 조용히 변경되지 않도록 버전을 신중하게 고정하세요.

시크릿은 암호화하여 별도로 백업하세요. 서비스 자격 증명, 레지스트리 토큰, 연속성이 중요한 경우의 SSH 호스트 키, 인증서 자료, 복구 코드, 스토리지 암호화 키가 여기에 포함됩니다. 각 시크릿을 복원하거나 교체하는 방법을 문서화하세요.

아래 복구 맵을 최소 재구축 목록으로 사용하세요.

안전한 종속성에 따라 교체 순서를 구성하세요

기본 OS를 설치하고 패치한 다음, 네트워킹과 원격 관리를 복원하고, 보호된 스토리지를 마운트하고, 시크릿을 복원한 뒤, 종속 애플리케이션보다 먼저 기반 서비스를 시작하세요. 프리뷰 앱과 러너가 작업을 시작하기 전에 데이터베이스와 인증 서비스가 정상 상태여야 합니다.

호스팅된 Git 원격 저장소, 내보낸 레지스트리 이미지, 두 번째 러너 등 중요한 개발 작업을 위한 임시 대체 수단을 유지하세요. 복구 절차가 장애가 발생한 호스트에서 필요한 지침을 가져와야만 작동해서는 안 됩니다.

관련 ZimaSpace 홈랩 스토리지 토폴로지는 부트, 앱 데이터, 대용량 스토리지 역할을 분리합니다.

독립적인 컨테이너 복구 개요에서도 이미지, 구성, 영구 데이터에는 서로 구분된 보호가 필요하다는 점을 강조합니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

빈 대상에서 복구를 검증하세요

기존 루트 파일 시스템을 통째로 복사하지 말고 여분의 SSD, 임시 VM, 격리된 머신에 스택을 복원하세요. SSH 접속, 첫 번째 정상 서비스, 전체 데이터셋 복원, 정상적인 개발자 워크플로에 걸리는 시간을 기록하세요.

저장소 무결성, 데이터베이스 일관성, 레지스트리 풀, TLS 이름, 러너 등록, 파일 소유권, 백업 일정, 재부팅 순서를 검증하세요. 샘플 아티팩트 또는 프로젝트를 원본과 비교하세요.

새 부트 드라이브가 기존 디스크의 숨겨진 파일 없이 문서화된 서비스 상태에 도달할 수 있을 때만 설정이 통과됩니다. 주요 플랫폼, 네트워크, 스토리지 변경 후에는 테스트를 반복하세요.