Umzug auf einen anderen Server #

Ein Umzug verschiebt eine bestehende Instanz auf neue Hardware oder einen anderen Hoster. Drei Dinge gehören dabei untrennbar zusammen und müssen vom selben Zeitpunkt stammen: das Datenverzeichnis, die Datenbank und config/config.php. Passen sie nicht zusammen, verweisen Metadaten auf Dateien, die es nicht gibt — oder umgekehrt.

Voraussetzungen auf dem Zielserver #

Die alte config/config.php wird übernommen, nicht neu erzeugt. Sie enthält instanceid, passwordsalt und secret. secret ist der Schlüssel, mit dem OC\Security\Crypto gespeicherte Zugangsdaten (Tabelle credentials, etwa für externen Speicher) und Anmelde-Token (Tabelle authtoken) ver- und entschlüsselt. Eine neu erzeugte config.php bedeutet: Alle diese Werte sind unbrauchbar.

1. Wartungsmodus auf dem alten Server #

sudo -u www-data php8.4 /var/www/owncloud.online/occ maintenance:mode --on

Der Befehl setzt maintenance auf true; jede Web-Anfrage wird danach mit HTTP 503 und der Wartungsseite beantwortet. Ein Abmelden erzwingt er nicht, bestehende Sitzungen werden nicht verworfen. occ weist zusätzlich darauf hin, den Webserver anzuhalten — für eine konsistente Sicherung ist das der sichere Weg:

systemctl stop apache2
systemctl stop php8.4-fpm

Ebenso den Cron-Eintrag des alten Servers stilllegen, damit während der Übertragung kein Hintergrund-Job mehr schreibt (siehe Hintergrund-Jobs (Cron)).

2. Sicherung von Datenverzeichnis, Datenbank und config.php #

tar -czf /root/oco-data-$(date +%F).tar.gz /var/owncloud-online-data
mysqldump --single-transaction -u root -p owncloud_online \
  > /root/oco-db-$(date +%F).sql
cp /var/www/owncloud.online/config/config.php /root/oco-config-$(date +%F).php

Im Datenverzeichnis liegen nicht nur die Benutzerdateien, sondern auch versteckte Dateien, die zur Funktion gehören: die Marker-Datei .ocdata, die .htaccess und die index.html aus dem Setup-Schutz sowie — je nach Konfiguration — owncloud.log und bei aktiver Verschlüsselung die Schlüsselverzeichnisse files_encryption/. Bei dbtype sqlite liegt auch die Datenbankdatei selbst dort.

3. Übertragung #

# Benutzerdaten (Berechtigungen und ACLs erhalten)
rsync -aAX /var/owncloud-online-data/ neu.example.com:/var/owncloud-online-data/

# Datenbankdump und die alte config.php
scp /root/oco-db-*.sql neu.example.com:/root/
scp /root/oco-config-*.php neu.example.com:/root/

Auf dem Zielserver einspielen:

mysql -u root -p owncloud_online < /root/oco-db-2026-08-13.sql
cp /root/oco-config-2026-08-13.php /var/www/owncloud.online/config/config.php
chown www-data:www-data /var/www/owncloud.online/config/config.php

Der Anwendungscode wird nicht kopiert, sondern auf dem Zielserver regulär installiert (siehe Leerer Linux-Server) — die dabei frisch erzeugte Datenbank und config.php werden anschließend durch den Dump und die mitgebrachte Datei ersetzt. Eine Ausnahme ist das Verzeichnis apps-external: Dort landen alle über den Markt nachinstallierten Apps (apps_paths, Eintrag mit "writable" => true). Es liegt im Codebaum und ist damit in keiner Datensicherung enthalten.

4. Anpassung der Konfiguration #

Zwei Werte gehören vor den ersten occ-Aufruf in die Datei: der Datenbankzugang und das Datenverzeichnis. Ohne gültigen Datenbankzugang bricht jeder Befehl beim ersten Zugriff ab. Ein falsches datadirectory hält occ dagegen nicht auf — die Verzeichnisprüfung läuft auf der Konsole nicht mit —, jeder Befehl, der Dateien anfasst, arbeitet dann aber am falschen Ort. Beides direkt in config/config.php eintragen:

'datadirectory' => '/var/owncloud-online-data',
'dbhost' => '127.0.0.1',
'dbname' => 'owncloud_online',
'dbuser' => 'owncloud_user',
'dbpassword' => 'CHANGE_ME',

Danach lassen sich die übrigen Werte mit occ setzen:

# neuer Hostname (Index 0 überschreibt den ersten Eintrag,
# ein weiterer Index ergänzt die Liste)
sudo -u www-data php8.4 /var/www/owncloud.online/occ \
  config:system:set trusted_domains 0 --value=cloud.example.com

# Basis-URL für Cron, occ und alle darin erzeugten Links
sudo -u www-data php8.4 /var/www/owncloud.online/occ \
  config:system:set overwrite.cli.url --value=https://cloud.example.com

# Kontrolle
sudo -u www-data php8.4 /var/www/owncloud.online/occ config:list system

Ändert sich zusätzlich der Unterpfad (Webroot), gehört danach ein Lauf für die .htaccess dazu — sie enthält die ErrorDocument-Pfade, die im CLI-Betrieb aus overwrite.cli.url abgeleitet werden:

sudo -u www-data php8.4 /var/www/owncloud.online/occ maintenance:update:htaccess

Steht die Instanz hinter einem Reverse-Proxy, gehören trusted_proxies, overwriteprotocol und gegebenenfalls overwritehost ebenfalls geprüft, siehe Sicherheit und Setup-Warnungen.

5. Rechte setzen #

Der Webserver-Benutzer muss in das Datenverzeichnis schreiben können; das Verzeichnis selbst darf für andere Benutzer nicht lesbar sein — der Server prüft das beim Start und meldet sonst „Dein Daten-Verzeichnis ist von anderen Benutzern lesbar".

chown -R www-data:www-data /var/owncloud-online-data
chown -R www-data:www-data /var/www/owncloud.online
chmod 0770 /var/owncloud-online-data
chmod 0640 /var/www/owncloud.online/config/config.php

6. Dateiverzeichnis neu einlesen #

Das Home-Verzeichnis jedes Kontos steht als absoluter Pfad in der Tabelle accounts (Spalte home). Der Wert wird nur beim Anlegen des Kontos geschrieben; ein späterer user:sync korrigiert ihn nicht. Hat sich der Pfad des Datenverzeichnisses geändert, zeigen diese Einträge also weiter auf den alten Ort. Zuerst prüfen, welche Wurzelverzeichnisse tatsächlich hinterlegt sind:

sudo -u www-data php8.4 /var/www/owncloud.online/occ user:home:list-dirs
sudo -u www-data php8.4 /var/www/owncloud.online/occ user:home:list-users /alter/pfad

Stimmt der Pfad nicht, zieht user:move-home das Home um. Als Argument wird das übergeordnete Verzeichnis angegeben; der Befehl deaktiviert das Konto, kopiert per rsync, trägt den neuen Pfad ein und aktiviert das Konto wieder:

sudo -u www-data php8.4 /var/www/owncloud.online/occ \
  user:move-home alice /var/owncloud-online-data

Zwei Bedingungen des Befehls bestimmen die Reihenfolge des Umzugs: Das bisherige Home muss auf der Platte noch vorhanden sein — sonst bricht er mit „Current user home … does not exist. Not mounted? Non local storage?" ab —, und unter dem Zielverzeichnis darf noch kein gefüllter Ordner des Kontos liegen, sonst meldet er „New user folder … is either not readable or not empty". Liegen die Dateien bereits am neuen Pfad, hilft der Befehl deshalb nicht mehr.

Daraus folgt: Soll sich der Pfad des Datenverzeichnisses wirklich ändern, das Datenverzeichnis zuerst unter dem alten Pfad wiederherstellen, dann Konto für Konto mit user:move-home auf den neuen Pfad umziehen und erst danach datadirectory anpassen. Der Befehl kopiert nur — das alte Home bleibt liegen und muss von Hand gelöscht werden. Auf S3-Primärspeicher verweigert er den Dienst. Am wenigsten Aufwand macht weiterhin der unveränderte Pfad.

Danach den Dateibestand einlesen, damit der Dateicache wieder zum Dateisystem passt:

sudo -u www-data php8.4 /var/www/owncloud.online/occ files:scan --all

Fehlen einzelne Dateien danach weiterhin in der Oberfläche, hilft occ files:scan --all --repair — der Lauf repariert abgehängte Cache-Einträge und dauert deutlich länger.

Anschließend die Reparaturschritte laufen lassen. Sie funktionieren nur im Wartungsmodus; ohne ihn bricht der Befehl mit „Turn on maintenance mode to use this command." ab:

sudo -u www-data php8.4 /var/www/owncloud.online/occ maintenance:repair

Stammt der Datenbankdump aus einem laufenden Betrieb, können Sperreinträge aus abgebrochenen Übertragungen enthalten sein. Das betrifft nur Instanzen ohne memcache.locking: Steht dort Redis, liegen die Sperren im Cache und ziehen gar nicht erst mit um.

sudo -u www-data php8.4 /var/www/owncloud.online/occ maintenance:file-locks --cleanup-expired

7. Wartungsmodus beenden #

sudo -u www-data php8.4 /var/www/owncloud.online/occ maintenance:mode --off
systemctl start php8.4-fpm
systemctl start apache2

Was nicht mitgenommen wird #

Datenverzeichnis, Datenbank und config.php decken die Instanz ab — nicht aber ihre Umgebung. Diese Punkte müssen auf dem Zielserver eigens eingerichtet werden:

Nicht mitgenommen werden dürfen dagegen instanceid, passwordsalt und secret in geänderter Form — sie sind Teil der übernommenen config.php und bleiben unverändert.

Was danach zu prüfen ist #

# Version, Installationszustand
sudo -u www-data php8.4 /var/www/owncloud.online/occ status

# Umgebungsabhängigkeiten (leere Ausgabe = in Ordnung)
sudo -u www-data php8.4 /var/www/owncloud.online/occ check

# Apps vollständig und aktiv
sudo -u www-data php8.4 /var/www/owncloud.online/occ app:list

# Job-Liste mit "Last Run" je Job (ISO-Zeitstempel)
sudo -u www-data php8.4 /var/www/owncloud.online/occ background:queue:status

# Zeitpunkt des letzten Cron-Laufs (Unix-Zeit, sollte frisch sein)
sudo -u www-data php8.4 /var/www/owncloud.online/occ config:app:get core lastcron

# Home-Pfade zeigen auf das neue Datenverzeichnis
sudo -u www-data php8.4 /var/www/owncloud.online/occ user:home:list-dirs

Dazu die Prüfungen, die nur im Betrieb sichtbar werden:

1. Anmeldung über den neuen Hostnamen.
2. Eine Datei hoch- und wieder herunterladen.
3. Einen bestehenden öffentlichen Link öffnen.
4. Externen Speicher öffnen, sofern eingerichtet — dort zeigt sich, ob secret korrekt übernommen wurde.
5. Einen Sync-Client verbinden und eine Änderung in beide Richtungen prüfen.
6. Die Setup-Warnungen unter Einstellungen → Administration → Allgemein durchgehen.

occ maintenance:data-fingerprint gehört nicht zum normalen Umzug. Der Befehl signalisiert allen Clients, dass eine Sicherung eingespielt wurde, und löst dort Konfliktdialoge aus. Er ist nur dann richtig, wenn Sie auf einen älteren Datenstand zurückgegriffen haben.

Sonderfall: Wechsel des Datenbanktyps #

Ein Umzug ist kein guter Anlass, gleichzeitig den Datenbanktyp zu wechseln. Der frühere Befehl db:convert-type ist in dieser Fassung entfernt worden (Changelog: „This experimental command is untested and unsupported and therefore removed."). Eine unterstützte In-Place-Konvertierung gibt es damit nicht.

Praktisch bleiben zwei Wege:

Typ beibehalten. Der Umzug läuft wie oben; nur dbhost, dbname, dbuser und dbpassword ändern sich. Bei dbtype sqlite liegt die Datenbank im Datenverzeichnis und zieht mit dem rsync aus Schritt 3 automatisch um. Für den produktiven Betrieb ist SQLite ungeeignet, siehe Datenbank.

Neu aufsetzen. Eine frische Installation mit dem Zieltyp anlegen …

sudo -u www-data php8.4 /var/www/owncloud.online/occ maintenance:install \
  --database mysql --database-name owncloud_online \
  --database-host 127.0.0.1 --database-user owncloud_user \
  --admin-user admin --data-dir /var/owncloud-online-data

Die Passwörter für Datenbank- und Administratorkonto fragt der Befehl interaktiv ab, wenn --database-pass und --admin-pass fehlen. Anschließend die Benutzerdateien in die Home-Verzeichnisse legen und mit occ files:scan --all einlesen. Der Preis ist hoch und muss vorher bekannt sein: Alles, was ausschließlich in der Datenbank steht, ist danach weg — Freigaben (Tabelle share), Kommentare, Tags, Konten des internen Backends, Konfiguration von externem Speicher sowie sämtliche App-Einstellungen. Auch instanceid, passwordsalt und secret werden neu erzeugt, womit gespeicherte Zugangsdaten und Anmelde-Token ungültig sind. Planen Sie diesen Weg getrennt vom Serverumzug und nicht in derselben Wartung.

Fehlersuche #

Der genaue Grund steht immer im Serverprotokoll, siehe Serverprotokoll und Fehlermeldungen. Der vollständige Ablauf für Sicherung und Rückweg ist unter Backups und Updates beschrieben.