Ihr eigener Blossom-Server

Zuletzt aktualisiert: 27. Oktober 2026

Herkos Drive zerlegt jede Datei in verschlüsselte Blöcke und bewahrt sie auf mehreren Blossom-Servern auf: drei Kopien, auf mindestens zwei Arten von Servern, und eine auf einem Server von Ihnen. Öffentliche Server bewahren Blöcke kostenlos auf, aber sie versprechen nichts: Sie können sie löschen, volllaufen oder schließen.

Ein eigener Blossom-Server bewahrt Ihre Kopie so lange auf, wie Sie es bestimmen, und nimmt Blöcke nur von Ihrem Drive an. Diese Seite erklärt, wie Sie einen in drei Schritten einrichten, dazu eine nächtliche Sicherung. Er passt gut zu Ihrem eigenen Postfach-Relay, und es dauert etwa fünfzehn Minuten, wenn Sie bereits einen Server haben.

Welchen Server Sie verwenden sollten

blossom-server von hzrd149, Version 6.4.1 (6. Oktober 2026, MIT-Lizenz). Wir haben ihn am 27. Oktober 2026 mit der Konfiguration unten und dem Upload-Code von Drive selbst betrieben und geprüft, was Drive braucht, nicht, was der Server verspricht:

Was Sie brauchen

• Einen Rechner, der immer eingeschaltet und aus dem Internet erreichbar ist: ein kleiner VPS oder ein Computer zu Hause. Er braucht so viel Speicherplatz, wie Ihr Drive enthält, und etwas Reserve zum Wachsen.
• Eine Domain oder Subdomain, die darauf zeigt, zum Beispiel blossom.example.com.
• Docker und einen Reverse Proxy, der HTTPS bereitstellt. Die Beispiele verwenden Caddy, das sich das Zertifikat selbst besorgt.
• Den Volume-Schlüssel Ihres Drive. Herkos Drive zeigt ihn unter Einstellungen → Server → Dein eigener Server an, als 64 Buchstaben und Ziffern. Es ist nicht der Schlüssel Ihres Profils: Drive lädt nie mit Ihrem Profilschlüssel hoch, daher würde ein Server, der nur Ihren npub akzeptiert, Drive abweisen.

Schritt 1: den Server starten

Legen Sie einen Ordner dafür an, zum Beispiel /root/blossom, und speichern Sie darin diese zwei Dateien. Die erste ist 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: {}

Die zweite ist config.yml. Tragen Sie Ihre Domain bei publicDomain ein und Ihren Volume-Schlüssel dort, wo YOUR-VOLUME-KEY steht:

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

Was das bedeutet: Nur Ihr Volume-Schlüssel darf hochladen oder um Kopien bitten (requirePubkeyInRule), und ein Block wird aufbewahrt, bis Drive ihn löscht. Der Server verlangt in jeder Regel eine Ablaufzeit; 100 years ohne Lesezugriff heißt in der Praxis nie, und Drive liest seine Blöcke ohnehin regelmäßig. Der Port lauscht nur auf dem Rechner selbst (127.0.0.1): Alles läuft über den Proxy. Starten Sie ihn:

cd /root/blossom
docker compose up -d

Schritt 2: HTTPS davorschalten

Mit Caddy lautet die gesamte Konfiguration (/etc/caddy/Caddyfile):

blossom.example.com {
    reverse_proxy 127.0.0.1:3000
}

Wenn derselbe Caddy bereits Ihr Relay bedient, fügen Sie diesen Block unter dem des Relays hinzu. Laden Sie Caddy neu (sudo systemctl reload caddy). Wenn Sie nun https://blossom.example.com im Browser öffnen, sollte eine Antwort kommen, und zwar ein 404: Eine Startseite gibt es absichtlich nicht.

Schritt 3: Herkos Drive Bescheid geben

1. Öffnen Sie in Herkos Drive Einstellungen → Server, fügen Sie https://blossom.example.com hinzu und markieren Sie ihn als Ihren eigenen.
2. Drive fragt ihn vor jedem Hochladen. Von da an bekommt jede neue Datei dort eine Kopie, und die Dateien, die Sie schon hatten, bekommen ihre, wenn Drive das nächste Mal die Kopien prüft.
3. Behalten Sie die anderen Server in der Liste. Ihrer ist eine der drei Kopien, nie die einzige: Wenn er ausfällt, liegen Ihre Dateien weiterhin auf den anderen, und Drive sagt es Ihnen nach einer Woche Funkstille.

Schritt 4: jede Nacht sichern

Wenn Ihr Server stirbt, bemerkt Drive das und gibt den betroffenen Dateien Kopien auf den anderen Servern Ihrer Liste. Aber die Kopie auf Ihrem Server ist die einzige, die von niemand anderem abhängt, und eine nächtliche Sicherung erlaubt Ihnen, sie neu aufzubauen, ohne alles noch einmal über das Internet zu kopieren.

Der Server hält alles im Docker-Volume blossom_data (der Name beginnt mit dem Ordner, in dem die Dateien liegen; prüfen Sie ihn mit docker volume ls): die Blöcke, je eine Datei, und eine kleine SQLite-Datenbank, die festhält, wer welchen Block hochgeladen hat. Blöcke ändern sich nie, aber die Datenbank darf nicht kopiert werden, während in sie geschrieben wird. Deshalb kopiert das Skript alles bei laufendem Server, hält ihn für die wenigen Sekunden an, die das Kopieren der zwischenzeitlichen Änderungen dauert, startet ihn wieder und lädt erst danach die Kopie hoch. Solange er angehalten ist, versucht es Drive einfach etwas später noch einmal.

Die Kopie verlässt den Server mit restic, das sie verschlüsselt, bevor sie hinausgeht. Nutzen Sie einen Ort bei einem anderen Anbieter als dem des Servers: ein SFTP-Konto (eine Storage Box, ein Computer zu Hause) oder einen S3-kompatiblen Bucket. Wenn Sie Ihr Relay bereits auf diese Weise sichern, nutzen Sie denselben Ort mit einem anderen Ordner.

1. Installieren Sie die Werkzeuge und legen Sie das Repository an. Bewahren Sie das Passwort zusätzlich in Ihrem Passwortmanager auf: Ohne es lassen sich die Kopien nicht lesen, und wenn es nur auf dem Server liegt, stirbt es mit dem Server. Für SFTP braucht root außerdem einen SSH-Schlüssel, den der Sicherungsrechner akzeptiert (sudo ssh-keygen -t ed25519, dann /root/.ssh/id_ed25519.pub dort hinzufügen).

   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. Speichern Sie dies als /usr/local/bin/backup-blossom und machen Sie es ausführbar (sudo chmod 700 /usr/local/bin/backup-blossom). Ändern Sie BLOSSOM_DIR, wenn Ihre Dateien nicht in /root/blossom liegen. Es behält die letzten 14 Tage, 8 Wochen und 12 Monate. Blöcke ändern sich nie, deshalb kommt jede Nacht nur Neues hinzu.

   #!/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. Führen Sie es einmal von Hand aus (sudo /usr/local/bin/backup-blossom) und planen Sie es dann mit sudo crontab -e. Die zweite Zeile liest jeden Monat ein Zehntel der gespeicherten Daten zurück, jedes Mal ein anderes Zehntel, um zu beweisen, dass sich die Kopien noch öffnen lassen. Schauen Sie ab und zu in /var/log/backup-blossom.log: Eine Zeile mit Fatal bedeutet, dass die Kopie dieser Nacht fehlgeschlagen ist. Wenn das Relay auf demselben Rechner gesichert wird, überschneiden sich diese Zeiten nicht mit seinen.

   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
   

Wiederherstellen (ein neuer Server oder nach einem Festplattenausfall): Richten Sie den Server erneut ein (Schritte 1 und 2) und wiederholen Sie die Punkte 1 und 2 dieses Schritts mit demselben Repository, schreiben Sie aber das gespeicherte Passwort in /root/.restic-blossom-password, statt ein neues zu erzeugen, und lassen Sie restic init weg. Kopieren Sie dann die neueste Sicherung in das Volume des Servers:

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

Wenn es das nächste Mal die Kopien prüft, findet Drive die Blöcke wieder und kopiert von den anderen Servern alles nach, was nach der letzten Sicherung hinzugekommen ist. Wir haben diese ganze Kette am 27. Oktober 2026 ausprobiert: Sicherung, Server gelöscht, Wiederherstellung, jeder Block mit seinem eigenen Hash zurückgelesen und danach mit dem Schlüssel von Drive gelöscht.

Führen Sie diese Wiederherstellung einmal im Jahr auf einem Ersatzrechner durch und prüfen Sie, dass der Server mit Ihren Blöcken antwortet: Es ist der einzige Test, der die ganze Kette beweist, das Passwort eingeschlossen.

Gut zu wissen

• Nur Ihr Drive kann hochladen. Wer die Adresse eines Blocks kennt, kann ihn herunterladen, wie auf jedem Blossom-Server, aber er ist verschlüsselt: Ohne die Schlüssel in Ihrem Drive ist er nur Rauschen.
• Wenn sich Ihr Volume-Schlüssel ändert (Drive sagt es Ihnen, wenn ein Volume erneuert wird), fügen Sie den neuen als weitere Zeile unter pubkeys hinzu, starten Sie neu (docker compose up -d) und lassen Sie den alten stehen.
• Updates. Lesen Sie das Changelog, ändern Sie die Version in image: und führen Sie docker compose pull und docker compose up -d aus.
• Ihre IP-Adresse. Der Server sieht die Adresse jeder App, die sich mit ihm verbindet, wie jeder Server. Auf Ihrem eigenen Server sind Sie der Einzige, der sie sieht.