Matomo umziehen: Server- oder Hosterwechsel ohne Datenverlust

Ein neuer Server, ein anderer Hoster oder der Abschied aus der Matomo Cloud: Irgendwann zieht fast jede Matomo-Instanz einmal um. Technisch ist das überschaubar, Matomo beschreibt den Weg in seiner FAQ in wenigen Schritten. Daten gehen meist an anderer Stelle verloren: an einer abweichenden Version, an einem neu erzeugten Salt oder an den Stunden, in denen Tracking-Anfragen ins Leere laufen.

Dieser Artikel führt durch Vorbereitung, Datenbank, Dateien, Umschalten und Prüfung und endet mit einer Checkliste. Die Befehle gelten für eine selbst betriebene Matomo-Instanz unter Linux.

Vorbereitung: dieselbe Version auf beiden Seiten#

Notieren Sie zuerst die Version der alten Instanz:

./console core:version

Auf dem neuen Server installieren Sie genau diese Version; ältere Releases liegen auf builds.matomo.org. Matomo empfiehlt das ausdrücklich: Eine neuere Version funktioniert zwar wahrscheinlich, startet aber eine automatische Datenmigration, die den neuen Server je nach Datenmenge Minuten bis Stunden blockieren kann.

Daraus folgt eine einfache Regel: Umzug und Upgrade nie in einem Schritt. Ziehen Sie mit derselben Version um und aktualisieren Sie danach, oder aktualisieren Sie vorher auf dem alten Server. Wer ohnehin auf Matomo 6 wechseln will, findet die neuen Voraussetzungen in unserer Checkliste für das Upgrade auf Matomo 6. So wissen Sie bei einem Problem immer, woran es liegt.

Außerdem vor dem Umzugstag:

• Systemanforderungen der neuen Umgebung prüfen: PHP- und Datenbankversion passend zu Ihrer Matomo-Version, die empfohlenen PHP-Erweiterungen und ein Datenbankbenutzer mit den Rechten, die Matomo verlangt (unter anderem CREATE, ALTER, DROP und LOCK TABLES).
• Probelauf mit einer Kopie: Dump, Import und Start einmal komplett durchspielen und die Dauer messen. Danach planen Sie das Wartungsfenster.
• DNS-TTL senken, wenn der Hostname gleich bleibt (dazu unten mehr).

Die Datenbank umziehen#

Für eine vollständige Kopie nennt Matomo diesen Aufruf:

mysqldump --extended-insert --no-autocommit --quick --single-transaction \
  MATOMO_DATENBANK -u MATOMO_BENUTZER -p > matomo_backup_database.sql

--single-transaction liefert bei InnoDB-Tabellen einen konsistenten Stand, ohne laufende Anwendungen zu blockieren. --quick liest große Tabellen zeilenweise, statt sie im Speicher zu puffern. Einen Haken nennt das MySQL-Handbuch: Während des Dumps darf keine andere Verbindung Tabellen anlegen, ändern oder löschen. Matomo legt Archivtabellen aber automatisch pro Monat an. Halten Sie deshalb den Archivierungs-Cron an, solange der Dump läuft.

Eingespielt wird auf dem neuen Server mit:

mysql MATOMO_DATENBANK -u MATOMO_BENUTZER -p < matomo_backup_database.sql

Behalten Sie das Tabellenpräfix bei (Standard: matomo_), dann erkennt Matomo Websites und Berichte sofort wieder.

Große Datenbanken: Das MySQL-Handbuch sagt selbst, dass mysqldump keine schnelle oder skalierbare Lösung für große Datenmengen ist. Vor allem das Einspielen kann sehr lange dauern, weil jede Zeile und jeder Index neu geschrieben wird. Für große Instanzen empfiehlt es physische Sicherungen oder die parallelen Dump- und Load-Werkzeuge der MySQL Shell. Welcher Weg passt, zeigt Ihr Probelauf.

Die Dateien: was mit umziehen muss#

Matomo empfiehlt, das komplette Matomo-Verzeichnis mitzunehmen. Wer auf dem neuen Server lieber frisch installiert, überträgt diese Teile gezielt:

• config/config.ini.php mit Datenbankzugang, aktivierten Plugins, trusted_hosts und dem salt im Abschnitt [General]. Den Datenbankzugang passen Sie an, alles andere übernehmen Sie.
• plugins/ mit allen Plugins aus dem Marketplace und von anderen Anbietern, in denselben Versionen wie auf dem alten Server.
• misc/user/ mit eigenem Logo und Favicon.
• misc/*.mmdb, die Geolocation-Datenbank von DB-IP oder MaxMind, falls Sie sie von Hand installiert haben. Alternativ laden Sie sie in den Einstellungen zur Standorterkennung neu herunter.
• js/container_*.js, die veröffentlichten Container des Tag Managers. Fehlen sie, erzeugt ./console tagmanager:regenerate-released-containers sie neu.

Den Ordner tmp/ lassen Sie weg; Matomos Anleitung für den Umzug auf eine neue Domain sieht ausdrücklich vor, ihn zu löschen. Achten Sie nach dem Kopieren auf die Dateirechte: PHP muss die Plugins lesen und in tmp/ schreiben können.

Der Salt: das unterschätzte Detail#

Der Installationsassistent erzeugt bei jeder Neuinstallation einen neuen, zufälligen Salt, auch wenn Sie ihn wie in Matomos FAQ beschrieben nur auf die übernommene Datenbank zeigen lassen. Das hat Folgen: Matomo speichert API-Tokens nur als Hash aus Token und Salt. Mit einem neuen Salt passt keiner der gespeicherten Hashes mehr, und jede Anbindung mit token_auth verliert ihren Zugriff, vom Dashboard in einem anderen Tool bis zum Export-Skript. Übernehmen Sie deshalb immer die alte config.ini.php oder zumindest ihren Salt.

Kostenpflichtige Plugins und Lizenzen#

Den Lizenzschlüssel für Premium-Plugins aus dem Matomo Marketplace speichert Matomo in der Datenbank, er zieht also mit um. Laut Marketplace-FAQ gilt ein Abo für eine produktive Instanz plus eine Test- oder Entwicklungsinstanz. Nach dem Umzug ist die neue Instanz die produktive; die alte sollte nicht dauerhaft parallel weiterlaufen. Für Plugins anderer Anbieter gelten deren Lizenzbedingungen. Klären Sie einen Umzug dort vorab.

Tracking ohne Lücke: der Moment des Umschaltens#

Matomo weist in seiner Anleitung darauf hin, dass während des Umzugs keine Besuche erfasst werden. Mit etwas Planung lässt sich diese Lücke schließen.

Hostname beibehalten. Läuft Matomo weiter unter derselben Adresse, etwa analytics.example.org, bleibt der Tracking-Code auf allen Websites unverändert. Ändert sich die Adresse, müssen Sie den Code auf jeder Seite anpassen und den neuen Namen in trusted_hosts eintragen.

TTL rechtzeitig senken. Resolver dürfen einen DNS-Eintrag so lange zwischenspeichern, wie seine TTL angibt. Senken Sie die TTL deshalb mindestens so lange vor dem Umzug, wie die alte TTL beträgt. Dann greift die Umstellung später schnell. Testen können Sie den neuen Server vorher über einen Eintrag in der hosts-Datei Ihres Rechners.

Alten Server einfrieren. Zu Beginn des Wartungsfensters stoppen Sie auf dem alten Server den Archivierungs-Cron, sperren die Oberfläche und pausieren das Tracking:

./console config:set General.maintenance_mode=1
./console config:set Tracker.record_statistics=0

Die Sperre verhindert, dass noch jemand Websites, Ziele oder Benutzer anlegt, die im finalen Dump fehlen würden. Tracking-Anfragen nimmt der Webserver weiter an und schreibt sie in sein Access-Log, sofern es aktiv ist. Dann folgen finaler Dump, Import und die DNS-Umstellung.

Lücke nachimportieren. Bis alle Caches abgelaufen sind, landen noch Anfragen auf dem alten Server. Sammeln Sie dort alle Zeilen mit matomo.php oder piwik.php ab Beginn der Pause, sortieren Sie sie chronologisch, kopieren Sie die Datei auf den neuen Server und spielen Sie sie dort mit dem Log-Importer ein:

./misc/log-analytics/import_logs.py --url=https://analytics.example.org \
  --replay-tracking matomo-luecke.log

Eine Grenze nennt Matomo selbst: POST-Anfragen stehen nicht im Access-Log und lassen sich so nicht nachholen. Häufig betroffen sind Formular-, Medien- und Heatmap-Daten sowie der Heartbeat-Timer.

Lassen Sie den Cron auf dem alten Server danach aus. Sonst können dort Archivierung und geplante E-Mail-Berichte weiterlaufen, und Ihre Empfänger bekommen Berichte doppelt.

Archivierung nach dem Umzug#

Die fertigen Berichte liegen in den Archivtabellen der Datenbank und ziehen mit dem Dump um. Alles neu zu berechnen ist also weder nötig noch ratsam. Drei Dinge sind trotzdem zu tun.

Cron einrichten. Der Archivierungs-Cron muss auf dem neuen Server neu angelegt werden, zum Beispiel stündlich mit ./console core:archive --matomo-domain=https://analytics.example.org. Dazu gehört browser_archiving_disabled_enforce = 1 im Abschnitt [General], damit nicht die Oberfläche Berichte rechnet.

Nachimportierte Tage neu verarbeiten. Sind für einen Tag schon Berichte archiviert, erscheinen nachträglich importierte Daten erst nach einer Neuberechnung. Wochen, Monate und Jahre, die diese Tage enthalten, markiert Matomo dabei automatisch mit:

./console core:invalidate-report-data --dates=2026-10-27,2026-10-28 --sites=1,3
./console core:archive --matomo-domain=https://analytics.example.org

Nur mit Rohdaten invalidieren. Ist das regelmäßige Löschen alter Rohdaten aktiv, lassen sich Berichte für gelöschte Zeiträume nicht wieder aufbauen. Invalidieren Sie deshalb nie pauschal alle Zeiträume.

Prüfen: neue gegen alte Instanz#

Bevor der alte Server abgeschaltet wird, vergleichen Sie beide Instanzen:

• Systemprüfung: Unter Administration > Diagnose > Systemprüfung oder mit ./console diagnostics:run sollten keine Fehler oder Warnungen stehen.
• Zahlen: Öffnen Sie in beiden Instanzen dieselben abgeschlossenen Zeiträume, etwa die letzten zwölf Monate je Website. Die Werte müssen übereinstimmen. Direkt nach dem Import, noch vor der DNS-Umstellung, sollten außerdem die Zeilenzahlen von matomo_log_visit und matomo_log_link_visit_action auf beiden Servern gleich sein.
• Tracking: Eine Testseite aufrufen und prüfen, ob der Besuch unter „Besuche in Echtzeit“ erscheint.
• Geplante Berichte: Einen vorhandenen E-Mail-Bericht testweise versenden oder den Versand mit ./console core:test-email ihre-adresse@example.org prüfen. Auf einem neuen Server ist der Mailversand oft anders eingerichtet.
• Benutzer und Tokens: Mit einem normalen Konto anmelden, dann jede API-Anbindung mit ihrem bisherigen Token testen.
• Plugins, Standorte, Logo: Alle Plugins sind aktiv, Besucher werden korrekt verortet, Logo und Favicon sind da.

Stimmt alles, bleibt der alte Server noch erreichbar, bis in seinem Access-Log keine Tracking-Anfragen mehr ankommen.

Sonderfall Matomo Cloud#

Von der Cloud auf einen eigenen Server: Für jeden bezahlten Cloud-Tarif stellt der Matomo-Support auf Anfrage einen Datenbank-Dump bereit, für Testkonten nicht. Der Dump enthält immer die komplette Datenbank; Websites, die Sie nicht brauchen, löschen Sie danach. Zwei Stolpersteine beschreibt Matomo selbst: Die Cloud läuft mitunter auf einer Version mit „alpha“-Kennung, die Sie dann genau so installieren (laut Matomo produktionsreif), und der Export hat womöglich kein Tabellenpräfix, dann installieren Sie ohne Präfix. Denken Sie auch an die Lizenzen: In der Cloud sind alle Matomo-Funktionen im Tarif enthalten, auf einer eigenen Instanz werden Premium-Plugins einzeln oder im Paket lizenziert.

Vom eigenen Server in die Cloud: Für bezahlte Tarife übernimmt Matomo den Umzug kostenlos über ein Migrationsformular, ebenfalls mit der gesamten Datenbank.

Nur einzelne Websites: Das Plugin „Migration“ aus dem Marketplace kopiert eine Website samt Rohdaten und Berichten in eine andere Matomo-Instanz. Dort bekommt sie eine neue ID, der Tracking-Code muss also angepasst werden. Beide Instanzen brauchen dieselbe Matomo-Version, und Daten von Premium-Funktionen überträgt das Plugin derzeit nicht.

Checkliste für den Umzug#

1. Version mit ./console core:version notieren und auf dem neuen Server genau diese installieren.
2. Systemanforderungen und Datenbankrechte prüfen, ein Upgrade separat planen.
3. DNS-TTL rechtzeitig senken.
4. Probelauf: Dump, Import, Start, Dauer messen, Test über die hosts-Datei.
5. Wartungsfenster: alter Server mit maintenance_mode=1 und record_statistics=0, Cron aus.
6. Finaler Dump und Import mit gleichem Tabellenpräfix.
7. Dateien übertragen: config.ini.php mit Salt, Plugins, misc/user/, Geolocation-Datenbank, Tag-Manager-Container.
8. DNS umstellen, Cron auf dem neuen Server einrichten.
9. Lücke aus dem Access-Log des alten Servers nachimportieren, betroffene Tage invalidieren und archivieren.
10. Prüfen: Systemprüfung, Zahlen, Echtzeit, E-Mail-Bericht, Tokens.
11. Alten Server abschalten, wenn keine Anfragen mehr ankommen, und alte Daten dort löschen, sobald Sie sie nicht mehr brauchen.

Neuer Hoster, neuer Vertrag#

Betreibt ein Dienstleister Ihre Instanz, verarbeitet er die Daten in Ihrem Auftrag. Dafür verlangt Art. 28 DSGVO einen Vertrag zur Auftragsverarbeitung, den Sie mit dem neuen Hoster abschließen. Die Datenschutz-Einstellungen Ihrer Instanz, etwa IP-Kürzung und Löschfristen, ziehen mit Datenbank und Konfiguration um. Prüfen Sie sie danach trotzdem, die Entscheidung darüber treffen Sie mit Ihrer Datenschutzberatung. Das ist eine technische Einordnung, keine Rechtsberatung.

Wenn Sie den Umzug nicht selbst stemmen möchten: In unserem Managed Matomo Hosting ist er inklusive, mit Rohdaten, Berichten, Benutzern und Einstellungen. Vor dem Umschalten prüfen wir die neue Instanz gegen Ihre bisherige, egal ob Sie von einem eigenen Server oder aus der Matomo Cloud kommen.