Datenintensive Systeme auf eine andere Software umziehen, ohne dabei Daten zu verlieren oder in tagelange Ausfälle zu laufen – das gehört zu meinem Kerngeschäft. Wie ich dabei vorgehe, zeige ich am liebsten an einem echten Beispiel aus meiner eigenen Infrastruktur: einem Dienst mit rund einem Terabyte an Daten.
Das Beispiel ist zufällig ein Bitcoin-Node. Sie müssen sich für Bitcoin nicht interessieren – das Vorgehen ist identisch mit dem, das ich bei einem Mailserver, einer Datenbank oder einem NAS anwende. Es geht um die Methode, nicht um die Anwendung.
Der Auslöser
Ich habe den Node bisher unter der Software Bitcoin Knots betrieben und bin auf Bitcoin Core gewechselt. Der Grund war eine nüchterne Risikoentscheidung: Neuere Knots-Versionen erzwingen ein neues Regelwerk (BIP-110), das Anfang August 2026 zu einer Abspaltung in eine kaum noch funktionierende Minderheits-Kette geführt hat. Mein Node soll dort bleiben, wo das Ökosystem tatsächlich arbeitet – nicht ein Regel-Experiment mit offenem Ausgang erzwingen. Die schlankere Datenverarbeitung, die ich an Knots schätzte, lässt sich in Core über wenige Konfigurationszeilen ebenfalls setzen. Damit stand fest: Wechsel auf Core – aber ohne das Terabyte neu herunterzuladen.
Und genau da beginnt die eigentliche Arbeit.
1. Erst analysieren, wo die Daten liegen
Der häufigste Fehler bei Migrationen ist, die Software zu tauschen und zu hoffen. Auf der eingesetzten Plattform (Umbrel) sind die alte und die neue Software zwei getrennte Anwendungen mit je eigenem Datenordner. Ein simples „alt weg, neu drauf“ hätte einen kompletten Neu-Download ausgelöst. Wer vorher versteht, wo die Daten physisch liegen, spart sich genau das.
2. Immer mit Rückweg arbeiten
Vor dem ersten Handgriff wird alles gesichert, was Zustand hält (Konfigurationen, Zahlungskanäle). Anschließend werden alle abhängigen Dienste sauber gestoppt – bei mir hingen mehrere Anwendungen am Node –, damit die Datenbank in einem konsistenten Zustand ist. Erst dann wird etwas bewegt. Und die alte Software bleibt so lange installiert, bis der neue Stand nachweislich läuft: Der Umzug muss jederzeit rückgängig gemacht werden können.
3. Umziehen statt neu laden
Statt eines Neu-Downloads wird der vorhandene Datenordner von der alten in die neue Anwendung verschoben.
⚠️ Warnung – bitte nicht blind übernehmen. Der folgende Befehl enthält ein unwiderrufliches Löschen (
rm -rf) des Ziel-Datenordners. Ein falscher Ordnername vernichtet Daten. Führen Sie das nur bei vollständig gestoppten Diensten aus und kontrollieren Sie vorher mitls umbrel/app-data/die tatsächlichen Ordnernamen auf Ihrem System.
cd umbrel/app-data/ && sudo rm -rf bitcoin/data/ && sudo mv bitcoin-knots/data/ bitcoin/ && sudo rm -f bitcoin/data/app/bitcoin-config.jsonDer Befehl entfernt den leeren neuen Datenordner, verschiebt die vorhandenen Daten hinüber und löscht die mitgezogene Alt-Konfiguration, damit die neue Software ihre eigene erzeugt. Danach startet der Dienst – und beginnt eben nicht bei null, sondern steht sofort auf aktuellem Stand. Aus einem potenziellen Tage-Projekt werden wenige Minuten Ausfallzeit.
4. Verifizieren statt vertrauen
Für mich ist eine Migration erst „fertig“, wenn ich nachgewiesen habe, dass sie funktioniert – nicht, wenn der Dienst startet:
- Läuft wirklich die neue Software? Versionsabfrage direkt am Dienst, nicht nur im Dashboard.
- Greift die gewünschte Konfiguration? Über den Status des Dienstes gegengeprüft, statt sie anzunehmen.
- Ist der Dienst von außen erreichbar? Extern getestet. Hier lauert ein Klassiker: Ein „aktiviert“-Schalter in der Oberfläche öffnet noch keinen Port in der Server-Firewall. Erst der externe Test bestätigt, was intern konfiguriert ist.
- Logs richtig einordnen. Das meiste, was nach „Fehler“ aussieht, ist harmloses Betriebsrauschen. Zu wissen, welche Meldung ignorierbar ist und welche nicht, ist der Unterschied zwischen Panik und Diagnose.
Für Techniker: meine Filterregeln in Bitcoin Core
Die schlankere Mempool-Policy, die ich früher an Knots schätzte, setze ich in Bitcoin Core über wenige Zeilen in der Konfiguration:
datacarrier=1
datacarriersize=83
permitbaremultisig=0datacarriersize=83 begrenzt eingebettete Daten (OP_RETURN) wieder auf das klassische ~80-Byte-Limit – Core lässt seit Version 30 sonst bis zu 100.000 Byte zu. permitbaremultisig=0 lehnt zusätzlich bare Multisig ab, einen alten Vektor zum Einbetten von Daten. Wichtig: Das ist reine lokale Relay-Policy, kein Eingriff in die Konsensregeln. Der Node bleibt voll kompatibel mit allen anderen und entscheidet nur für sich, was er in den Mempool aufnimmt und weiterreicht. Cores Filter sind bewusst schmäler als die von Knots – für meinen Zweck reichen sie, ohne das Split-Risiko der Knots-Regel in Kauf zu nehmen.
Was das für Ihre Systeme bedeutet
Ein Software-Wechsel bei datenintensiven Diensten muss keinen Neuaufbau bedeuten, wenn man weiß, wo die Daten liegen. Backup und Rückweg gehören zu jeder Migration, und ein Dienst gilt erst als migriert, wenn er verifiziert ist – Erreichbarkeit, Konfiguration und Version werden nachgewiesen, nicht vermutet.
Ob Node, Mailserver, Datenbank oder ein ganzer Server: Wenn bei Ihnen ein System umziehen muss und Sie dabei kein Risiko eingehen wollen, übernehme ich das für Sie – methodisch, dokumentiert und ohne Datenverlust.
