So verschieben Sie einen CasaOS-Server auf neue Hardware

Beste Migrationsstrategie: Betrachten Sie CasaOS als drei Ebenen: Host-Betriebssystem, App-Definitionen und persistente Daten. Die Neuinstallation von CasaOS ist der einfache Teil. Entscheidend ist, die von Ihren Containern tatsächlich verwendeten Ordner und Konfigurationen beizubehalten und anschließend dieselben Pfade auf dem neuen Computer erneut zu erstellen.

Vor dem Kopieren inventarisieren

• CasaOS- und Linux-Basisversionen;
• Container-Images, Ports und Umgebungsvariablen;
• alle Quellpfade von Bind-Mounts;
• /DATA/AppData sowie benutzerdefinierte App-Ordner;
• Mountpunkte für Medien- und Datenträger;
• UID/GID-Besitzrechte;
• statische IP, DNS, Proxy, VPN- und Firewall-Regeln.

CasaOS-Store-Apps speichern Daten üblicherweise unter /DATA/AppData/$AppID. Das CasaOS-AppData-Muster zeigt, warum das Kopieren allein eines Docker-Containers keine Migration darstellt.

Schreibintensive Apps vor dem abschließenden Kopieren stoppen

Datenbanken und App-Zustände können sich während des Kopierens ändern. Stoppen Sie die betreffenden Container – oder Docker für die abschließende Synchronisierung –, bevor Sie die letzte Sicherung erstellen.

sudo systemctl stop casaos-app-management
sudo systemctl stop docker

Kopieren Sie anschließend mit einem Tool zur Bewahrung von Metadaten, etwa rsync -aHAX wenn Ihre Dateisysteme dies unterstützen.

Auch benannte Volumes inventarisieren

Einige Apps verwenden Docker-Volumes anstelle von Bind-Mounts des Hosts. Die persistenten Docker-Volumes überdauern Container, müssen aber dennoch gezielt migriert werden.

Speicherpfade zuerst neu erstellen

Binden Sie auf dem neuen Host die Datenträger ein, bevor Sie Apps starten. Wenn Jellyfin zuvor /DATA/Media/MoviesWenn Sie denselben Pfad wiederherstellen, vermeiden Sie dadurch beschädigte Bibliotheken. Wenn sich Pfade ändern, bearbeiten Sie die Container-Zuordnungen vor dem ersten Start.

Numerische Besitzrechte beibehalten

Für Container sind numerische UID/GID-Werte entscheidend. Vergleichen Sie wichtige Verzeichnisse auf alten und neuen Systemen:

stat -c '%u:%g %a %n' /DATA/AppData/*

Stellen Sie die Dienste schrittweise wieder her.

1. Installieren Sie eine unterstützte Linux-Basis.
2. Installieren Sie CasaOS.
3. Binden Sie alle Datenträger ein.
4. Stellen Sie persistente Daten wieder her.
5. Erstellen Sie App-Definitionen neu oder importieren Sie sie.
6. Starten Sie zustandsbehaftete Apps nacheinander.
7. Validieren Sie Datenbanken, Medien, Berechtigungen und Zeitpläne.
8. Wechseln Sie IP/DNS erst, wenn die Tests erfolgreich sind.

Die CasaOS-Docker-Struktur erklärt, warum App-Daten und Container getrennt betrachtet werden. Die Self-Hosting-App-Plattform ist relevant, wenn du zu ZimaOS migrierst, statt CasaOS neu aufzubauen.

Für einen kompakten x86-Ersatz eignet sich ZimaBoard 2 für kleinere Bereitstellungen.

Klassifiziere jede App nach ihrem Zustandstyp

Nicht alle Container werden auf dieselbe Weise migriert:

• Zustandslose Apps: Die Konfiguration kann anhand von Compose/Umgebungsvariablen neu erstellt werden.
• Dateibasierte Apps: Kopiere die per Bind-Mount eingebundenen Ordner.
• SQLite: Stoppe die App, bevor du die Datenbankdatei kopierst.
• PostgreSQL/MySQL: Verwende nach Möglichkeit ein Anwendungs- oder Datenbank-Backup, statt dich ausschließlich auf eine Live-Kopie des Dateisystems zu verlassen.
• Apps mit benannten Volumes: Exportiere das Docker-Volume bewusst oder kopiere es.

Erfasse die aktuelle Docker-Konfiguration

Sichere für jeden wichtigen Container:

docker inspect <container> > container-inspect.json

Dies ist keine direkt importierbare Compose-Datei, sondern dokumentiert Mounts, Ports, Umgebungsvariablen, Netzwerke und Geräte, damit du überprüfen kannst, ob der neu erstellte Dienst mit dem alten übereinstimmt.

Plane die Umstellung von IP-Adresse und Hostnamen

Wenn Clients einen Server-Hostnamen verwenden, ist die Migration einfacher: Verweise DNS nach der Überprüfung auf die neue IP-Adresse. Wenn jede App fest auf die alte IP-Adresse eingestellt ist, kannst du dem neuen Host nach dem Abschalten des alten Servers stattdessen die alte statische Adresse zuweisen.

Lass den alten Server unangetastet, bis ein Rollback nicht mehr erforderlich ist

Lösche die Quelldaten nicht unmittelbar nach der ersten erfolgreichen Anmeldung. Lass den alten Server ausgeschaltet, aber vollständig intakt, bis mindestens ein Backup-Zyklus und eine Phase normaler Nutzung vergangen sind. So hast du eine bekannte funktionierende Rückfalloption, falls eine geplante Aufgabe, Datenbank oder ein Remote-Client übersehen wurde.

Überprüfe die Daten, nicht nur die Container

Ein grüner Docker-Status bestätigt nur, dass der Prozess läuft. Überprüfe:

• Jellyfin-Mediathek und Wiedergabestatus;
• Syncthing-Ordnerstatus;
• Backup-Aufgaben und Wiederherstellungstests;
• Datenbankanwendungen;
• Pfade zu externen Laufwerken;
• Reverse-Proxy-Zertifikate;
• Remote-VPN-/Tunnelzugriff.

FAQ

Kann ich die Bootfestplatte klonen?

Manchmal, aber ein Klon übernimmt hardwarespezifische Annahmen zu Netzwerk, Bootvorgang und Mounts. Ein sauber eingerichteter Host mit wiederhergestellten Daten lässt sich oft leichter überprüfen.

Wann kann ich den alten Server außer Betrieb nehmen?

Erst wenn App-Anmeldungen, Datenbanken, Medienpfade, Berechtigungen, geplante Aufgaben, Backups und der Fernzugriff auf dem neuen Host funktionieren.