Herkos

나만의 Blossom 서버

최종 수정: 2026년 10월 27일

Herkos Drive는 각 파일을 암호화된 블록으로 잘라 여러 Blossom 서버에 보관합니다. 사본은 세 개이며, 적어도 두 종류의 서버에 두고, 그중 하나는 여러분의 서버에 둡니다. 공개 서버는 블록을 무료로 보관해 주지만 아무것도 약속하지 않습니다. 블록을 지우거나, 공간이 가득 차거나, 문을 닫을 수 있습니다.

나만의 Blossom 서버는 여러분이 정하는 기간 동안 여러분의 사본을 보관하고, 여러분의 Drive에서 오는 블록만 받습니다. 이 페이지는 세 단계로 서버를 설정하는 방법과 매일 밤 백업하는 방법을 설명합니다. 나만의 메일함 릴레이와 함께 쓰기 좋으며, 이미 서버가 있다면 15분 정도 걸립니다.

어떤 서버를 쓸까

hzrd149의 blossom-server, 버전 6.4.1(2026년 10월 6일, MIT 라이선스)입니다. 2026년 10월 27일에 아래 설정과 Drive 자체의 업로드 코드로 직접 돌려 보고, 서버가 광고하는 내용이 아니라 Drive에 필요한 것을 확인했습니다:

Drive가 하는 일 결과
8 MiB 암호화 블록 업로드(application/octet-stream) 받아들임
업로드 전에 먼저 물어봄(BUD-06) 응답하며, 다른 키는 모두 거절
공개 서버의 블록을 복사하도록 여러분의 서버에 요청(BUD-04) 복사됨
신원 확인 없이 블록 읽기 바이트 하나 다르지 않게 제공
업로드한 키로 블록 삭제 삭제됨: 다시 요청하면 404
다른 키로 업로드 거부(401)

필요한 것

1단계: 서버 실행

서버용 폴더(예: /root/blossom)를 만들고 그 안에 다음 두 파일을 저장하세요. 첫 번째는 docker-compose.yml입니다:

services:
  blossom:
    image: ghcr.io/hzrd149/blossom-server:6.4.1
    environment:
      BLOSSOM_REQUIRE_CONFIG: "1"
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - data:/app/data
      - ./config.yml:/app/config.yml:ro
    restart: unless-stopped
volumes:
  data: {}

두 번째는 config.yml입니다. publicDomain에 도메인을, YOUR-VOLUME-KEY라고 적힌 곳에 볼륨 키를 넣으세요:

port: 3000
host: 0.0.0.0
publicDomain: blossom.example.com
storage:
  backend: local
  local:
    dir: ./data/blobs
  rules:
    - type: "*"
      expiration: 100 years
      pubkeys:
        - "YOUR-VOLUME-KEY"
upload:
  requireAuth: true
  maxSize: 104857600
  requirePubkeyInRule: true
mirror:
  enabled: true
  requireAuth: true
delete:
  requireAuth: true
list:
  enabled: false
media:
  enabled: false
report:
  enabled: false
landing:
  enabled: false

이 설정의 뜻은 이렇습니다. 업로드하거나 복사를 요청할 수 있는 것은 여러분의 볼륨 키뿐이며 (requirePubkeyInRule), 블록은 Drive가 지울 때까지 보관됩니다. 서버는 모든 규칙에 만료 기한을 요구하는데, 읽히지 않은 채 100 years라면 사실상 영원이고, 어차피 Drive는 블록을 정기적으로 읽습니다. 포트는 그 기계 안에서만 열려 있습니다(127.0.0.1). 모든 것이 프록시를 거칩니다. 실행합니다:

cd /root/blossom
docker compose up -d

2단계: 앞에 HTTPS 두기

Caddy를 쓰면 전체 설정(/etc/caddy/Caddyfile)은 이것뿐입니다:

blossom.example.com {
    reverse_proxy 127.0.0.1:3000
}

같은 Caddy가 이미 릴레이를 서비스하고 있다면, 이 블록을 릴레이 블록 아래에 추가하세요. Caddy를 다시 불러오세요(sudo systemctl reload caddy). 이제 브라우저에서 https://blossom.example.com을 열면 404로 응답이 와야 합니다. 일부러 홈페이지를 두지 않았습니다.

3단계: Herkos Drive에 알려 주기

  1. Herkos Drive에서 설정 → 서버를 열고 https://blossom.example.com을 추가한 뒤 내 서버로 표시합니다.
  2. Drive는 업로드할 때마다 먼저 이 서버에 물어봅니다. 그때부터 모든 새 파일은 그곳에 사본이 생기고, 이미 있던 파일들은 다음에 Drive가 사본을 확인할 때 사본이 생깁니다.
  3. 목록의 다른 서버들은 그대로 두세요. 여러분의 서버는 세 사본 중 하나일 뿐, 결코 유일한 사본이 아닙니다. 서버가 내려가도 파일은 다른 서버들에 남아 있고, 일주일 동안 응답이 없으면 Drive가 알려 줍니다.

4단계: 매일 밤 백업하기

서버가 죽으면 Drive가 알아채고, 영향을 받은 파일의 사본을 목록의 다른 서버들에 만듭니다. 하지만 여러분의 서버에 있는 사본은 다른 누구에게도 의존하지 않는 유일한 사본이며, 매일 밤 백업해 두면 인터넷으로 모든 것을 다시 복사하지 않고도 그 사본을 다시 만들 수 있습니다.

서버는 모든 것을 Docker 볼륨 blossom_data 안에 보관합니다(이름은 파일들이 있는 폴더 이름으로 시작합니다. docker volume ls로 확인하세요). 블록마다 파일이 하나씩 있고, 각 블록을 누가 업로드했는지 기록하는 작은 SQLite 데이터베이스가 있습니다. 블록은 절대 바뀌지 않지만, 데이터베이스는 쓰는 중에 복사하면 안 됩니다. 그래서 스크립트는 서버가 실행 중인 상태로 모든 것을 복사하고, 그사이 바뀐 부분을 복사하는 몇 초 동안 서버를 멈췄다가 다시 시작하고, 그다음에야 사본을 업로드합니다. 멈춰 있는 동안 Drive는 조금 뒤에 다시 시도할 뿐입니다.

사본은 restic으로 서버 밖으로 보내며, restic은 내보내기 전에 암호화합니다. 서버와 다른 업체의 장소를 쓰세요. SFTP 계정(스토리지 박스, 집에 있는 컴퓨터)이나 S3 호환 버킷이면 됩니다. 이미 이 방법으로 릴레이를 백업하고 있다면, 같은 장소에 다른 폴더를 쓰세요.

  1. 도구를 설치하고 저장소를 만듭니다. 비밀번호는 비밀번호 관리자에도 보관하세요. 비밀번호가 없으면 사본을 읽을 수 없고, 서버에만 있으면 서버와 함께 사라집니다. SFTP를 쓴다면 root에게 백업 기계가 받아들이는 SSH 키도 필요합니다 (sudo ssh-keygen -t ed25519 후 그곳에 /root/.ssh/id_ed25519.pub 추가).

    sudo apt install restic rsync
sudo sh -c 'openssl rand -base64 32 > /root/.restic-blossom-password'
sudo sh -c 'cat > /root/.restic-blossom-env' <<'END'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/blossom
export RESTIC_PASSWORD_FILE=/root/.restic-blossom-password
END
sudo chmod 600 /root/.restic-blossom-password /root/.restic-blossom-env
sudo sh -c '. /root/.restic-blossom-env && restic init'

  2. 다음을 /usr/local/bin/backup-blossom로 저장하고 실행 권한을 주세요 (sudo chmod 700 /usr/local/bin/backup-blossom). 파일이 /root/blossom에 있지 않다면 BLOSSOM_DIR를 바꾸세요. 최근 14일, 8주, 12개월분을 보관합니다. 블록은 절대 바뀌지 않으므로 매일 밤 새로 생긴 것만 더해집니다.

    #!/bin/sh
set -eu
. /root/.restic-blossom-env
BLOSSOM_DIR=/root/blossom
COPY=/var/backups/blossom-data
VOLUME=$(docker volume inspect --format '{{ .Mountpoint }}' blossom_data)
mkdir -p "$COPY"
rsync -a --delete "$VOLUME/" "$COPY/"
cd "$BLOSSOM_DIR"
docker compose stop blossom
trap 'docker compose start blossom' EXIT
rsync -a --delete "$VOLUME/" "$COPY/"
docker compose start blossom
trap - EXIT
restic backup "$COPY" --tag blossom
restic forget --tag blossom --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

  3. 한 번 직접 실행한 뒤(sudo /usr/local/bin/backup-blossom) sudo crontab -e로 예약하세요. 두 번째 줄은 매달 저장된 데이터의 10분의 1을, 매번 다른 부분을 다시 읽어 사본을 아직 열 수 있는지 확인합니다. 가끔 /var/log/backup-blossom.log를 살펴보세요. Fatal이 들어간 줄은 그날 밤 사본이 실패했다는 뜻입니다. 릴레이도 같은 기계에 백업한다면, 이 시각들은 릴레이의 시각과 겹치지 않습니다.

    35 4 * * * /usr/local/bin/backup-blossom >> /var/log/backup-blossom.log 2>&1
55 5 2 * * . /root/.restic-blossom-env && restic check --read-data-subset=10% >> /var/log/backup-blossom.log 2>&1

복원하려면(새 서버, 또는 디스크 고장 후): 서버를 다시 설정하고(1단계와 2단계) 같은 저장소로 이 단계의 1번과 2번을 반복하되, 새 비밀번호를 만드는 대신 저장해 둔 비밀번호를 /root/.restic-blossom-password에 쓰고 restic init은 건너뛰세요. 그런 다음 가장 최근 백업을 서버의 볼륨에 복사합니다:

sudo sh -c '. /root/.restic-blossom-env && restic restore latest --tag blossom --target /'
cd /root/blossom && sudo docker compose stop blossom
sudo rsync -a --delete /var/backups/blossom-data/ "$(sudo docker volume inspect --format '{{ .Mountpoint }}' blossom_data)/"
sudo docker compose start blossom

다음에 사본을 확인할 때 Drive는 블록들을 다시 찾아내고, 마지막 백업 이후에 도착한 것은 다른 서버들에서 복사해 옵니다. 2026년 10월 27일에 이 전체 과정을 시험했습니다. 백업하고, 서버를 지우고, 복원한 뒤, 모든 블록을 각자의 해시로 확인하며 다시 읽었고, 그 후 Drive의 키로 삭제했습니다.

1년에 한 번은 여분의 기계에서 이 복원을 해 보고, 서버가 여러분의 블록으로 응답하는지 확인하세요. 비밀번호를 포함한 전체 과정을 증명하는 유일한 시험입니다.

알아 두면 좋은 점