> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/de/wartung/data-and-backups.md). # Daten und Backups Manchmal müssen wir das Schema der Daten in der Datenbank ändern, wenn wir Overleaf weiterentwickeln. Migrationsskripte werden verwendet, um diesen Prozess zu automatisieren. Sie werden auf [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) zuerst ausgeführt, was die größte Overleaf-Instanz der Welt ist, sodass die meisten Eventualitäten bereits vorgekommen sein werden; wir geben jedoch keine Garantien für Ihre Daten. Bitte stellen Sie sicher, dass Sie ein **konsistentes** Backup Ihrer Daten **bevor** Ihre Instanz zu aktualisieren. {% hint style="info" %} Beim Upgrade auf ein neues Docker-Image werden alle Migrationen, die **nicht** noch nicht ausgeführt wurden, automatisch ausgeführt. Dies kann je nach Größe Ihres Datensatzes einige Zeit dauern; das Mitverfolgen der Logs gibt Ihnen Auskunft über den Fortschritt. Weitere Informationen finden Sie in unserem [Logging](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging) Dokumentation. {% endhint %} ### Datenspeicherung Overleaf Community Edition und Server Pro speichern ihre Daten an drei separaten Stellen: * **MongoDB-Datenbank:** Hier befinden sich Benutzer- und Projektdaten. * **Redis:** dient als hochleistungsfähiger Cache für laufende Daten und speichert vor allem Informationen zu Projektbearbeitungen und Zusammenarbeit. * **Overleaf-Dateisystem:** speichert nicht bearbeitbare Projektdateien (einschließlich Bilder) und dient außerdem als temporärer Festplatten-Cache während der Projektkompilierungen. {% hint style="info" %} Dies könnte `~/sharelatex_data` oder `~/overleaf_data`, je nachdem, wann Ihre Instanz eingerichtet wurde. {% endhint %} {% hint style="success" %} Für Projektdateien und vollständige Projektverlaufsdaten unterstützen wir außerdem S3-kompatible Speicher-Backends. {% endhint %} Weitere Informationen zum Ordnerlayout auf der Festplatte finden Sie unter „Ordner im Detail“. ### Ein konsistentes Backup erstellen Es gibt drei Speicherorte, die bei einem konsistenten Backup enthalten sein müssen: * MongoDB * Redis * Overleaf-Dateisystemdaten Um ein konsistentes Backup zu erstellen, ist es **zwingend erforderlich** zu verhindern, dass Benutzer während des Backup-Prozesses neue Daten erzeugen. Wir empfehlen daher, ein Wartungsfenster einzuplanen, in dem Benutzer nicht auf die Instanz zugreifen oder ihre Projekte bearbeiten können. Bevor Sie mit dem Backup-Prozess beginnen, müssen Sie Ihre Instanz offline nehmen. Beginnend mit Server Pro `3.5.0` automatisiert der Herunterfahrprozess das Schließen der Website und die Trennung der Benutzer. Um Ihre Instanz herunterzufahren, müssen Sie `bin/docker-compose stop sharelatex` ausführen, wenn Sie eine Toolkit-Bereitstellung verwenden, oder `docker compose stop sharelatex` wenn Sie Docker Compose verwenden. Sobald der `sharelatex` Container gestoppt wurde, können Sie den Backup-Prozess starten. Sobald der Backup-Prozess **erfolgreich** abgeschlossen wurde, müssen Sie den `sharelatex` Container starten. Führen Sie dazu `bin/docker-compose start sharelatex` ausführen, wenn Sie eine Toolkit-Bereitstellung verwenden, oder `docker compose start sharelatex` wenn Sie Docker Compose verwenden. {% hint style="danger" %} * Backups sollten auf einem anderen Server als dem gespeichert werden, auf dem Ihre Overleaf-Instanz läuft, idealerweise sogar an einem völlig anderen Standort. * Die Replikation von Datenbanken auf mehrere MongoDB-Instanzen kann zwar etwas Redundanz bieten, schützt aber nicht vor Datenkorruption. * Das Testen Ihrer Backups ist der beste Weg, um sicherzustellen, dass sie vollständig und funktionsfähig sind. {% endhint %} ### MongoDB MongoDB wird mit einem Kommandozeilenwerkzeug namens [mongodump](https://docs.mongodb.com/manual/reference/program/mongodump/) geliefert, das verwendet werden kann, um ein Backup der in der Datenbank gespeicherten Benutzer- und Projektdaten zu erstellen. ### Overleaf-Dateisystemdaten Für Toolkit-Bereitstellungen wird der Pfad, in dem Ihre nicht bearbeitbaren Dateien gespeichert werden, in `config/overleaf.rc` mithilfe der `OVERLEAF_DATA_PATH` einer Umgebungsvariable angegeben, aber je nachdem, wann Ihre Instanz erstellt wurde, könnte dies `data/sharelatex`. Die Verwendung eines Werkzeugs wie **rsync** zum rekursiven Kopieren dieses Verzeichnisses ist erforderlich, um sicherzustellen, dass ein vollständiges Backup erstellt wird. ### Redis Redis speichert Benutzersitzungen und ausstehende Dokumentaktualisierungen, bevor sie nach MongoDB geschrieben werden. Die Persistenz über Append Only File (AOF) ist die empfohlene Konfiguration für die Redis-Persistenz. Toolkit-Benutzer haben die AOF-Persistenz standardmäßig für **neuen** Installationen aktiviert; bestehende Benutzer finden weitere Informationen zur Aktivierung von AOF [hier](/on-premises/de/konfiguration/overleaf-toolkit/redis.md#enabling-append-only-file-persistence). Wenn Sie sich dafür entscheiden, weiterhin RDB-Snapshots zusammen mit AOF-Persistenz zu verwenden, können Sie die RDB-Datei als Backup an einen sicheren Ort kopieren. ### Daten zwischen Servern migrieren Im besten Fall haben Sie in der neuen Instanz noch keine wertvollen Daten. Wir haben keinen Prozess zum Zusammenführen der Daten von Instanzen. Unter der Annahme, dass die neue Instanz noch keine Daten hat, sind hier einige Schritte, denen Sie folgen könnten. Grob gesagt erstellen wir ein Tar-Archiv der `mongo`, `redis` und `Overleaf` Volumes, kopieren es auf den neuen Server und entpacken es dort erneut. #### Toolkit ```bash # Die alte Instanz ordnungsgemäß herunterfahren old-server$ bin/stop # Das Tar-Archiv erstellen old-server$ tar --create --file backup-old-server.tar config/ data/ # Die Datei backup-old-server.tar vom old-server auf den # new-server mit einer beliebigen passenden Methode kopieren # Die neue Instanz ordnungsgemäß herunterfahren (falls noch nicht geschehen) new-server$ bin/stop # Die neuen Daten verschieben, Sie können sie auch löschen new-server$ mkdir backup-new-server new-server$ mv config/ data/ backup-new-server/ # config/data-Verzeichnis erneut befüllen new-server$ tar --extract --file backup-old-server.tar # Container starten new-server$ bin/up ``` #### Docker Compose ```bash # Die alte Instanz ordnungsgemäß herunterfahren old-server$ docker stop sharelatex old-server$ docker stop mongo redis # Das Tar-Archiv erstellen old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data # Die Datei backup-old-server.tar vom old-server auf # den new-server mit einer beliebigen passenden Methode kopieren # Die neue Instanz ordnungsgemäß herunterfahren (falls noch nicht geschehen) new-server$ docker stop sharelatex new-server$ docker stop mongo redis # Die neuen Daten verschieben, Sie können sie auch löschen new-server$ mkdir backup-new-server new-server$ mv ~/OVERLEAF_data ~/mongo_data ~/redis_data backup-new-server/ # Datenverzeichnisse erneut befüllen new-server$ tar --extract --file backup-old-server.tar # Container starten new-server$ docker start mongo redis new-server$ docker start sharelatex ``` Je nach Ihrem **docker-compose.yml** Datei müssen Sie möglicherweise die Pfade der `mongo`, `redis`, `Overleaf` Volumes anpassen. {% hint style="info" %} Wenn tar als Root-Benutzer (oder mit sudo) ausgeführt wird, behält es den Datei-Eigentümer/die Gruppe und die Berechtigungen bei, was bei der Wiederherstellung des Backups entscheidend ist. {% endhint %} ### Ordner im Detail {% hint style="info" %} Die folgenden Ordner haben zusätzliche Hinweise: * (b) in Backups einbeziehen, am besten wenn die Instanz gestoppt ist, um Konsistenz sicherzustellen * (d) kann gelöscht werden * (e) flüchtige Dateien, können gelöscht werden, wenn die Instanz gestoppt ist {% endhint %} 1. `~/mongo_data` (b) * MongoDB-Datadir 2. `~/redis_data` (b) * Redis-DB-Datadir 3. `~/overleaf_data` 1. bin 1. synctex (d) * in der neuesten Version nicht verwendet, zuvor wurde ein benutzerdefiniertes synctex-Binary verwendet (synctex wird für das Source-Mapping zwischen .tex-Dateien und dem PDF verwendet) 2. data 1. Cache (e) * binärer Datei-Cache für Kompilierungen 2. Kompilierungen (e) * hier findet die LaTeX-Kompilierung statt 3. db.sqlite (d) * in der neuesten Version nicht verwendet, zuvor wurden hier CLSI-Cache-Details gespeichert (entweder in einfache In-Memory-Maps verschoben oder wir scannen die Festplatte) 4. db.sqlite-wal (d) * in der neuesten Version nicht verwendet, siehe db.sqlite 5. Ausgabe (e) * Speicher für LaTeX-Kompilierungsausgaben zur Bereitstellung an den Client 6. template\_files (b) * Bildvorschauen des Vorlagensystems (nur Server Pro) 7. user\_files (b) * binäre Dateien von Projekten 8. history (b) * Dateien des vollständigen Projektverlaufs 3. tmp 1. dumpFolder (e) * temporäre Dateien aus der Verarbeitung von ZIP-Dateien 2. uploads (e) * Pufferung von Datei-Uploads (binäre Datei/Upload eines neuen Projekts aus ZIP) 3. projectHistories (e) * temporäre Dateien für Migrations des vollständigen Projektverlaufs --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ayakaleaf-pro.ayaka.space/on-premises/de/wartung/data-and-backups.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.