Linux-Desktop und Datenmigration zwischen Computern

Hinweis: Dieser Beitrag erschien zuerst im Blog von Jiří Eischmann und wurde hier mit seiner freundlichen Genehmigung übersetzt und publiziert.

Vor einem Monat bekam ich einen neuen Arbeitslaptop und überlegte, wie ich Daten von einem auf den anderen übertragen könnte. Zum ersten Mal machte ich den Übergang zwischen zwei Computern, auf denen Silverblue läuft, und ich fand heraus, dass eine "Wow"-Migration, bei der sowohl Anwendungen als auch deren Daten verschoben werden, eigentlich gar nicht so schwer zu erreichen ist.

Es gibt eine Reihe von individuellen Ansätzen für die Migration von Daten zwischen Computern. Ich kenne Leute, die den Inhalt einer ganzen Festplatte mit rsync auf einen neuen Computer übertragen. Aber für mich ist ein neuer Computer auch eine Art Neuanfang. Ich verwalte Computer, auf denen dieselbe Fedora-Installation schon seit 10 Jahren läuft, zahlreiche Upgrades erhalten hat und immer noch einwandfrei funktioniert. Aber ich denke, es hat keinen Sinn, an der Lebensdauer der Installation herumzubasteln, und ein neuer Computer verdient eine neue Installation. Ich nehme dies auch zum Anlass, den Computer von Arbeitsdateien zu befreien, die ich zurücklassen kann.

Daher ist für mich der Ausgangspunkt für die Datenmigration ein sauber installiertes System. Silverblue hat den Vorteil, dass das neu installierte System auch sehr nahe an dem des alten Computers liegt. Zumindest versuche ich, mich an die Idee eines unveränderten Basis-Images zu halten und so wenig eigene Änderungen wie möglich vorzunehmen. Bei einem klassischen Paketsystem hingegen hat man nach ein paar Jahren ein einzigartiges Betriebssystem-Image, das auf einem neuen Rechner nicht ganz trivial zu reproduzieren ist.

Wenn du alle deine Anwendungen als Flatpak hast, ist es einfach, sie zu migrieren. Du kannst eine Liste davon in einer Datei auf dem ursprünglichen Computer speichern und diese als Input für die Installation von Flatpak auf dem neuen Computer verwenden. Noch einfacher ist es bei einzelnen Anwendungsdaten. Sie sind nicht im Home-Verzeichnis verstreut, sondern befinden sich nur in ~/.var/app. Verschiebe einfach dieses Verzeichnis auf einen neuen Rechner. Wenn du dann die neu installierte Anwendung öffnest, hat sie die gleichen Einstellungen und Daten wie die Anwendung auf dem alten Computer.

Silverblue macht es auch einfacher, Entwicklungsumgebungen zu verschieben. Da man normalerweise nicht auf das System selbst schreiben kann, findet die Arbeit in der Regel in Containern statt. In Silverblue ist toolbx für diese Arbeit bereit. Dabei handelt es sich um nichts anderes als Podman-Container, die für die Arbeit auf dem Desktop konfiguriert sind. Podman ermöglicht es, Container als Images zu speichern und sie als tar zu exportieren und zu importieren, sodass man sie einfach auf dem alten Rechner exportieren, auf den neuen Rechner verschieben und importieren kann. Man hat sofort die alte vertraute Umgebung, in der man die erforderlichen Pakete, Einstellungen usw. installiert hat.

Das Verschieben anderer Benutzerdaten in das Home-Verzeichnis kann dann z.B. mit rsync einfach durchgeführt werden. Die Migration von einem alten Computer auf einen neuen ist mit Silverblue wirklich nicht schwer. Da ich das nicht nur für mich mache, sondern auch für andere Leute, deren Computer ich verwalte, wäre es praktisch, wenn das alles automatisiert wäre. Starte es, gibt einige Daten ein, wähle aus, was verschoben werden soll, und lass ein Skript die Arbeit machen.

Ich habe nachgeschaut, ob es so etwas gibt, aber ich war überrascht, nichts zu finden. Viele Leute haben ihre eigenen Migrationsskripte, aber die sind in der Regel der Weg des geringsten Supports: hart kodierte Pfade, Namen oder sogar Passwörter, sodass man sie gar nicht weitergeben sollte, und woanders würde es sowieso nicht funktionieren.

Vor einiger Zeit haben wir sogar in unserem Team darüber nachgedacht, eine Art Migrationswerkzeug zu entwickeln. Idealerweise eines, das die ausgewählten Daten kontinuierlich irgendwo auf dem Server speichert und von einem anderen Fedora-Rechner aus leicht wiederherstellbar machen würde. Die vorherrschende Meinung in der Community war, dass systemd-homed mit verschlüsselten Home-Verzeichnissen, die frei zwischen den Systemen verschoben werden können, dies elegant lösen würde. Jedoch sprang niemand an Bord und die Idee wurde schließlich von anderen Prioritäten überlagert. Aber selbst nach all diesen Jahren ist systemd-homed immer noch ein Experiment, das nicht annähernd in einer regulären Linux-Distribution eingesetzt wird.

Also beschloss ich, diese Idee in Form eines eigenen kleinen Projekts etwas näher zu untersuchen. Im Idealfall würde ich gerne eine schöne Desktop-Anwendung dafür erstellen, aber das übersteigt derzeit meine Fähigkeiten und meine Zeit, die ich dafür aufwenden kann. Deshalb habe ich mich für den Weg über Shell-Skripte entschieden, der zwar weniger benutzerfreundlich ist, aber die Arbeit auch erledigt und mich viel schneller ans Ziel bringt.

Ich habe eine erste Version veröffentlicht, die das Wesentliche kann: Sie kann Daten in XDG-Verzeichnissen (Dokumente, Bilder, Videos, Downloads...) migrieren, Anwendungen in Flatpak neu installieren und die Daten dieser Anwendungen verschieben. Bis jetzt ist das Skript recht kurz, aber da es auf jedem Rechner funktionieren soll (ich konzentriere mich auf Silverblue, aber im Moment sollte es mit so ziemlich jeder modernen Desktop-Distribution funktionieren), wächst der Zeitaufwand dafür. Das Skript ist so konzipiert, dass es nur in der ersten Phase interaktiv ist. Es fragt die notwendigen Daten ab und benötigt dann keine Eingaben.

Der ursprüngliche Entwurf sah vor, dass das Skript auf dem Ausgangscomputer ausgeführt wird und die Daten auf den neuen Computer überträgt. Allerdings stieß ich auf eine Einschränkung, mit der ich ursprünglich nicht gerechnet hatte. "flatpak install" erfordert keine Administratorrechte, sondern nur im Falle eines lokalen Benutzers. Wenn man versucht, es über ssh auszuführen, benötigt man sudo, was für ein nicht-interaktives Skript ein ziemliches Problem darstellt, wenn es sudo für eine Operation benötigt, die es über ssh auf einem entfernten Rechner durchführt. Ich habe das Problem schließlich gelöst, indem ich das Skript auf dem Zielcomputer ausgeführt habe. Dies löste nicht nur das Problem, sondern erwies sich insgesamt als die bessere Idee, da es mir half, den Code an anderen Stellen zu vereinfachen, und auch das Testen vereinfachte, da ich nun alles als Zielgerät verwenden kann, sogar einen Container, ohne herausfinden zu müssen, wie ich über ssh auf ihn zugreifen kann.

Ein weiteres Problem, auf das ich gestoßen bin, war, dass "flatpak install" mit einem Fehler endete, wenn es auf ein bereits installiertes Flatpak stieß. Normalerweise sollte es sich so verhalten, dass es dieses einfach überspringt und mit der Installation der anderen fortfährt. Ich habe nun von den Flatpak-Entwicklern erfahren, dass dies passieren kann, wenn das installierte Flatpak aus einem anderen Repository stammt als das, aus dem ich installiere. Und genau das ist mein Fall. Silverblue hat mehrere Flatpaks aus Fedora-Repositories vorinstalliert, und das Skript installiert sie aus Flathub. Der Workaround ist der Parameter -reinstall, der die bereits installierten Flatpacks mit denjenigen aus Flathub neu installiert. Die Lösung wäre wahrscheinlich eine Funktion, die die Flatpacks eines nach dem anderen installiert, indem sie zuerst prüft, ob eines bereits installiert ist, bevor sie versucht, es zu installieren. Aber das hat für mich noch keine Priorität, zumal ich mit dem jetzigen Verhalten besser zurechtkomme.

Ich verwende rsync für das eigentliche Verschieben von Daten. Aus irgendeinem Grund hatte ich den Eindruck, dass rsync auf Silverblue nicht vorinstalliert ist, also habe ich ursprünglich sftp verwendet. Aber als ich herausfand, dass rsync tatsächlich verfügbar ist, bin ich gerne darauf umgestiegen.

Die erste Version ist fertig, sie kann zuverlässig die grundlegenden Funktionen ausführen, die ich mir vorgenommen habe. Für die Zukunft plane ich, an seiner Robustheit zu arbeiten (Behandlung von Eingaben, Behandlung von Fehlern bei einzelnen Operationen) und weitere Dinge hinzuzufügen: Migration anderer Verzeichnisse, Toolbx-Container, persönliche Zertifikate, Neuinstallation von Paketen in das Overlay-System-Image usw.

Ich mache das Skript in erster Linie für meinen eigenen Gebrauch, aber wenn jemand anderes es verwendet, entweder als Ganzes oder als Basis für sein eigenes Migrationstool, würde ich mich freuen. Ich würde mich auch über Feedback und jegliche Beiträge in Form von Code freuen. 😉

P.S. Ich habe Codeberg.org, die europäische Alternative zu Github, als Heimat für das Projekt gewählt. Hauptsächlich, weil ich den Dienst ausprobieren wollte. Bisher bin ich damit zufrieden (abgesehen von den schrecklichen englischen Übersetzungen) und ich habe nichts gefunden, was ich vermisse, aber mir ist klar, dass jeder auf Github ist. Wenn das Projekt einige Leute anziehen würde, die bereit sind, dazu beizutragen, und Codeberg ein Problem für das Projekt wäre, hätte ich wahrscheinlich kein Problem damit, es zu verschieben oder zu spiegeln.

Quelle: https://blog.eischmann.cz/2023/08/21/linuxovy-desktop-a-migrace-dat-mezi-pocitaci/