<div id="readability-page-1" class="page"><section>
                <p>Dockhand의 백업 기능을 이용해 Docker 볼륨을 Garage(S3 호환 오브젝트 스토리지)에 백업하고, 이를 다시 Cloudflare R2로 백업하는 2단계 백업 구성을 구축했습니다.</p><p>Docker 기반 홈서버를 운영하다 보면 대부분의 서비스는 컨테이너만 다시 배포하면 복구할 수 있습니다. 그러나 메일 서버, 데이터베이스, 자동화 워크플로우처럼 상태(state)를 가지는 서비스는 볼륨 데이터 자체가 서비스의 핵심이며, 컨테이너보다 백업 전략이 더 중요합니다. 기존에는 restic을 직접 스케줄링하는 방식을 고려했지만, Dockhand 1.0.38부터 restic 기반 백업 기능이 베타로 추가되었습니다. 아직 실험적 기능이지만, 컨테이너 관리와 백업 구성을 동일한 인터페이스에서 관리할 수 있다는 점이 매력적이었습니다.</p><p>이 글에서는 Dockhand의 백업 기능을 이용해 Docker 볼륨을 Garage에 1차 백업하고, Garage 스택 자체를 Cloudflare R2로 다시 백업하여 오프사이트 사본을 유지하는 구성을 소개합니다.</p><h2 id="%EC%A0%84%EC%B2%B4-%EA%B5%AC%EC%84%B1">전체 구성</h2><p>이번 구성은 Docker 볼륨을 Garage에 백업하고, Garage 자체를 다시 Cloudflare R2에 백업하는 2단계 구조입니다.</p><pre><code>flowchart LR
    subgraph VM["Proxmox VM (SSD)"]
        V[Docker 볼륨들] --&gt;|"매일 02:00&lt;br/&gt;restic 백업"| G[(Garage&lt;br/&gt;local-s3)]
    end
    G --&gt;|"매일 03:00&lt;br/&gt;restic 백업"| R2[(Cloudflare R2&lt;br/&gt;remote-r2)]
</code></pre><p>1차 백업은 빠른 복구를 위한 로컬 백업 계층이고, 2차 백업은 서버 자체가 손실되는 상황을 대비한 오프사이트 백업 계층입니다.</p><h2 id="dockhand-%EB%B0%B1%EC%97%85-%EA%B8%B0%EB%8A%A5-%ED%99%9C%EC%84%B1%ED%99%94">Dockhand 백업 기능 활성화</h2><p>백업 기능은 Dockhand 1.0.38부터 베타 기능으로 제공되며 기본적으로 비활성화되어 있습니다. <code>FEAT_BACKUPS_ENABLED</code> 환경변수를 활성화해야 Backups 메뉴와 관련 API가 노출됩니다.</p><pre><code>services:
  dockhand:
    image: fnsys/dockhand:latest
    environment:
      - FEAT_BACKUPS_ENABLED=true
</code></pre><p>저는 대부분의 서비스를 GitOps로 관리하고 있지만 Dockhand는 자기 자신을 관리할 수 없기 때문에 이 스택만 별도로 운영하고 있습니다. 따라서 해당 환경변수도 Dockhand의 <code>docker-compose.yml</code>에 직접 추가한 뒤 컨테이너를 재시작했습니다. 재시작이 완료되면 사이드바에 <strong>Backups</strong> 메뉴가 생성됩니다.</p><figure><img src="https://lamanus.kr/content/images/2026/08/image.png" alt="" loading="lazy" width="2000" height="878" sizes="(min-width: 720px) 720px"></figure><p>참고로 이 기능은 무료 에디션에서도 사용할 수 있으며, 정식 출시 이후에도 무료로 유지될 예정이라고 공지되어 있습니다.</p><h2 id="%EB%B0%B1%EC%97%85-%EC%A0%80%EC%9E%A5%EC%86%8C-%EA%B5%AC%EC%84%B1">백업 저장소 구성</h2><p>Dockhand에서는 백업 저장소를 <em>Destination</em>이라고 부르며, 실제로는 restic Repository를 의미합니다. 저장소는 <strong>Settings → Backups</strong>에서 등록할 수 있으며, 이번 구성에서는 두 개의 목적지를 만들었습니다.</p><figure><img src="https://lamanus.kr/content/images/2026/08/image-1.png" alt="" loading="lazy" width="2000" height="905" sizes="(min-width: 720px) 720px"></figure>

<table>
<thead>
<tr>
<th>목적지</th>
<th>백엔드</th>
<th>용도</th>
</tr>
</thead>
<tbody>
<tr>
<td>local-s3</td>
<td>Garage (S3 호환)</td>
<td>1차 백업</td>
</tr>
<tr>
<td>remote-r2</td>
<td>Cloudflare R2</td>
<td>2차 백업</td>
</tr>
</tbody>
</table>

<p>Garage는 자체 구축한 S3 호환 오브젝트 스토리지이며, 백업 전용 버킷과 접근 키를 별도로 생성해 사용했습니다.</p><pre><code>docker exec garage /garage bucket create dockhand-backups
docker exec garage /garage key create dockhand-key
docker exec garage /garage bucket allow --read --write --owner dockhand-backups --key dockhand-key
</code></pre><p>Garage는 기본 리전으로 <code>garage</code>를 사용하기 때문에 일반적인 S3 클라이언트에서는 리전 설정에 따라 서명 오류가 발생하는 경우가 있습니다. 다행히 Dockhand는 별도의 리전 입력 없이 엔드포인트만으로 정상적으로 연결되었습니다. Cloudflare R2는 공식 문서에서 권장하는 것처럼 리전을 <code>auto</code>로 지정하면 됩니다.</p><figure><img src="https://lamanus.kr/content/images/2026/08/image-2.png" alt="" loading="lazy" width="1838" height="1852" sizes="(min-width: 720px) 720px"></figure><p>Destination을 저장할 때 restic Repository 암호도 함께 설정하게 되는데, 이 암호를 분실하면 저장소를 복구할 방법이 없습니다. Dockhand 역시 암호를 복구해 줄 수 없으므로 반드시 비밀번호 관리자 등 별도의 안전한 위치에 보관해야 합니다. 등록이 완료되면 Dockhand가 <code>restic init</code>까지 자동으로 수행하여 Repository를 초기화합니다.</p><h2 id="%EB%B0%B1%EC%97%85-%EB%8C%80%EC%83%81-%EC%84%A4%EA%B3%84">백업 대상 설계</h2><p>Dockhand는 컨테이너 단위와 스택 단위 모두 백업을 지원하며, 각각 전체 볼륨 또는 일부 볼륨만 선택해서 백업할 수 있습니다. 백업 대상을 정의하기 전에 먼저 확인해야 할 것은 <strong>데이터가 볼륨 단위로 적절히 분리되어 있는지</strong>입니다. 설정 파일과 캐시, 메트릭처럼 언제든 다시 생성할 수 있는 데이터가 하나의 볼륨에 섞여 있으면 백업 용량만 불필요하게 증가하고, 반대로 설정과 데이터가 별도 볼륨으로 분리되어 있다면 필요한 데이터만 선택적으로 백업할 수 있습니다.</p><p>다행히 제가 운영하는 대부분의 스택은 초기 구성 단계에서 데이터를 목적별 볼륨으로 분리해 두었기 때문에 필요한 볼륨만 선택하면 됐습니다. 반면 Uptime Kuma는 <code>/app/data</code> 하나에 설정과 모니터링 이력이 모두 저장되는 구조인데, 모니터링 이력은 복구 우선순위가 높지 않다고 판단하여 해당 스택은 백업 대상에서 제외했습니다.</p><p>실제 운영에서는 대부분 스택 단위 백업을 사용했습니다. 스택 백업은 볼륨 데이터뿐 아니라 <code>docker-compose.yml</code>, <code>.env</code>, 스택 디렉터리의 설정 파일까지 함께 스냅샷에 포함하므로, 복원 시 단순히 데이터를 되돌리는 것이 아니라 스택 전체를 다시 배포할 수 있습니다.</p><p>예외는 Dockhand 자신입니다. Dockhand의 데이터베이스에는 백업 Repository 암호를 비롯한 여러 Secret 정보가 저장됩니다. 따라서 Dockhand까지 함께 복구할 수 있어야 전체 백업 체계를 온전히 복원할 수 있으므로, Dockhand는 별도로 볼륨 단위 백업을 구성해 1차 백업에 포함했습니다.</p><h2 id="1%EC%B0%A8-%EB%B0%B1%EC%97%85-docker-%EB%B3%BC%EB%A5%A8-%E2%86%92-garage">1차 백업: Docker 볼륨 → Garage</h2><p>백업 대상을 결정했다면 이제 백업 작업을 생성합니다. 스택 편집 화면의 <strong>Backups</strong> 탭에서 생성하면 대상 스택과 볼륨 목록이 자동으로 채워지므로 가장 편리하며, 백업 작업에서는 Destination, 실행 스케줄(cron), 리텐션 정책을 지정하면 됩니다. 이번 구성에서는 <code>asf</code>, <code>dovecot</code>, <code>ghost</code>, <code>n8n</code>, <code>wg-easy</code> 다섯 개 스택을 매일 02:00에 <code>local-s3</code>로 백업하도록 설정했고, 리텐션은 최근 7개의 스냅샷을 유지하도록 구성했습니다.</p><p>한 가지 흥미로운 점은 Dockhand가 데이터를 직접 전송하지 않는다는 것입니다. 백업이 시작되면 대상 호스트에서 <code>fnsys/dockhand-backup</code> 헬퍼 컨테이너를 생성하고, 백업 대상 볼륨을 읽기 전용으로 마운트한 뒤 해당 컨테이너 내부에서 restic을 실행합니다. 데이터는 헬퍼 컨테이너에서 Destination으로 직접 업로드되며, 수동으로 백업을 실행하면 restic의 진행률과 함께 <code>Done: N new, N changed ... MB added</code> 형태의 결과도 실시간 로그에서 확인할 수 있습니다.</p><p>restic은 증분 백업 방식을 사용하기 때문에 최초 백업 이후에는 변경된 데이터 블록만 추가 저장됩니다. 따라서 매일 백업을 수행하더라도 실제 저장 공간은 변경된 데이터 크기에 비례하여 증가합니다. 또 하나 알아둘 점은 동일한 restic Repository를 사용하는 백업 작업은 동시에 실행되지 않는다는 것인데, restic이 쓰기 작업 중 Repository Lock을 사용하므로 여러 백업이 동시에 시작되더라도 Dockhand가 순차적으로 실행합니다.</p><h2 id="2%EC%B0%A8-%EB%B0%B1%EC%97%85-garage-%E2%86%92-cloudflare-r2">2차 백업: Garage → Cloudflare R2</h2><p>여기까지 구성하면 Docker 볼륨은 Garage에 안전하게 백업됩니다. 그러나 Garage 역시 원본 데이터와 동일한 서버, 동일한 SSD 위에서 동작한다는 문제가 남습니다. SSD 장애나 서버 전체 손실이 발생하면 원본과 1차 백업을 동시에 잃게 되므로, 이를 해결하기 위해 Garage 스택 자체를 Cloudflare R2로 백업했습니다.</p><p>방법은 별도의 도구를 사용하는 대신 Dockhand의 백업 기능을 한 번 더 적용하는 것입니다. Garage 역시 Dockhand가 관리하는 하나의 스택이므로 <code>remote-r2</code> Destination을 대상으로 매일 03:00 백업을 설정했습니다. Garage의 데이터 디렉터리에는 1차 백업용 restic Repository 자체가 저장되어 있으므로, Garage를 백업하면 결과적으로 모든 Docker 볼륨 백업이 Cloudflare R2에도 함께 저장됩니다.</p><p>rclone을 이용해 버킷을 미러링하거나 <code>restic copy</code>를 사용하는 방법도 고려할 수 있습니다. 하지만 별도의 도구를 추가하면 스케줄 관리와 장애 대응 대상도 함께 늘어나는 반면, 이번 구성은 이미 운영 중인 Dockhand 기능만 이용하기 때문에 관리 복잡도가 증가하지 않는다는 장점이 있습니다. 대신 전체 서버를 복구해야 하는 상황에서는 <strong>Cloudflare R2 → Garage → 각 Docker 스택</strong> 순서로 복원해야 하므로 복구 과정이 한 단계 늘어나는데, 재해 복구는 빈도가 매우 낮은 작업이라는 점을 고려하면 충분히 감수 가능한 절충이라고 판단했습니다.</p><h2 id="%EB%B3%B5%EA%B5%AC">복구</h2><p>Dockhand에서는 백업 목록에서 원하는 스냅샷을 선택해 파일을 탐색하거나 개별 파일만 다운로드할 수 있으며, 전체 복원도 지원합니다. 복원 방식은 두 가지입니다.</p><h3 id="to-an-environment"><em>To an environment</em></h3><p>스냅샷을 새로운 볼륨 또는 다른 호스트 경로로 복원한 뒤 저장된 Compose 파일과 설정을 이용해 스택을 다시 배포하는 방식입니다. 원본 환경은 변경하지 않기 때문에 복구 테스트나 서버 이전 작업에 적합하고, 동일한 이름의 볼륨이 이미 존재하면 덮어쓰지 않고 복원을 거부하도록 설계되어 있어 안전하게 사용할 수 있습니다.</p><h3 id="overwrite-live"><em>Overwrite live</em></h3><p>실행 중인 볼륨을 스냅샷으로 직접 교체하는 방식입니다. 파괴적인 작업이므로 확인 절차를 거쳐야 하며, Dockhand가 대상 컨테이너를 중지한 뒤 데이터를 복원하고 다시 시작합니다.</p><p>스택 백업은 Compose 파일과 <code>.env</code>까지 함께 저장되므로 원래 스택이 완전히 삭제된 상태에서도 스택 전체를 다시 복원할 수 있습니다. 백업은 반드시 실제 복구까지 검증하는 것이 좋은데, 운영 중인 서비스를 직접 덮어쓰기보다 테스트용 볼륨으로 <em>To an environment</em> 복원을 한 번 수행해 두면 백업이 실제로 복구 가능한지 미리 확인할 수 있습니다.</p><h2 id="%EB%A7%88%EB%AC%B4%EB%A6%AC">마무리</h2><p>이번 구성의 1차 백업은 엄밀히 말하면 완전한 재해 복구용 백업은 아닙니다. 원본과 동일한 SSD를 사용하기 때문에 물리적인 저장장치 장애가 발생하면 함께 손실될 가능성이 있습니다. 1차 백업의 역할은 빠른 롤백과 운영 실수를 복구하는 것이고, 실제 재해 복구는 Cloudflare R2에 저장된 2차 백업이 담당합니다.</p><p>엄격한 의미의 3-2-1 백업 원칙과 비교하면 서로 다른 저장 매체가 부족하므로 완전한 구성은 아닙니다. 하지만 이번 목표는 완벽한 백업 체계를 만드는 것이 아니라 추가 하드웨어 없이 최소한의 비용으로 서버 전체를 복구할 수 있는 오프사이트 사본을 확보하는 것이었고, 기존에 사용하던 Dockhand의 백업 기능과 Cloudflare R2만으로도 그 목표는 충분히 달성할 수 있었습니다. 향후 별도의 HDD나 NAS를 추가하게 된다면 중간 백업 계층을 추가하여 보다 전형적인 3-2-1 구조로 확장할 계획입니다.</p><p>아직 베타 기능이므로 세부 구현은 변경될 가능성이 있지만, 현재만으로도 restic을 별도로 운영해야 하는 부담을 크게 줄여 주는 기능입니다. Dockhand를 이용해 Docker 환경을 관리하고 있다면, 플래그 하나만 활성화하여 충분히 도입을 검토해 볼 만한 기능이라고 생각합니다.</p>
            </section></div>

Lamanus' Archive

Dockhand의 백업 기능을 이용해 Docker 볼륨을 Garage(S3 호환 오브젝트 스토리지)에 백업하고, 이를 다시 Cloudflare R2로 백업하는 2단계 백업 구성을 구축했습니다.
Docker 기반 홈서버를 운영하다 보면 대부분의 서비스는 컨테이너만 다시 배포하면 복구할 수 있습니다. 그러나 메일 서버, 데이터베이스, 자동화 워크플로우처럼 상태(state)를 가지는 서비스는 볼륨 데이터 자체가 서비스의 핵심이며, 컨테이너보다 백업 전략이 더 중요합니다. 기존에는 restic을 직접 스케줄링하는 방식을 고려했지만, Dockhand 1.0.38부터 restic 기반 백업 기능이 베타로 추가되었습니다. 아직 실험적 기능이지만, 컨테이너 관리와 백업 구성을 동일한 인터페이스에서 관리할 수 있다는 점이 매력적이었습니다.
이 글에서는 Dockhand의 백업 기능을 이용해 Docker 볼륨을 Garage에 1차 백업하고, Garage 스택 자체를 Cloudflare R2로 다시 백업하여 오프사이트 사본을 유지하는 구성을 소개합니다.
전체 구성
이번 구성은 Docker 볼륨을 Garage에 백업하고, Garage 자체를 다시 Cloudflare R2에 백업하는 2단계 구조입니다.
flowchart LR
    subgraph VM["Proxmox VM (SSD)"]
        V[Docker 볼륨들] -->|"매일 02:00<br/>restic 백업"| G[(Garage<br/>local-s3)]
    end
    G -->|"매일 03:00<br/>restic 백업"| R2[(Cloudflare R2<br/>remote-r2)]
1차 백업은 빠른 복구를 위한 로컬 백업 계층이고, 2차 백업은 서버 자체가 손실되는 상황을 대비한 오프사이트 백업 계층입니다.
Dockhand 백업 기능 활성화
백업 기능은 Dockhand 1.0.38부터 베타 기능으로 제공되며 기본적으로 비활성화되어 있습니다. FEAT_BACKUPS_ENABLED 환경변수를 활성화해야 Backups 메뉴와 관련 API가 노출됩니다.
services:
  dockhand:
    image: fnsys/dockhand:latest
    environment:
      - FEAT_BACKUPS_ENABLED=true
저는 대부분의 서비스를 GitOps로 관리하고 있지만 Dockhand는 자기 자신을 관리할 수 없기 때문에 이 스택만 별도로 운영하고 있습니다. 따라서 해당 환경변수도 Dockhand의 docker-compose.yml에 직접 추가한 뒤 컨테이너를 재시작했습니다. 재시작이 완료되면 사이드바에 Backups 메뉴가 생성됩니다.
참고로 이 기능은 무료 에디션에서도 사용할 수 있으며, 정식 출시 이후에도 무료로 유지될 예정이라고 공지되어 있습니다.
백업 저장소 구성
Dockhand에서는 백업 저장소를 Destination이라고 부르며, 실제로는 restic Repository를 의미합니다. 저장소는 Settings → Backups에서 등록할 수 있으며, 이번 구성에서는 두 개의 목적지를 만들었습니다.
목적지
백엔드
용도
local-s3
Garage (S3 호환)
1차 백업
remote-r2
Cloudflare R2
2차 백업
Garage는 자체 구축한 S3 호환 오브젝트 스토리지이며, 백업 전용 버킷과 접근 키를 별도로 생성해 사용했습니다.
docker exec garage /garage bucket create dockhand-backups
docker exec garage /garage key create dockhand-key
docker exec garage /garage bucket allow --read --write --owner dockhand-backups --key dockhand-key
Garage는 기본 리전으로 garage를 사용하기 때문에 일반적인 S3 클라이언트에서는 리전 설정에 따라 서명 오류가 발생하는 경우가 있습니다. 다행히 Dockhand는 별도의 리전 입력 없이 엔드포인트만으로 정상적으로 연결되었습니다. Cloudflare R2는 공식 문서에서 권장하는 것처럼 리전을 auto로 지정하면 됩니다.
Destination을 저장할 때 restic Repository 암호도 함께 설정하게 되는데, 이 암호를 분실하면 저장소를 복구할 방법이 없습니다. Dockhand 역시 암호를 복구해 줄 수 없으므로 반드시 비밀번호 관리자 등 별도의 안전한 위치에 보관해야 합니다. 등록이 완료되면 Dockhand가 restic init까지 자동으로 수행하여 Repository를 초기화합니다.
백업 대상 설계
Dockhand는 컨테이너 단위와 스택 단위 모두 백업을 지원하며, 각각 전체 볼륨 또는 일부 볼륨만 선택해서 백업할 수 있습니다. 백업 대상을 정의하기 전에 먼저 확인해야 할 것은 데이터가 볼륨 단위로 적절히 분리되어 있는지입니다. 설정 파일과 캐시, 메트릭처럼 언제든 다시 생성할 수 있는 데이터가 하나의 볼륨에 섞여 있으면 백업 용량만 불필요하게 증가하고, 반대로 설정과 데이터가 별도 볼륨으로 분리되어 있다면 필요한 데이터만 선택적으로 백업할 수 있습니다.
다행히 제가 운영하는 대부분의 스택은 초기 구성 단계에서 데이터를 목적별 볼륨으로 분리해 두었기 때문에 필요한 볼륨만 선택하면 됐습니다. 반면 Uptime Kuma는 /app/data 하나에 설정과 모니터링 이력이 모두 저장되는 구조인데, 모니터링 이력은 복구 우선순위가 높지 않다고 판단하여 해당 스택은 백업 대상에서 제외했습니다.
실제 운영에서는 대부분 스택 단위 백업을 사용했습니다. 스택 백업은 볼륨 데이터뿐 아니라 docker-compose.yml, .env, 스택 디렉터리의 설정 파일까지 함께 스냅샷에 포함하므로, 복원 시 단순히 데이터를 되돌리는 것이 아니라 스택 전체를 다시 배포할 수 있습니다.
예외는 Dockhand 자신입니다. Dockhand의 데이터베이스에는 백업 Repository 암호를 비롯한 여러 Secret 정보가 저장됩니다. 따라서 Dockhand까지 함께 복구할 수 있어야 전체 백업 체계를 온전히 복원할 수 있으므로, Dockhand는 별도로 볼륨 단위 백업을 구성해 1차 백업에 포함했습니다.
1차 백업: Docker 볼륨 → Garage
백업 대상을 결정했다면 이제 백업 작업을 생성합니다. 스택 편집 화면의 Backups 탭에서 생성하면 대상 스택과 볼륨 목록이 자동으로 채워지므로 가장 편리하며, 백업 작업에서는 Destination, 실행 스케줄(cron), 리텐션 정책을 지정하면 됩니다. 이번 구성에서는 asf, dovecot, ghost, n8n, wg-easy 다섯 개 스택을 매일 02:00에 local-s3로 백업하도록 설정했고, 리텐션은 최근 7개의 스냅샷을 유지하도록 구성했습니다.
한 가지 흥미로운 점은 Dockhand가 데이터를 직접 전송하지 않는다는 것입니다. 백업이 시작되면 대상 호스트에서 fnsys/dockhand-backup 헬퍼 컨테이너를 생성하고, 백업 대상 볼륨을 읽기 전용으로 마운트한 뒤 해당 컨테이너 내부에서 restic을 실행합니다. 데이터는 헬퍼 컨테이너에서 Destination으로 직접 업로드되며, 수동으로 백업을 실행하면 restic의 진행률과 함께 Done: N new, N changed ... MB added 형태의 결과도 실시간 로그에서 확인할 수 있습니다.
restic은 증분 백업 방식을 사용하기 때문에 최초 백업 이후에는 변경된 데이터 블록만 추가 저장됩니다. 따라서 매일 백업을 수행하더라도 실제 저장 공간은 변경된 데이터 크기에 비례하여 증가합니다. 또 하나 알아둘 점은 동일한 restic Repository를 사용하는 백업 작업은 동시에 실행되지 않는다는 것인데, restic이 쓰기 작업 중 Repository Lock을 사용하므로 여러 백업이 동시에 시작되더라도 Dockhand가 순차적으로 실행합니다.
2차 백업: Garage → Cloudflare R2
여기까지 구성하면 Docker 볼륨은 Garage에 안전하게 백업됩니다. 그러나 Garage 역시 원본 데이터와 동일한 서버, 동일한 SSD 위에서 동작한다는 문제가 남습니다. SSD 장애나 서버 전체 손실이 발생하면 원본과 1차 백업을 동시에 잃게 되므로, 이를 해결하기 위해 Garage 스택 자체를 Cloudflare R2로 백업했습니다.
방법은 별도의 도구를 사용하는 대신 Dockhand의 백업 기능을 한 번 더 적용하는 것입니다. Garage 역시 Dockhand가 관리하는 하나의 스택이므로 remote-r2 Destination을 대상으로 매일 03:00 백업을 설정했습니다. Garage의 데이터 디렉터리에는 1차 백업용 restic Repository 자체가 저장되어 있으므로, Garage를 백업하면 결과적으로 모든 Docker 볼륨 백업이 Cloudflare R2에도 함께 저장됩니다.
rclone을 이용해 버킷을 미러링하거나 restic copy를 사용하는 방법도 고려할 수 있습니다. 하지만 별도의 도구를 추가하면 스케줄 관리와 장애 대응 대상도 함께 늘어나는 반면, 이번 구성은 이미 운영 중인 Dockhand 기능만 이용하기 때문에 관리 복잡도가 증가하지 않는다는 장점이 있습니다. 대신 전체 서버를 복구해야 하는 상황에서는 Cloudflare R2 → Garage → 각 Docker 스택 순서로 복원해야 하므로 복구 과정이 한 단계 늘어나는데, 재해 복구는 빈도가 매우 낮은 작업이라는 점을 고려하면 충분히 감수 가능한 절충이라고 판단했습니다.
복구
Dockhand에서는 백업 목록에서 원하는 스냅샷을 선택해 파일을 탐색하거나 개별 파일만 다운로드할 수 있으며, 전체 복원도 지원합니다. 복원 방식은 두 가지입니다.
To an environment
스냅샷을 새로운 볼륨 또는 다른 호스트 경로로 복원한 뒤 저장된 Compose 파일과 설정을 이용해 스택을 다시 배포하는 방식입니다. 원본 환경은 변경하지 않기 때문에 복구 테스트나 서버 이전 작업에 적합하고, 동일한 이름의 볼륨이 이미 존재하면 덮어쓰지 않고 복원을 거부하도록 설계되어 있어 안전하게 사용할 수 있습니다.
Overwrite live
실행 중인 볼륨을 스냅샷으로 직접 교체하는 방식입니다. 파괴적인 작업이므로 확인 절차를 거쳐야 하며, Dockhand가 대상 컨테이너를 중지한 뒤 데이터를 복원하고 다시 시작합니다.
스택 백업은 Compose 파일과 .env까지 함께 저장되므로 원래 스택이 완전히 삭제된 상태에서도 스택 전체를 다시 복원할 수 있습니다. 백업은 반드시 실제 복구까지 검증하는 것이 좋은데, 운영 중인 서비스를 직접 덮어쓰기보다 테스트용 볼륨으로 To an environment 복원을 한 번 수행해 두면 백업이 실제로 복구 가능한지 미리 확인할 수 있습니다.
마무리
이번 구성의 1차 백업은 엄밀히 말하면 완전한 재해 복구용 백업은 아닙니다. 원본과 동일한 SSD를 사용하기 때문에 물리적인 저장장치 장애가 발생하면 함께 손실될 가능성이 있습니다. 1차 백업의 역할은 빠른 롤백과 운영 실수를 복구하는 것이고, 실제 재해 복구는 Cloudflare R2에 저장된 2차 백업이 담당합니다.
엄격한 의미의 3-2-1 백업 원칙과 비교하면 서로 다른 저장 매체가 부족하므로 완전한 구성은 아닙니다. 하지만 이번 목표는 완벽한 백업 체계를 만드는 것이 아니라 추가 하드웨어 없이 최소한의 비용으로 서버 전체를 복구할 수 있는 오프사이트 사본을 확보하는 것이었고, 기존에 사용하던 Dockhand의 백업 기능과 Cloudflare R2만으로도 그 목표는 충분히 달성할 수 있었습니다. 향후 별도의 HDD나 NAS를 추가하게 된다면 중간 백업 계층을 추가하여 보다 전형적인 3-2-1 구조로 확장할 계획입니다.
아직 베타 기능이므로 세부 구현은 변경될 가능성이 있지만, 현재만으로도 restic을 별도로 운영해야 하는 부담을 크게 줄여 주는 기능입니다. Dockhand를 이용해 Docker 환경을 관리하고 있다면, 플래그 하나만 활성화하여 충분히 도입을 검토해 볼 만한 기능이라고 생각합니다.

Dockhand 백업 기능으로 Docker 볼륨 2중 백업 구성하기

댓글