콘텐츠로 이동

오프사이트 및 복구

재구축 이후 오프사이트 사본은 기다립니다

4단계가 이전 설정 없이 항목을 재구축하면, 배치 기본값이 확인될 때까지 그 도메인들의 오프사이트 복제가 일시 정지됩니다. 항목별 배치를 참고하세요.

로컬 백업은 잃어버린 컨테이너나 잘못된 업데이트로부터 보호합니다. 오프사이트 복제와 테스트된 복구 키트는 장비 전체, 랜섬웨어, 화재로부터 보호합니다. 이 페이지는 오프사이트로 복제하기, 그 사본을 변조 방지로 만들기, 복원할 수 있음을 입증하기, 그리고 BombVault 자체가 사라졌을 때 복구하기를 다룹니다.

오프사이트 복제

빠른 로컬 백업을 유지하면서 하나 이상의 오프사이트 복제본을 추가하세요. 설정, 오프사이트 페이지에서 도메인별로 저장소를 설정하세요. BombVault는 새 스냅샷을 restic copy로 최선 노력 방식으로 그곳에 복제하므로, 오프사이트 장애가 로컬 백업을 실패시키는 일은 없습니다. 이 형태에서는 로컬 저장소가 주 저장소이고 오프사이트 저장소는 복제본이지만, 도메인의 주 저장소가 꼭 로컬일 필요는 전혀 없습니다. 오프사이트로 복제하는 대신 S3/rest-server 등으로 바로 백업하는 방법은 아래 원격 기본 저장소를 참고하세요.

  • 도메인별 여러 오프사이트 대상. 각 도메인(컨테이너, VM, 플래시, 구성, 파일 세트, ZFS 데이터세트)은 하나만이 아니라 여러 오프사이트 대상에 동시에 복제할 수 있으므로, 예를 들어 친구의 장비에 있는 rest-server와 S3 버킷을 병렬로 유지할 수 있습니다. 설정, 오프사이트에서 추가 대상을 더하세요. 각각 자체 저장소, S3 스토리지 클래스, append-only 플래그, 보존, 증가 예산을 가집니다. 기존의 단일 오프사이트 설정은 첫 번째 대상으로 손대지 않고 이어지며, 도메인의 모든 대상은 그 도메인의 오프사이트 일정에 따라 복제됩니다.
  • 도메인별 오프사이트 일정(설정, 일정에서 다른 모든 일정과 함께 편집): 매 로컬 백업 후 복제하려면 비워 두고, 로컬 백업보다 오프사이트로 덜 자주 보내려면 주기를 설정하세요(예: weekly Sun 03:00). 지금 복제 버튼이 온디맨드 실행을 담당합니다.
  • 오프사이트 보존은 설정, 보존에 있으므로 오프사이트 사본을 아카이브로 더 오래 보관할 수 있습니다. 오프사이트 스냅샷을 자동으로 정리하지 않으려면 정책을 모두 0으로 두세요.
  • 대역폭 제한(설정, 오프사이트)은 restic 업로드/다운로드 속도를 제한하여 복제가 WAN을 포화시키지 않도록 합니다.
  • 복제 표시기는 실행 중일 때 어떤 도메인이 복제 중인지 보여줍니다(해당 페이지와 대시보드에서). restic copy가 기계가 읽을 수 있는 진행 상황을 노출하지 않으므로, 백분율 막대가 아니라 활성 표시기입니다.

어디서든 복원

모든 컨테이너, VM, 파일 세트, 플래시, 앱 구성은 백업이 있는 모든 위치를 아우르는 하나의 타임라인으로 백업을 나열합니다. B2로 복사된 백업은 한 번만 나타나며, 그것을 보유한 각 위치가 표시됩니다. 복원은 항목이 기록되는 저장소를 시작점으로, 도달할 수 있는 첫 번째 위치를 사용하며, 행마다 다른 위치를 고를 수도 있습니다. 오프사이트 위치는 열었을 때만 읽힙니다. 한 위치에서 삭제하면 먼저 다른 위치를 확인하고 마지막 사본이었는지 알려줍니다.

대상

설정, 오프사이트는 대상으로 시작합니다. 오프사이트 사본이 가는 곳이며, 모든 도메인을 위해 한 번만 설정합니다. 대상은 이후 모든 도메인과 항목의 배치 행에 버튼으로 나타납니다. 도메인에서 처음 켜는 순간, BombVault는 그 대상 아래의 폴더에 그 도메인의 저장소를 만듭니다. 예를 들면 rclone:onedrive:BombVault/containers입니다. 플래시, 셀프 백업, ZFS 데이터세트에는 배치 행이 없으므로, 오프사이트 섹션에는 대신 대상 이름 뒤에 에서 추가가 붙은 버튼이 나옵니다.

대상 추가는 다섯 단계의 마법사를 엽니다.

  1. 백업을 어디에 보낼까요? 모든 서비스가 로고와 함께 네 그룹으로 나열됩니다. S3 버킷을 제공하는 스토리지 서비스(Backblaze B2, Wasabi, Cloudflare R2, Hetzner Object Storage, Amazon S3 등), 직접 운영하는 S3 서버(Garage, SeaweedFS, RustFS, Silo, Ceph, JuiceFS, Versity S3 Gateway), 직접 운영하는 서버와 공유(rest-server, Hetzner Storage Box, SFTP, SMB, WebDAV, 마운트된 경로), 클라우드 스토리지(OneDrive, Google Drive, Dropbox, pCloud, Nextcloud 및 rclone이 지원하는 나머지)입니다. 각 항목에는 백업에 얼마나 적합한지가 적혀 있습니다. 클라우드 드라이브는 요청이 많아지면 느려지므로, 첫 백업과 정리에 시간이 더 걸립니다.
  2. 로그인. 입력란은 서비스에 따라 다릅니다. S3는 액세스 키, WebDAV와 SMB는 사용자와 비밀번호, 2단계 인증이 일반 비밀번호를 막는 곳에서는 앱 비밀번호, SFTP와 Storage Box는 BombVault의 공개 SSH 키, 브라우저로 로그인하는 서비스는 토큰입니다. 후자의 경우 마법사가 브라우저가 있는 컴퓨터에서 실행할 rclone authorize 명령을 보여 주며, 그 명령이 출력하는 토큰을 입력란에 넣으면 됩니다. 연결 테스트는 무엇이든 저장하기 전에 로그인을 확인합니다.
  3. 폴더 선택. 마법사가 대상의 폴더를 나열합니다. 새 폴더로 폴더를 만들 수 있고, 서비스가 알려 주는 경우 남은 공간도 표시됩니다. 비어 있는 폴더가 가장 안전합니다.
  4. 삭제 방지. 마법사가 서비스가 할 수 있는 일을 솔직하게 알려 줍니다. append-only 모드의 rest-server는 삭제를 거부하며, 변조 테스트가 이를 확인합니다. S3 버킷은 버전 관리와 객체 잠금으로 이전 버전을 보관할 수 있지만, BombVault는 아직 이를 확인할 수 없습니다. 클라우드 드라이브는 삭제를 아예 거부할 수 없습니다. 서버에 침입한 사람은 그 사본에도 접근할 수 있습니다. 불변 (append-only)은 상대편이 실제로 삭제를 거부하는 경우에만 켜세요. 그러면 BombVault는 그곳에서 절대 정리하지 않습니다.
  5. 비상 상황에 대비. 복구 키트는 모든 대상을 나열하고, 그 아래에 각 도메인의 저장소를 적습니다. 로그인 정보는 BombVault의 설정 백업과 함께 돌아옵니다. 설정 백업이 없는 새 설치에서는 같은 위치에 대상을 다시 설정하세요.

S3 서비스는 restic 자체의 S3 백엔드를 거치므로 스토리지 클래스와 객체 잠금을 적용할 수 있습니다. 그 밖의 모든 서비스는 BombVault에 포함된 rclone을 거치며, 그 리모트는 설정, 클라우드 액세스의 rclone 구성에 나타납니다. 설정 내보내기에는 대상이 들어 있고, 자격 증명을 포함하면 로그인 정보도 들어 있습니다.

그룹의 다른 인스턴스가 운영하는 수신 서버는 마법사의 내 그룹에서 아래에 나타납니다. 수신 서버를 참고하세요.

대상에서 만든 도메인의 대상은 그 대상의 이름, 위치, 자격 증명, 스토리지 클래스, 불변 스위치를 가져옵니다. 보존, 압축, 증가 예산은 도메인별로 남으며, 도메인의 저장소가 그곳에 있으므로 위치는 옮길 수 없습니다. 각 도메인 아래의 이 도메인에만 대상 추가는 여전히 직접 입력한 저장소 URL을 받습니다.

직접 입력한 대상의 저장소가 어떤 대상의 폴더 안에 있으면 그 대상에 합류할 수 있습니다. 대상은 이런 대상을 이미 이 대상 아래에 있습니다 아래에 나열하고, 인수로 그중 하나를 그 아래에 붙입니다. 직접 입력한 대상은 저장소, 스냅샷, 보존, 배치를 그대로 유지하고, 대상의 이름, 자격 증명, 스토리지 클래스, 불변 스위치를 가져옵니다. BombVault는 먼저 대상의 로그인으로 저장소가 열리는지 확인하며, append-only가 아닌 대상 아래에 append-only 대상을 두는 것은 거부합니다. 도메인의 기본 대상을 인수하면 그 도메인의 오프사이트 필드가 비워집니다.

항목별 배치

각 컨테이너, VM, 파일 세트 카드에는 버튼으로 이루어진 배치 행이 있습니다. 로컬, 도메인의 오프사이트 대상마다 하나씩, 그리고 그 도메인에 아직 대상이 없는 대상 버튼이 이어집니다. 켜진 버튼이 항목의 백업을 받습니다.

  • 로컬이 켜져 있으면 항목은 저장 위치 아래에 표시된 저장소에 기록되고, 켜져 있는 다른 모든 대상으로 복사됩니다. 대상을 끄면 그 대상은 이 항목에서 새로 받는 것이 없어집니다. 로컬만 켜면 어디에도 복사하지 않으며, 이미 두 번째 사본이 있는 데이터, 예를 들어 NAS에 있는 공유에 알맞습니다.
  • 로컬이 꺼져 있으면 항목은 켜진 첫 번째 대상의 직접 저장소에 바로 기록되고, 거기서 켜져 있는 다른 대상으로 복사됩니다. 처음에는 창이 열려 그 직접 저장소를 만듭니다.
  • 대상 버튼은 그 대상 아래에 도메인의 대상을 만들고, 이 항목에만 켭니다. 다른 모든 항목은 그곳에 사본이 없는 상태로 시작합니다.
  • 버튼 하나는 항상 켜져 있습니다. 백업에는 갈 곳이 필요하기 때문입니다. 무언가를 백업에서 빼려면 제외하세요.

위치는 항목의 첫 백업부터 고정됩니다. BombVault는 백업을 저장소 사이에서 절대 옮기지 않기 때문입니다. 사본은 언제든 바뀔 수 있습니다. 더 이상 항목을 받지 않는 대상은 가지고 있는 사본을 그대로 유지하며, 도메인의 다음 오프사이트 실행 때 자체 보존 정책에 맞게 정리합니다. 카드의 B2에서 삭제는 즉시 제거합니다. 그 사본 일부가 다른 어디에도 없다면, 확인 창은 날짜별로 목록을 보여주고 항목 이름 입력을 요구합니다. append-only 대상에서는 삭제할 수 없습니다.

행 아래에서 카드는 항목이 어디로 가는지, 실제로 무엇이 있는지를 알려줍니다: 몇 개의 사이트가 보유하는지, 각 대상이 마지막으로 확인된 시점, 그리고 3-2-1이 충족되는지입니다. 사이트란 원본 데이터가 있는 서버, 각 오프사이트 대상, 그리고 부지 밖으로 표시된 각 저장소입니다. BombVault는 사본과 사이트를 확인하며, 3-2-1의 «두 가지 매체» 부분은 확인하지 않습니다.

배치 기본값

설정, 저장 공간, 배치 기본값에는 도메인마다 같은 버튼을 가진 행이 하나씩 있습니다. 사본은 자체 선택이 없는 모든 항목과 Compose 스택의 프로젝트 폴더에 즉시 적용됩니다. 위치는 새 항목의 첫 백업 시 적용되며, 바꿔도 기존 백업은 옮겨지지 않습니다. 저장하기 전에 이 행은 항목을 얻거나 잃는 모든 대상과 그것이 의미하는 스냅샷 수를 알려줍니다. 백업이 없는 항목에 적용은 아직 백업이 없는 모든 항목을 기본값으로 되돌립니다.

새 오프사이트 대상은 로컬로 설정되지 않은 모든 항목을 받습니다. 추가할 때 열리는 창은 몇 개의 항목인지, 그리고 알 수 있는 경우 그것이 얼마만큼의 이력인지 보여주며, 다른 대상에서 이미 제외된 항목을 제외할 수 있는 선택지를 제공합니다.

직접 저장소

항목의 로컬을 꺼서 직접 저장소가 없는 대상이 그 항목의 보관처가 되면, 대상 옆에 제안된 위치(예: s3:https://s3.eu-central-003.backblazeb2.com/bucket/containers-direct)와 아무것도 만들지 않는 연결 테스트가 담긴 창이 열립니다. 만들고 사용은 저장소를 만들고 항목을 그곳으로 향하게 합니다. 직접 저장소는 대상의 키, 스토리지 클래스, 제한, append-only 설정, 보존을 그대로 쓰며 함께 바뀝니다. 저장소 카드는 이를 읽기 전용으로 보여줍니다. 대상의 새 키로 열 수 없으면 직접 저장소는 가지고 있던 키를 유지하고, 저장할 때 그렇게 안내합니다. 직접 저장소에 있는 항목은 그곳에서 켜져 있는 다른 대상으로 복사되며, 그 저장소가 속한 대상으로는 복사되지 않습니다. 이 저장소의 스냅샷에는 bv:direct 태그가 붙고, 다른 모든 보존 처리는 이를 그대로 남기므로, 대상과의 연결이 끊긴 직접 저장소는 로컬 규칙으로는 절대 오래되지 않습니다. B2는 S3 엔드포인트를 통해 접근하며, 키 ID와 애플리케이션 키를 S3 자격 증명으로 입력합니다. 대상 자신의 폴더로 제한된 키는 그 옆 폴더에는 닿지 못하므로, 대신 키를 대상보다 한 단계 위 폴더로 제한하세요.

부지 밖

이름이 있는 저장소는 저장소 카드에서 부지 밖으로 표시할 수 있습니다. 원격 저장소는 처음부터 표시된 채로 시작합니다. 같은 건물에 있는 rest-server라면 꺼 두세요. 이 표시는 카드의 사이트 수와 3-2-1 계산에만 영향을 줍니다. 사본은 전혀 바뀌지 않습니다.

재구축 이후

사본 선택은 BombVault 자체 설정 안에 있습니다. 복원된 /config 없이 백업 검색을 통해 재구축하면 그 선택은 사라지고, 모든 것을 복사하면 제외해 두었던 항목을 B2로 다시 보내게 됩니다. 그래서 재구축된 모든 도메인의 오프사이트 복제는 일시 정지됩니다. 대시보드는 이를 호박색으로 보여주며, 배치 기본값은 다음 실행이 무엇을 복사할지 미리 보기와 항목이 없는 백업 속 이름을 보여주는 기본값 확인을 제공하고, 거기서 제외할 수 있습니다. 오직 확인만이 이 정지를 끝냅니다. 설정 파일을 가져오면 규칙과 기본값은 돌아오지만 정지는 끝나지 않습니다.

원격 기본 저장소

도메인의 백업 경로(설정, 저장 공간)는 로컬 폴더로 한정되지 않습니다. restic 원격(s3:..., rest:http://host:8000/repo, sftp:user@host:/repo, rclone:remote:bucket/path)을 곧장 지정하면 BombVault는 별도의 로컬 사본도 복제 단계도 없이 거기로 바로 백업합니다. 이는 위의 원격지 복제와는 정말로 다른 모양입니다. 그쪽에서는 로컬 저장소가 주이고 원격지 저장소는 최선을 다한 사본입니다. 여기서는 원격 저장소 자체가 주이며, 그 도메인에 원격지 복제(또는 두 번째 원격)를 따로 설정하지 않는 한 유일한 사본입니다.

여섯 개의 경로 칸(컨테이너, VM, 플래시, 셀프 백업, 폴더, ZFS 데이터세트)에는 바로 옆에 로컬 / 원격 전환이 붙어 있습니다.

  • 로컬은 익숙한 폴더 탐색기를 보여 줍니다.
  • 원격은 그것을 단순한 URL 칸으로 바꾸고, 원격지 대상이 쓰는 것과 같은 연결 테스트 및 자격 증명 대화 상자를 이 기본 저장소용으로 구성해 여는 버튼을 함께 둡니다. 거기서 다음을 얻습니다.
    • 연결 테스트. 믿고 쓰기 전에 실제 경로를 상대로 확인합니다.
    • 대역폭 제한(업로드와 다운로드). 원격 기본 저장소로 가는 예약 백업이 WAN 회선을 가득 채우지 않도록, 원격지 복제가 쓰는 것과 같은 restic 옵션 --limit-upload와 --limit-download를 백업 자체에 적용합니다.
    • 추가 전용(불변) 보호. 원격지 대상이 받는 것과 같은 능동 변조 테스트(상대 쪽에 실제 DELETE 시도)로 확인합니다. 켜 두면 BombVault는 그 저장소를 스스로 정리(prune)하기를 거부합니다. 뒤에 별도의 로컬 사본이 없는 이상, 이 기기의 자격 증명이 백업의 유일한 사본을 지울 수 있어서는 안 되기 때문입니다.
    • 증가량 예산 경보. 저장 공간 카드가 이미 추적하는 것과 같은 저장소 크기 추이에서 뽑아냅니다.

이 가운데 무엇도 필수는 아닙니다. 손으로 입력하기만 하고 안전 설정을 저장하지 않은 원격 경로는 지금까지와 똑같이 백업합니다(대역폭 무제한, 정리 가능, 예산 경보 없음). 안전 설정 대화 상자는 원격지 사본이 받는 것과 같은 보호를, 그 때문에 원격지 대상을 따로 만들지 않고도 누리고 싶을 때를 위한 것입니다.

클라우드와 REST 자격 증명은 공용입니다

원격 기본 저장소는 설정, 클라우드 액세스, 공유 클라우드 자격 증명에 등록한 것과 같은 S3/REST 자격 증명으로 인증합니다. 기본 저장소만을 위한 별도의 자격 증명 보관소는 없습니다.

호스트 마운트 없는 SMB와 WebDAV

설정, 클라우드 액세스, rclone에는 Windows 또는 Samba 공유와 WebDAV 서버(Nextcloud, ownCloud, SharePoint 또는 그 밖의 서버)를 위한 양식이 있습니다. 짧은 이름, 호스트와 공유(SMB) 또는 URL과 서버 종류(WebDAV), 사용자, 비밀번호를 입력하면 BombVault가 rclone 섹션을 대신 작성합니다. 비밀번호는 저장되기 전에 rclone이 직접 난독화합니다. 이미 있는 이름으로 대상을 추가하면 두 번째 섹션을 추가하는 대신 그 섹션을 바꿉니다.

양식은 완성된 위치로 답합니다. 예를 들면 rclone:nas:backups입니다. 이것을 백업 경로나 오프사이트 대상에 넣고, 원하면 하위 폴더를 덧붙이세요(rclone:nas:backups/bombvault). 공유는 경로의 첫 부분이며 이름의 일부가 아닙니다.

이는 Unraid에 공유를 마운트하는 것보다 나은 방법입니다. restic은 마운트된 CIFS 공유에 저장소를 두지 말라고 권하는데, 여기서는 아무것도 마운트되지 않습니다. NFS가 양식에 없는 것은 restic과 rclone 모두 NFS 백엔드가 없기 때문입니다. NFS라면 호스트에 익스포트를 마운트하고 백업 경로를 그곳으로 지정하세요.

불변(append-only) 오프사이트

오프사이트 저장소를 append-only로 표시하여 랜섬웨어나 손상된 호스트가 백업을 삭제하거나 다시 쓸 수 없게 하세요. 상대편(--append-only 모드로 실행되는 restic/rest-server)이 이를 강제합니다. BombVault는 오직 검증만 하고 구성 주장만으로는 절대 녹색을 표시하지 않습니다.

안내형 오프사이트 설정 마법사가 백엔드 선택(rest-server / rclone / S3)부터 바로 붙여넣을 수 있는 rest-server 배포 스니펫, 연결 테스트, 불변 토글(즉시 변조 테스트를 실행함), 보존 전략까지 안내하므로, 구성을 손으로 편집하지 않고도 append-only 오프사이트에 도달할 수 있습니다.

/locks/ 아래의 삭제 성공은 예상된 동작입니다

추가 전용은 이제 아무것도 삭제할 수 없다는 뜻이 아닙니다. restic은 자체 잠금을 걸고 다시 풀어야 하므로 /locks/는 의도적으로 쓰기와 삭제가 가능한 상태로 남습니다. 스냅샷과 그 뒤의 데이터, 즉 랜섬웨어가 노리는 대상은 제거할 수 없습니다. 원격 측을 직접 확인했을 때 /locks/ 아래에서 삭제가 성공하는 것은 올바른 동작이며 보호의 구멍이 아닙니다.

불변 저장소는 이 장비에서 절대 정리되지 않습니다

불변 오프사이트는 의도적으로 오래된 스냅샷을 절대 정리하지 않습니다. 저장소 크기가 폭주하기 전에 경고받을 수 있도록 증가 예산 경보를 설정하세요.

변조 테스트

BombVault는 주기적으로 오프사이트 저장소에 대해 실제로 삭제를 시도하여(존재하지 않는 객체를 대상으로) append-only 보증을 입증합니다:

  • 거부됨은 보호됨을 의미합니다.
  • 허용됨은 보호되지 않음을 의미합니다.
  • 결론이 나지 않는 결과(서버 도달 불가, 인증 오류)는 저장된 판정을 절대 뒤집지 않습니다.

실제로 보호됨에서 보호되지 않음으로의 전환은 단일 경고를 발생시킵니다.

DR 리허설

BombVault는 백업이 단지 존재하는 것이 아니라 실제로 복원 가능하다는 두 가지 수준의 증거를 제공합니다.

  • 복원 검증 리허설(로컬). BombVault는 주기적으로 restic check --read-data-subset(제한됨, 디스크를 채우는 전체 복원이 아님)을 실행하고 도메인별로 복원 가능 확인됨 배지를 표시합니다. 주기는 설정, 일정에, 배지는 설정, 무결성에 있습니다.
  • DR 리허설(오프사이트). BombVault는 오프사이트 저장소에서 실제 대상을 일회용 샌드박스로 복원하고, 파일 단위와 바이트 단위로 검증한 다음 정리합니다. 이는 저장소가 단지 응답하는 것이 아니라 오프사이트에서 복구할 수 있음을 입증합니다.

대시보드의 랜섬웨어 보호 스코어카드는 이를 도메인별 녹색 / 황색 / 적색 자세로 정리하며, 시점이 표시된 체크리스트(오프사이트 구성됨, append-only 검증됨, 복제 최신, 복원 리허설 통과, 암호화 켜짐, 정리 전략 설정됨)를 제공합니다. 모든 적색 행은 수정 방법으로 딥 링크되며, 카드는 검증된 사실에서만 녹색이 됩니다.

인스턴스 페어링

수신자, 가져오기 소스, 인스턴스 페이지, Mesh 오프사이트는 모두 다른 BombVault와 통신합니다. 이는 하나의 페어링 그룹의 구성원으로서 이루어지며, 인스턴스는 열두 단어로 그룹에 합류합니다.

첫 번째 인스턴스에서 설정 → 페어링을 열고 페어링 카드에서 문구 생성을 누르세요. 열두 단어가 복사 버튼이 있는 창에 나타납니다. 다른 모든 인스턴스에서 같은 곳을 열고 문구 입력을 누른 뒤 붙여넣거나 입력하거나, 그 창에서 붙여넣기를 누르세요. 목록에 없는 단어는 입력하는 즉시 그 위치와 함께 표시되고, 마지막 단어에는 체크섬이 들어 있어 잘못 입력하거나 순서가 바뀐 단어를 페어링이 이루어지기 전에 잡아냅니다. 문구는 인스턴스 하나에서만 생성하세요. 두 인스턴스가 모두 문구를 만들면 두 개의 별도 그룹이 생깁니다. 1분이 지나도 아무도 나타나지 않으면, 탭에 두 가지 방법이 표시됩니다. 단어를 다시 표시해 상대 쪽에서 입력하거나, 상대 인스턴스의 단어를 입력해 한 번에 그 그룹에 합류하는 것입니다. 페어링은 로그인 비밀번호 없이도 작동하지만, 비밀번호를 설정해 두세요. 설정하지 않으면 이 웹 화면을 열 수 있는 사람은 누구나 단어를 읽고, 그룹을 통해 그 안의 모든 인스턴스의 restic 비밀번호를 얻을 수 있습니다. 비밀번호가 설정되기 전까지는 페어링 카드에 그 사실이 표시됩니다. 비밀번호를 설정하면 문구를 다시 표시할 때 비밀번호를 물어봅니다. 그룹 나가기로 인스턴스를 다시 뺄 수 있습니다.

단어를 아는 사람은 누구나 그룹에 합류할 수 있으므로, 비밀번호처럼 다루세요.

구성원이 서로에게 도달하는 방법. 각 인스턴스는 로그인하는 순간 브라우저에서 네트워크상의 자신의 주소를 알아내며, 이는 릴레이 카드에 네트워크상의 이 인스턴스로 표시됩니다. 앞에 리버스 프록시나 특이한 포트가 있다면 거기서 고치세요. 같은 네트워크에서는 구성원이 이 주소를 멀티캐스트로 알리고 직접 통신하며, 멀티캐스트가 Docker의 기본 bridge 네트워크 같은 컨테이너 네트워크를 넘지 못하는 곳에서는 인스턴스가 대신 자신의 서브넷을 검색해 그룹 구성원만 응답할 수 있는 서명된 호출로 다른 인스턴스를 찾으므로, 릴레이 없이도 페어링이 몇 초 만에 끝납니다. 아무것도 나타나지 않으면 페어링 카드 아래의 찾을 수 없나요?가 다른 서브넷이나 비표준 포트를 위해 주소를 하나 직접 입력받습니다. 다른 네트워크에 있는 인스턴스는 릴레이를 거치며, 릴레이는 같은 탭에서 선택합니다:

  • 프로젝트 릴레이(기본값): parleyport.halleluja.design. KnightLoader도 사용하는 릴레이입니다. 설정할 것이 없습니다.
  • 자체 릴레이: Unraid Community Apps의 ParleyPort 컨테이너, 또는 이미 외부에서 접근 가능하고 릴레이 역할 수행이 켜져 있는 자신의 인스턴스 중 하나입니다. 그 인스턴스는 이미 가지고 있는 리버스 프록시와 인증서 뒤에서 자신의 주소의 /relay/connect로 응답하며, 자신의 그룹만 들어오게 합니다. 사용해야 할 모든 인스턴스에 릴레이 주소를 입력하세요.
  • 릴레이 없음: 구성원은 같은 네트워크에서만 자동으로 서로를 찾으며, 그 외에는 찾지 못합니다.

릴레이가 보는 것. 구성원 간의 모든 통신은 열두 단어에서 유도된 키로 AES-256-GCM을 통해 봉인되며, 그 키는 인스턴스 밖으로 절대 나가지 않습니다. 릴레이가 아는 것은 연결을 묶는 해시, 메시지가 어느 인스턴스를 위한 것인지, 크기, 통과 시각뿐입니다. 로컬 네트워크에서의 직접 통신도 같은 방식으로 봉인되고 서명도 되므로, 인스턴스가 제공하는 자체 서명 인증서에는 아무것도 의존하지 않습니다.

그룹을 통해 오가는 것. 인스턴스 페이지의 스코어카드, 지금 한 도메인을 확인해 달라는 요청, Mesh 오프사이트 제안, 그리고 수신자나 가져오기 소스가 필요로 하는 것, 즉 상대 인스턴스의 저장소 위치와 그 restic 비밀번호입니다. 백업 데이터는 절대 오가지 않으며, 언제나 restic 백엔드로 곧장 향합니다. APP_KEY도 마찬가지입니다. restic 비밀번호는 그 인스턴스의 저장소만 열 뿐, 저장된 비밀이나 세션, 복구 코드는 열지 않습니다.

페어링 이전의 항목. 플릿 토큰으로 추가된 인스턴스, 그리고 다른 인스턴스의 APP_KEY로 설정된 수신자와 가져오기 소스는 업데이트 후에도 남아 있으며 다시 페어링으로 표시됩니다. 수신자와 가져오기 소스는 계속 작동합니다. 처음 시작할 때 BombVault가 저장된 각 APP_KEY를 그로부터 유도한 restic 비밀번호로 바꾸기 때문입니다. 두 인스턴스를 페어링한 다음 항목을 편집해 그 인스턴스를 선택하세요. 같은 이름의 인스턴스가 그룹에 나타나는 즉시, 그런 인스턴스는 예전 카드를 넘겨받습니다.

여전히 손으로 APP_KEY를 입력해야 하는 유일한 곳은 다른 BombVault 저장소에서 복원입니다. 다른 인스턴스가 사라져서 그룹 안에서 응답할 수 없는 경우를 위한 것입니다.

수신자 대시보드(수신 측)

받는 쪽을 읽기 전용으로 지켜보며, 무결성 검사는 이 하드웨어에서 실행합니다.

받는 쪽을 읽기 전용으로 지켜보며, 무결성 검사는 이 하드웨어에서 실행합니다.

위의 모든 것은 보내는 측입니다. 다른 BombVault로부터 불변 오프사이트 사본을 받는 장비에서, 수신자 대시보드는 수신 하드웨어에서 그 저장소를 독립적으로 읽기 전용 모니터링하므로, 상대편의 조용한 실패가 눈에 띄지 않고 지나가지 않습니다.

설정에서 수신자 토글을 켜서 수신자 탭을 표시하세요. 기본적으로 꺼져 있으며, 실제로 불변 오프사이트 백업을 받는 장비에서만 활성화하세요. 그런 다음 받은 저장소(읽기 전용, 보내는 인스턴스의 restic 비밀번호로 열리며, 이는 페어링 그룹을 통해 도착합니다)를 등록하면 다음을 얻습니다:

  • 소스별로 그룹화된 스냅샷 인벤토리로, 어떤 컨테이너, VM, 파일 세트가 도착했는지 정확히 볼 수 있습니다.
  • 소스별 마지막 수신으로, 각각이 얼마나 최신인지 알 수 있습니다.
  • 수신 하드웨어에서 실행되는 독립적인 restic check로, 데이터가 실제로 있는 곳에서 무결성이 검증되며 보내는 쪽에서만이 아닙니다.
  • 데드맨 스위치: 설정한 기간 내에 소스가 전송을 멈추면 경고합니다.
  • 무결성 경고: 수신 측에서 검사가 실패하면 경고합니다.

수신자는 엄격히 읽기 전용입니다. 받은 저장소에 절대 쓰지 않으므로, 보내는 쪽이 의존하는 append-only 보증을 절대 깨뜨릴 수 없습니다.

수신 서버

수신 측 컴퓨터는 다른 인스턴스가 복사해 오는 rest-server도 실행할 수 있습니다. 수신기 탭 맨 위의 수신 서버 설정은 공유 폴더 안의 폴더(새 폴더로 만들 수 있습니다)와 포트(다른 컨테이너가 쓰지 않으면 8000)를 묻습니다. 그러면 BombVault는 다음을 수행합니다.

  1. rest-server라는 이름의 컨테이너가 이미 있거나 다른 컨테이너가 그 포트를 쓰고 있으면 거부합니다.
  2. restic/rest-server를 받아 Docker 소켓으로 append-only 모드에서 시작합니다. 저장소는 비공개이고 로그인 파일은 해당 폴더에 둡니다.
  3. Unraid 템플릿을 플래시에 쓰므로 컨테이너는 Docker 탭에서 계속 편집할 수 있습니다. 플래시에 닿지 않으면 템플릿을 다운로드로 제공합니다.
  4. 변조 테스트를 실행해 삭제를 거부하는지 보여 줍니다.

그룹의 인스턴스는 대상 마법사의 내 그룹에서 아래에서 수신 측 컴퓨터의 이름으로 이 서버를 찾습니다. 각 인스턴스는 서버를 처음 고를 때 자기만의 로그인을 받고, 그곳에서는 자기 폴더에만 씁니다. 카드에 이 로그인들이 나열되며 로그인 취소로 하나를 거둘 수 있습니다. 그 인스턴스가 이미 복사한 것은 폴더에 남습니다. 설정할 때 그룹 밖 사람을 위한 로그인도 하나 만들어지며, 그 비밀번호는 카드에 한 번만 표시됩니다.

릴레이로만 수신 측 컴퓨터에 닿는 인스턴스는 릴레이가 백업을 나르지 않으므로 이 서버를 쓸 수 없습니다. 먼저 설정, 페어링에서 수신 측 컴퓨터의 주소를 추가하세요. BombVault가 자체 IP 주소(예: br0)로 실행 중이면 서버가 호스트의 주소에서 수신 대기하므로 파트너용 주소를 채우세요.

실전 예시: Unraid 두 대, 처음부터 끝까지

위는 부품 설명입니다. 여기서는 실제 값을 사용한 완전한 구성을 하나 보여 줍니다. 부품은 한 번 조립된 모습을 보고 나면 훨씬 조립하기 쉬워지기 때문입니다.

두 대: TOWER 는 컨테이너를 돌리며 백업을 보내고, VAULT 는 이를 받아 불변성을 강제합니다. 이름과 주소, 공유 경로는 각자의 것으로 바꾸세요.

1. VAULT 에 추가 전용 서버를 세웁니다. TOWER 의 BombVault 에서 설정 → 오프사이트 → 설정 으로 가서 rest-server 를 고르고 레시피를 생성합니다. Unraid 템플릿 (XML) 탭을 복사해 VAULT 에 /boot/config/plugins/dockerMan/templates-user/my-rest-server.xml 로 저장한 뒤, Docker → Add Container 에서 템플릿 목록의 rest-server 를 고릅니다. 시작하기 전에 표시된 htpasswd 줄을 VAULT 의 /mnt/user/appdata/rest-server/.htpasswd 에 적어 넣으세요. 일회용 비밀번호는 한 번만 표시되고 저장되지 않으니 지금 복사하세요. 그 줄에는 같은 비밀번호가 bcrypt로 해시되어 들어 있습니다. 평문은 TOWER의 REST 자격 증명에, 해시된 줄은 VAULT의 .htpasswd에 넣습니다. 직접 해시할 것은 없습니다.

OPTIONS 항목의 `--append-only` 는 그대로 두세요. 이것이 핵심이며, 빼면 VAULT 는 다시 평범한 공유가 됩니다.

2. TOWER 에서 오프사이트 저장소를 그쪽으로 향하게 합니다. 저장소 URL 은 레시피가 출력하는 형태를 따릅니다:

rest:http://VAULT:8000/bombvault-containers/containers

경로의 첫 구간이 htpasswd 사용자, 두 번째가 저장소입니다. 생성된 사용자와 비밀번호를 대상의 REST 자격 증명으로 입력하고 연결 테스트를 실행하세요.

3. TOWER 에서 «불변» 을 켭니다. 변조 테스트가 즉시 실행되며 보호됨 이라고 나와야 합니다. 각 결과의 뜻:

결과 무슨 일이 있었나
보호됨 VAULT 가 삭제를 거부했습니다. 통과 상태는 이것뿐입니다.
보호되지 않음 VAULT 가 삭제를 받아들였습니다. --append-only 가 없거나 제거되었습니다.
판정 불가 둘 다 아닙니다. 보통 URL 이 restic 이 쓰는 것과 다르거나 자격 증명이 바뀐 경우입니다. 아무것도 기록되지 않고 경고도 울리지 않습니다.

4. VAULT 에서 도착하는 것을 봅니다. 두 장비를 페어링한 다음(인스턴스 페어링), 설정 → 일반 → 수신기 를 켜고 리시버 탭을 열어 TOWER 를 보내는 인스턴스로 하여 저장소를 읽기 전용으로 등록하세요.

위치는 컨테이너 안쪽의 경로이며, 호스트 마운트를 기준으로 상대 경로로 씁니다

user/appdata/rest-server/bombvault-containers/containers 를 입력하세요. /mnt/user/appdata/… 가 아닙니다. BombVault 는 컨테이너 안에서 돌아가고 호스트의 /mnt 는 다른 곳에 마운트되어 있어, 호스트 절대 경로는 그 안에 존재하지 않습니다. 붙여 넣으면 BombVault 가 대신 써야 할 상대 경로를 알려 줍니다.

저장하면 VAULT 는 그룹을 통해 TOWER 의 restic 비밀번호를 받습니다. 키를 입력하는 사람은 없습니다.

5. 원하면 상호로 만드세요. 같은 다섯 단계를 반대 방향으로도 합니다. TOWER 의 rest-server 가 VAULT 의 사본을 받는 형태입니다. 그러면 각 기기가 상대의 불변성을 강제하며, 어느 쪽도 상대의 백업을 지울 수 없습니다.

안내형 복구

전용 복구 탭이 새로 설치하거나 재구축한 설치본을 한 곳에서 재해 상황으로 안내합니다:

  1. BombVault 자체 설정을 먼저 복원하므로, 나머지 흐름에 필요한 백업 경로, 오프사이트 대상, 자격 증명이 미리 채워집니다(Docker 소켓을 통한 자체 재시작으로 적용되므로, 열려 있는 핸들 아래에서 실행 중인 설정 데이터베이스가 덮어쓰이는 일이 없습니다).
  2. BombVault가 백업을 읽을 수 있는지 확인합니다(암호화 키 함정을 먼저).
  3. 기존 저장소를 가리키게 합니다(로컬 또는 오프사이트).
  4. 그 안에 저장된 컨테이너, VM, 파일 세트, ZFS 데이터세트를 검색합니다.
  5. 컨테이너와 VM을 한 번에 복원합니다(중지된 상태로 두어 의도적으로 시작하게 함). 파일 세트와 ZFS 항목은 목록으로 보여 주며 하나씩 복원합니다. ZFS 항목은 꺼진 상태로 돌아옵니다. 복구 키트는 원클릭 거리에 있습니다.

계획된 마이그레이션 대 재해

안내형 복구는 백업에서 BombVault 자체 설정을 복원합니다. 새 장비로의 계획된 이동의 경우, 대신 설정 내보내기 / 가져오기 카드(이식 가능한 JSON 파일)로 구성을 직접 옮길 수 있습니다. 구성을 참고하세요.

다른 BombVault 저장소에서 복원

복구 탭의 별도 카드는 일회성 읽기 전용 세션에서 그 인스턴스의 APP_KEY로 다른 BombVault 인스턴스의 저장소(/mnt 아래에 마운트된 공유, 또는 원격 URL)를 엽니다. 거기에 저장된 컨테이너, VM, 파일 세트를 탐색하고, 스냅샷을 선택하여 복원하면, 복원된 객체가 정상적인 로컬 컨테이너, VM, 파일 세트가 됩니다. 다른 저장소에는 절대 아무것도 기록되지 않으며, 자체 백업 설정은 손대지 않은 채 유지됩니다(세션은 메모리에 있고 스스로 만료됨). 서버 A에서 서버 B로 컨테이너를 옮기는 것이 더 이상 저장소 설정을 다시 가리키고 나중에 되돌리는 것을 의미하지 않습니다. 이 카드는 일회성입니다. 세션을 열고, 고른 것을 복원하고, 다른 인스턴스는 잊습니다. 대신 이 장비가 다른 인스턴스의 스냅샷을 일정에 따라 자기 저장소로 가져오는 상시 구성을 원한다면, 그것은 인스턴스 페이지의 가져오기 탭입니다.

이 서버에 없는 네트워크를 쓰는 컨테이너(예: 일반 Docker 호스트에서의 Unraid br0 네트워크)는 행 아래에 네트워크 선택이 나타납니다. BombVault는 고른 네트워크에 다른 네트워크를 유지한 채 컨테이너를 만듭니다. 고정 IP 주소와 MAC 주소는 이전 네트워크에 속해 있었으므로 빠지고, 새 네트워크가 할당합니다.

암호화 키 복구 키트

이것은 실행 중인 BombVault가 없을 때조차 재해 복구를 가능하게 하는 요소입니다.

원클릭으로 마스터 키, 파생된 restic 비밀번호, 정확한 저장소 위치와 명령을 다운로드하므로, 어떤 장비에서든 restic CLI로 바로 복원할 수 있습니다. 저장하기 전까지 대시보드 알림이 계속 재촉합니다.

복구 키트를 서버 밖에 보관하세요

키트에는 백업을 복호화하는 비밀이 들어 있습니다. 서버와 분리된 안전한 곳(비밀번호 관리자, 금고에 인쇄한 사본)에 보관하세요. 복구 키트 없이 BombVault와 APP_KEY를 모두 잃으면 암호화된 백업을 복구할 수 없습니다.

가장 최근 스냅샷이 항상 복원할 스냅샷은 아닙니다

restic 0.17부터 restic snapshots는 각 스냅샷의 크기를 보여 줍니다. 데이터를 잃은 뒤에는 가장 최근 스냅샷이 비워진 것일 수 있으므로, 이전 스냅샷보다 훨씬 작은 스냅샷은 복원하지 마세요. 랜섬웨어 뒤에는 평소 크기의 암호화된 스냅샷일 수 있습니다. BombVault가 아직 실행 중이라면 먼저 이상 징후 페이지를 확인하세요. 마지막 정상 백업이 표시됩니다. 복원에는 BombVault의 이상 징후 데이터가 필요 없으며, 보존 일시 중지는 스냅샷을 더 많이 남길 뿐입니다.

키트 봉인

일반 내보내기에 age 암호화를 켜 두었다면(설정), 키트도 그것으로 봉인되어 bombvault-recovery-kit.md.age로 다운로드됩니다. 바이너리가 아니라 ASCII 아머 형식이므로 여전히 일반 텍스트입니다. 비밀번호 관리자에 붙여 넣거나 인쇄하는 것은 전과 똑같이 되고, 내용만 키 없이는 읽을 수 없습니다.

age 키를 키트 안에 보관하지 마세요

봉인된 키트를 열려면 age 개인 키가 필요합니다. 그 키는 키트 자체에 의존하지 않는 곳에 두세요. 그렇지 않으면 복구해야 할 것이 하나가 아니라 둘이 됩니다. 봉인은 키트를 완전히 통제하지 못하는 곳(공유 비밀번호 관리자, 클라우드 메모, 사무실의 인쇄본)에 보관할 때 가치가 있습니다. 자기 금고에 든 키트는 이미 금고가 지켜 줍니다.

암호화가 켜져 있는데 쓸 수 있는 수신자가 설정되지 않았다면 다운로드는 그대로 거부됩니다. BombVault는 마스터 키를 평문으로 내주는 쪽으로 절대 돌아가지 않습니다.

키트가 손에 없을 때

비밀번호는 어디에도 저장되지 않고 APP_KEY에서 계산됩니다. 키와 셸만 있으면 직접 같은 값을 만들 수 있습니다.

printf 'bombvault:restic-repo' \
  | openssl dgst -sha256 -mac HMAC -macopt hexkey:$APP_KEY -r \
  | cut -d' ' -f1

고정 문자열 bombvault:restic-repo에 대한 HMAC-SHA256이며, 키는 16진 APP_KEY의 원시 바이트, 출력은 소문자 16진 64자입니다. 같은 값이 키트에도 파생된 restic 비밀번호로 적혀 있습니다. 이 절은 키트가 당신과 다른 곳에 있는 날을 위한 것입니다.

받은 저장소에는 '보내는 쪽' 인스턴스의 키를 쓰세요

원격지 복제로 여기에 도착한 저장소는 그것을 보낸 기기가 자신의 APP_KEY로 만든 것입니다. 받는 쪽 키로 파생하면 restic이 거부하는 비밀번호가 나오고, 그 모습은 손상된 저장소와 똑같지만 손상된 것이 아닙니다. 받은 저장소에서 restic check가 비밀번호를 계속 다시 묻는 흔한 이유가 바로 이것입니다.

복구 정의는 각 저장소 안(<repo>/def, <repo>/vm-def)에 있으므로, 복사한 저장소 폴더는 완전히 자기 완결적입니다. 따라서 키트와 저장소만 있으면 베어메탈 복원에 필요한 모든 것이 갖춰집니다.

데이터베이스 덤프 되찾기

데이터베이스 덤프는 컨테이너 저장소 안의 독립된 복원 지점으로, dbdump:<container> 태그를 달고 /dbdump/<container>.sql 파일 하나만 담고 있습니다. BombVault는 백업에서 이 덤프들을 나열하고 내려받고 가져옵니다. 아래는 restic만으로 하는 같은 절차로, BombVault가 없는 날을 위한 것입니다.

restic -r <repo> snapshots --tag dbdump:<container>
restic -r <repo> dump --tag dbdump:<container> latest /dbdump/<container>.sql > <container>.sql

각 덤프의 dbversion:과 dbname: 태그는 어느 서버 버전에서 왔고 어떤 데이터베이스를 담았는지 알려 줍니다. 온전한 파일은 -- PostgreSQL database cluster dump complete 또는 -- Dump completed로 끝납니다.

같은 버전이거나 더 새로운 버전(PostgreSQL), 또는 같은 주 버전(MySQL과 MariaDB)의 컨테이너로 가져오세요. 그 컨테이너는 빈 데이터 폴더로 한 번 시작해 초기화를 마친 상태여야 합니다. 호스트에는 데이터베이스 클라이언트가 필요 없고, 컨테이너에 하나 있습니다.

docker exec -i <container> sh -c 'exec psql -X -U "${POSTGRES_USER:-postgres}" -d postgres' < <container>.sql
docker exec -i <container> sh -c 'exec mariadb -uroot -p"$MARIADB_ROOT_PASSWORD"' < <container>.sql
docker exec -i <container> sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD"' < <container>.sql

전체 덤프에서 데이터베이스 하나만 넣으려면 MySQL과 MariaDB는 클라이언트 명령에 --one-database <name>을 받습니다. PostgreSQL 덤프는 데이터베이스마다 구획이 있고 각 구획은 \connect <name> 줄로 시작합니다. 그 구획을 별도 파일로 복사한 뒤, 데이터베이스를 만들고 -d <name>으로 가져오세요.

root로 뜬 덤프는 서버의 사용자까지 데려옵니다

root로 뜬 MySQL이나 MariaDB 전체 덤프에는 시스템 데이터베이스 mysql이 들어 있어, 가져오면 새 서버의 계정이 root 비밀번호를 포함해 덤프의 계정으로 바뀝니다. PostgreSQL에서는 컨테이너가 직접 만든 사용자에 대한 role ... already exists 메시지가 예상된 것이며 해롭지 않습니다.