Herkos

Seu próprio servidor Blossom

Última atualização: 27 de outubro de 2026

O Herkos Drive corta cada arquivo em blocos criptografados e os guarda em vários servidores Blossom: três cópias, em pelo menos dois tipos de servidor, e uma num servidor seu. Servidores públicos guardam blocos de graça, mas não prometem nada: podem expurgá-los, lotar ou fechar.

Um servidor Blossom próprio guarda sua cópia pelo tempo que você decidir e só aceita blocos do seu Drive. Esta página explica como configurar um em três passos, mais um backup noturno. Ele combina bem com seu próprio relay de caixa postal, e leva uns quinze minutos se você já tiver um servidor.

Qual servidor usar

blossom-server de hzrd149, versão 6.4.1 (6 de outubro de 2026, licença MIT). Rodamos o servidor em 27 de outubro de 2026 com a configuração abaixo e o próprio código de upload do Drive, e verificamos o que o Drive precisa, não o que o servidor anuncia:

O que o Drive faz Resultado
Envia blocos criptografados de 8 MiB (application/octet-stream) Aceitos
Pergunta antes de enviar (BUD-06) Responde, e recusa qualquer outra chave
Pede ao seu servidor que copie um bloco de um servidor público (BUD-04) Copiado
Lê um bloco sem se identificar Servido, byte a byte
Apaga um bloco com a chave que o enviou Apagado: pedir de novo dá 404
Envios de qualquer outra chave Recusados (401)

Do que você precisa

Passo 1: rode o servidor

Crie uma pasta para ele, por exemplo /root/blossom, e salve nela estes dois arquivos. O primeiro é o 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: {}

O segundo é o config.yml. Coloque seu domínio em publicDomain e sua chave do volume onde está escrito 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

O que ele diz: só sua chave do volume pode enviar ou pedir cópias (requirePubkeyInRule), e um bloco fica guardado até o Drive apagá-lo. O servidor exige uma expiração em cada regra; 100 years sem ser lido é, na prática, nunca, e de qualquer forma o Drive lê seus blocos regularmente. A porta só escuta na própria máquina (127.0.0.1): tudo passa pelo proxy. Inicie-o:

cd /root/blossom
docker compose up -d

Passo 2: coloque HTTPS na frente

Com o Caddy, a configuração inteira (/etc/caddy/Caddyfile) é:

blossom.example.com {
    reverse_proxy 127.0.0.1:3000
}

Se o mesmo Caddy já serve seu relay, adicione este bloco abaixo daquele. Recarregue o Caddy (sudo systemctl reload caddy). Abrir https://blossom.example.com num navegador agora deve dar resposta, com um 404: não há página inicial, de propósito.

Passo 3: avise o Herkos Drive

  1. No Herkos Drive, abra Configurações → Servidores, adicione https://blossom.example.com e marque-o como seu.
  2. O Drive pergunta a ele antes de cada envio. A partir daí, todo arquivo novo ganha uma cópia lá, e os arquivos que você já tinha ganham a deles na próxima vez que o Drive verificar as cópias.
  3. Mantenha os outros servidores na lista. O seu é uma das três cópias, nunca a única: se ele cair, seus arquivos continuam nos outros, e o Drive te avisa depois de uma semana de silêncio.

Passo 4: faça backup toda noite

Se seu servidor morrer, o Drive percebe e dá aos arquivos afetados cópias nos outros servidores da sua lista. Mas a cópia no seu servidor é a única que não depende de mais ninguém, e um backup noturno permite reconstruí-la sem copiar tudo de novo pela internet.

O servidor guarda tudo dentro do volume Docker blossom_data (o nome começa com a pasta em que estão os arquivos; confira com docker volume ls): os blocos, um arquivo cada, e um pequeno banco de dados SQLite que diz quem enviou cada um. Os blocos nunca mudam, mas o banco de dados não deve ser copiado enquanto está sendo escrito. Então o script copia tudo com o servidor rodando, para-o pelos poucos segundos que leva para copiar o que mudou nesse meio-tempo, inicia-o de novo e só então envia a cópia. Enquanto ele está parado, o Drive simplesmente tenta de novo um pouco depois.

A cópia sai do servidor com o restic, que a criptografa antes que ela saia. Use um lugar num provedor diferente do servidor: uma conta SFTP (um storage box, um computador em casa) ou um bucket compatível com S3. Se você já faz backup do seu relay assim, use o mesmo lugar com outra pasta.

  1. Instale as ferramentas e crie o repositório. Guarde a senha também no seu gerenciador de senhas: sem ela as cópias não podem ser lidas, e se ela só existir no servidor, morre com o servidor. Para SFTP, o root também precisa de uma chave SSH que a máquina de backup aceite (sudo ssh-keygen -t ed25519 e depois adicione /root/.ssh/id_ed25519.pub lá).

    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. Salve isto como /usr/local/bin/backup-blossom e torne-o executável (sudo chmod 700 /usr/local/bin/backup-blossom). Mude BLOSSOM_DIR se seus arquivos não estiverem em /root/blossom. Ele mantém os últimos 14 dias, 8 semanas e 12 meses. Os blocos nunca mudam, então cada noite só acrescenta o que é novo.

    #!/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. Rode-o uma vez à mão (sudo /usr/local/bin/backup-blossom) e depois agende-o com sudo crontab -e. A segunda linha relê um décimo dos dados guardados a cada mês, um décimo diferente a cada vez, para provar que as cópias ainda podem ser abertas. Olhe o /var/log/backup-blossom.log de vez em quando: uma linha com Fatal significa que a cópia daquela noite falhou. Se o backup do relay é feito na mesma máquina, estes horários não se sobrepõem aos dele.

    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
    

Para restaurar (um servidor novo, ou depois de uma falha de disco): configure o servidor de novo (passos 1 e 2) e repita os pontos 1 e 2 deste passo com o mesmo repositório, mas escreva a senha que você guardou em /root/.restic-blossom-password em vez de criar uma nova, e pule o restic init. Depois copie o backup mais recente para o volume do servidor:

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

Na próxima vez que verificar as cópias, o Drive encontra os blocos de volta e copia dos outros servidores o que tiver chegado depois do último backup. Testamos essa cadeia inteira em 27 de outubro de 2026: backup, servidor apagado, restauração, cada bloco relido com seu próprio hash, e apagado depois com a chave do Drive.

Uma vez por ano, faça essa restauração numa máquina reserva e confira se o servidor responde com seus blocos: é o único teste que prova a cadeia inteira, senha incluída.

Bom saber