> For the complete documentation index, see [llms.txt](https://overleaf-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://overleaf-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, während wir Overleaf weiterentwickeln. Um diesen Prozess zu automatisieren, werden Migrationsskripte verwendet. Sie werden auf [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) zunächst, die die größte Overleaf-Instanz der Welt ist, sodass die meisten Eventualitäten vermutlich bereits aufgetreten sein dürften; dennoch übernehmen wir keine Garantie für Ihre Daten. Bitte stellen Sie sicher, dass Sie eine **konsistente** Sicherung Ihrer Daten **vor** beim Upgrade Ihrer Instanz. {% 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. Wenn Sie die Logs verfolgen, sehen Sie den Fortschritt. Weitere Informationen finden Sie in unserer [Protokollierung](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging) Dokumentation. {% endhint %} ### Datenspeicherung Overleaf Community Edition und Server Pro speichern ihre Daten an drei getrennten Orten: * **MongoDB-Datenbank:** Hier befinden sich Benutzer- und Projektdaten. * **Redis:** dient als Hochleistungs-Cache für Daten, die gerade verarbeitet werden, und speichert hauptsächlich Informationen zu Projektbearbeitungen und Zusammenarbeit. * **Overleaf-Dateisystem:** speichert nicht bearbeitbare Projektdateien (einschließlich Bilder) und dient außerdem als temporärer Festplattencache während der Projektkompilierung. {% hint style="info" %} Das könnte `~/sharelatex_data` oder `~/overleaf_data`, je nachdem, wann Ihre Instanz eingerichtet wurde. {% endhint %} {% hint style="success" %} Für Projektdateien und vollständige Projekthistoriendaten unterstützen wir außerdem S3-kompatible Speicher-Backends. {% endhint %} Weitere Informationen zum Ordnerlayout auf der Festplatte finden Sie unter „Ordner im Detail“. ### Eine konsistente Sicherung durchführen Es gibt drei Speicherorte, die bei einer konsistenten Sicherung einbezogen werden müssen: * MongoDB * Redis * Overleaf-Dateisystemdaten Um eine konsistente Sicherung zu erzeugen, ist es **zwingend erforderlich** zu verhindern, dass Benutzer während der Ausführung des Sicherungsprozesses neue Daten erzeugen. Wir empfehlen daher, ein Wartungsfenster zu planen, während dessen Benutzer nicht auf die Instanz zugreifen oder ihre Projekte bearbeiten können. Bevor Sie mit dem Sicherungsprozess beginnen, müssen Sie Ihre Instanz offline nehmen. Beginnend mit Server Pro `3.5.0` der Herunterfahrprozess automatisiert 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 mit dem Sicherungsprozess beginnen. Sobald der Sicherungsprozess **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" %} * Sicherungen sollten auf einem separaten Server gespeichert werden als dem, auf dem Ihre Overleaf-Instanz läuft, idealerweise an einem völlig anderen Ort. * Das Replizieren von Datenbanken auf mehrere MongoDB-Instanzen kann zwar etwas Redundanz bieten, schützt aber nicht vor Beschädigung. * Das Testen Ihrer Sicherungen 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, mit dem sich eine Sicherung der in der Datenbank gespeicherten Benutzer- und Projektdaten erstellen lässt. ### Overleaf-Dateisystemdaten Für Toolkit-Bereitstellungen wird der Pfad, in dem Ihre nicht bearbeitbaren Dateien gespeichert sind, in `config/overleaf.rc` mithilfe der `OVERLEAF_DATA_PATH` der 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 eine vollständige Sicherung erstellt wird. ### Redis Redis speichert Benutzersitzungen und ausstehende Dokumentaktualisierungen, bevor sie an MongoDB weitergeleitet werden. Die Persistenz über Append-Only-Datei (AOF) ist die empfohlene Konfiguration für die Redis-Persistenz. Toolkit-Benutzer haben die AOF-Persistenz standardmäßig für **neue** Installationen aktiviert; bestehende Benutzer finden weitere Informationen zum Aktivieren von AOF [hier](/on-premises/de/konfiguration/overleaf-toolkit/redis.md#enabling-append-only-file-persistence). Wenn Sie sich entscheiden, RDB-Snapshots zusammen mit AOF-Persistenz weiter zu verwenden, können Sie die RDB-Datei als Sicherung 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, können Sie die folgenden Schritte ausführen. Auf hoher Ebene erstellen wir einen Tarball der `mongo`, `redis` und `Overleaf` Volumes, kopieren ihn auf den neuen Server und entpacken ihn dort wieder. #### Toolkit ```bash # Die alte Instanz ordnungsgemäß herunterfahren old-server$ bin/stop # Den Tarball erstellen old-server$ tar --create --file backup-old-server.tar config/ data/ # Kopieren Sie die Datei backup-old-server.tar vom alten Server auf den # neuen Server mit einer beliebigen Methode, die passt # Neue Instanz ordnungsgemäß herunterfahren (falls noch gestartet) 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/ # Konfigurations-/Datenverzeichnis 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 # Den Tarball erstellen old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data # Kopieren Sie die Datei backup-old-server.tar vom alten Server auf # den neuen Server mit einer beliebigen Methode, die passt # Neue Instanz ordnungsgemäß herunterfahren (falls noch gestartet) 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 Ihrer **docker-compose.yml** Datei müssen Sie möglicherweise die Pfade der `mongo`, `redis`, `Overleaf` Volumes anpassen. {% hint style="info" %} Wenn Sie als Root-Benutzer (oder mit sudo) ausführen, behält tar den Besitzer/die Gruppe der Datei und die Berechtigungen bei, was bei der Wiederherstellung der Sicherung entscheidend ist. {% endhint %} ### Ordner im Detail {% hint style="info" %} Die folgenden Ordner haben zusätzliche Hinweise: * (b) in Sicherungen 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-Datenverzeichnis 2. `~/redis_data` (b) * Redis-DB-Datenverzeichnis 3. `~/overleaf_data` 1. bin 1. synctex (d) * in der neuesten Version nicht verwendet, zuvor wurde eine benutzerdefinierte synctex-Binärdatei verwendet (synctex wird für das Quell-Mapping zwischen .tex-Dateien und dem PDF verwendet) 2. data 1. Cache (e) * Binärdatei-Cache für Kompilierungen 2. Kompilierungen (e) * hier findet die LaTeX-Kompilierung statt 3. db.sqlite (d) * in der neuesten Version nicht verwendet; früher wurden hier CLSI-Cache-Details gespeichert (entweder in einfache In-Memory-Maps verschoben oder wir durchsuchen 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 für den Client 6. template\_files (b) * Bildvorschauen des Vorlagensystems (nur Server Pro) 7. user\_files (b) * Binärdateien der Projekte 8. history (b) * Dateien der vollständigen Projektchronik 3. tmp 1. dumpFolder (e) * temporäre Dateien aus der Verarbeitung von ZIP-Dateien 2. uploads (e) * Pufferung von Datei-Uploads (Binärdatei-/Neues-Projekt-aus-ZIP-Upload) 3. projectHistories (e) * temporäre Dateien für Migrationen der vollständigen Projekthistorie --- # 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://overleaf-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.