MariaDB / Datenverzeichnis unter Ubuntu und Windows ändern

Um den Speicherort von MariaDB zu ändern, fahren Sie den Server sauber herunter, kopieren das vollständige Datenverzeichnis und passen die Serveroption datadir sowie die Zugriffsrechte an. Eine Konfigurationsänderung verschiebt vorhandene Daten nicht; eine gewöhnliche Dateikopie bei laufendem Server kann inkonsistent sein. Planen Sie deshalb zuerst eine unabhängige Sicherung und eine Schreibpause ein.

Geltungsbereich und Vorbereitung

Das Datenverzeichnis enthält Datenbanken und Verwaltungsdateien der Speicher-Engines. Die Servervariable datadir zeigt seinen aktuellen Pfad. Diese Anleitung betrifft eine einzelne Instanz auf demselben Rechner mit unveränderter MariaDB-Version. Versionswechsel, Betriebssystemwechsel, Replikation, Galera-Cluster und Container-Volumes benötigen einen eigenen Migrationsplan.

Verbinden Sie sich mit einem administrativen MariaDB-Konto und dokumentieren Sie die folgenden Ergebnisse. Bei einer üblichen Ubuntu-Installation mit Socket-Authentifizierung eignet sich sudo mariadb; unter Windows verwenden Sie bin\mariadb.exe -u root -p im Installationsverzeichnis. Bei einer anderen Authentifizierung nutzen Sie das tatsächlich vorgesehene Administrationskonto.

SELECT VERSION(), @@datadir, @@port;
SHOW VARIABLES WHERE Variable_name IN (
  'log_error', 'log_bin_basename', 'innodb_data_home_dir',
  'innodb_log_group_home_dir', 'aria_log_dir_path'
);

• Unabhängige Sicherung: Erstellen Sie ein wiederherstellbares Backup an einem anderen Ort; bei Produktivdaten prüfen Sie auch die Wiederherstellung. Das Aufbewahren des alten Ordners ersetzt kein separates Backup. Die MariaDB-Übersicht zu Backups erklärt logische und physische Verfahren.
• Pfade und Speicherplatz: Notieren Sie das tatsächliche Quellverzeichnis und ein Ziel mit ausreichend freiem Platz. /var/lib/mysql/ und die Windows-Version 11.4 sind Beispiele und müssen zur Installation passen.
• Externe Dateien: Binärlogs mit absoluten Pfaden, externe Tablespaces, Verschlüsselungsschlüssel, symbolische Links und Windows-Reparse-Points müssen gesondert geprüft werden. Nicht jede Datei folgt automatisch dem neuen datadir.
• Wartungsfenster: Unterbrechen Sie Anwendungsschreibzugriffe, geplante Jobs und automatische Neustarts durch Überwachungsprozesse. Lassen Sie externe Schreibzugriffe bis zum Abschluss der Prüfung gesperrt.

Führen Sie beim Umzug einer bestehenden Instanz im Ziel nicht mariadb-install-db aus. Dieses Werkzeug initialisiert eine neue Instanz; hier werden dagegen sämtliche vorhandenen Daten kopiert.

Datenverzeichnis unter Ubuntu verschieben

Konfiguration und Ziel-Mount ermitteln

Eine typische Paketinstallation unter Ubuntu 24.04 verwendet /etc/mysql/mariadb.conf.d/50-server.cnf. Andere Installationsarten können abweichen. Prüfen Sie Startargumente und Drop-ins mit systemctl cat und die aus Optionsdateien gelesenen Werte mit mariadbd --print-defaults. Veröffentlichen Sie die Ausgabe nicht ungeprüft, da sie sensible Einstellungen enthalten kann.

sudo systemctl cat mariadb
sudo mariadbd --print-defaults
sudo du -sh /var/lib/mysql
df -h /data
findmnt -T /data

Falls /data fehlt, richten Sie zunächst das Ziellaufwerk ein und hängen es ein. Vergewissern Sie sich mit df und findmnt, dass das richtige Dateisystem verwendet wird. Laut MariaDB-Dokumentation zu Optionsdateien können spätere Einstellungen und Startargumente frühere Werte überschreiben. Sichern Sie vor der Bearbeitung die Datei, die der Dienst tatsächlich liest.

Server stoppen und alle Daten kopieren

Das Beispiel verwendet den Dienst mariadb, das Betriebssystemkonto mysql und das Ziel /data/mariadb/. Installieren Sie rsync bei Bedarf vor der Unterbrechung. Prüfen Sie nach dem Stoppen den Zustand inactive und das Ende des Serverprozesses. is-active kann bei einem inaktiven Dienst einen von null verschiedenen Status liefern. Kopieren Sie nicht nach einem fehlgeschlagenen Herunterfahren oder solange eine andere Instanz dasselbe Verzeichnis verwendet.

sudo systemctl stop mariadb
sudo systemctl is-active mariadb
sudo systemctl status mariadb --no-pager

Das Ziel muss leer sein. Vermischen Sie keine Daten verschiedener Instanzen. Die Befehle erstellen den Ordner, setzen Besitzer und Rechte und kopieren auch versteckte Dateien sowie Engine-Dateien. -a erhält unter anderem Besitzer und Berechtigungen. Auch cp -a kann Attribute erhalten; eine einfache Kopie liefert nicht zwangsläufig dasselbe Ergebnis.

sudo mkdir -p /data/mariadb
sudo chown mysql:mysql /data/mariadb
sudo chmod 750 /data/mariadb
sudo rsync -aHAX --numeric-ids /var/lib/mysql/ /data/mariadb/
sudo rsync -aHAXnci --numeric-ids /var/lib/mysql/ /data/mariadb/

Der erste rsync-Aufruf kopiert tatsächlich, der zweite vergleicht per Prüfsumme im Probelauf. Beide müssen erfolgreich enden; untersuchen Sie gemeldete Änderungen im zweiten Lauf. Der abschließende Schrägstrich an der Quelle bedeutet, dass deren Inhalt kopiert wird. Fehler beim Erhalten von ACLs (Zugriffskontrolllisten) oder erweiterten Attributen müssen geklärt werden, etwa durch Prüfung des Zieldateisystems und der Optionen.

datadir und Sicherheitsregeln anpassen

Ändern Sie den vorhandenen Eintrag datadir in einer vom Dienst gelesenen Server-Optionsgruppe. Vermeiden Sie widersprüchliche Mehrfacheinträge.

[mysqld]
datadir=/data/mariadb

Der richtige Besitzer genügt nicht immer. AppArmor beschränkt unter Linux die Dateizugriffe einzelner Programme. Prüfen Sie aktive Profile und Kernelmeldungen auf DENIED-Einträge zur MariaDB-Programmdatei.

sudo aa-status
sudo journalctl -k -b --no-pager

Erlaubt das tatsächlich durchgesetzte Profil nur den alten Pfad, passen Sie dessen lokale Regeln oder einen wirksamen Alias an. Die MariaDB-Hilfe bei Startproblemen beschreibt folgenden Eintrag in /etc/apparmor.d/tunables/alias. Prüfen Sie zuerst, ob das aktive Profil diese Datei nutzt, sichern Sie sie und kontrollieren Sie nach der Änderung den Erfolg von sudo systemctl reload apparmor. Profile unterscheiden sich je nach Distribution und Paket; der Alias ist kein Pflichtschritt für jede Installation.

alias /var/lib/mysql/ -> /data/mariadb/,

Prüfen Sie in systemctl cat mariadb außerdem ReadWritePaths, ProtectSystem und weitere Einschränkungen. Für ein separates Laufwerk können Sie über sudo systemctl edit mariadb diese Mount-Abhängigkeit ergänzen. Sie ersetzt weder die Einrichtung des Datenträgers noch einen dauerhaften Mount-Eintrag in /etc/fstab. Weitere Details bietet systemd zu RequiresMountsFor.

[Unit]
RequiresMountsFor=/data/mariadb

Das Beispiel vermeidet /home und /root, die der Dienst standardmäßig sperren kann. Ist zusätzlicher Schreibzugriff nötig, erlauben Sie gezielt den erforderlichen Pfad, statt den Schutz insgesamt abzuschalten. Siehe MariaDB und systemd.

Starten und den aktiven Pfad prüfen

Laden Sie nach Änderungen an Unit-Einstellungen die Dienstkonfiguration neu und starten Sie MariaDB. Die SQL-Ausgabe muss /data/mariadb/ anzeigen. Der Socket-Pfad des Clients muss durch den Verzeichnisumzug nicht ebenfalls geändert werden; lassen Sie sachfremde Einstellungen unverändert.

sudo systemctl daemon-reload
sudo systemctl start mariadb
sudo systemctl status mariadb --no-pager
sudo mariadb -e "SELECT @@datadir;"

Schlägt der Start fehl oder erscheint der alte Pfad, verbinden Sie die Anwendungen noch nicht und fahren Sie mit der Fehlerdiagnose fort.

Datenverzeichnis unter Windows verschieben

Dienst, Konto und my.ini identifizieren

Führen Sie diese Abfragen in einer PowerShell mit Administratorrechten aus. Sie zeigen den tatsächlichen Dienstnamen, das Anmeldekonto und die Startargumente. Ersetzen Sie MariaDB und die Version 11.4 in allen Beispielen durch Ihre Werte. Der Standardname aus der Windows-MSI-Installationsanleitung muss nicht dem registrierten Dienstnamen entsprechen.

Get-CimInstance Win32_Service |
  Where-Object { $_.PathName -match 'mariadbd|mysqld' } |
  Select-Object Name, State, StartName, PathName
sc.exe qc MariaDB

Prüfen Sie die durch --defaults-file angegebene my.ini. Fehlt diese Angabe, kontrollieren Sie die vom betreffenden Programm mit --help --verbose ausgegebenen Suchpfade und die vorhandenen Dateien. Aktivieren Sie im Explorer Ansicht → Anzeigen → Dateinamenerweiterungen, damit die Datei nicht versehentlich als my.ini.txt gespeichert wird. Notieren Sie @@datadir und sichern Sie die aktive Konfiguration an einem anderen Ort.

Dienst stoppen und Dateien kopieren

Das Beispiel kopiert C:\Program Files\MariaDB 11.4\data in den neuen, leeren Ordner C:\MariaDB. Prüfen Sie vor dem Kopieren den Zustand Stopped. Existiert das Ziel bereits, untersuchen Sie seinen Inhalt und führen keine Datenbestände zusammen.

Stop-Service -Name 'MariaDB'
Get-Service -Name 'MariaDB'

New-Item -ItemType Directory -Path 'C:\MariaDB'
robocopy "C:\Program Files\MariaDB 11.4\data" "C:\MariaDB" /E /COPY:DAT /DCOPY:DAT /R:1 /W:1 /XJ /XF my.ini
$copyExit = $LASTEXITCODE
if ($copyExit -ge 8) { throw "Robocopy failed: $copyExit" }

Unterverzeichnisse werden mitkopiert, my.ini bleibt dagegen am ursprünglichen Ort. /COPY:DAT übernimmt Daten, Attribute und Zeitstempel; die Zielberechtigungen folgen im nächsten Schritt. /XJ schließt Junctions aus, sodass externe Inhalte eigens behandelt werden müssen. Laut Microsofts Robocopy-Referenz bedeuten Rückgabecodes ab 8 einen Kopierfehler. Prüfen Sie auch bei 0–7 die Zusammenfassung auf Fehler, Unterschiede und unerwartete zusätzliche Dateien.

Dienstkonto berechtigen und datadir ändern

Öffnen Sie services.msc und prüfen Sie beim betreffenden Dienst Eigenschaften → Anmelden. Unter Eigenschaften → Sicherheit → Bearbeiten → Hinzufügen des Zielordners gewähren Sie dem tatsächlichen Dienstkonto das Recht Ändern. Der SQL-Benutzer root ist nicht mit dem Windows-Dienstkonto identisch. Vollzugriff für Everyone ist nicht erforderlich.

Verwenden Sie das folgende Beispiel nur, wenn das virtuelle Dienstkonto wirklich NT SERVICE\MariaDB lautet. Bei anderem Dienstnamen oder lokalem beziehungsweise Domänenkonto setzen Sie das richtige Konto ein. (OI)(CI)M steht für Änderungsrechte, die an Dateien und Unterordner vererbt werden. Die Syntax erläutert Microsofts icacls-Referenz.

icacls "C:\MariaDB" /grant "NT SERVICE\MariaDB:(OI)(CI)M"
icacls "C:\MariaDB"

Ändern Sie in der ursprünglichen my.ini die vorhandene Server-Optionsgruppe und speichern Sie die Datei am selben Ort. Vorwärtsschrägstriche vermeiden Probleme mit Escape-Sequenzen. --defaults-file soll weiterhin auf die ursprüngliche Konfiguration zeigen; verschieben Sie diese Datei nicht gleichzeitig.

[mysqld]
datadir=C:/MariaDB

Dienst starten und Verbindung testen

Starten Sie MariaDB und verbinden Sie sich mit dem Client. Geben Sie das Passwort erst bei der Abfrage ein, nicht als Teil des Befehls nach -p.

Start-Service -Name 'MariaDB'
Get-Service -Name 'MariaDB'
& 'C:\Program Files\MariaDB 11.4\bin\mariadb.exe' -u root -p

Prüfen Sie mit SELECT @@datadir;, ob C:\MariaDB\ oder die gleichwertige Schreibweise mit Vorwärtsschrägstrichen erscheint. Der Dienststatus Running allein beweist nicht, dass die richtigen Daten geöffnet wurden.

Vorhandene Daten, Schreibzugriffe und Neustart prüfen

Vergleichen Sie vorhandene Datenbanken, typische Zeilenzahlen und bekannte Werte mit den vorherigen Aufzeichnungen. Prüfen Sie anschließend, ob der folgende Testdatenbankname noch frei ist, und führen Sie das SQL mit einem administrativen Konto aus. Existiert der Name bereits, wählen Sie einen eindeutigen anderen und ersetzen ihn in sämtlichen Anweisungen. Legen Sie keine Testobjekte in einer Geschäftsdatenbank an.

SELECT @@datadir;
CREATE DATABASE datadir_move_check_13862;
CREATE TABLE datadir_move_check_13862.probe (id INT PRIMARY KEY);
INSERT INTO datadir_move_check_13862.probe VALUES (1);
SELECT * FROM datadir_move_check_13862.probe;

Die letzte Abfrage soll eine Zeile mit id = 1 liefern. Lassen Sie externe Schreibzugriffe gesperrt, starten Sie den Dienst noch einmal sauber neu und führen Sie nach erneuter Verbindung Folgendes aus:

SELECT @@datadir;
SELECT * FROM datadir_move_check_13862.probe;

Der neue Pfad und die Zeile 1 müssen erhalten sein. Entfernen Sie nur die Testdatenbank mit der folgenden Anweisung, prüfen Sie die tatsächliche Anwendungsverbindung sowie Lesen und Schreiben und geben Sie dann den Betrieb frei. Ein neu angelegter Ordner allein belegt keine vollständige InnoDB-Migration.

DROP DATABASE datadir_move_check_13862;

Bewahren Sie das Quellverzeichnis auf, bis die Prüfungen und Ihre Backup-Aufbewahrungsregeln erfüllt sind. Berücksichtigen Sie den neuen Speicherort auch in Sicherungsaufträgen und Monitoring.

Startfehler oder unveränderten Pfad untersuchen

• Alter datadir-Pfad: Wurde die falsche Datei bearbeitet, überschreibt eine spätere Option den Wert, oder ist der Client mit einer anderen Instanz über einen anderen Port oder Socket verbunden?
• Permission denied oder keine Testdatei: Prüfen Sie Dienstkonto, Durchgangsrechte aller übergeordneten Verzeichnisse und Schreibrechte am Ziel. Unter Ubuntu kommen AppArmor und systemd hinzu, unter Windows die ACL des tatsächlichen Dienstkontos.
• Fehlende Systemtabellen oder Datenbanken: Suchen Sie nach einer zusätzlichen Verzeichnisebene oder unvollständigen Kopie. Initialisieren Sie das Ziel nicht neu und löschen Sie weder ibdata1 noch Logdateien auf Verdacht.
• Fehler nach Rechnerneustart: Prüfen Sie dauerhafte Mounts, Startreihenfolge und stabile Laufwerksbuchstaben.

Unter Ubuntu zeigen die folgenden Befehle Zeitpunkt und Pfad des Fehlers. Mit namei lassen sich die Rechte aller übergeordneten Verzeichnisse untersuchen.

sudo journalctl -u mariadb -b -n 100 --no-pager
sudo journalctl -k -b --no-pager
namei -l /data/mariadb
sudo systemctl cat mariadb

Unter Windows prüfen Sie das konfigurierte log_error-Ziel, .err-Dateien im alten und neuen Verzeichnis und passende Ereignisanzeigen. Eine allgemeine Dienstmeldung wie Fehler 1067 verrät noch nicht die Ursache. Die MariaDB-Startdiagnose bietet fehlerspezifische Hinweise.

Voraussetzungen und Schritte für ein Rollback

Gab es am neuen Speicherort noch keine externen Schreibzugriffe, stoppen Sie MariaDB vollständig und stellen die gesicherte Konfiguration oder den alten datadir-Wert wieder her. Entfernen Sie nur die bei diesem Umzug ergänzten AppArmor-Aliase und systemd-Drop-ins; erhalten Sie andere Einstellungen. Nach Unit-Änderungen führen Sie vor dem Start daemon-reload aus und prüfen anschließend den ursprünglichen Pfad und die Daten.

Wurden am neuen Ort bereits echte Daten geschrieben, ist die zurückbehaltene Quelle veraltet. Ein bloßes Zurückschalten kann diese Änderungen verlieren. Sperren Sie Schreibzugriffe erneut, sichern Sie die neuesten Daten und planen Sie eine Rückmigration im gestoppten Zustand oder eine passende Wiederherstellung. Vermischen Sie nicht die Dateien beider Verzeichnisse und betreiben Sie nicht beide Kopien gleichzeitig.