So migrieren Sie von ownCloud 10 Classic zu ownCloud Infinite Scale

Beispiel: Stellen Sie sich ein fiktives Designbüro mit 32 Mitarbeitern vor, Cedar Studio, das ownCloud Classic 10 mit LDAP-Verzeichnis, persönlichen Dateibereichen, Gruppenfreigaben, öffentlichen Links und einem externen Projektspeicher nutzt. Das Büro möchte auf ownCloud Infinite Scale (oCIS) umsteigen, ohne davon auszugehen, dass die Daten und Berechtigungen bei der Installation eines neuen Servers übernommen werden. Dieses Beispiel ist rein hypothetisch und stellt keine abgeschlossene Migration dar.

Der von ownCloud dokumentierte Migrationspfad ist eine geführte Migration mithilfe der migrate-to-ocisApp auf dem Classic-Server und occBefehlen. Es handelt sich um eine schrittweise Übertragung auf ein separates, sauberes oCIS-Zielsystem, nicht um ein direktes Upgrade der Classic-Datenbank oder des Datenverzeichnisses. Laut Migrationshandbuch bleibt die Quelle während des größten Teils des Prozesses betriebsbereit, es wird jedoch weder eine kontinuierliche Synchronisierung noch ein unterbrechungsfreier abschließender Delta-Durchlauf beschrieben. Planen Sie vor dem Produktiveinsatz eine kontrollierte Umstellung und bestätigen Sie die Kompatibilität der Quellversionen sowie das abschließende Write-Freeze-Verfahren mit dem ownCloud-Support.

Die folgenden Schritte orientieren sich an der offiziellen Migrationsanleitung für ownCloud Server 11.0 und der Dokumentation zu Authentifizierung und Datensicherung von Infinite Scale 8.2, die am 6. Oktober 2026 verfügbar ist. Befehlssyntax, Umgebungsvariablen und Supportvereinbarungen können sich ändern; überprüfen Sie diese anhand der Dokumentation für Ihre installierten Versionen.

Schritt 1: Inventarisieren Sie die Classic-Instanz und definieren Sie, was „migriert“ bedeutet.

Für Cedar Studio besteht die erste Aufgabe darin, Benutzer, Gruppen, aktivierte und deaktivierte Konten, freigegebene Ordner, Linkfreigaben, externe Einbindungen und alle lokalen Benutzer, die nicht in LDAP vorhanden sind, aufzulisten. Erfassen Sie, welche Teams von welchem ​​Element abhängig sind. Dadurch wird vermieden, dass eine erfolgreiche Übertragung persönlicher Dateien als Beweis dafür gewertet wird, dass alle alten Workflows übertragen wurden.

Laut Migrationsleitfaden können aktivierte Benutzer und Gruppen mit ihren Mitgliedschaften, die Dateien im jeweiligen Benutzerverzeichnis sowie Benutzer-, Gruppen- und Linkfreigaben migriert werden. Die Dateien werden im persönlichen Bereich jedes Benutzers in oCIS abgelegt. Deaktivierte Benutzer und deren Dateien werden nicht migriert. Passwörter und externe Einbindungen werden nicht migriert. Daten in externen Einbindungen und empfangenen Freigaben sind von der Übertragung der persönlichen Dateien ausgeschlossen und müssen separat behandelt werden. Erstellen Sie eine Liste dieser Speicherorte und weisen Sie einen Verantwortlichen für die manuelle Migration zu.

Erfassen Sie auch, ob passwortlose öffentliche Links verwendet werden. Standardmäßig erfordert oCIS ein Passwort für öffentliche Links; solche Classic-Links können unter Umständen nicht migriert werden, wenn die Zielrichtlinie nicht geändert wird. Schwächen Sie diese Richtlinie nicht ab, nur um alte URLs zu erhalten. Entscheiden Sie, ob Linkinhaber stattdessen neue passwortgeschützte Links erstellen sollten. Die Passwörter migrierter passwortgeschützter Links stimmen nicht mit den alten Passwörtern überein, daher sollten Benutzer sie nach der Umstellung zurücksetzen.

Schritt 2: Bereiten Sie ein sauberes oCIS-Ziel und die Migrationsverbindung vor.

Erstellen und testen Sie eine separate oCIS-Instanz, bevor Sie Produktionsdaten übertragen. Laut Migrationsleitfaden müssen beide Systeme ausgeführt werden und voneinander erreichbar sein. Er weist außerdem darauf hin, dass das Zielsystem neu und sauber sein muss: Vorhandene Benutzer oder Daten können mit importierten Inhalten in Konflikt geraten. Sichern Sie die aktuelle Classic-Instanz und erstellen Sie einen Rollback-Plan, der die Verfügbarkeit bis zur Akzeptanz des neuen Dienstes durch die Benutzer gewährleistet.

Für die Migration ist eine von ownCloud bereitgestellte App erforderlich, die auf dem Classic-Server installiert ist. Sie wird im Rahmen einer geführten Migration bereitgestellt; die Dokumentation verweist Administratoren an den ownCloud-Support, um sie zu erhalten. Die App enthält eine eigene rclone-Binärdatei. Verwenden Sie anstelle des dokumentierten Migrationsprozesses für diese App kein beliebiges Marketplace-Paket oder einen nicht zugehörigen Dateikopiervorgang.

Aktivieren Sie auf der oCIS-Seite den auth-appDienst und die Anwendungsauthentifizierungseinstellung. Die Migrationsanleitung erfordert außerdem, dass die Identitätswechselfunktion aktiviert und ein App-Token für den oCIS-Administrator erstellt wird. Die Dokumentation zur Infinite Scale 8.2-Authentifizierungs-App weist ausdrücklich darauf hin, dass die Identitätswechselfunktion für die Migration vorgesehen ist und in einer Produktionsumgebung deaktiviert werden sollte. Behandeln Sie sie als temporäre Migrationseinstellung: Schützen Sie das Token, beschränken Sie den Zugriff darauf und deaktivieren Sie die Identitätswechselfunktion nach Abschluss der Migration. Wenden Sie in einer verteilten Bereitstellung die Einstellungen gemäß der Dokumentation auf den entsprechenden Dienst an.

Für das hypothetische Cedar Studio sollte das oCIS-Zielsystem mit demselben LDAP-Dienst getestet werden, den der Classic-Server verwendet. Bewahren Sie die Anmeldeinformationen im geheimen Mechanismus der Bereitstellung auf, anstatt Bind-Passwörter in den Shell-Verlauf oder ein gemeinsames Runbook einzufügen. Der offizielle ownCloud-Migrationsleitfaden listet die Zielsystemanforderungen auf und verweist auf die ownCloud-Unterstützung für die Migrations-App. Der oCIS 8.2-Auth-App-Leitfaden erläutert App-Token und Identitätswechsel.

Schritt 3: Identitätszuordnung vereinheitlichen und anschließend Bereitschaftsprüfungen durchführen

oCIS muss die Benutzer und Gruppen auflösen können, bevor deren Dateien und Freigaben migriert werden. Cedar Studio verwendet bereits LDAP. Der Administrator von Cedar Studio verbindet oCIS daher mit demselben Verzeichnis, überprüft die Benutzeranmeldung und stellt sicher, dass die Kennungen den gewünschten Konten zugeordnet sind. Die ownCloud-Anleitung nennt eindeutige, gültige E-Mail-Adressen für jeden aktivierten Classic-Benutzer. Für LDAP-basierte Classic-Benutzer werden außerdem das Attribut „username“ (üblicherweise „ uidusername“ samAccountName) und die entsprechenden oCIS-LDAP-Schemaeinstellungen angegeben. Die Attribute müssen mit dem tatsächlichen Verzeichnis abgeglichen werden; Beispielwerte dürfen nicht einfach kopiert werden.

Wenn Classic lokale Konten verwendet, oCIS aber ein externes LDAP-Verzeichnis nutzt, müssen Sie vor der Dateiübertragung entsprechende Benutzer und Gruppen in dieses Verzeichnis erstellen oder migrieren. Benutzer- und Gruppennamen müssen übereinstimmen. Das interne oCIS IDM ist ein eingeschränktes, eingebettetes Verzeichnis, das für kleine Umgebungen oder Tests gedacht ist. ownCloud empfiehlt für den Produktivbetrieb ein echtes LDAP- oder externes Identitätsmanagementsystem. Das offizielle Migrationsverfahren unterstützt keine gemischte Benutzergruppe aus lokalen und LDAP-basierten Classic-Benutzern in einem Migrationszweig. Klären Sie diese Architektur mit dem Support, anstatt währenddessen zu improvisieren.

Sobald die Migrations-App auf Classic installiert und aktiviert ist, passen Sie den dokumentierten Pfad und das Dienstkonto an Ihre Installation an. Die Anleitung verwendet /var/www/ownclouddie www-dataBeispiele:

sudo -u www-data php /var/www/owncloud/occ app:enable migrate_to_ocis
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:init ocis.example.com
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:verify

Der Verifizierungsbefehl prüft, ob aktivierte Benutzer über gültige, eindeutige E-Mail-Adressen verfügen. Beheben Sie gemeldete Probleme, bevor Sie fortfahren, anstatt die Verifizierung zu überspringen. Wenn ein deaktivierter Benutzer migriert werden muss, überprüfen Sie das Konto, aktivieren Sie es vor der Verifizierung in Classic und nehmen Sie es in den Migrationsplan auf. Cedar Studio sollte außerdem die LDAP-Anmeldung bei oCIS mit mehreren repräsentativen Benutzern überprüfen, bevor die Datenübertragung beginnt.

Schritt 4: Schließen Sie den Benutzer- und Gruppenzweig ab und migrieren Sie anschließend Dateien und Freigaben.

Folgen Sie dem Zweig in der offiziellen Anleitung, der Ihrer Identitätskonfiguration entspricht. Wenn Classic-Benutzer lokal arbeiten und das in oCIS integrierte IDM verwenden, umfasst die Anleitung die Migration von Benutzern, die Zuweisung einer oCIS-Rolle und die Migration von Gruppen. Jedem migrierten Benutzer wird eine Rolle zugewiesen; Classic-Rollen werden nicht eins zu eins übernommen, und Classic-Subadministratorrechte haben keine Entsprechung in oCIS. Überprüfen Sie die Administratorzugriffe manuell. Wenn beide Systeme dasselbe LDAP-Verzeichnis verwenden, stellen Sie sicher, dass Benutzer und Gruppen bereits in oCIS verfügbar sind, und folgen Sie dem LDAP-Zweig, anstatt Duplikate zu erstellen.

Sobald Benutzer, Gruppen und Rollen eingerichtet sind, verwenden die dokumentierten Datei- und Freigabebefehle den oCIS-Administratorbenutzernamen als letztes Argument. Das Classic-Administratorkennwort wird interaktiv abgefragt.

sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:files admin
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:shares admin

Führen Sie die Dateiübertragung vor der Freigabeübertragung gemäß der Migrationsanleitung durch. Benutzer, die sich noch nie angemeldet haben und keine Dateien besitzen, oder Benutzer, die in oCIS fehlen, werden beim Dateitransfer übersprungen. Freigaben mit fehlenden Benutzern oder Gruppen können während der Migration als Fehler gemeldet werden. Für Cedar Studio bedeutet dies, dass das Team die Befehlsausgabe und die Freigabeliste überprüfen muss; ein erfolgreicher Abschluss ohne schwerwiegenden Abbruch ist kein Beweis dafür, dass alle Freigaben funktionieren.

Der Migrationsleitfaden weist darauf hin, dass erfolgreiche Schritte nicht einfach wiederholt werden können, ohne die erstellten Zieldaten vorher zu löschen. Ein --forceZurücksetzen der Initialisierung entfernt keine bereits migrierten Dateien aus oCIS. Verwenden Sie Reset-Flags nicht routinemäßig für Wiederholungsversuche. Wenn ein Schritt fehlschlägt, sichern Sie die Protokolle, ermitteln Sie die erstellten Daten und konsultieren Sie den Migrationsleitfaden oder den Support, bevor Sie entscheiden, ob Sie das Ziel reparieren oder mit einem sauberen Ziel neu starten.

Schritt 5: Umstellung mit einem bewussten Validierungs- und Wiederherstellungszeitraum

Für einen sicheren Übergang plant Cedar Studio einen Zeitraum ein, in dem Mitarbeiter keine Dateien in Classic ändern, führt die genehmigte Migration durch und leitet Kunden und Benutzer erst nach erfolgreichen Prüfungen zu oCIS weiter. Diese Schreibsperre dient der Betriebssicherheit und ist kein Beweis dafür, dass die Migrations-App eine Live-Synchronisierung durchführt. Die veröffentlichte Migrationsanleitung dokumentiert weder eine kontinuierliche Synchronisierung noch einen abschließenden Delta-Copy-Befehl. Falls Ihr Unternehmen eine Schreibsperre nicht tolerieren kann, wenden Sie sich bitte an den ownCloud-Support, um einen versionsspezifischen Übergangsplan zu erhalten, bevor Sie einen unterbrechungsfreien Umzug zusichern.

Validierung mit einer Checkliste anstelle eines einzelnen Administrator-Logins:

• Prüfen Sie, ob die erwarteten aktivierten Benutzer, Gruppen und Gruppenmitgliedschaften in oCIS angezeigt werden; prüfen Sie die Rollenzuweisungen, insbesondere für ehemalige Administratoren.
• Benutzer sollen repräsentative migrierte Dateien aus mehreren persönlichen Bereichen öffnen, darunter große Dateien und kürzlich bearbeitete Dokumente.
• Testen Sie interne Benutzerfreigaben und Gruppenfreigaben sowohl mit dem Eigentümer- als auch mit einem Empfängerkonto.
• Öffentliche Links in einer privaten Browsersitzung öffnen; Passwörter für migrierte geschützte Links zurücksetzen und Links neu erstellen, die die Richtlinienprüfung nicht bestanden haben.
• Externe Mounts neu erstellen und die darauf verweisenden Daten separat migrieren oder neu verbinden, dann überprüfen, ob die Benutzer den gewünschten Zugriff haben.
• Bevor Sie die neue Adresse bekanntgeben, prüfen Sie bitte die Desktop- und Mobilclients, die Anmelde- und Synchronisierungsfunktionen sowie den Supportweg für Passwortzurücksetzungen.

Halten Sie Classic in einem kontrollierten, schreibgeschützten oder anderweitig eingefrorenen Zustand, bis der Geschäftsinhaber die Freigabe erteilt und die erforderlichen Datensätze geprüft wurden. Entfernen Sie die temporäre Identitätswechselfunktion und widerrufen Sie das Migrations-App-Token, sobald es nicht mehr benötigt wird. Erstellen und testen Sie anschließend eine oCIS-Sicherung gemäß der für das Speicherlayout vorgesehenen Vorgehensweise. Die offiziellen Sicherungshinweise für oCIS 8.2 besagen, dass die Instanz für die dokumentierte Sicherungsprozedur vollständig heruntergefahren werden muss und erklären, dass Metadaten und Dateiblobs unterschiedliche Speicherpfade haben können.

So sieht eine erfolgreiche Migration aus

Im Beispiel von Cedar Studio bedeutet Erfolg nicht nur, dass die oCIS-Weboberfläche geladen wird. Er bedeutet auch, dass sich Mitarbeiter mit der vorgesehenen Identitätsquelle authentifizieren, ihre Home-Verzeichnisse finden, Teamdateien öffnen und neu erstellte oder migrierte Freigaben mit den erwarteten Berechtigungen nutzen können. Passwortzurücksetzungen, externe Einbindungen und Änderungen an öffentlichen Links werden berücksichtigt, während Classic bis zur Abnahme verfügbar bleibt. Sollte eine dieser Prüfungen fehlschlagen, pausieren Sie die Umstellung, erfassen Sie die betroffenen Benutzer und Objekte und beheben Sie die Lücke, bevor Sie oCIS als neues System verwenden.