Warum überhaupt migrieren? Die Grenzen von SQLite

SQLite ist eine bewundernswerte Engine. Sie benötigt keinen separaten Serverprozess, speichert alles in einer einzigen Datei und ist für viele Anwendungsfälle erstaunlich leistungsfähig. Nextcloud nutzt sie als Standard, um die Erstinstallation maximal zu vereinfachen. Für den Produktiveinsatz in einer wachsenden Umgebung stößt sie jedoch an klare Grenzen.

Das fundamentale Problem ist die fehlende echte Client-Server-Architektur. Jeder Lese- und Schreibzugriff erfordert exklusiven Zugriff auf die Datenbankdatei. Bei parallelen Anfragen – und eine aktive Nextcloud-Instanz erzeugt Dutzende gleichzeitiger Requests – müssen diese serialisiert werden. Das führt zu Wartezeiten und Performance-Einbrüchen unter Last, die sich direkt in langsameren Seitenladzeiten für die Nutzer übersetzen. Zudem fehlen fortgeschrittene Optimierungen eines vollwertigen Datenbankservers: komplexe Abfrageoptimierer, ausgefeilte Indizierungsstrategien und ein ausgereiftes Transaktions- und Locking-Management.

Ein praktisches Beispiel: Die Suche nach einer Datei in einem großen, gut gefüllten Dateibereich. Während MariaDB oder PostgreSQL solche Joins über mehrere Tabellen hinweg effizient ausführen, kann SQLite hier ins Stocken geraten. Nicht zuletzt ist die Betriebssicherheit ein Argument. Professionelle Datenbankserver bieten point-in-time Recovery, Replikation für Ausfallsicherheit und wesentlich robustere Mechaniken gegen Datenkorruption bei unerwarteten Abstürzen.

Die Wahl der neuen Engine: MariaDB/MySQL vs. PostgreSQL

Nextcloud unterstützt offiziell zwei Familien von Datenbankservern: MariaDB (bzw. dessen direkten Verwandten MySQL) und PostgreSQL. Die Entscheidung zwischen beiden ist oft eine Glaubensfrage, hat aber praktische Konsequenzen.

MariaDB/MySQL ist der weit verbreitetste Weg. Die Integration ist seit Jahren eingespielt, die Community kennt die typischen Fallstricke, und viele Hosting-Umgebungen sind standardmäßig darauf ausgelegt. Die Performance ist allgemein sehr gut, besonders für typische Lese-lastige Workloads. Ein interessanter Aspekt ist, dass Nextcloud historisch gewachsen oft eine leicht MySQL-lastige Syntax verwendet, was die Migration manchmal einfacher gestaltet.

PostgreSQL hingegen genießt unter Datenbank-Puristen einen hervorragenden Ruf aufgrund seiner strikten ACID-Compliance, seiner mächtigen und standardkonformen SQL-Implementierung und fortgeschrittener Datentypen. Für komplexe Datenstrukturen und Anwendungen mit hohen Anforderungen an Datenintegrität wird es häufig bevorzugt. Nextcloud unterstützt es vollumfänglich, und in einigen Szenarien, besonders bei sehr vielen gleichzeitigen Schreibzugriffen, kann dessen MVCC- (Multi-Version Concurrency Control) Modell Vorteile bieten.

Praktisch betrachtet: Wenn Ihr Team bereits Erfahrung mit einer der beiden Technologien hat, oder Ihre Infrastruktur einen von beiden bevorzugt, ist das ein starkes Argument. Die reine Nextcloud-Performance unterscheidet sich im Alltag für die meisten Installationen kaum. Wichtiger ist die korrekte Konfiguration der gewählten Engine.

Vorbereitung ist alles: Der Plan vor dem Umzug

Eine Migration in der Produktion ist kein „Try-and-Error“-Projekt. Sie erfordert einen präzisen Plan, der Ausfallzeiten minimiert und ein sicheres Rollback ermöglicht. Der erste, nicht verhandelbare Schritt ist ein vollständiges und getestetes Backup. Das bedeutet: Ein Snapshot des gesamten Servers inklusive Datenpartition, falls möglich. Zusätzlich ein export der SQLite-Datenbank via Kommandozeile und – ganz wichtig – ein konsistenter Dateisystem-Export aller Nextcloud-Daten (dem `data/`-Verzeichnis). Die `occ`-Wartung sollte vorher in den Modus `maintenance:mode –on` versetzt werden, um während der Sicherung keine Änderungen zuzulassen.

Als nächstes muss die Ziel-Datenbank vorbereitet werden. Auf dem Zielserver (der derselbe sein kann wie der Nextcloud-Server) installieren Sie MariaDB oder PostgreSQL und konfigurieren eine leere Datenbank mit einem dedizierten Benutzer und den nötigen Rechten. Achten Sie hier bereits auf die Zeichensatzeinstellung (`utf8mb4` für MariaDB/MySQL ist Pflicht, um Emojis und alle Unicode-Zeichen korrekt zu speichern). Notieren Sie sich Zugangsdaten, Hostnamen und Port.

Ein oft übersehener, aber kritischer Punkt: Stellen Sie sicher, dass die PHP-Module für die *neue* Datenbank (`php-mysql` oder `php-pgsql`) auf dem Nextcloud-Server installiert und aktiviert sind, gleichzeitig aber die Module für SQLite (`php-sqlite3`) *nicht* deaktiviert werden. Sie werden sie für den Migrationsvorgang noch benötigen. Ein Neustart des PHP-FPM-Dienstes oder des Apache-Webservers ist danach fällig.

Testen Sie den leeren Datenbankzugriff von der Nextcloud-Maschine aus. Ein kleines Skript oder manueller Login mit den Credentials schafft hier Sicherheit. Nun kann die eigentliche Migration beginnen.

Kernprozess: Der Datenbank-Transfer im Detail

Nextcloud bietet einen integrierten Mechanismus für die Konvertierung des Datenbank-Backends. Dies geschieht über den `occ`-Befehl `db:convert-type`. Dieser Befehl ist das Schweizer Taschenmesser für den Umzug. Er erwartet, dass die Nextcloud-Instanz im Wartungsmodus ist und mit der aktuellen SQLite-Datenbank funktioniert.

Der grundlegende Aufruf sieht so aus (Beispiel für MariaDB):

sudo -u www-data php occ db:convert-type --all-apps mysql nextclouduser localhost nextclouddb

Das Tool fordert interaktiv nach dem Passwort für den Datenbankbenutzer. Es beginnt dann, das komplette Schema in der Ziel-Datenbank anzulegen und alle Daten zeilenweise aus der SQLite-Tabellen zu extrahieren und in die neuen Tabellen zu importieren. Bei großen Instanzen mit mehreren hunderttausend Dateien und Aktivitätseinträgen kann dies Stunden dauern. Die Prozess ist single-threaded, also brauchen Sie Geduld.

Für PostgreSQL ist der Befehl analog, nur der Typ ist `pgsql`. Während des Imports sollten Sie die Log-Ausgabe im Auge behalten. Fehler treten typischerweise bei der Verarbeitung bestimmter App-Tabellen auf, wenn es Inkompatibilitäten in den Datentypen gibt. Hier kann es notwendig werden, eine störende App vorübergehend zu deaktivieren oder sogar zu deinstallieren. Die gute Nachricht: Die Core-Tabellen von Nextcloud selbst sind robust und gut getestet.

Ein manueller, aber manchmal notwendiger Alternativweg ist der Export und Import per `mysqldump` oder `pg_dump`. Dazu muss die SQLite-Datenbank zunächst in ein generisches SQL-Format gebracht werden (z.B. mit dem Tool `sqlite3 .db .dump`). Dieses Dump-File bedarf jedoch meist einer manuellen Nachbearbeitung, da die SQL-Dialekte sich in Details unterscheiden. Dieser Weg ist fehleranfälliger, aber bei exotischen Problemen mit `occ db:convert-type` die letzte Rettung.

Fallstricke und Troubleshooting: Wenn es nicht glatt läuft

Trotz bester Vorbereitung kann es zu Problemen kommen. Ein Klassiker ist der Zeichensatz. MySQL/MariaDB haben eine lange, verwirrende Geschichte mit `utf8` (das nur 3 Byte pro Zeichen unterstützt) und `utf8mb4` (das echte UTF-8 mit 4 Byte ist). Nextcloud benötigt zwingend `utf8mb4`. Wenn die Zieldatenbank oder die Tabellen mit `utf8` erstellt wurden, scheitern Einfügeoperationen für Emojis oder spezielle Zeichen mit einem Fehler. Die Abhilfe: Datenbank und Tabellen-Collation vor der Migration korrekt setzen.

Ein weiterer häufiger Fehler sind Timeouts während des langen Importvorgangs. Die PHP-Konfiguration (`max_execution_time`) und die Datenbank-Konnektor-Einstellungen können den Prozess abbrechen, wenn sie zu niedrig sind. Bei großen Migrationen sollte man diese Werte temporär erhöhen oder besser: den Import von der Kommandozeile via `occ` durchführen, der sich nicht an das Web-Server-Timeouts hält.

Speicher ist ebenfalls ein Thema. Sowohl der Export als auch der Import brauchen RAM. Bei sehr großen Instanzen kann der PHP-Speicherlimit (`memory_limit`) gesprengt werden. Ein Blick in die Systemlogs (`/var/log/syslog`, `journalctl`) und die Nextcloud-`data/nextcloud.log`-Datei gibt oft Aufschluss. Nach einer fehlgeschlagenen Migration muss die Zieldatenbank komplett geleert (DROP) und neu angelegt werden, bevor ein neuer Versuch startet. Ein halb importiertes Schema führt garantiert zu Folgefehlern.

Interessant ist auch das Verhalten von Indizes. Die `occ`-Methode baut Indizes oft erst am Ende des Datenimports auf, was den Prozess beschleunigt. Nach der Migration sollten Sie dennoch prüfen, ob alle wichtigen Indizes vorhanden sind. Mit `occ db:add-missing-indices` kann Nextcloud fehlende Indizes nachträglich hinzufügen, was die Performance nach dem Umzug noch einmal spürbar verbessern kann.

Nach der Migration: Konfiguration, Tests und Optimierung

Ist der Import erfolgreich durchgelaufen, ändert Nextcloud automatisch die Konfiguration in `config/config.php`. Der Eintrag `’dbtype’` wechselt von `’sqlite3’` zu `’mysql’` oder `’pgsql’`. Die Zugangsdaten werden hier hinterlegt. Ein manueller Check dieser Datei ist ratsam. Anschließend kann der Wartungsmodus deaktiviert werden:

sudo -u www-data php occ maintenance:mode --off

Nun kommt der kritische Test: Prüfen Sie die Web-Oberfläche. Melden Sie sich mit einem Admin- und einem Testbenutzer-Account an. Öffnen Sie die Dateiliste, die Aktivitätsübersicht, die geteilten Links. Testen Sie die Synchronisation eines Clients. Überwachen Sie dabei die Log-Dateien auf Fehler. Besonders heikel sind oft benutzerdefinierte Spalten in der Dateitabelle, die von einigen Apps hinzugefügt wurden. Diese sollten vom Migrationsskript mit übernommen worden sein, aber manchmal benötigen die Apps selbst ein Update oder eine Neuinstallation.

Die eigentliche Arbeit beginnt jetzt erst: die Optimierung der neuen Datenbank. Die Standardkonfiguration von MariaDB/MySQL oder PostgreSQL ist selten für Nextcloud optimiert. Anpassungen in `my.cnf` oder `postgresql.conf` sind nötig. Wichtige Stellschrauben sind der InnoDB-Puffer (bei MariaDB), der für das Caching von Tabellen- und Indexdaten zuständig ist, und die Anzahl der erlaubten Verbindungen (`max_connections`), die bei aktiven Nextcloud-Instanzen höher sein sollte als der Default. Für PostgreSQL sind `shared_buffers` und `work_mem` zentrale Parameter.

Ein einfacher, aber wirksamer Schritt ist das Analysieren der Tabellen nach dem großen Datenumzug. In MariaDB/MySQL hilft ein `ANALYZE TABLE`; in PostgreSQL `ANALYZE;`. Dies hilbst dem Abfrageplaner, statistisch korrekte Entscheidungen zu treffen. Auch das Durchführen der Nextcloud-eigenen Wartungsroutinen via `occ db:add-missing-indices` und `occ db:add-missing-primary-keys` ist jetzt sinnvoll.

Performance-Vergleich: Was bringt der Wechsel wirklich?

Nach einer erfolgreichen Migration stellt sich die Frage: Hat es sich gelohnt? Die Erfahrung aus zahlreichen Projekten zeigt ein klares Ja – vorausgesetzt, die Ziel-Datenbank ist richtig konfiguriert. Die offensichtlichste Verbesserung zeigt sich unter paralleler Last. Während SQLite bei 20 gleichzeitigen Web-Anfragen oft in die Knie geht, bleibt MariaDB/PostgreSQL hier völlig entspannt. Seitenladzeiten, besonders in der Files-App mit vielen Einträgen, verbessern sich teils drastisch.

Ein konkreter, messbarer Unterschied liegt in der Handhabung der `oc_filecache`-Tabelle, dem Herzstück der Nextcloud-Dateimetadaten. Komplexe rekursive Abfragen für Berechtigungen oder Suche werden von den vollwertigen Datenbankservern deutlich effizienter ausgeführt. Auch Hintergrund-Jobs, wie die Verarbeitung der Aktivitäts-Streams oder das Versenden von Benachrichtigungen, werden beschleunigt, da sie nicht auf den exklusiven Lock einer SQLite-Datei warten müssen.

Langfristig betrachtet ist die größte Errungenschaft jedoch die Skalierbarkeit. Mit einer Client-Server-Datenbank können Sie, wenn nötig, den Datenbankserver auf eine separate Maschine auslagern (Trennung von App- und DB-Layer). Sie können Read-Replicas für Lastverteilung einrichten oder fortgeschrittene Hochverfügbarkeits-Cluster für die Datenbankebene aufbauen. Diese Optionen sind mit SQLite schlicht nicht existent. Sie wandeln mit der Migration also von einer monolithischen zu einer entkoppelten, service-orientierten Architektur – zumindest auf der Datenebene.

Fortgeschrittenes Szenario: Migration im laufenden Cluster-Betrieb

Die bisher beschriebene Migration geht von einer klassischen Einzel-Server-Installation aus. Was aber, wenn Nextcloud bereits in einer hochverfügbbaren Cluster-Konfiguration läuft, nur eben mit SQLite? Das ist ein Sonderfall, der eine abgewandelte Strategie erfordert. Ein direktes `occ db:convert-type` auf einem Cluster-Knoten wird nicht funktionieren, da die SQLite-Datenbank nicht über Knoten hinweg konsistent ist.

In diesem Fall muss der Cluster zunächst „eingefroren“ werden. Ein Knoten wird als primärer Migrationsknoten bestimmt und von den Load-Balancern genommen. Auf diesem Knoten wird die Migration wie beschrieben durchgeführt. Anschließend muss die neue, leere Datenbank auf allen anderen Knoten der Cluster-Umgebung verfügbar gemacht werden – typischerweise durch Replikation vom neuen primären Datenbankserver aus.

Die große Herausforderung ist die Synchronisation der *Dateien*. Während der Migration des primären Knotens laufen auf den anderen Knoten unter Umständen noch Schreibvorgänge in deren lokale SQLite-Datenbank und das geteilte Dateisystem (z.B. NFS oder S3). Hier ist ein konsistenter Stopp des gesamten Clusters für das Migrationsfenster meist unumgänglich. Nach der Migration der Datenbank müssen die `config.php`-Dateien auf allen App-Servern angepasst werden, um auf die neue zentrale Datenbank zu zeigen. Dies unterstreicht, wie sehr SQLite den Aufbau einer horizontal skalierbaren Architektur von vornherein behindert.

Rückschritt und Rollback: Die Sicherheitsleine

Jede Migrationsanleitung wäre unvollständig ohne ein klares Rollback-Konzept. Was tun, wenn Stunden nach der Migration schwerwiegende, unvorhergesehene Fehler auftauchen? Der goldene Rettungsanker sind die zuvor erstellten Backups.

Das Rollback-Szenario sieht vor, die Nextcloud-Instanz wieder in den Wartungsmodus zu versetzen. Dann wird die Verbindung zur neuen Datenbank in der `config.php` gekappt, indem der `dbtype` wieder auf `sqlite3` gesetzt und der alte SQLite-Datenbankpfad angegeben wird. Die ursprüngliche SQLite-Datenbankdatei muss an ihren angestammten Ort zurückkopiert werden. Entscheidend ist, dass auch das Dateisystem (`data/`-Verzeichnis) auf den exakten Stand zum Zeitpunkt des SQLite-Backups zurückgesetzt wird. Eine gemischte Zustände – neue Datenbank mit alten Dateien oder umgekehrt – führen zu Chaos und Datenverlust.

Daher ist die Dokumentation des genauen Zeitpunkts der Backups essenziell. In der Praxis bedeutet ein Rollback fast immer einen gewissen Datenverlust: alle Änderungen, die zwischen dem Backup und dem Abbruch der Migration stattfanden. Dieses Risiko muss im Kommunikationsplan an die Nutzer klar benannt werden. Oft ist es jedoch besser, einen kurzen Datenverlust in Kauf zu nehmen, als wochenlang mit einer instabilen neuen Datenbank zu kämpfen.