Herkos

自分の Blossom サーバー

最終更新: 2026年10月27日

Herkos Drive は各ファイルを暗号化されたブロックに分け、複数の Blossom サーバーに保管します。 コピーは 3 つで、少なくとも 2 種類のサーバーに置き、そのうち 1 つは自分のサーバーに 置きます。公開サーバーは無料でブロックを保管しますが、何も約束しません。ブロックを消去したり、 容量がいっぱいになったり、閉鎖したりすることがあります。

自分の Blossom サーバーは、あなたが決めた期間だけあなたのコピーを保管し、あなたの Drive から のブロックしか受け付けません。このページでは、その立て方を 3 つの手順と、毎晩のバックアップで 説明します。自分のメールボックス用リレーと組み合わせるのに向いていて、すでに サーバーがあれば、およそ 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） コピーされる
識別せずにブロックを読む 1 バイトも違わずに返される
アップロードした鍵でブロックを削除する 削除される。再度求めると 404
他の鍵からアップロードする 拒否される（401）

必要なもの

手順 1：サーバーを動かす

サーバー用のフォルダー（例：/root/blossom）を作り、次の 2 つのファイルを保存します。 1 つ目は 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: {}

2 つ目は 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. 一覧の他のサーバーは残しておいてください。あなたのサーバーは 3 つのコピーのうちの 1 つで あって、唯一のコピーではありません。停止しても、ファイルは他のサーバーに残っており、 1 週間応答がなければ Drive が知らせます。

手順 4：毎晩バックアップする

サーバーが壊れると、Drive はそれに気づき、影響を受けたファイルのコピーを一覧の他のサーバーに 作ります。しかし、あなたのサーバーにあるコピーは、誰にも依存しない唯一のコピーです。毎晩の バックアップがあれば、インターネット越しにすべてをコピーし直さずに、それを再構築できます。

サーバーはすべてを Docker ボリューム blossom_data の中に保存します（名前はファイルを 置いたフォルダー名で始まります。docker volume ls で確認してください）。中身は、1 つに つき 1 ファイルのブロックと、各ブロックを誰がアップロードしたかを記録する小さな 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 で予約します。2 行目は毎月、保存データの 10 分の 1 を、毎回 異なる 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 の鍵で削除しました。

年に一度、予備のマシンでこの復元を行い、サーバーがあなたのブロックで応答することを 確認してください。パスワードを含めた全体の流れを証明できる唯一のテストです。

知っておくとよいこと