Blockchain von einem verschlüsselten Start9-System exportieren

10. Februar 2026 · 6 Min. Lesezeit

Du hast 880.000+ Blöcke auf deinem Start9-Server synchronisiert. Jetzt willst du einen zweiten Bitcoin-Node auf anderer Hardware betreiben — vielleicht ein Raspberry Pi, ein Mini-PC oder ein Laptop — ohne tagelang auf eine neue Synchronisation zu warten.

Die Blockchain liegt direkt auf deinem Start9. Aber sie rauszubekommen ist schwieriger als man denkt.

Das Problem

Start9 (StartOS) verschlüsselt alle Paketdaten mit LUKS. Bitcoins Blockchain liegt tief im verschlüsselten Volume unter:

/embassy-data/package-data/volumes/bitcoind/data/main/

Wenn du dich per SSH als start9-User einloggst, stößt du auf drei Hürden:

Hürde 1: Kein Paketmanager. StartOS blockiert apt. Du kannst weder NFS, noch Samba, noch irgendeinen File-Sharing-Dienst installieren.

Hürde 2: Root-Dateien. Die Blockchain-Daten gehören root (sie laufen in einem Podman-Container). Der start9-User kann sie nicht direkt lesen.

Hürde 3: SSHFS ist zu langsam. Du kannst die Dateien per SSHFS mounten, aber Bitcoins random I/O Muster (Millionen kleiner Lesezugriffe für UTXO-Lookups) funktioniert über SSH miserabel — oft unter 1 MB/s.

Die Lösung: NFS via Podman

Start9 liefert Podman mit (die Container-Runtime für alle Embassy-Dienste). Damit können wir einen NFS-Server im Container starten — kein apt nötig.

            Kernidee: Podman ist auf jedem Start9-System bereits installiert.
            Wir brauchen nur einen leichtgewichtigen NFS-Container, der das
            Blockchain-Verzeichnis exportiert.
        

Schritt für Schritt

Schritt 1: NFS-Kernelmodule laden

Per SSH auf deinem Start9 einloggen und die NFS-Module laden:

ssh start9@deine-start9-ip
sudo modprobe nfs
sudo modprobe nfsd

Diese Module sind im StartOS-Kernel enthalten, aber standardmäßig nicht geladen.

Schritt 2: NFS-Container starten

Ein Befehl erledigt alles:

sudo podman run -d \
  --name nfs-blocks \
  --privileged \
  --network=host \
  -v /embassy-data/package-data/volumes/bitcoind/data/main/blocks:/export/blocks \
  -e NFS_EXPORT_0='/export/blocks 192.168.1.0/24(ro,no_subtree_check,all_squash,anonuid=0,anongid=0)' \
  docker.io/erichough/nfs-server:2.2.1

Das exportiert das Blocks-Verzeichnis read-only in dein lokales Netzwerk. Passe 192.168.1.0/24 an dein Subnetz an.

Schritt 3: Auf dem Zielrechner mounten

Auf deinem Pi, Laptop oder Mini-PC:

sudo apt install -y nfs-common
sudo mkdir -p /mnt/bitcoin-blocks
sudo mount -t nfs -o ro,vers=3 deine-start9-ip:/export/blocks /mnt/bitcoin-blocks

Prüfen ob es funktioniert:

ls /mnt/bitcoin-blocks/blk00000.dat  # Sollte existieren
ls /mnt/bitcoin-blocks/ | wc -l      # Sollte tausende Dateien zeigen

Was kopiert werden muss

Du musst nicht 800 GB Block-Dateien kopieren. Bitcoin speichert drei Arten von Daten, und du brauchst nur zwei kleine davon:

Start9 Bitcoin-Daten ├── blocks/ (~760 GB) ← Auf Start9 lassen, per NFS bereitstellen │ ├── blk*.dat (rohe Blockdaten) │ ├── rev*.dat (Undo-Daten) │ └── xor.dat (Verschleierungsschlüssel, 8 Bytes) ├── blocks/index/ (~215 MB) ← Dies kopieren └── chainstate/ (~11 GB) ← Dies kopieren

Der Block-Index ordnet Block-Hashes Dateipositionen zu. Der Chainstate ist das UTXO-Set — jeder unausgegebene Transaktionsausgang in Bitcoin. Zusammen sind das ~11 GB. Die 760 GB rohen Blockdaten bleiben auf Start9 und werden übers Netzwerk bereitgestellt.

Wichtig: Stoppe Start9s bitcoind vor dem Kopieren des Chainstate. Ein laufender Node ändert ständig die UTXO-Datenbank — Kopieren im laufenden Betrieb ergibt einen korrupten Snapshot.

Daten kopieren

Stoppe den Bitcoin-Dienst auf Start9 (über die Start9-UI oder Kommandozeile), dann per SSH kopieren:

# Vom Zielrechner aus:
SRC=/embassy-data/package-data/volumes/bitcoind/data/main

# Block-Index (klein, schnell)
ssh start9@deine-start9-ip "sudo tar cf - -C $SRC/blocks/index ." | \
  tar xf - -C /pfad/zu/deinem/datadir/blocks/index/

# Chainstate (~11 GB, dauert ~25 Min. über Gigabit)
ssh start9@deine-start9-ip "sudo tar cf - -C $SRC/chainstate ." | \
  tar xf - -C /pfad/zu/deinem/datadir/chainstate/

Vergiss nicht, Start9s Bitcoin-Dienst danach wieder zu starten.

XOR-Verschleierung (xor.dat)

Seit Bitcoin Knots v28+ (und Bitcoin Core) werden Block-Dateien mit einem 8-Byte XOR-Schlüssel verschleiert. Dieser Schlüssel liegt in blocks/xor.dat und wird bei der ersten Synchronisation zufällig generiert.

Das bedeutet: Die blk*.dat und rev*.dat Dateien sind nicht im Klartext gespeichert. Jedes Byte wird mit dem 8-Byte-Schlüssel XOR-verknüpft. Das schützt zwar nicht vor gezieltem Zugriff (der Schlüssel liegt direkt daneben), verhindert aber, dass Virenscanner oder Backup-Programme Bitcoin-Transaktionen als verdächtige Daten erkennen.

Warum das wichtig ist: Der Block-Index speichert Dateipositionen, die auf diese verschleierten Dateien verweisen. Solange dein Ziel-Node die gleichen Block-Dateien liest (per NFS), wird xor.dat automatisch gelesen und alles funktioniert. Du musst xor.dat nicht separat kopieren — es liegt bereits im Blocks-Verzeichnis.

Keine Block-Dateien aus verschiedenen Syncs mischen. Jede unabhängige Synchronisation schreibt Blöcke in einer anderen Reihenfolge und erzeugt einen eigenen XOR-Schlüssel. Ein Block-Index von Sync A funktioniert nicht mit Block-Dateien von Sync B — weder die Dateipositionen noch der Verschleierungsschlüssel stimmen überein.

NFS vs SSHFS: Warum es wichtig ist

Bitcoins Block-Validierung bombardiert den Speicher mit Millionen kleiner zufälliger Lesezugriffe. Der Protokoll-Overhead pro Operation macht einen riesigen Unterschied:

Protokoll Sequentiell Bitcoin Random I/O ───────── ────────────── ────────────────── Lokale SSD 500+ MB/s 100.000+ IOPS NFS 6-7 MB/s ~3 MB/s effektiv SSHFS 5-6 MB/s ~0,5 MB/s effektiv

NFS ist 6x schneller als SSHFS für Bitcoins Zugriffsmuster, weil es nicht den SSH-Verschlüsselungs-Roundtrip pro Operation hat. Für leseintensive Workloads wie Block-Bereitstellung ist NFS der klare Gewinner.

Das Ergebnis

Nach dem Kopieren von ~11 GB Index-Daten (~25 Minuten) und der NFS-Konfiguration startet dein zweiter Node mit einer vollständig validierten Blockchain. Kein Reindex. Kein tagelangtes Warten. Die Blöcke werden übers Netzwerk von Start9 bereitgestellt, und der lokale Chainstate übernimmt die UTXO-Lookups mit voller Geschwindigkeit.

            Gesamte Setup-Zeit: ~50 Minuten

            Kopierte Daten: ~11 GB (nicht 800 GB)

            Neu-Synchronisation nötig: Keine

Persistent machen

Füge den NFS-Mount zur /etc/fstab auf deinem Zielrechner hinzu, damit er Neustarts überlebt:

# /etc/fstab
deine-start9-ip:/export/blocks  /mnt/bitcoin-blocks  nfs  ro,soft,timeo=300,_netdev  0  0

Auf Start9 startet der NFS-Container automatisch neu, wenn du ihn richtig einrichtest. Du kannst auch ein kleines Skript erstellen, das sicherstellt, dass die Kernel-Module geladen und der Container nach einem Neustart läuft.

Sicherheitshinweise

Der NFS-Export ist read-only und auf dein lokales Subnetz beschränkt
Block-Daten sind öffentliche Informationen — es gibt kein Datenschutzrisiko beim lokalen Bereitstellen
Die Chainstate-Kopie enthält keine privaten Schlüssel oder Wallet-Daten
Start9s LUKS-Verschlüsselung schützt die Daten weiterhin im ausgeschalteten Zustand
Die XOR-Verschleierung in xor.dat ist kein Sicherheitsfeature — sie verhindert nur False Positives bei Antivirenprogrammen

Bitcoin auf ungewöhnlicher Hardware betreiben?

Ich helfe bei der Einrichtung von Bitcoin-Nodes auf allem von Banana Pis bis zu verteilten Multi-Maschinen-Setups. Lass uns reden.

Kontakt aufnehmen